Data isolation
One customer’s documents never reach another customer’s answers
Every customer’s data is indexed separately. Not filtered at query time — separated at the source.
The distinction that matters
Most RAG systems pool and filter. We don’t.
Pool and filter
Everything in one index. A metadata filter decides what each customer may see, applied at query time, on every query.
A bug in the filter is a data breach.
Separate at the source
One index per customer. A query runs against that customer’s index and nothing else — the other customers’ content was never a candidate.
There is no filter to have a bug.
Two customers, one platform, no overlap.
Under 50agents.com, customer #12 uploads their refund policy and customer #47 uploads theirs. Each question runs against one index. Customer #47’s policy is not ranked lower for customer #12 — it is not in the search at all.
Plain answers
The questions people actually ask.
Can one customer’s documents show up in another’s search?
No. Retrieval targets the index resolved from the session’s user_id. Another customer’s chunks live in a different index and are never scored against the query.
What if the filter has a bug?
There is no filter. Separation happens when the document is indexed, not when the query runs, so there is no query-time rule that could be written wrongly and expose the wrong rows.
What happens when a customer deletes a document?
The document and its chunks are removed from the index. Retrieval stops returning it immediately, including for runs already in flight.
What happens when a customer leaves?
Their index and their stored documents are deleted. Their content is exportable beforehand if they want to take it with them.
Who at GTWY can read the documents?
Access is limited to named operations staff, requires a logged reason, and is auditable. The current list is documented for your security team during review rather than asserted on this page.
Where is the data stored?
Storage region is selectable per platform account. Confirm the currently available regions with us during review.
For your engineers
Technical detail.
Index architecture
Each of your customers gets a dedicated index namespace created on first ingest. Documents, chunks and vectors are written to it and to nothing else; there is no shared collection holding multiple customers’ content.
Embedding storage
Vectors are stored alongside their source chunk and document reference inside that customer’s index, so a retrieval result can always be traced back to the document it came from.
Token scoping for the upload UI
The upload embed runs on the same signed token as the agent embed, carrying one user_id. It can list, add and delete documents for that customer and has no route to any other customer’s index.
Query scoping
The index targeted by a query is resolved server-side from the verified token, never from a parameter the client supplies. A request naming a different customer is rejected, not re-scoped.
Encryption at rest and in transit
TLS in transit; encryption at rest for stored documents, extracted text and vectors. Key management detail is in the security whitepaper.
Retention and deletion
Retention windows are configurable per platform account. Deleting a customer removes their documents, extracted text, vectors and index within the documented window.
Access controls
Operations access is role-gated, reason-logged and auditable. Your platform’s own staff reach customer content only through the interfaces you build on the usage and document APIs.
Compliance
Documents your security team will ask for.
Your embedding provider processes your customers’ documents, so it is named on the subprocessor list alongside everyone else in the path.