One request, one workspace
Every authenticated request resolves to an identity in exactly one workspace before anything else happens, and that binding is what every subsequent read and write is scoped by. There is no cross-workspace mode and no way to ask for one: an agent, run, credential, knowledge base, or channel in one workspace is not visible from another. The same is true of the things agents produce. Run records, evidence, and knowledge are all workspace-scoped, so no agent can retrieve another workspace’s data — which is the property that matters most once agents are searching history to do their work.How ownership is established
Two design choices are worth knowing, because they are what stop ownership being something a caller can influence:- A run’s workspace comes from the agent, not from the caller. Whoever invokes an agent cannot set, forge, or omit the workspace a run belongs to — it is derived from the agent being invoked.
- Child records inherit ownership from their parent in the same transaction that creates them, so a run’s events, evidence, and outputs are owned by construction rather than by a later attribution step.
Names are per workspace
Friendly names — an agent’s slug, a credential’s name — are unique inside a workspace rather than globally. Two teams can each run an agent calledtriage and each store a credential called
github with no collision, and neither can discover that the other’s exists by trying the name.
Underneath, each agent has a stable opaque identity. That is what the platform attributes work to
and enforces isolation with, which is why a friendly name being reused elsewhere changes nothing.
Isolation between agents
Inside one workspace, agents are separated by identity and permission rather than by a boundary you configure.An agent is not privileged by being in the same workspace as a privileged one, so granting one agent
production access does not widen what any other agent can reach. What that grant is worth on its own
still depends entirely on the permissions behind it.
Revocation
Because identity is carried by a credential rather than by configuration, removing access is immediate and needs no redeploy. Revoking a worker token stops it authenticating — it does not terminate the deployed worker process. Removing a credential binding prevents further authorized retrieval; a value already loaded into a running process needs separate handling, including provider-side revocation where that matters. Suspending a member stops their sessions and keys authenticating.Next steps
Secrets & credential handling
How a secret reaches one run and nothing else.
Data handling & redaction
What an agent can see, and what is masked.
Agent identity
The credential that establishes which agent is acting.
Network & egress control
What leaves your environment, and what cannot reach in.