> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Agent isolation & tenancy
> The workspace is the isolation boundary — how a request is bound to exactly one, and how an agent is kept from reaching anything outside it.
Everything in the platform belongs to a workspace, and the workspace is the isolation boundary. This
page explains how a request comes to be scoped to one workspace, why an agent cannot reach outside
its own, and what isolation looks like between two agents inside the same workspace.
## 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 called `triage` 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.
| Mechanism | Effect |
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **One worker, one agent** | A worker process hosts exactly one agent, so two agents never share a process. |
| **Its own credential** | A worker's token resolves that agent and that workspace, so it cannot act as another agent even inside the same workspace. |
| **Its own roles** | An agent holds its own [permissions](/security-and-governance/identity-and-access/roles-permissions), and reaches only the resources they cover. |
| **Its own credential bindings** | A stored [credential](/security-and-governance/architecture-considerations/secrets-credential-handling) is bound to the agents allowed to use it, so access to a secret does not follow from being in the workspace. |
| **Label-scoped grants** | Labels let you separate agents by team or environment without splitting the workspace. |
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
How a secret reaches one run and nothing else.
What an agent can see, and what is masked.
The credential that establishes which agent is acting.
What leaves your environment, and what cannot reach in.
## Related topics
- [Architecture](/get-started/architecture.md)
- [Data handling & redaction](/security-and-governance/architecture-considerations/data-handling-redaction.md)
- [Deployment methods](/get-started/deployment-methods.md)
- [Agent identity](/security-and-governance/identity-and-access/agent-identity.md)
- [Admin Console](/security-and-governance/controls/admin-console.md)