Testing an agent’s network-egress boundary

An agent with outbound HTTPS can publish code, call a webhook, upload a document, resolve a redirect or connect to a command channel. Port 443 says almost nothing about whether the communication belongs to the task. If the agent also reads sensitive data or hostile web content, broad egress turns a model error into a data-release path.

An egress boundary should be designed and tested as a policy decision: which workload may send which data, to which destination, over which protocol, for what purpose and under what approval?

Write the expected traffic contract first

Collect traces from representative tasks in a controlled environment, but do not convert every observed destination into an allow rule. Start with the workflow’s intended dependencies: model endpoint, approved search or retrieval service, package mirror, source repository, telemetry endpoint and business APIs. Assign an owner and purpose to each.

Define the contract at application level:

Flow	Destination	Method and payload	Identity	Decision evidence
Model inference	Named regional endpoint	POST, bounded prompt	Workload instance	Model/version, bytes, policy result
Public research	Search proxy	Query only; no private context	Research task	Query provenance and returned URL
Repository fetch	Approved host and repo	Read selected refs	Task mandate	Repo, ref and credential audience
Result delivery	Fixed internal service	Typed result schema	Task mandate	Classification and recipient

Everything else starts denied. A destination without a documented purpose is not “probably telemetry”; it is an unknown path.

Enforce more than IP addresses

IP allowlists age badly behind content-delivery networks and shared cloud services. Domain rules are more expressive but introduce DNS, wildcard and redirect risks. Application-aware proxies can enforce host, TLS identity, method, path, payload size and workload identity. Use the strongest layer the workflow can sustain, and prevent direct network routes around it.

Validate destinations after redirects, not only before the first request. Resolve and connect through the controlled boundary to reduce time-of-check/time-of-use gaps. Block loopback, link-local, private and cloud metadata ranges unless specifically required. Cover IPv4 and IPv6. Restrict raw sockets and alternate protocols so a process cannot replace denied HTTPS with DNS, WebSocket, SSH or another channel.

NIST firewall guidance treats outbound policy as a real part of boundary protection, not only an inbound concern. The technology has changed, but the operational principle remains: define allowed traffic and log policy decisions at the boundary.

Add a data-release decision

An approved destination is not automatically approved for every payload. A source-code host may be valid for cloning and invalid for uploading customer records. A collaboration service may be legitimate yet support attacker-controlled webhooks. MITRE ATT&CK describes exfiltration over common web services precisely because normal services and encrypted connections can conceal harmful transfer.

Before an effectful outbound call, evaluate data classification, destination, task purpose and payload fields. Strip secrets and internal metadata that the receiving service does not need. Cap body size and attachment types. For high-impact releases, bind approval to the exact payload digest and destination so a model cannot change them after review.

Do this in a trusted adapter, not in a prompt. A content classifier may supply a signal, but deterministic rules should protect known secret formats, tenant boundaries and prohibited destinations.

Build a bypass-oriented test plan

Test what a compromised process would try, not only what the client library normally does.

1. Direct path: bypass the proxy by IP, alternate DNS resolver, IPv6 or another interface.
2. Destination confusion: use subdomains, user-info syntax, Unicode lookalikes, trailing dots and alternate ports.
3. Resolution change: alter DNS between validation and connection; test private and metadata addresses.
4. Redirect chain: begin at an allowed host and redirect to a denied one, including scheme changes.
5. Protocol tunnel: try WebSocket, DNS, ICMP, SSH and HTTP CONNECT where relevant.
6. Shared-service exfiltration: post to an attacker-controlled repository, paste, bucket or webhook on an otherwise approved provider.
7. Payload splitting: send small fragments across repeated requests or hide data in headers, query strings and filenames.
8. Failure path: make the gateway or DNS service unavailable and verify the workload does not fail open.

MITRE’s application-layer protocol technique shows why ordinary protocols deserve scrutiny: adversaries use them to blend command and control with expected traffic. Agent tests should include both confidential-data canaries and harmless simulated command responses.

Observe identity, decisions and volume

Log the workload and task identity, resolved destination, TLS identity, protocol, method, byte counts, policy decision and reason. Record enough request context to investigate without copying sensitive prompts and data into a less protected logging system. Correlate the network event with tool-call, authorisation and model-run identifiers.

Baseline by workflow, not by the entire agent fleet. A coding agent downloading dependencies has a different pattern from a support agent sending one response. Alert on first-seen destinations, rejected bypasses, unusual upload-to-download ratios, repeated small transfers and activity after a task is cancelled.

Keep denied events useful. A policy log should identify the requested destination and reason without echoing the prohibited payload or secret-bearing query string. Sample successful high-volume flows carefully enough to investigate them. Test whether responders can move from a network alert to the responsible task, user delegation, retrieved inputs and tool call without granting broad access to content from unrelated tasks.

International event-logging guidance led by ASD’s ACSC and co-authored by NSA and other agencies emphasizes enterprise-wide visibility and useful logging for threat detection. For agents, the missing link is often task context; without it, responders cannot distinguish research traffic from unexplained exfiltration.

Test shutdown and policy change mid-flight

Change the allow policy while a long-running task has open connections. Revoke a workload identity. Disable an external service. Stop the agent with requests queued. Confirm that connection pools, retry workers and child processes do not preserve access after the decision.

The NCSC secure-deployment guidance treats infrastructure security, access controls and protection of models and data as deployment responsibilities. Egress testing belongs in the same release evidence as application behaviour because the effective boundary exists in runtime configuration, not architecture slides.

Set a release criterion that survives change

Require every outbound flow to have a named purpose, owner, enforcing rule and observable test. High-risk workflows should demonstrate that denied destinations and prohibited data cannot leave through direct, redirected, shared-service or alternate-protocol paths. All bypass attempts should produce attributable events, and emergency policy changes should take effect within a measured window.

Re-run tests after network, runtime, DNS, proxy, model endpoint, tool or deployment changes. “The sandbox has internet” is not a design. A defensible agent has only the communications its task requires, with a boundary that can explain and stop each release of data.

Include third-party change in that trigger list. A provider may add new domains, redirects or upload features while the organisation’s configuration remains untouched. Monitor dependency notices and compare observed destinations with the approved contract. When a temporary exception is needed, time-box it, narrow it to one workload and capture the traffic needed to replace the exception with a reviewed rule.

Record the exception’s expiry in enforcement, not only in a ticket, and alert before it becomes an accidental permanent route.

Egress is not a networking footnote to an agent release. It is the point where information becomes an external effect. Trust the boundary only when every permitted route has a purpose, every denied route stays denied under realistic bypasses, and operators can stop the flow when the workflow changes.