Agent Executor Egress-Containment Lab
An AI agent runs model-generated code in an executor, and that executor keeps reaching out — to documentation, to an unknown domain, to the cloud metadata endpoint (169.254.169.254), to an internal service, to a package registry, to a paste site, to the model-provider API, and — during a scored run — to the benchmark rubric host. For each, decide the egress call, the risk, and the control that fits — because default-deny is not deny-everything, link-local metadata is always off-limits, and a legitimate provider call should still go through a logging proxy. Motivated by Google Research's Harness² (arXiv 2610.14224), grounded in SSRF and cloud-metadata defence, with no invented CVEs.
The real job. More noise, a tighter clock.
Executor egress log
1 / 9 triaged
GET https://docs.python.org/3/library/asyncio.html
The agent is reading language documentation it was told to consult while writing code.
1 · Egress decision
2 · Risk
3 · Containment control
Pick a decision, the risk, and a control to continue.
Destination × risk map
This request: name its risk and where it lands by destination.
Triage
A stream of outbound requests and runtime behaviours from an agent's code executor. For each of 9, decide the egress decision (allow / proxy+log / deny), the risk, and the containment control that fits.
So far: 0 / 9 requests triaged.
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based triage lab: work a stream of outbound requests and runtime behaviours from an AI agent's code executor — fetch a docs page, POST to an unknown domain, read the cloud metadata endpoint (169.254.169.254), reach an internal service, download and run a dependency, phone home to a paste site, call the model-provider API, reach the benchmark/eval rubric host — and contain each one.
- For every request you pick the EGRESS DECISION (allow / allow via proxy+log / deny), the RISK (benign, data-exfil/C2, SSRF, eval contamination, supply-chain, or credential theft via cloud metadata), and the CONTROL that actually fits.
- The motivation is real and attributed: Google Research's Harness² (arXiv 2610.14224) reports its executor's network access is UNRESTRICTED and that the Codex executor runs with its SANDBOX DISABLED, and warns to restrict the network before evaluation so agents cannot reach benchmark answers / grading rubrics.
- The core skill it drills: default-deny egress with a short allow-list, link-local / cloud-metadata and internal ranges always denied, sandbox the executor before running model-generated code, and block eval/rubric hosts during scoring — while NOT over-blocking the model-provider API, docs and a vetted mirror.
- A live egress log plus a destination × risk map, difficulty tiers, a speed bonus and an S–D grade.
Default-deny is not deny-everything
Most agent-security mistakes sit at one of two extremes. The convenient one is an executor with unrestricted network and the sandbox disabled — which is precisely what Google Research's Harness² (arXiv 2610.14224) reports for its own setup, together with an explicit warning to restrict the network before evaluation so agents cannot reach benchmark answers or grading rubrics. That configuration lets model-generated code read the cloud metadata endpoint for IAM credentials, pivot into internal servicesvia SSRF, exfiltrate context to an attacker host, and quietly inflate its own benchmark score. The other extreme — deny all egress — breaks the agent, because it genuinely needs the model-provider API, documentation and vetted dependencies.
The job is the middle: a default-deny executor with a short, explicit allow-list reached through a logging proxy. The model-provider API, a docs host and a vetted artifact mirror are allowed and audited; everything else — unknown POSTs, paste uploads, arbitrary outbound channels, internal RFC1918 ranges and the link-local metadata service — simply has nowhere to go. Run model-generated code sandboxed, and during scoring block the eval and rubric hosts so the measurement reflects the agent and not retrieved answers. The whole skill of containment is telling the few legitimate destinations apart from the many that should never connect, and spending your allow-list only where the agent truly needs it.
Frequently asked questions
What does the Agent Executor Egress-Containment Lab teach?
It teaches how to contain the network and runtime of an AI agent's code-execution environment (the "executor"). For each outbound request or runtime behaviour you decide the egress decision (allow, allow via a logging proxy / allow-list, or deny), name the risk, and choose the control that fits. The lab makes the key distinction explicit: a default-deny egress stance is not the same as denying everything — a few destinations like the model-provider API, documentation and a vetted package mirror are legitimate and should be allowed through a proxy, while unknown POSTs, paste uploads, arbitrary outbound channels, internal services and the cloud-metadata endpoint are denied.
Is the "unrestricted executor" scenario based on something real?
Yes. It is attributed to Google Research's Harness² paper (arXiv 2610.14224), which reports that its executor's network access is unrestricted and that the Codex executor runs with its sandbox disabled, and explicitly warns operators to restrict the executor's network access before evaluation so agents cannot reach benchmark answers or grading rubrics. The lab turns that warning into practice: default-deny egress, sandboxing the executor, and blocking the eval/rubric hosts during scoring so a measurement reflects the agent rather than retrieved answers. The lab invents no CVEs and contains no exploit detail.
Why is the cloud metadata endpoint (169.254.169.254) always a deny?
Because the link-local metadata service hands out temporary cloud IAM credentials to anything on the instance that can reach it. A code-execution environment reaching 169.254.169.254 (or a friendly alias like metadata.google.internal, which resolves to the same link-local address) is credential theft waiting to happen. There is no legitimate reason for the executor to call it, so the control is to hard-deny link-local and metadata ranges at the network boundary and give the workload a minimal, scoped identity instead of node-wide credentials. This is standard SSRF / cloud-metadata defence.
Is this a real proxy or does it touch my network?
No. It is an educational, offline triage exercise with a synthetic set of requests. It does not connect to, proxy, or touch any network, and it contains no exploit detail — only the defender decision of egress call, risk and control. It is meant to build the judgement a platform-security or ML-infrastructure owner uses when deciding what an agent's executor may and may not reach.