Verifiable egress control is a security property: every network action an AI agent takes is mediated by a process outside the agent’s trust boundary, and each decision produces a signed receipt any third party can verify offline. The short version is “receipts or it didn’t happen.” Pipelock is the reference implementation. The full definition is the property pair below.
The property pair
A control qualifies as verifiable egress control when both hold:
- Binary-enforced mediation at the network boundary. The 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 path to bypass the enforcement that does not require breaking out of the deployment-level containment. A compromised agent cannot turn the control off.
- Signed action receipts for every adjudicated action. Each decision (allow, block, warn, ask, strip, forward, redirect) produces an Ed25519-signed record. Records chain by hash into a tamper-evident log. A relying party verifies the chain offline with a binary built from open-source verifier code; the verification step trusts a pinned public key, not the vendor.
A control that has property 1 without property 2 is a sandbox or firewall. A control that has property 2 without property 1 is a logging tool.
Why both properties matter
The first property answers “what is preventing the agent from doing the wrong thing.” The second property answers “what evidence does anyone have that the prevention happened.”
Take three failure modes:
| Failure | Enforcement-only control | Logging-only control | Verifiable egress control |
|---|---|---|---|
| Agent leaks API key in URL query | Blocks the request | Logs the attempt; the agent might have edited the log | Blocks the request and emits a signed receipt of the block, verified offline |
| MCP tool returns prompt injection | Scanner catches it (if it has one) | Logs the response (might) | Scanner catches it; signed receipt names the layer, pattern, severity, and verdict |
| Auditor asks “what did the agent do last quarter” | “Trust our logs” | “Trust our logs” | “Verify the bundle locally, here is the public key” |
The third row is the procurement-evidence shift. Auditors and buyers treat signed receipts they can verify themselves as different evidence from logs they have to trust.
What this category is not
- Not a new internet PKI. This category is procurement evidence first. Receipts land as audit-trail and governance artifacts before they land as anything browser-equivalent. The longer arc is to lift the primitive into existing standards (CoSAI, IETF, OASIS), not to ship a Pipelock-controlled certificate format.
- Not a replacement for sandboxing or identity governance. Layer 4 in the control-layer map is one of four lanes. Each lane covers a different threat class.
- Not a replacement for compliance certification. Verifiable egress control maps to specific evidence requirements in SOC 2, HIPAA, and PCI engagements. It does not certify a control environment. A vendor with this control still needs a compliance program.
- Not vendor-locked. Format, schema, conformance corpus, and four verifier implementations are public. Other vendors can emit and consume the same artifacts.
The Pipelock implementation
The current reference implementation is shipped:
- Single Go binary under Apache 2.0. Pipelock 2.5 ships with the full receipt-emission pipeline.
- 11-layer scanner covering DLP, prompt injection, SSRF, tool poisoning, MCP rug-pull detection, policy-bound tool routing, WebSocket frame scanning.
- Ed25519 signing from outside the agent trust boundary. Receipts
chain by hash in an
evidence.jsonlflight recorder file. - Four verifier implementations in Go, TypeScript, Rust, and Python, with the public corpus available for cross-language conformance checks.
- Audit Packet v0 bundle format with a published JSON Schema (pipelab.org/schemas/audit-packet-v0.schema.json) and a GitHub Action that emits complete bundles in CI.
- Public conformance corpus at agent-egress-bench/receipts/v0/conformance/ with 28 fixtures across golden, malicious, and edge cases.
The locked positioning copy for the v2.5 launch:
Pipelock is an open-source agent firewall that controls AI agent egress and produces verifiable audit evidence for every allowed or blocked action.
Microsoft-counter framing for buyer comparisons:
Open-source agent firewall for network-enforced, independently verifiable AI egress.
Both reflect the property pair: binary-enforced mediation plus signed evidence.
When to ask a vendor about verifiable egress control
If you are evaluating an AI agent platform, an MCP gateway, or an agent-security tool, the question is short:
Does your control emit signed action receipts I can verify offline against a pinned public key, with the verifier shipped as open source?
If the answer is no, the vendor has a logging or enforcement product, not a verifiable egress control product. Both are legitimate; only the latter produces the procurement evidence auditors and buyers can rely on without trusting the vendor.
Where to go next
- Agent action receipts: the primitive in detail.
- Verify a Pipelock receipt: hands-on walkthrough against the public conformance corpus.
- Agent security control layers: where verifiable egress control sits in the four-lane map.
- Compliance evidence substrate: what receipts buy in a procurement or audit engagement.
- Agent egress control launch post: the v2.4 announcement that introduced the framing.
Receipts or it didn’t happen. The proxy enforces. The receipt proves the enforcement happened.