Skip to main content
gavAI is multi-tenant, which means workspaces share a platform but not a process, a database, or a URL. This page documents the four boundaries that separate them, what enforces each one, and what behavior you can rely on when you put a production app on the platform. By the end you’ll be able to name each layer of isolation and the exact response codes that signal a cross-workspace attempt was blocked. If you’re a security reviewer, the boundaries table is the architectural view. If you’re a developer integrating, the guarantees list is the operational view — these are the behaviors your code can depend on.

​
The four isolation boundaries

Four distinct layers separate one workspace from another. Each layer is sufficient on its own to stop the most common cross-tenant attack; together they implement defense in depth.

​
What you can rely on in practice

These are the guarantees the platform enforces. State them this way: if any one of them ever fails, that’s a security incident.

​
Cross-workspace operations

There is no cross-workspace API. If you operate multiple workspaces — for example, a parent organization with several child orgs — each workspace gets its own credentials and you orchestrate across them at the application layer. A request authenticated to workspace A cannot act on workspace B, regardless of how the token was minted.
This is the design, not a limitation we’ll lift later. Cross-tenant action paths are exactly what the four boundaries above are built to prevent. An “orchestrator” workspace that could reach into child workspaces would collapse the runtime boundary and the credential scoping at the same time.

​
Verifying isolation empirically

You can confirm the isolation properties without inside knowledge of the platform. Issue a token scoped to workspace A. Attempt to call workspace B’s resources. Every such attempt returns a 403 or 404 before any data is read.
The response codes are deterministic, and they’re chosen so neither one leaks information about the target workspace:
A 404 from a cross-tenant probe looks identical to a 404 for a resource that genuinely doesn’t exist. You can’t use the response to enumerate other workspaces or fingerprint their data.

​
Perimeter controls at the runtime edge

Isolation is the inner boundary. Sitting in front of every workspace runtime is a per-tenant edge perimeter that the platform runs before any handler sees a request. These are the controls that shape what an attacker can even attempt before the four boundaries above kick in.

​
Account-level identity policy

Independent of the per-tenant runtime, the control-plane identity service enforces the policies that govern who can mint credentials for a workspace in the first place.

​
The named cross-tenant threats

These are the scenarios the boundaries are designed to stop. They are listed by name so a finding that matches one is unambiguous.

​
Reporting cross-tenant findings

Cross-tenant access — a session authenticated to workspace A successfully reading or writing workspace B’s data — is the highest-severity bucket in the disclosure policy. If you find a path that achieves this, stop immediately and email security@gavai.io. Do not attempt to reproduce it beyond confirming the finding. Do not exfiltrate data from the second workspace. See Reporting vulnerabilities for the full process and response SLAs.

Reporting vulnerabilities

In-scope buckets, response SLA, the 90-day window, and where to send the report.

Scopes and least privilege

How tokens are scoped and how to mint a key that can only do one job.