Data isolation
Every customer gets their own private space
Their agents, their data, their history. Invisible to everyone else — including you.
One account. Four hundred private spaces.
ViaSocket is one GTWY account with 400+ of their own customers underneath it. Customer #12 and customer #47 share infrastructure and can never see each other — not their agents, not their documents, not their run history.
Plain answers
The questions people actually ask.
Can one customer see another’s data?
No. Agents, documents, keys and run history are stored against a single customer and every read is scoped to the token that made it. A token belonging to customer A resolves to customer A or it fails — there is no query path that returns another customer’s rows.
What happens when a customer leaves?
Their data goes with them. Their agent configurations and knowledge sources are exportable, and deletion removes the documents, embeddings and run history for that customer.
Can I see how much each customer is using?
Yes — that is the usage API, and it is how you bill them. Ask how many runs customer #4127 used last month and you get a number back, not a log file to parse.
What if someone steals a token?
It only works for that one customer’s space, and only until it expires. It cannot be replayed against another customer’s ID, and it carries no ability to mint further tokens.
Can our customers post their agents publicly?
No. Embedded accounts have no publish capability at all — it is enforced by account type, not by a setting somebody could switch on. Your users cannot be pulled into a public GTWY community, because the capability does not exist on their account.
For your engineers
Technical detail.
The same content as the tenant isolation fact sheet, written for the person who has to review it.
Storage isolation model
Every agent, document, embedding and run record carries a tenant identifier assigned at write time from the authenticated token, never from client input. Reads are filtered on that identifier before any application logic runs.
Token generation, scoping, validation and expiry
You sign tokens on your own backend with the JWT secret we share after configuration, carrying exactly one user_id and a short expiry. The embed exchanges the token for a session; the signature is verified and the identity resolved on every request, never taken from client-supplied input.
Replay behaviour across tenant IDs
A token whose signature does not verify, or which is presented against a different user_id, is rejected rather than downgraded. Re-presentation after expiry fails closed.
Usage attribution
Runs are attributed at execution time to the user_id on the session, including tool calls and knowledge lookups made inside it. Cost is returned with the run and totalled by the usage API from the same attribution.
Who at GTWY can access tenant data
Access is limited to named operations staff, requires a logged reason, and is auditable. Document the current list with your security team during review rather than relying on this page.
Encryption at rest and in transit
TLS in transit; encryption at rest on stored documents, embeddings and run records. Key management details are covered in the security whitepaper.
Data retention and deletion
Retention windows are configurable per platform account. Deletion of a customer removes their documents, embeddings and run history within the documented window.
Data residency
Storage region selection — confirm the currently available regions with us during review.
Compliance
Documents your security team will ask for.
Everything here is a document you can read before you sign anything.