Execution Isolation and Network Egress
Bounding what a compromised agent runtime can reach, and enumerating every outbound path.
Objective
Bound what a compromised agent process can reach at the infrastructure layer.
Minimum bar (L2). Agents execute in isolated, non-privileged runtimes with no host filesystem and no host network access.
9.1 Controls #
| ID | Control | Minimum bar (L2) | Enforced state (L3) |
|---|---|---|---|
| ISO-1 | Enumerated egress paths | A documented list of permitted outbound destinations for every agent runtime, default-deny for everything else, with an explicit allowlist as the only route in. Each entry names the business reason it exists and the owner of the software terminating that path. | Enumerated, owned, and monitored egress paths. Every outbound route—package proxies, artifact caches, telemetry endpoints, DNS resolvers, model API endpoints—is inventoried with a named owner and a patch cadence matching production applications. |
| ISO-2 | Egress segmented by trust tier | Agents that process untrusted input—external retrieval, inbound email, web browsing, customer-supplied documents—run in a network segment distinct from agents holding privileged credentials. The separation is written into network policy and verified in the running environment at deployment. | Egress domains segmented by trust tier. Agents processing untrusted input do not share an outbound path with agents holding privileged credentials. |
| ISO-3 | Ephemeral runtimes | Agent execution contexts are rebuilt from a known-good image on a defined cadence rather than persisting indefinitely, and no agent writes to a shared filesystem that survives its task. State that must persist is externalized to a governed store with its own access controls. | Ephemeral runtimes destroyed after task completion; no persistence between tasks unless explicitly authorized. |
| ISO-4 | Internal package mirror | Package and dependency installation flows through an internal mirror or proxy rather than directly to public registries. That mirror is inventoried as a production asset with a named owner and is patched on the production cadence, not a best-effort one. | Package and dependency installation from an internal mirror that is itself treated as a production security boundary, subject to vulnerability management, monitoring, and—critically—the assumption that it is a target. |
| ISO-5 | Egress anomaly monitoring | Egress from agent runtimes is logged with destination, volume, and timestamp, and reviewed against a documented baseline on a defined schedule. Alerting exists for previously unseen destinations even where automated blocking does not. | Egress volume and destination-diversity monitoring, with automated blocking on anomaly. |
9.2 Evidence to Request #
- The egress inventory with owners and last-patched dates.
- Network policy for a representative agent runtime.
- Evidence that the package proxy or artifact cache is in the same vulnerability management program as production applications.
9.3 Failure Modes #
- One permitted egress path, running third-party infrastructure software, unreviewed because it is “just a cache.” This is the precise architecture that failed in July 2026: a single package-registry cache proxy carrying an undiscovered vulnerability, which frontier models found and exploited to reach the open internet from an environment believed to be isolated.4
- Isolation asserted in design documents and not verified in the running environment.
- Development, evaluation, and red-team environments given weaker isolation than production, despite frequently running models with safety controls reduced.
References cited in this section
1 of 32 · numbering matches the PDF
- 4"OpenAI and Hugging Face Partner to Address Security Incident During Model Evaluation," OpenAI, July 21, 2026.openai.com/index/hugging-face-model-evaluation-security-incident ↗