Egress control
Who this is for.
Who this is for. Three readers, and every section is written for at least one of them:
| you are | read |
|---|---|
| a manager or a buyer | the box below, then §1 and §2. Two minutes. |
| a DevOps engineer | §3, §4 and §6 — how it works, how a policy is written, and what to do when something is refused. |
| a security officer | §5, §7 and §9 — the exact shape of the boundary, what lands in the audit record, and what this control does not cover. |
Read this before anything else
Egress control is READY in this release, and it is OPT-IN PER RUN. The part that judges a destination, the policy document you author, the per-run socket, the door on it, the confinement that binds a run to that door, the network cut that makes the door the only way out, the far (ssh) lane's own door, and the console page that edits the document — all of it is in this build, and all of it is reached by production code. A run started with
saphan run --egress-policyis governed by all of it. §4.7 is the numbered ceremony for turning it on, and §6.6 is what to do when it refuses.⚠ A run that does not pass that flag is governed by NONE of it, and that is every run in this fleet today. There is no fleet-wide setting that turns the wall on: the posture is decided per dispatch, by whoever composes it. Switching the default is an owner's act and has not been taken. ⇒ So the operative sentence for your own network boundary is unchanged: until every dispatch asks for it, you must still own egress at your firewall, your security group, your network ACL. ⛔ Read the two paragraphs as ONE fact. Available and on by default are different words, and this document will not spend the second on the first.
**THIS BANNER OPENED "Network egress is not restricted in this release — nothing in this product currently stands between a run and the network" The second half was already false when it was written: since 2026-08-30 the product stands between a doored run and the network, and the product walls the rest of the road off. What the retired wording got RIGHT is carried whole in the paragraph above — the wall is per-run and nobody is compelled to ask — because a ruling that a mechanism EXISTS cannot make a sentence about DEFAULTS true, and deleting a true operational caveat to satisfy a ruling about existence is the one way this edit could have gone wrong.
What is still open, named rather than implied — read this as the shape of the gap, never as a promise that any of it will be built.
- No policy DERIVATION. No seat and no machine carries a policy of its own, so a run either names the ONE shared document or is judged by nothing (§4.5, and §8's effective policy row).
- No per-judgement record is written. The row shape, the table and its reader all ship and nothing wires them, so a governed run's decisions are not on any surface you can query afterwards (§7, and §8's audit record row).
- No
saphan-egressdaemon, and no transport for the HTTP-styleCONNECTdoor — the second is a deliberate absence, not an unwritten task (§8).- A far Linux host is refused, not governed. This build emits no network lever there, so a policy-carrying spawn onto one is refused by name rather than run unwalled (§9B.3).
This document says governed of a run that asked for it. It will say enforces of your fleet when a run that bypasses the proxy is refused at the network layer without having to ask, and not one release before.
The chapters of this document
This section is one page per chapter, in the order the product itself uses. The list below, and this paragraph, are written for this site; everything above and every chapter page is the engine's text.
- 1. What this protects you from — An agent that can only write inside its own working directory can still read the machine it runs on, and can still connect anywhere.
- 2. Where this stands today — THREE STATES, and a security reviewer must not collapse them into two
- 3. How it works — The default is not "an empty allowlist".
- 4. Writing a policy — ⚠ The policy document is BUILT AND LIVE (§2's three states, §8's row) — a run that passes --egress-policy is judged by the file this section teaches you to write
- 5. What no policy can open — Some destinations are refused no matter what any policy says.
- 6. When a connection is refused — You cannot diagnose any of this from the client.
- 7. What lands in the audit record — ⚠ The record surface is BUILT, NOT WIRED (§8) — the row, the store and the table all ship; nothing constructs the store, so no judgement is ever written down
- 8. What is not built, what is built and unreached, and what unblocks each — The three states are defined ONCE — in §2's legend table — and this table uses no others (NOT BUILT · BUILT, NOT WIRED · BUILT AND LIVE).
- 9A. Advanced: where the door lives, and why it could not live anywhere obvious — For a security reviewer.
- 9B. The remote (ssh) lane: a door on the far host, or a refusal — Everything in §9A describes a door served by the engine on the dispatcher, for a child on the same machine.
- 10. Where this sits with the other documents
- 9. Limits and known gaps — The section a security officer should turn to first.
How to read a provenance line
Sandboxing: which agent is confined, where, and how we know
The confinement each agent gets per platform, what it costs, what it does not cover, and how each cell was measured.
What this protects you from
An agent that can only write inside its own working directory can still read the machine it runs on, and can still connect anywhere.