Most agent governance focuses on what an agent may do. Egress controls focus on where the results of that work may go. An agent with modest permissions and an open network path can still send the wrong data to the wrong place, and it can do so quietly, inside a run that otherwise looks successful. The control that prevents this is not a warning inside the agent. It is a bound on the plan the agent runs under: which domains it may reach, how much it may transfer, which data classes may leave at all, and what happens — by default, without exception — when a destination is not on the list.
The Governed Agent Mesh Playbook treats egress as one of the bounds that make a unit of work a plan at all. A plan states its egress as allowed domains and a maximum transfer size, alongside its storage scope, data class, time window, cost ceiling, and expiry. Builders on Hacker News have framed the underlying question as who can use which agent and what each agent can access. Egress is the outbound half of that question: not just what the agent can read, but where what it read can be sent. This checklist turns that bound into nine checkable controls.
The checklist¶
- Start from default-deny. No outbound traffic leaves under a plan unless the plan explicitly allows the destination. This is the same posture the Playbook takes toward identity and grants: an unrecorded actor is rejected at the dispatch path, and a capability with no grant does not run. Egress deserves the same treatment. When required evidence is missing — identity, grant, approval, budget headroom, or, here, an egress bound naming the destination — the action is blocked. It is never degraded to a warning, and it is never allowed through "just this once" on the agent's own judgement.
- Give every plan its own domain allowlist. The allowlist belongs to the plan, not to the agent fleet, because the destination a workload legitimately needs is a property of that workload. The Playbook's example plan allows exactly two competitor domains — competitor-a.com and competitor-b.com — and nothing else. A research plan's destinations are not a support plan's destinations. Write the list the way agents actually invoke destinations: the real domains the workload calls, not a category like "the internet" or "APIs." If a domain is not named in the plan that is running, it does not exist as far as that run is concerned.
- Cap transfers per plan, and count in real time. An allowlist decides where data may go; a cap decides how much. The example plan pairs its two domains with a maximum of 50 MB of egress. Count transfers against the cap as they happen, the same way spend is counted against a plan's cost ceiling in real time. When the cap is reached, the transfer fails closed: it is blocked, recorded as blocked, and never retried automatically. A cap that only alerts is information, not a control — the runaway loop that cost one developer $700 in 72 hours was not missing visibility into its spending; it was missing a bound that stopped it.
- Tie egress to data class. Every plan records its data class — public, internal, confidential, or restricted — as the highest class the workload touches, and egress rules follow that class. A plan touching only public data can carry a public destination list. A plan whose workload touches restricted data does not earn a wide egress bound because its earlier steps happened to be harmless: the bound is written for the highest class in the run. If you cannot state which class a workload touches, the egress bound is not ready to be written either, and the plan does not run until both are stated.
- Bound storage alongside egress. What cannot leave immediately can still be staged somewhere unbounded and leave later. The example plan pairs its egress cap with a storage scope and a maximum of 500 MB stored. Treat the storage bound and the egress bound as one decision: the scope names where intermediate artifacts may live, the size names how much may accumulate there, and any movement out of that scope is egress again, judged against the allowlist and the cap. An unbounded staging store next to a tight allowlist is a hole wearing a control's clothing.
- Write an audit row for every egress decision. Every request, approval, block, and outcome writes a row: actor, action, target, outcome, and timestamp, hash-linked to the row before it. For egress, the target is the destination and the outcome is allowed or blocked. A blocked outcome always carries the exact reason — which evidence was missing — so a later review can tell a policy refusal from a malfunction. Rows never contain secrets or credentials; the destination and the decision are evidence, the payload is not. Any synthetic or test rows are labelled "synthetic demo" never mixed silently into real telemetry.
- Never retry a blocked transfer automatically. A retry requires new evidence, not a timer. If a transfer was blocked because the domain was not allowlisted, resending it unchanged asks the same question and must get the same answer. What changes the answer is evidence: an allowlist change, a corrected data class, a grant that now covers the destination. Every block should tell the owner, in plain language, exactly which piece of evidence would unblock it — the destination to add, the cap decision to make, the approval to record. Governance then reads as a to-do list at block time instead of a maze to decode during an incident.
- Hard-gate every allowlist change. Adding a domain, raising a transfer cap, or widening a data class is a permission change, and permission changes are hard-gated in the Playbook: they require a recorded human approval, always, with no auto-grant path. The approver must be a human holding the approver role, and the acting agent can never approve its own change — an agent that could widen its own egress bound would hold the very authority egress controls exist to limit. Each approval is recorded with the approver's identity, the timestamp, the action reference, and the decision, and a denied approval persists as an exact blocked result, never a silent skip.
- Test the negative cases, and re-check the list when the workload changes. Before production, attempt the failures on purpose: a destination that is not on the list, a transfer past the cap, a request under an expired grant. Each must be blocked and recorded. Then keep the list honest over time. Grants in the Playbook are least-privilege records with expiries — no permanent grants, no auto-grant — and an allowlist should age the same way: when a workload changes, its destinations are reviewed, domains it no longer calls come off the list, and every change goes through the same hard gate as the original addition. Drift is a permission change that never asked permission.
What breaks without egress controls¶
Each missing control fails quietly. Without default-deny, the first unlisted destination an agent tries is the moment you learn the path was open. Without a per-plan list, one workload's legitimate integration becomes every workload's reachable destination. Without a cap, a looping or retrying agent can move data at machine speed for as long as the run lasts. Without the audit rows, none of this is even reconstructable afterwards: you would have outcomes with no record of which destinations were reached, allowed by whom, or blocked for what. The system keeps working, right up until the run where something leaves that should never have been able to.
Before you call it governed¶
Governed does not mean the agent is well behaved. It means its outbound world is stated, bounded, and evidenced: a named allowlist per plan, a transfer cap counted in real time, data-class rules that follow the highest class touched, a storage bound that closes the staging hole, hash-linked rows for every decision, and hard-gated human approval for any change to any of it. State the bounds before the run — if you cannot state them, you do not have a plan yet.
Put this into practice¶
The egress bound is one line in a larger discipline. The Governed Agent Mesh Playbook — Studio Edition (https://ghostcorpnet.gumroad.com/l/hdigmr) gives you the working documents behind this checklist: the plan-bound schema that makes egress, storage, cost ceiling, and expiry required fields, the audit-row schema those decisions are recorded in, the six adopt-as-is policies covering identity, grants, hard gates, spend limits, fail-closed blocks, and retention, the risk-tier worksheet, and the 14-day rollout that installs them in order. Write the bound once, as a plan — then every run inherits it, and every exception has to ask a human first.