Agent security: the whole set
Every control that stands between an agent session and your machine — confinement, tool policy, egress, credentials, and the human gate — and where each one is documented.
An agent that writes code on your infrastructure is a program you did not write, running with your credentials, against your repositories. This page is the whole list of what stands between such a session and the rest of your machine — five controls, each independent, each documented in full where it belongs.
⚠ Read the list as a whole before you read any part of it. Every one of these controls answers a different question, and a deployment that adopts three of the five is not "mostly protected" — it is unprotected along the two axes it skipped.
| the control | the question it answers | where it is documented in full |
|---|---|---|
| Confinement (sandboxing) | what the session may READ and WRITE on the host | Sandboxing: which agent is confined, where, and how we know |
| Tool policy (permission classes) | which COMMANDS the session may run at all | Permission classes |
| Egress | which hosts the session may REACH over the network | Egress — and the policy document itself in Writing a policy |
| Credential isolation | whose keys the session holds, and whose it cannot | Security |
| The human gate | what may be MERGED, and by whom | The shape of work |
What each one does not do
This is the part worth reading twice, because the gaps between these controls are where surprises live.
- Confinement bounds the filesystem, not the network. A confined session with no egress policy still reaches whatever the host can reach. ⇒ Confinement and egress are two controls, and neither implies the other.
- A tool policy bounds which commands start, not what a command then does. ⚠ If a policy admits a shell, everything reachable from a shell is admitted with it — see the warning in Permission classes, which is the single easiest way to write a policy that reads strict and is not.
- Egress governs the connections a policy is given to judge. A run that is handed no policy is judged by none of it — the control is per-run and nothing compels a run to ask for it.
- Credential isolation separates seats, not intentions. A session holds the credential of its own seat; it does not hold another's. What it does with its own is bounded by the three controls above, not by the credential.
- The human gate is the only control that decides whether work LANDS. Everything else bounds what a session may do while working; the gate bounds what survives it. ⇒ No amount of confinement replaces a person deciding.
How this section is ordered
The pages below follow the list above: orientation (what the risk is, and the principles the design answers it with) → the controls, one per page, in the order a session meets them → operating it → reference → and what it does not cover, deliberately last, because the edge of a boundary reads differently once you know what the boundary is.
⚠ Sandboxing and egress sit next to each other on purpose. They are the two controls most often mistaken for one another, and the page between them says so in its own words: confinement governs the filesystem, and it is not egress.
Where to start, by what you are trying to answer
- "Can this agent vendor run on this machine at all?" → Sandboxing, which is a per-platform, per-vendor matrix rather than a claim.
- "How do I stop an agent running a tool I do not want it running?" → Permission classes.
- "How do I stop it calling out?" → Egress.
- "What does my auditor get?" → Audit and compliance.
- "What is actually enforced today, and what is not?" → Security states the boundary as it ships, including what it does not cover.