One Server, Many Teams
One machine with the memory for serious models is usually bought once and shared. This server is built for that: every caller acts inside an OWNER boundary that isolates data automatically, grants narrow what a credential may do, and the pieces that should be shared (the engine, the models, the operator plane) are shared deliberately. This page assembles the whole tenancy picture; the sibling guides own each mechanism's depth.
1The owner boundary#
Every credential resolves to an owner id: each API key carries one, and a provider JWT's
configured claim becomes one under an oidc: prefix (Single Sign-On). The
owner id is the isolation boundary, enforced where data lives rather than in client code:
| Per owner, automatically | Meaning |
|---|---|
| Uploaded files | A file id resolves only for the owner that uploaded it, on every surface that consumes file ids, MCP sessions included |
| Vector stores and their indexed content | Stores list and answer per owner (Responses and Vector Stores) |
| Stored responses and their chains | previous_response_id cannot cross owners |
| Agent memories | Facts written by one owner's conversations are recalled for that owner |
| Jobs | Polling and cancel match the owner that started the job (Errors, Retries, and Jobs) |
Two teams with two keys can share every endpoint all day and never see one byte of each other's data. There is nothing to configure to get this; it is how storage is addressed.
2What you assign deliberately: grants#
Isolation says WHOSE data; grants say WHAT a credential may do. Both attach to keys in the admin console:
- Scope: full, or read-only (safe methods only); provider JWTs mirror this through the read-only scope.
- Tool grants: which server-executed tools one key may use, only ever narrowing the server's own tools policy.
- Search access: which clusters a key may address and which tenants it holds grants in; new keys mint with none, so search reach is always an explicit decision (Access Model).
The pattern that scales: one key (or JWT audience) PER CONSUMING SYSTEM, named for it, with exactly the grants that system needs. The request trail then reads as an attribution ledger for free.
3Search tenancy is its own, richer axis#
Inside the Search engine, tenancy has dedicated machinery: clusters (separate databases), tenants (the grantable unit), and collections, with per-key grants deciding reach, and row-level security on the database tier where the engine supports it. Mapping teams, programs, and datasets onto those nouns is the architecture guide's subject; the short rule is that the tenant is the smallest unit you will ever grant or revoke independently.
4What is shared, on purpose#
- The engine and the models. One model pool serves everyone; capacity under contention is a policy you choose (queue or reject) and size (Inference Capacity). Owners isolate DATA, not throughput: a noisy neighbor is a sizing question, not a leak.
- The operator plane. The admin console is a separate identity domain (password or admin SSO), deliberately not reachable with API credentials; operators see and manage the whole server (Security Model).
- Server-wide policy. The tools catalog, egress mode, retention clocks, and web-area exposure are one configuration; keys narrow within it, never widen past it.
5Patterns that work#
| Situation | Shape |
|---|---|
| A few internal teams, one trusted network | One key per team, tool grants per team's needs, search tenants per team |
| Many services in one product | One key or JWT audience per service; the owner boundary keeps their files, stores, and memories apart even when they share models |
| Departments with hard data separation requirements | Separate search CLUSTERS (separate databases) per department, grants scoped accordingly; the strongest isolation the platform offers short of separate servers |
| Individuals as tenants | API OIDC with a per-user owner claim: every signed-in user is automatically their own tenant, with zero key management |
And the honest boundary: owners share compute, models, and policy, whether that is one machine or a load-balanced fleet: the owner boundary, keys, and grants are domain-wide on a farm too (Scaling Out). Where the requirement is "regulatory separation with independent failure and audit domains", run separate servers or separate fleets; everything below that line, this architecture covers.
6Stated plainly#
- One owner id per credential is the data boundary, enforced in storage on every surface, with nothing to configure.
- Grants (scope, tools, search reach) narrow what a credential may do; mint one credential per consuming system and the audit trail writes itself.
- Compute, models, and policy are shared by design; size for your neighbors and pick your saturation policy.
- Search tenancy adds clusters and tenant grants for the hard cases; separate servers or fleets remain the answer above the hardest line.