Skip to main content
A SaaS platform that lets you build apps for your customers has to decide what isolation between those customers looks like. gavAI’s answer is the strictest available: every workspace gets its own isolated runtime, its own managed Postgres database, its own subdomain, and its own configuration. Nothing is shared between workspaces at the runtime or data layer. By the end of this page you will know what’s isolated, what you can rely on as a result, and how workspace identity shows up in API calls.

​
What “multi-tenant” means here

Most multi-tenant platforms put many tenants in one runtime and one database, separated by a workspace_id column or row-level security. That works, but a single misconfigured query can leak across the boundary. gavAI does the opposite: each tenant gets dedicated infrastructure. A request that lands on acme.gavai.app cannot, by construction, touch any data that doesn’t belong to Acme — because the runtime handling that request has no credentials, no connection string, and no DNS handle for any other tenant. The Acme runtime has Acme’s database connection string and only Acme’s. The Globex runtime has Globex’s. There is no shared data plane that a misconfigured query could traverse.

​
What’s isolated

​
What you can rely on

Tenants cannot cross-tenant read, write, or invoke capabilities against another workspace’s data. The runtime enforces this at the per-tenant boundary — a request arriving at acme.gavai.app can only touch the Acme database, Acme secrets, and Acme configuration.

​
How workspace identity shows up in the API

Every authenticated request operates in the context of one workspace. There are two ways the API knows which one. OAuth session tokens. A gst_… session token is bound to the workspace the user signed into. If you hold a session and need to act on a different workspace, call POST /v1/workspaces/{slug}/switch to re-scope the session. Workspace-scoped API keys. A gak_live_… or gak_test_… key is bound to a single workspace at creation time. Machines and CI pipelines mint a key per workspace; the key cannot accidentally be used against another workspace because the binding is permanent. The shape of the URL reflects the binding too: workspace-scoped endpoints live under /v1/workspaces/{slug}/…, and the slug in the URL must match the workspace the credential is bound to.

​
Where to read more

For the full security architecture — threat model, data handling commitments, penetration-testing posture, incident response — read the security overview. The summary on this page is the what; the security pages are the how and why.