Who you are
For the security officer
You need the boundary, the assumptions behind it, and the hardening you own.
| Who this is for | You are the person who signs off on the boundary and owns what sits outside it. |
| What you need | The deployment's architecture and an appetite for reading assumptions. |
Your first task: read what the product declines to claim. A security document's limits page tells you more about it than its claims do, and it is the fastest way to decide whether the rest is worth your time.
Read these first, in this order
The security section is published. These five pages are the ones written for your seat, and the order is the one the source documents themselves recommend for a security officer.
| Go here | Because |
|---|---|
| What the risk actually is | Why an agent fleet is not a CI pipeline, in three differences. Two minutes, and everything else assumes it. |
| Seats: separating agents that share a machine | The boundary most often mistaken for a stronger one than it is. The page says exactly how hard it is. |
| Runners: what happens during a run | Which operating-system mechanism confines a run, what the record proves about it, and what happens when it cannot be enforced. |
| Egress control | What the product does about a connection leaving a run — including, in its own opening banner, what is opt-in and what is therefore not protecting you today. |
| Documented limits | What the product does not protect against, stated as limits rather than buried in caveats. |
⇒ If you are deciding quickly whether this product is worth your time, read the last row first. What a security document declines to claim tells you more about it than what it claims.
The rest of the boundary
| Go here | Because |
|---|---|
| Authentication and its lifetimes | Credentials, sessions, approval and revocation — including the acts a human must perform. |
| The exposed surface | Ports, files, processes and permissions: everything the installation puts on a host. |
| What crosses the boundary | Every connection to another system, and what each one carries. |
| Evidence | What you can prove after the fact, and from which artefact. |
The limits, and they are the point
- Egress control is opt-in per run. A dispatch that asks for a policy is judged by one and confined to a per-run proxy; a dispatch that does not ask is not. Until every dispatch in your fleet asks, egress control at your network boundary remains yours (where this stands today).
- Confinement is an operating-system mechanism, and not every platform has been measured. Where a guarantee was observed on one platform only, the page names that platform rather than implying the other.
- The seat boundary is weaker than it is often assumed to be, and the page says exactly how weak.
- What the product does not protect against is written as limits rather than buried in caveats: documented limits.