Egress control

An agent that can call any tool can, in principle, send data anywhere. The agent runtime closes that risk with egress control: by default a deployed agent has no outbound network access at all, and every external host it may reach must be on its allowlist.

Deny-all by default

Each agent carries its own egress policy, fixed at build time. The default posture is deny-all: no outbound connections except localhost. From there, the platform builds the agent's allowlist from what the agent actually needs:

• Explicit domains you configure for the agent.
• Skill and tool requirements — a skill or tool that declares the API hosts it talks to gets those domains added automatically.
• Platform services — the model gateway, channel platforms (for example Slack), and the platform's own verification endpoints are included so the agent can function.

Allowlist entries match exactly (api.example.com) or by wildcard (*.example.com matches subdomains). Anything not matched is blocked.

Layers of enforcement

The same allowlist is enforced at several levels, so there is no gap between what the agent's code does and what its scripts or subprocesses do:

• In-process enforcement — every HTTP request made by the agent's own tools (such as http_request or web_search) is checked against the allowlist before it leaves the process.
• Subprocess enforcement — skill scripts and approved command-line binaries (for example curl) are routed through a local proxy that applies the same allowlist rules.
• Network-level enforcement — in the agent's deployment environment, a network policy generated from the same allowlist restricts traffic at the infrastructure level, backstopping the in-process controls.

Beyond domain matching, the runtime defends against common bypass techniques: disguised IP address formats are rejected, DNS answers are re-validated before connecting (preventing DNS-rebinding tricks), cloud metadata addresses are always blocked, and credentials are stripped when a request is redirected to a different origin.

What happens on a blocked call

When the agent (or one of its scripts) tries to reach a host that is not allowlisted:

• The request fails immediately with a clear "egress blocked" error naming the domain — the connection is never attempted.
• The agent sees the failure as a tool error and can report it or try a different approach; it cannot retry its way around the policy.
• An egress_blocked audit event is emitted with the blocked domain, and it surfaces in the platform's Security area so operators can see exactly which agent tried to reach what, and when.

Allowed calls are recorded too (as egress_allowed events), giving a complete picture of an agent's outbound behavior.