The frontier labs just made agent egress control official

The frontier labs just validated the agent egress vector, in their own docs.

OpenAI's Codex runs its agent phase with internet access blocked by default, behind a domain allowlist. The documentation is blunt about it: "By default, Codex blocks internet access during the agent phase." Turning it on means picking an allowlist, and the reasons given are prompt injection and exfiltration of code or secrets.

Anthropic sandboxes Claude Code behind an egress proxy and states the threat in one sentence: "Without network isolation, a compromised agent could exfiltrate sensitive files like SSH keys." Network access there runs through a proxy outside the sandbox that enforces a per-project domain allowlist.

Google now ships Agent Sandbox on GKE, gVisor kernel isolation for agent code execution, to keep untrusted agent code away from the node.

Read that again. The people who build the agents are telling you where to police them: at egress, on the network. Not payload inspection. Egress.

We love this

This is the right vector, argued by the right people, in primary documentation rather than a vendor deck. Every one of those three controls is a real reduction in risk, and if you run agents you should turn all of them on today.

And here is the part that keeps us up at night anyway.

Look at the shape of the control

Per-agent config, inside each runtime.

Now scale it. Every agent in your fleet needs that control configured, on every host, in every framework, including the agents your agents spawn. The allowlist is a project setting. The sandbox is a pod spec. The default is only a default until someone flips it to ship a build.

One slipped config is all the exfil path needs. Config drift is not a hypothetical, it is Tuesday.

There is a second problem underneath the first. A control that lives inside the agent's own runtime is a control the agent's runtime can lose. It depends on the agent being launched the way you intended, in the framework you audited, by a person who read the docs. Fleets do not work that way. Agents spawn agents, and the child inherits whatever the parent happened to be configured with, which nobody reviewed.

And notice what none of these controls give you: a fleet-wide answer. There is no single place to ask which agents reached which destinations last night, because the policy is scattered across as many places as you have agents.

The wire does not drift

That is exactly why Maya enforces on the wire. The policy lives in the network, not in each agent's settings. Add hosts, add agents, add frameworks: same egress policy, same enforcement, across the whole fleet, whether each agent's own sandbox was configured right or not.

Maya derives per-agent identity from the wire, so the unit of control is the agent rather than the IP address it happens to share with four others. You declare what an agent may reach. Maya observes what it actually reaches. The gap is a deviation, typed and emitted in milliseconds, and enforcement lands in-kernel on the next packet.

None of that requires changing a line of agent code, and none of it requires the agent to cooperate. An agent that declares its own scope is an agent you are trusting to report its own escape.

Two layers, one fleet

The runtime sandbox is a good seatbelt. Wear it. It protects the agent you configured, on the host you configured it on.

The wire is where the fleet gets governed.

We're taking on a small number of design partners running agents in their own cloud. If that's you, we'd like to talk.