AI Agent Egress Control: Signed Receipts at the Network Boundary

A support agent can clear schema checks, run inside a sandbox, and still leak an API key by curling a public host with the secret in the query string. Tool allowlists do not close that path once the agent already has shell or HTTP. You need a network-boundary contract: mediation outside the agent process, default-deny destinations, inspection of the bytes that cross, and signed action receipts a third party can verify offline.

It sits beside preventing SSRF in AI agent HTTP tools (fetch-broker address, DNS, and redirect checks), sandboxing AI agent tool execution (disposable cells and denied-by-default networking inside the runtime), securing MCP servers for internal AI workflows (server trust and metadata consent), validating AI agent tool calls before execution (schema, identity, authorization), binding human approval to exact AI agent actions (the approval artifact), and propagating tool-output taint before privileged AI agent actions (provenance after a result returns). The job here is narrower: decide whether bytes may leave the host, and keep evidence the agent cannot rewrite.

Why in-process network trust fails

OWASP LLM06:2025 Excessive Agency covers what happens when agents get more functionality, permissions, or autonomy than the job needs. Triggers include hallucination, direct and indirect prompt injection, and compromised extensions. The mitigations start with fewer extensions, least privilege, complete mediation in downstream systems, logging, and rate limits - not another prompt that begs the model to behave.

Twilio's Rogue Agents guidance states the mindset cleanly: treat the LLM like an untrusted browser or mobile client. You would not put production SMS or checkout keys in front of a browser. The same rule applies when the caller is a model loop that an email body or a poisoned tool result can steer. Validation, authorization, rate limits, and least privilege belong in a gate the model does not own.

Many internal platforms stop at an in-process allowlist library, a sandbox network namespace, or logs written by the agent sidecar. Those pieces still help. They leave a hole when a prompt-injected agent can unset HTTP_PROXY, open a raw socket, or edit its own audit file. The network decision and the proof of that decision have to live outside the trust boundary the agent can reach.

The property pair: mediation plus receipts

PipeLab's definition of verifiable egress control frames the category as a property pair:

1. Binary-enforced mediation at the network boundary. Enforcement runs in a process outside the agent trust boundary. The agent has no access to the enforcement code, no access to the signing key, and no bypass that does not require breaking deployment containment.
2. Signed action receipts for every adjudicated action. Each allow, block, warn, ask, strip, forward, or redirect produces a signed record. Records chain by hash. A relying party verifies offline against a pinned public key with open-source verifier code.

Property 1 without property 2 is a sandbox or firewall. Property 2 without property 1 is a logging tool. Procurement and audit teams already treat those artifacts differently. "Trust our dashboard" is not the same ask as "verify this bundle on a laptop."

Place mediation outside the agent trust boundary; an in-process allowlist the agent can disable is not egress control. That is the first operating rule. If the agent can turn the control off, you have a suggestion, not a boundary.

Default-deny destinations and agent profiles

Start with deny. Publish the hosts, methods, and path prefixes each agent may reach for its job, and give each agent an explicit profile when several share infrastructure. A support summarizer may reach the ticket API and the LLM gateway. It must not reach cloud metadata, arbitrary customer domains, or your secrets manager unless that is a separate, narrowly scoped tool with its own identity.

Open Agent Guard documents the portable shape many teams land on: an HTTP/HTTPS forward proxy with deny-before-allow evaluation, host/method/path/IP matching, per-agent rate limits and body caps, content inspection, and structured audit events. OAG also states that it is not a sandbox and does not own the compute plane. Keep that split. The sandbox owns the cell. The egress mediator owns what leaves the host.

Profile fields that survive a design review:

• agent_id and workload identity (service account, SPIFFE ID, or equivalent)
• allowed destinations and transports (HTTPS, MCP upstreams, WebSocket)
• max body size, requests per minute, and data budget per session
• whether TLS interception is required for DLP on CONNECT tunnels
• who may approve an emergency allow, and how that approval expires

Set HTTP_PROXY / HTTPS_PROXY only after the deployment also blocks direct egress. Otherwise the first non-cooperative tool or curl --noproxy '*' walks around the contract.

Inspect the bytes, not only the hostname

Destination allowlists catch many accidents. They do not stop a secret leaving through an allowed host. Content-aware inspection on the mediated path is the second floor:

• DLP patterns for API keys, tokens, private keys, and common cloud credentials in URLs, headers, and bodies
• SSRF floors for private ranges, link-local, and cloud metadata even when a hostname looks public
• Prompt-injection and tool-poisoning scans on MCP responses and tool descriptions before they re-enter the model
• Redirect re-evaluation so an allowlisted host cannot hop to a blocked address

