ZK Firewall: Cryptographic Compliance for Agentic AI
ZK Firewall: Cryptographic Compliance for Agentic AI
AI agents are no longer just chatbots. They execute tool calls, access customer data, and generate outputs that flow into production systems. Every one of those actions is a potential risk: a leaked API key, an unauthorized endpoint call, a response containing data that should never have left the boundary. Individuals who use agents without protection risk leaking personal information to malicious actors, such as hostile foreign entities or dark web hackers who sell harvested data online. Organizations face the same risks but with greater accountability and consequences when data is leaked. Compliance is costly when done after the fact. An individual data exploit can cost as high as $10M per incident to organizations who must pay for damages.
Traditional security checks these actions with rules engines and logging. Rules engines can be bypassed. Logs can be tampered with. Neither produces a guarantee that a third party can independently verify.
The OpenMatter ZK (Zero-Knowledge) Firewall replaces probabilistic guardrails with mathematical certainty. It generates a cryptographic certificate of compliance for every agent action that crosses the secure boundary, including every output, every tool call, every data retrieval. The certificate is a zero-knowledge proof: the verifier — the user who uses the agent — confirms compliance with mathematical certainty, without ever seeing the underlying data. Compliant actions produce valid proofs and are executed. Non-compliant actions fail to produce a proof and are blocked. This creates an audit trail for compliant tracking of all agent actions.
The firewall is ‘zero-knowledge’ because privacy of all data, credentials, and toolcalls is maintained and never revealed to the user. This means the user, while being able to verify all agent actions, never violates any role permissions or security policies regarding data access. The user (who is the verifier) never learns anything about the underlying data the agent is interacting with and so we refer to the verifier as having zero-knowledge. Accelerating compliance and security without sacrificing privacy: This is what the ZK firewall enables.
The Problem: Agents Act, and Actions Have Consequences
Securing an agent’s environment variables is necessary but not sufficient. An agent with properly protected secrets can still:
Leak sensitive data in its outputs, such as PII, financial records, proprietary details embedded in a natural-language response.
Call unauthorized APIs, like a payment processor, a file-sharing service, or an endpoint the agent was never approved to contact.
Access data belonging to the wrong customer, causing a multi-tenant isolation failure where session boundaries are crossed.
This is why we built the ZK Firewall. The OpenMatter hosting layer protects the agent’s inputs. ZK Firewall protects every policy-relevant output. Together, they close the loop: nothing unauthorized goes in, nothing unauthorized comes out. The advantage becomes clear: a full stack security platform for the agentic economy.
Three Verifiable Safety Checks at Machine Speed
ZK Firewall enforces three compliance checks. Each can be verified in isolation. The design goes beyond traditional firewalls. Rather than strictly focusing on preventing traffic from the outside the ZK firewall provides protection from the inside out while maintaining privacy. Each agent action is verified as an audit trail via logs or in real time during agent execution. This optionality allows for both historical compliance and real time protection from agents actions. These checks can be broken out into three categories: Output compliance, Toolcall Compliance, and Data Access Compliance.
1. Output Compliance
Agents generate free-form responses that may inadvertently contain information the enterprise’s policy prohibits from appearing in outputs. The enterprise defines the policy as a set of forbidden field identifiers: terms, patterns, or categories that must never appear in any response that leaves the boundary. OpenMatter provides easy to use templates to define policies and reduce friction during setup.
Before any agent output is released to the user, ZK Firewall checks every token in the response against the forbidden list and generates a proof certifying the output is clean. If a forbidden term appears, proof generation fails, the output is blocked, and the agent must reformulate.
The ZK proof commits only a small public output to the proof journal: a boolean (yes or no) verdict indicating whether the output is compliant, the number of unique tokens scanned, and the count of any forbidden hits. The user sees the verdict. It never sees the response text, the forbidden list, or which tokens were scanned. The proof is the evidence. A mathematical guarantee that the agent output is compliant.
2. Tool-Call Compliance
Agents that execute tool calls (payments, DevOps operations, data queries) present the highest risk surface. A single unauthorized API call can exfiltrate data, trigger a financial transaction, or modify production infrastructure. An unsanitized toolcall request could leak sensitive information of the users. ZK Firewall enforces two independent checks on every outbound tool call.
2a. Endpoint Allowlist Enforcement
The enterprise defines the set of approved tools and services. ZK Firewall proves that every tool the agent invoked is a member of the approved set.
The ZK Firewall compacts and normalizes tool identifiers from the session and the policy allowlist into comparable representations. The guest performs a set-membership verification. Every requested tool must appear in the allowlist, or the proof fails.
An agent configured to access a CRM and a calendar cannot secretly call a file-sharing API or a payment processor. The proof certifies exact set membership. This is not an approximation or a log entry, but a mathematical guarantee.
2b. Request Sanitization
Beyond which tools are called, the firewall enforces what data flows through them. The enterprise defines sensitive parameter keys (tokens, API keys, credentials, account identifiers) whose values must be masked before any request leaves the boundary.
The ZK Firewall transforms tool-call parameters into compact representations that preserve the key-value structure without exposing raw content. The ZK proof verifies that every parameter matching a sensitive key has been properly redacted according to the masking policy. Any unmasked sensitive value causes an assertion failure, and no valid proof is produced.
Both checks must pass independently. The proof shows explicitly the distinct tool count, total parameter count, and the number of sensitive pairs verified, but reveals nothing about the actual tool names, parameter keys, or values.
3. Data Access Compliance
Multi-tenant agent platforms serve multiple customers on shared infrastructure. Each customer’s data must be strictly isolated. In production systems, that isolation is enforced through session-scoped access controls at the service boundary. ZK Firewall extends this mechanism cryptographically.
At session start, the system derives a public hash commitment from the authenticated context (e.g., tenant_id and user_id). During execution, all data-access requests issued by the agent should use a consistent context across different layers (e.g., request metadata, retrieval scope, and storage namespace). Inside the zkVM, the proof checks that these context fields are equal across all occurrences, and then recomputes a hash commitment from the private tenant_id and user_id, asserting that it matches the expected public value.
The proof verifies that the authenticated context (e.g., tenant_id and user_id) is used consistently across the entire interaction, ensuring no distinct identity appears across different layers. It then checks that this unified context is the correct one by committing to the same public hash value. The verifier can confirm the access decision without learning the underlying identifiers. This provides a compact, independently verifiable guarantee that all data access remains bound to the correct customer context throughout execution.
Verification is decoupled from proving. A verifier needs only the proof artifact and the known program IDs — not the original input, not the agent’s response, not the session data. Verification runs in milliseconds.
Latency: Real-time Proofs vs. Audit Trail Mode
Before any output is published, any tool is called, or any data is accessed, the ZK Firewall generates a zero-knowledge proof that the action complies with the enterprise’s policy. An optional alternative ‘audit trail’ mode is available where proofs are generated in parallel, so you can have an action executed in near real-time and have a proof afterward to verify. The proof is verifiable by anyone — the enterprise, a regulator, or an auditor — without revealing the underlying data. If the proof fails, the action is blocked.
The ZK Firewall adds marginal per-action latency. Proof verification is sub-second for the use cases described above— a modest cost for a cryptographic compliance guarantee, and considerably cheaper than manual review or post-incident response. Proof times are acceptable achieving ~1s prover times even on larger datasets with hundreds of toolcalls. These efficient verification speeds are achievable in both real-time and audit trail mode.
Deployment: Bring Your Own Agent
ZK Firewall is decoupled from the hosting layer. It functions as middleware that can secure any agent, regardless of where it runs.
Fully Hosted (End-to-End Protection). Enterprises deploy agents directly onto OpenMatter nodes. Secrets are protected via threshold cryptography, compute runs in a post-quantum secure environment, and ZK Firewall enforces compliance natively. No single party sees the agent’s inputs, logic, or outputs. This provides the highest assurance.
Middleware Mode (External Infrastructure). Agents running on external networks, enterprise servers, or legacy cloud infrastructure route operational requests through ZK Firewall. The firewall ingests the proposed action, runs the zkVM compliance checks, and returns a proof of conformance. The validated instruction is returned to the external agent for final execution on its native infrastructure. Native integrations with Model Context Protocol (MCP) for tool orchestration and x402 for agent payment rails ensure seamless adoption.
Middleware mode protects outputs and tool calls but does not secure the agent’s internal state or secrets. Fully hosted mode provides complete protection across the stack. Both modes produce the same proofs with the same verification guarantees.
By separating proof generation from agent hosting, ZK Firewall becomes a universal security primitive. Enterprises can inject cryptographic compliance into existing AI workflows without migrating infrastructure. Adoption does not require an all-or-nothing commitment.
From Probable to Certain
Traditional agent security asks: “Do we trust this system to enforce our policies?” ZK Firewall asks a different question: “Can this system prove it enforced our policies?”
Every output is checked against the forbidden list, and the proof certifies it. Every tool call is validated against the allowlist, and the proof certifies it. Every sensitive parameter is masked, and the proof certifies it. Every data access is bound to the correct session, and the proof certifies it.
The proofs are compact, fast to verify, and reveal nothing about the underlying data. They compose into a complete compliance record for every agent interaction. And they are independently verifiable by any party, requiring no access to the agent, the infrastructure, or the data.
Agents are going to act in the world on behalf of enterprises. The question is not whether to let them. It is how to guarantee they act within policy. ZK Firewall makes that guarantee mathematical. The advantage becomes clear: compliant and secure AI without sacrificing data or user privacy.