Egress control

Data theft needs a route out. Restricting reads is hard, because reading is the job. Restricting *sends* is often easy, because the list of places an agent legitimately needs to reach is short: a model provider, a package registry, your own APIs.

Everything else is an allowlist miss, and an allowlist miss is a signal.

Why it is the cheap leg

Of the three legs of the lethal trifecta, untrusted content is usually the point of the task and private access is usually needed to do the work. Egress is the one you can often remove with almost no loss of capability. An agent that reads hostile pages and holds secrets but can only reach three known hosts has been reduced from a theft risk to a bad-answer risk.

What counts as egress

More than obvious HTTP requests, and this is where it gets missed:

• HTTP from tools, including ones you did not think of as network tools.
• DNS. A hostname lookup carries data in the name itself. Restricting HTTP while leaving DNS open leaves a channel open.
• Git push. A commit to a remote is an outbound transfer.
• Anything that sends messages: email, Slack, webhooks, issue comments.
• Rendered output. A generated image URL or link that a client will fetch turns your viewer into the sender.

Practical shapes

• Allowlist by hostname at the sandbox or proxy layer. Default deny.
• Route through a proxy you log. The log is as valuable as the block, because it tells you what the agent tried.
• No egress at all for tasks that do not need it, which is more tasks than people expect: analysis, review, refactoring in a local checkout.

Honest limits

Egress control is partial. An agent that can commit code can exfiltrate through the commit. One that can open a PR can write data into the description. Wherever the agent produces output a human or system will read, there is a channel, so treat egress control as raising the cost rather than closing the door.