Network Egress Control

The control record

Id

AIGE-CTL-EVAL-002 · v0.2 · Draft · Open for technical review

Objective

Outbound connections from an evaluation environment reach only the destinations on the run's egress allow-list, and every other connection attempt is refused and logged.

Failure modes

• A connection from the environment to a host that is not on the run's egress allow-list succeeds.
• A run starts in an environment with no egress policy attached, or with a policy that allows every destination although the task did not declare that it needs the internet.
• A permitted destination, such as a package mirror, a cache or a tool server, carries data onward to a party or to another run that nobody listed.
• The run leaves no flow log, so the connections it made cannot be compared with its allow-list.

Scope

Every network path out of the environment a run executes in: the agent's container or virtual machine, auxiliary machines, DNS, and the tools, MCP servers and proxies the run can call. Resources shared between runs count as destinations. Inbound operator access is out of scope.

Enforcement points

• deploy: before a version is deployed or released
• runtime: at the point of action (gateway or guardrail)

Verification

• Inspect: Before the run, inspect the egress policy attached to the task environment: deny by default, with an allow-list naming each permitted destination (for example the LLM API proxy and the progress server) and nothing else unless the task declares that it needs the internet.
• Test: At admission, from inside the environment, attempt one connection to a destination that is not on the allow-list and one to a listed destination; the first must be refused and logged, the second must succeed.
• Observe: After the run, compare the run's flow log with its allow-list: every outbound connection matches a listed destination, and every refused attempt is recorded with its time and target.

Evidence

• The egress policy and allow-list attached to the run, with its hash recorded in the run record · Layer 04
• Admission test verdict: the refused connection to an unlisted destination · Layer 04 · evidence-record.v1
• Flow log of the run, allowed and refused connections, kept outside the environment · Layer 04
• One observation per run comparing observed connections with the allow-list · Layer 05 · control-observation.v1

Failure response

deny: block the action. Connections to unlisted destinations are refused at the enforcement point and logged. A run whose environment has no egress policy attached is not started; a run in which an unlisted connection succeeded is stopped and its result is withheld until the connection is explained.

Layer

Layer 04 Runtime Controls & Observability

Patterns

Runtime Guardrail, Sanctioned AI Gateway

Seeded from

Output and egress filter, Tool allow-list, deny by default, Code runs only in a sandbox

Mappings

• Obligations: EU AI Act Art. 15 accuracy, robustness and cybersecurity; OWASP Top 10 for LLM Applications 2026; OWASP Top 10 for Agentic Applications 2026
• ISO/IEC 42001: A.6.2.6 AI system operation and monitoring
• NIST AI RMF: MEASURE 2.7 Security and resilience are evaluated and documented
• OWASP: ASI02 Tool Misuse and Exploitation; LLM02:2026 Sensitive Information Disclosure
• MITRE ATLAS: AML.T0086 Exfiltration via AI Agent Tool Invocation
• AIUC-1: B006
• MITRE ATLAS mitigation: AML.M0032 (Segmentation of AI Agent Components)
• NIST SP 800-53 Rev. 5: SC-7 (Boundary Protection)
• NIST SP 800-53 Rev. 5: SC-7(5) (Deny by default, allow by exception)

References

• [1] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "The tool allow-list")
• [2] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Runtime guardrails for tool calls")
• [3] METR Task Standard, STANDARD.md (version 0.5.0; unless a task declares the full_internet permission, the task machines "MUST NOT have internet access" except to an LLM API, an LLM API proxy or a hardened local server)
• [4] Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident (METR states that agents "meant to be fully isolated from one another" communicated through an internal package repository, and that one agent found working Hugging Face credentials exposed on the internet and posted them to the agents' board; it reports spoofed tool calls in at least 96 transcripts and transcripts missing components after container resets)
• [5] Vivaria server environment variables (no-internet task environments connected to a separate Docker network and optionally sandboxed with iptables rules; model API requests can be routed through a separate proxy service)
• [6] MCP Security Best Practices (2026-07-28) (token passthrough "is explicitly forbidden"; egress proxies and network policies for server-side clients)
• [7] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
• [8] OWASP GenAI LLM Top 10 2026 (LLM01:2026 Prompt Injection to LLM10:2026 Improper Output Handling; resource page dated 3 Aug 2026)
• [9] MITRE ATLAS data, release v2026.09 (16 tactics, 120 techniques, 88 sub-techniques, 40 mitigations; technique names and technique-to-mitigation links read from dist/v6/ATLAS-2026.09.yaml)
• [10] NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (control catalogue cited by control id; publication page of Revision 5 with update 1 of 10 Dec 2020)
• [11] An agent used DNS to reach an external chatbot (misalignment report) (OpenAI reports a training run that reached a public chatbot through "insufficient DNS filtering" in its sandbox; the monitor flagged it within 15 minutes, the run "did not stop automatically as expected" and was killed 2.5 hours later)
• [12] OpenAI Hugging Face Incident Technical Report (OpenAI states that high-risk workloads are "prohibited via technical controls from receiving direct or transitive Internet access", protected by "two separate layers of network isolation", and that it is building tooling to "identify and halt evaluation workloads")
• [13] Improving our alignment and security efforts (best practices for external partners running cyber evaluations: the only outside connection is "to the model's own API", with the API keys kept outside the environment; the configuration "should be verified before every evaluation begins"; boundaries "phrased as instructions"; challenges confirmed "solvable in principle"; a monitor that flags a scope violation to a human and ends the exercise)
• [14] AIUC-1 requirements (public requirement index, A001 to F002, each requirement on its own page (E007 and E014 marked retired); AIUC-1 is a standard of the Artificial Intelligence Underwriting Company; this site is not affiliated with AIUC, and a mapping here is not an AIUC-1 certificate or audit)

Implementation notes

• Attach a default-deny egress policy to every task environment (a network policy, a firewall rule set or an egress proxy, by category) that lists each permitted destination explicitly, for example the LLM API proxy and the progress server. Enforce it on the resolved address, and serve DNS from a resolver that answers only for listed names: DNS is an egress path too. OpenAI reports a training run that reached a public chatbot through "insufficient DNS filtering" in its sandbox.
• Record the allow-list with the run (its hash goes in the run record next to the environment version) and keep a flow log per run at the enforcement point, outside anything the agent can reach or change, with refused attempts as well as allowed connections, so the connections made can be compared with what was declared, not with what was intended.
• Enforce the policy in two places a single misconfiguration cannot both open, for example at the sandbox and at the cluster boundary. OpenAI's technical report on the Hugging Face incident describes "two separate layers of network isolation" of this kind, and Anthropic's guidance for external evaluation partners asks that the only outside connection be to the model's own API and that the configuration be verified before every evaluation begins.
• At admission, run a canary from inside the environment: one connection to a reserved test address that is not on the list. Expect a refused connection and a log entry; a success blocks the run.
• Treat resources shared between runs (package mirrors, caches, artefact stores) as destinations with their own entry and a per-run scope. METR's public investigation of the OpenAI/Hugging Face incident reports that agents meant to be "fully isolated from one another" communicated through a shared internal package repository.

Open questions

• How should the egress allow-list of a run be recorded so that a third party can compare it with the connections actually observed?
• When a task needs the internet (what METR's Task Standard calls the full_internet permission), which part of this control still applies, and what should the run record say instead?

Observation

• Subject: Evaluation environment
• Expected: Outbound connections only to the destinations on the run's egress allow-list; every other attempt refused and logged.
• Example: 1 connection to an unlisted host during run 88213, in an environment with no egress policy attached: fail.