Pipelock runs that ordered scanner pipeline for mediated HTTP, WebSocket, MCP, and A2A traffic, emits Ed25519-signed action receipts, and states the honesty note every design review needs: direct egress still has to be blocked by OS or cluster containment for tools that ignore proxy settings. A green "proxy configured" checkbox is incomplete without a test that non-proxy paths fail.

Fail closed when the agent can reach the internet without the mediator; HTTP_PROXY alone is not containment. Pair the proxy with network policy, nftables/iptables owner-match, Landlock/netns sandboxes, or an equivalent host/cluster topology that makes the mediator unavoidable.

Signed receipts auditors can verify offline

Require signed action receipts for allow and block decisions; mutable agent logs are not auditor-grade evidence. Keep the receipt small:

{
  "receipt_id": "ar_7c91e2",
  "ts": "2026-09-28T00:14:02+03:00",
  "agent_id": "support-summarizer",
  "transport": "https_connect",
  "destination": "api.tickets.example",
  "method": "GET",
  "verdict": "block",
  "reason_codes": ["dlp.aws_access_key_id", "exfil.query_param"],
  "policy_hash": "sha256:4b1e...",
  "prev_receipt_hash": "sha256:91aa...",
  "mediator_key_id": "egk_2026_09",
  "signature": "ed25519:..."
}

Keep the signing private key only in the mediator zone. Publish the public key to auditors and CI. Verify with an offline tool that exits non-zero on tamper, missing chain links, or an unpinned key. Hash-chain the receipts so deleting a block event shows up. If you later anchor checkpoints to a transparency log, say what that proves: operator-held keys prove the boundary's decision and signature, not that the operator is honest without external anchoring.

Blocks need receipts as much as allows. "We blocked the exfil" without a signed record is a story. "Here is the verified bundle" is evidence.

Worked example: support agent with a poisoned ticket

1. The agent reads a ticket that tells it to "verify connectivity" by fetching a collector URL that embeds the provider API key in a query parameter.
2. Tool validation accepts a well-typed http_get call. The sandbox allows outbound HTTPS to public destinations for this profile.
3. Without egress control, the secret leaves in the query string. Application logs may omit the URL. The agent process can omit it on purpose.
4. With the contract, the mediator sits outside the agent. Default-deny rejects hooks.example, or DLP catches the key pattern on an allowlisted host. Verdict block. A signed receipt records destination, reason codes, and policy hash.
5. Direct-egress tests from the agent network namespace fail closed. CI verifies the receipt chain against the pinned public key before the incident review closes.

The same pattern covers MCP. Wrap upstreams so tool responses and tools/list descriptions are scanned before the model sees them, and emit receipts for mediated MCP actions too. Server allowlisting from the MCP security guide remains necessary. It is not a substitute for the network boundary.

How this contract fits the rest of the stack

Keep adjacent controls in their lanes:

• SSRF fetch broker: owns URL parsing, DNS pinning, redirects, and metadata denial for HTTP tools (SSRF guide).
• Sandbox: owns the disposable execution cell, filesystem scope, and denied-by-default networking inside the runtime (sandboxing guide).
• MCP server trust: owns which servers may be connected and how tool metadata is consented (MCP guide).
• Tool validation and human approval: own whether a proposed call is well-formed and explicitly authorized (validation, approval).
• Tool-output taint: owns provenance after results return, before privileged sinks fire again (taint guide).

Egress control owns the path after a tool is allowed to run: which bytes may leave, under which profile, with which signed evidence. Collapse those jobs into one proxy config and incident review can no longer say which layer failed.

Decision record: promote or hold

Before an internal agent reaches production, record:

Hold if any row is a promise without a failing test. A proxy env var without containment is a hold. Logs without signatures are a hold. Signatures without out-of-process mediation are a hold.

What to do next

List every production agent runtime. For each one, answer with evidence:

1. Can it reach the internet without the mediator?
2. Which destinations and payloads are allowlisted, and who owns that list?
3. Do allow and block decisions produce signed receipts verified offline?
4. Do SSRF brokers, sandboxes, MCP trust, tool validation, human approval, and tool-output taint still cover their adjacent jobs?

If you cannot answer those four from artifacts, the agent is not ready for privileged workflows. Build the boundary first. Scale autonomy after the receipts verify.

---