---
title: "Zero-Knowledge Verified Agent Egress"
summary: "Intercepts each outbound HTTP or MCP call, proves its claims against a private source of truth with a zero-knowledge proof, and blocks calls that fail"
status: "emerging"
category: "Security & Safety"
url: "https://agentic-patterns.com/patterns/zero-knowledge-verified-agent-egress"
source: "https://github.com/ProvablyAI/sourcerykit"
authors: ["Provably (@aural-psynapse)"]
tags: ["egress","zero-knowledge-proof","source-of-truth","allow-list","mcp","outbound-verification","runtime-protection"]
signals: ["Agent makes high-value outbound calls such as payments","Tampered tool arguments are a threat that domain allow-lists miss","Source of truth must stay hidden from the agent and destination"]
anti_signals: ["Agent makes no outbound calls with consequences","Per-call proof latency is not acceptable","No one can define and maintain a source of truth per flow"]
updated_at: "2026-10-13"
---

# Zero-Knowledge Verified Agent Egress

> Intercepts each outbound HTTP or MCP call, proves its claims against a private source of truth with a zero-knowledge proof, and blocks calls that fail

## Use when

- Agent makes high-value outbound calls such as payments
- Tampered tool arguments are a threat that domain allow-lists miss
- Source of truth must stay hidden from the agent and destination

## Avoid when

- Agent makes no outbound calls with consequences
- Per-call proof latency is not acceptable
- No one can define and maintain a source of truth per flow

## Problem

An agent can be tricked into making an outbound request that looks fine at the network layer but carries a false claim: a payment to the wrong recipient, an API call with tampered parameters, a tool call whose arguments do not match what the user approved. A domain allow-list or egress firewall lets the call through because the destination is allowed; it never checks whether the *content* of the request is truthful. In regulated or high-value flows, teams need each outbound call to prove it matches a trusted source of truth before it leaves, without exposing that source of truth to the agent or the destination.

## Solution

Put a verification layer in front of every outbound request. Before the call leaves, the agent's claims about it get checked against a source of truth, and a zero-knowledge proof confirms the claims hold without revealing the underlying data. The call only goes out if the proof verifies.

The layer wraps the agent's HTTP path and MCP handoffs:

1. **Intercept**: hook the HTTP libraries the agent already uses, plus MCP tool calls, so every outbound request passes through.
2. **Verify**: check the request's claims against the source of truth and produce a zero-knowledge proof that they match. The proof runs against a backend that holds the source of truth, so neither the agent nor the destination sees it.
3. **Enforce**: block anything whose proof does not verify, and block any endpoint not on the trusted allow-list. Log every outbound call for audit.

```pseudo
on_outbound_request(req):
    proof = prove_against_source_of_truth(req.claims)   # zero-knowledge
    if not verify(proof):        return BLOCK
    if req.endpoint not in allow_list:  return BLOCK
    log(req, proof)
    return ALLOW
```

This is complementary to [Egress Lockdown (No-Exfiltration Channel)](egress-lockdown-no-exfiltration-channel.md): that pattern controls *where* an agent may send data at the network layer, while this one verifies that *what* the agent is sending is true before it goes. It also differs from [Policy-Gated Tool Proxy](policy-gated-tool-proxy.md): the proxy decides whether a call is *allowed* against static policy rules, while this pattern proves the call's *content* matches a private source of truth at egress time.

## Evidence

- **Evidence Grade:** medium
- **Most Valuable Findings:**
  - NIST SP 800-207 (Zero Trust Architecture) establishes per-request verification before granting access as a core tenet; this pattern applies the same tenet to an agent's outbound calls. NIST SP 800-207 does not mention agents or egress content verification, so it serves as a conceptual basis, not a description of this pattern.
  - Zero-knowledge proofs let a verifier confirm a claim without seeing the secret behind it (Goldwasser, Micali & Rackoff, 1989), so the source of truth stays private from both the agent and the destination.
  - Agent-security literature treats untrusted tool calls and prompt-injection-driven misuse as a first-class problem (see the agentic-security survey arXiv:2510.06445, OWASP's Agentic AI Threats and Mitigations guide, and CaMeL in "Defeating Prompt Injections by Design", which enforces security policies when tools are invoked through a capability mechanism). None of these describes content verification via zero-knowledge proofs at egress.
  - Hooking at the HTTP and MCP layer catches outbound calls regardless of which framework produced them.
- **Unverified / Unclear:** Proof-generation latency and the operational cost of running the verification backend at high call volumes need more production data.
- **Adoption caveat:** the only known implementation is from the pattern author's own company; no third-party deployment, adoption, or independent writeup exists yet.

## How to use it

- Wrap any agent framework that makes outbound HTTP or MCP tool calls (LangChain, CrewAI, MCP servers, custom SDKs) so every outbound request passes through the verification layer.
- Define the source of truth for the flows that matter (approved recipients, order details, policy limits) and a trusted-endpoint allow-list.
- Pick a proof mechanism: a zero-knowledge proof keeps the source of truth private from both the agent and the destination; where privacy is not a constraint, a signed attestation from the verifier achieves the same gating.
- Route outbound calls through the layer; treat a failed proof or a non-allowlisted endpoint as a hard block.
- Keep the signed logs for audit and incident review.

An existing implementation of this pattern is [SourceryKit](https://github.com/ProvablyAI/sourcerykit) (Python SDK, source-available under Business Source License 1.1, converting to GPL-3.0-or-later in 2029). Disclosure: it is the pattern author's own product — the Python SDK for Provably — and it depends on Provably's hosted backend, which holds the source of truth and produces the anchored verification proofs; interception happens locally, but verification is not fully offline.

## Trade-offs

- **Pros:** Catches truthful-looking but false requests that a network allow-list misses; the source of truth stays private via the zero-knowledge proof; framework-agnostic through HTTP and MCP hooks; every call is logged.
- **Cons:** Proof generation adds latency per call; verification runs against a backend rather than fully offline; someone has to define and maintain the source of truth for each flow.

## References

- [SourceryKit](https://github.com/ProvablyAI/sourcerykit) (implementation; pattern origin)
- [NIST SP 800-207: Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final) (conceptual basis)
- [Goldwasser, Micali & Rackoff: The Knowledge Complexity of Interactive Proof Systems (SIAM J. Comput., 1989)](https://doi.org/10.1137/0218012)
- [A Survey on Agentic Security (arXiv:2510.06445)](https://arxiv.org/abs/2510.06445)
- [Debenedetti et al., "Defeating Prompt Injections by Design" (CaMeL, arXiv:2503.18813)](https://arxiv.org/abs/2503.18813)
- [OWASP GenAI Security Project: Agentic AI - Threats and Mitigations](https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/)
- [Egress Lockdown (No-Exfiltration Channel)](egress-lockdown-no-exfiltration-channel.md)
- [Policy-Gated Tool Proxy](policy-gated-tool-proxy.md)