Zero-Knowledge Proofs for AI Agent Compliance: Proving Behavioral Properties Without Revealing Data

In 1985, Shafi Goldwasser, Silvio Micali, and Charles Rackoff published "The Knowledge Complexity of Interactive Proof Systems," introducing zero-knowledge proofs — one of the most profound ideas in theoretical computer science. The concept: it is possible to prove the truth of a statement without revealing anything beyond the fact that the statement is true. The classic example: prove you know the location of Waldo in a "Where's Waldo?" puzzle without pointing to Waldo — by covering the rest of the page and showing only a small window centered on Waldo. The verifier sees Waldo but learns nothing about where Waldo is on the page.

For four decades, zero-knowledge proofs were primarily theoretical. The computational cost was prohibitive for practical applications. Then, in the 2010s and 2020s, a series of breakthrough constructions — Groth16, PLONK, STARK, and their successors — made ZKPs practical. Ethereum's ZK-Rollup ecosystem demonstrated that ZKPs could process millions of transactions with efficient proofs. Privacy applications like Zcash showed that financial transactions could be validated without revealing amounts or participants.

Now, in 2026, ZKPs are approaching practicality for AI agent compliance. The core use case: an AI agent needs to prove to a regulator, a counterparty, or a governance system that it complied with specific behavioral requirements — without revealing the underlying interaction data that would violate user privacy, expose competitive information, or breach confidentiality obligations.

"I never accessed PII outside my authorized scope" — provable without revealing what data I did access. "My decisions were within the statistical distribution of my training distribution" — provable without revealing individual decisions. "My outputs never contained content matching GDPR Article 9 special categories" — provable without revealing the outputs themselves.

These are the compliance proofs that the privacy-first AI economy needs. This document provides a rigorous technical introduction to ZKPs for AI agent compliance, from the mathematical foundations through practical implementation considerations and current limitations.

TL;DR

• Zero-knowledge proofs enable AI agents to prove compliance properties (e.g., "I never accessed PII outside authorized scope") without revealing the underlying behavioral data.
• ZK-SNARKs (Succinct Non-Interactive Arguments of Knowledge) are currently the most practical ZK construction for AI agent applications: proofs are small (< 1 KB) and verify in milliseconds, but proof generation is computationally expensive.
• ZK-STARKs (Scalable Transparent ARguments of Knowledge) require no trusted setup, are post-quantum secure, but produce larger proofs than SNARKs.
• Practical ZK compliance circuits for AI agents can prove: range properties (output scores within expected bounds), absence properties (no specific categories of content generated), frequency properties (task completion rate above threshold), and membership properties (all API calls were to authorized endpoints).
• Current limitations: proving general LLM transformer computation in ZK is infeasible today (a single transformer forward pass would require circuits with billions of gates). Practical ZK compliance focuses on post-hoc assertions about behavioral logs, not on proving the computation itself.
• The most practical near-term application is ZK proofs over structured behavioral log data (not over LLM computation), enabling privacy-preserving compliance attestation for regulatory disclosures.
• Armalo's zero-knowledge attestation roadmap targets behavioral log ZK proofs as the near-term priority, with model-level ZK proofs as a multi-year research direction.

Zero-Knowledge Proof Fundamentals

Before examining AI applications, a precise definition of what ZKPs provide.

The Three Properties of a Zero-Knowledge Proof

Completeness: If the statement is true, an honest prover can convince an honest verifier.

Soundness: If the statement is false, a cheating prover cannot convince an honest verifier (except with negligible probability).

Zero-Knowledge: The verifier learns nothing beyond the fact that the statement is true. More formally: everything the verifier could compute from interacting with the prover, it could compute from just knowing the statement is true.

The zero-knowledge property is formalized through the concept of a simulator: there exists a polynomial-time algorithm that, knowing only that the statement is true, can generate a simulated transcript of the proof interaction that is computationally indistinguishable from a real transcript. Since the simulated transcript was generated without knowledge of the prover's secrets, the real transcript cannot have revealed those secrets either.

Non-Interactive ZKPs

Interactive ZKPs require multiple rounds of communication between prover and verifier. For AI agent compliance applications, we need non-interactive proofs (NIZKs) — the prover sends a single message that the verifier can check without interaction.

The Fiat-Shamir heuristic converts interactive proofs to non-interactive proofs by replacing the verifier's random challenges with hash function outputs. In the random oracle model, this transformation is provably secure.

ZK-SNARKs and ZK-STARKs are both non-interactive, making them suitable for asynchronous compliance verification.

ZK-SNARKs: The Practical Standard

ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) are the dominant ZK construction in deployed systems as of 2026.

"Succinct" means: both the proof size and the verification time are very small compared to the witness (secret) and the circuit (computation).

Key parameters for current constructions:

• Groth16: ~200 bytes proof, ~1 ms verification, trusted setup required
• PLONK: ~400 bytes proof, ~2 ms verification, universal trusted setup
• Halo2 (no trusted setup variant): ~1 KB proof, ~5 ms verification

Trusted setup requirement: Most ZK-SNARKs require a trusted setup ceremony that produces a Common Reference String (CRS). If the setup is compromised (the "toxic waste" is not destroyed), an adversary could create false proofs. This is mitigated by multi-party computation (MPC) ceremonies where hundreds of participants contribute to the setup.

SNARK Circuit Model

ZK-SNARKs operate over arithmetic circuits. A circuit takes public inputs (what the verifier knows) and private inputs (the witness — what the prover knows but doesn't reveal) and checks that a set of constraints is satisfied.

Example circuit for compliance proof:

Public inputs: Total number of API calls (N), authorized endpoint list hash (H_auth), timestamp range (T_start, T_end) Private inputs: The list of N API calls (each with endpoint, timestamp, and data hash) Constraint: For all i in 0..N, endpoint[i] is in the authorized endpoint list

The prover generates a proof that they know N API calls satisfying the constraint, without revealing the calls themselves.

// ZK circuit in pseudocode (Circom-like syntax)
pragma circom 2.0.0;

template AuthorizedEndpointCheck(N, num_endpoints) {
    // Public inputs
    signal input authorized_endpoint_hashes[num_endpoints];
    signal input num_calls;  // = N
    
    // Private inputs (witness)
    signal input call_endpoints[N];  // Actual endpoints called (secret)
    signal input call_timestamps[N]; // Timestamps (secret)
    
    // Output
    signal output all_authorized;
    
    // Check each call endpoint is in the authorized list
    component membership_checks[N];
    signal is_authorized[N];
    
    for (var i = 0; i < N; i++) {
        // Check that call_endpoints[i] is in authorized_endpoint_hashes
        var found = 0;
        for (var j = 0; j < num_endpoints; j++) {
            found += (call_endpoints[i] == authorized_endpoint_hashes[j])? 1 : 0;
        }
        is_authorized[i] <== found;
        is_authorized[i] === 1;  // Assert: each call must be to an authorized endpoint
    }
    
    all_authorized <== 1;  // Output: all checks passed
}

A valid proof of this circuit proves: "I made N API calls, all to endpoints in the authorized list, and I'm not revealing which endpoints or what data was transmitted."

ZK-STARKs: No Trusted Setup, Post-Quantum Secure

ZK-STARKs (Scalable Transparent ARguments of Knowledge) offer different tradeoffs:

Advantages over SNARKs:

• No trusted setup (transparent: CRS is just a random string, no toxic waste)
• Post-quantum secure (security based on hash functions, not elliptic curve DLP)
• Asymptotically faster proof generation for large circuits

Disadvantages vs. SNARKs:

• Larger proof sizes (~100 KB vs. ~1 KB)
• Slower verification (~10 ms vs. ~1 ms)

When to prefer STARKs for AI agent compliance:

• Regulatory environments where trusted setup is not acceptable (some regulators may question whether the CRS was properly generated)
• Long-term compliance proofs that may need to withstand post-quantum adversaries
• Large compliance circuits (thousands of constraints) where STARK's faster prover justifies the larger proof size

Practical ZK Compliance Circuits for AI Agents

While proving a complete LLM forward pass in ZK is infeasible today, several compliance predicates over structured behavioral logs are practical.

Circuit 1: Scope Compliance (No Unauthorized Data Access)

Statement: "During session S, I accessed only data sources in the authorized access list A."

Circuit design:

// Inputs
public: session_id, authorized_sources_root (Merkle root of authorized source list)
private: accessed_sources[] (actual list of data sources accessed)
         access_merkle_proofs[] (Merkle proofs that each source is in A)

// Constraints
for each accessed_source[i]:
    verify_merkle_proof(accessed_source[i], access_merkle_proofs[i], authorized_sources_root) == true

What this proves: Every data source accessed in session S was in the authorized list. What this does NOT reveal: Which data sources were accessed, how many times, in what order, or what data was retrieved.

Circuit 2: Output Quality Score

Statement: "My task completion rate over the past N tasks is at least T%."

Circuit design:

// Inputs
public: N, threshold T, public commitment to task list
private: task_results[] (0 or 1 for each task: success or failure)
         commitment_opening (reveals commitment to task list is correct)

// Constraints
sum = 0
for each task_result[i]:
    task_result[i] is 0 or 1  // Binary check
    sum += task_result[i]

// Prove sum/N >= T
sum * 100 >= T * N  // Integer arithmetic version of sum/N >= T/100

What this proves: At least T% of N tasks were completed successfully. What this does NOT reveal: Which specific tasks succeeded, which failed, what the tasks were, or what outputs were produced.

Circuit 3: Absence of Prohibited Content Categories

Statement: "None of my outputs in session S matched patterns in the prohibited content category P."

This is more complex because it requires proving a negative — that no output matched a pattern. The practical approach:

Method 1: Commitment-then-audit Commit to all outputs cryptographically. Allow regulators to audit a random sample (say, 5%) with full revelation. The ZK proof covers only the non-audited outputs, proving they were processed by a content classifier that returned "not prohibited" for each.

Method 2: Classifier output ZK proof Run a content classifier (a small, ZK-provable model) on each output. Prove in ZK that the classifier returned "safe" for all outputs without revealing the outputs.

The challenge: even a simple classifier model may have too many parameters for practical ZK circuits. Current practical threshold is approximately 10,000 parameters for circuits that can generate proofs in under 10 minutes.

Circuit 4: Differential Privacy Budget Compliance

For agents that process personal data, differential privacy provides mathematical guarantees on privacy leakage. ZK proofs can verify that an agent's data processing satisfied a specific privacy budget:

Statement: "The sequence of queries I executed satisfies (ε, δ)-differential privacy."

Circuit design: The privacy budget consumption for each query can be computed from the noise mechanism parameters. Summing these consumptions and verifying the sum doesn't exceed the budget is a straightforward arithmetic circuit.

# Conceptual ZK circuit for differential privacy budget
class PrivacyBudgetCircuit:
    """
    ZK circuit that proves DP budget compliance without revealing queries.
    """
    def __init__(self, epsilon: float, delta: float):
        self.epsilon = epsilon
        self.delta = delta
    
    def compute_query_budget_consumption(self, sensitivity: float, noise_sigma: float) -> float:
        """
        GDP (Gaussian DP) budget consumption for a single query.
        Computed from the query's sensitivity and the noise applied.
        """
        # Gaussian mechanism: sigma = sensitivity * sqrt(2 * log(1.25/delta)) / epsilon
        # Budget consumed = sensitivity / (noise_sigma * sqrt(2 * log(1.25/delta)))
        import math
        epsilon_consumed = sensitivity / (noise_sigma * math.sqrt(2 * math.log(1.25 / self.delta)))
        return epsilon_consumed
    
    def verify_budget_compliance(self, queries: list[dict]) -> tuple[bool, float]:
        """
        Verify that the sequence of queries fits within the privacy budget.
        In ZK proof system: queries would be the private witness.
        """
        total_epsilon = sum(
            self.compute_query_budget_consumption(q["sensitivity"], q["noise_sigma"])
            for q in queries
        )
        return total_epsilon <= self.epsilon, total_epsilon

Current Limitations and Performance Overhead

The LLM Forward Pass Problem

The most desirable compliance proof for AI agents would prove properties of the model's computation directly: "This output was produced by model weights W operating on input X, and the output contains no prohibited content." This would provide the strongest possible compliance guarantee.

The problem: an LLM with 7B parameters has a forward pass that involves approximately 7 × 10⁹ multiply-add operations, organized into hundreds of transformer layers. A ZK-SNARK circuit for this computation would have on the order of 10¹¹ constraints — far beyond what is practical with current technology.

Current limits: State-of-the-art SNARK proof systems (2026) can handle circuits with approximately 10⁸–10⁹ constraints in proof generation times of minutes to hours. A 7B parameter model exceeds this by 2-3 orders of magnitude.

Research directions: Several teams are working on ZK ML, including:

• Model compression specifically for ZK (reducing parameter count to ZK-provable range)
• Recursive SNARK composition (breaking the forward pass into chunks, proving each chunk separately, recursively combining)
• Custom hardware for ZK proof generation (ZK-specific ASICs or FPGAs)

Timeline estimate: ZK-provable inference for models in the 1B-7B parameter range is likely feasible within 3–5 years; for frontier 100B+ parameter models, 7–10 years.

Practical Near-Term ZK Compliance

Given current limitations, practical ZK compliance for AI agents focuses on:

1. Post-hoc log assertions: Proofs over structured behavioral logs (API calls, data accesses, task completion records) rather than over model computation itself.

2. Small classifier ZK: Running small (< 10K parameter) content classifiers in ZK to prove outputs passed safety filters.

3. Differential privacy budget proofs: Pure arithmetic circuits that are well within ZK-provable range.

4. Membership/exclusion proofs: Proving that specific actions were or were not taken (via Merkle proofs over commitment-anchored logs).

Performance Overhead for Practical ZK Circuits

For the practical ZK compliance circuits described above:

How Armalo's Zero-Knowledge Attestation Roadmap Works

Armalo's approach to ZK compliance is pragmatic: implement practical ZK proofs for the compliance predicates that matter most today, while investing in the research that will make more comprehensive ZK compliance feasible tomorrow.

Current: ZK-Backed Behavioral Log Attestations

Armalo's current attestation system can generate ZK proofs over structured behavioral logs for:

• API scope compliance (all calls to authorized endpoints)
• Data access scope compliance (no unauthorized data access)
• Task completion rate claims (completion rate above threshold)

These proofs are generated using the Circom/SnarkJS toolchain and verified in Armalo's trust oracle before issuing trust score updates.

# Example: Request a ZK scope compliance attestation from Armalo
import requests

response = requests.post(
    "https://armalo.ai/api/v1/trust/zk-attestation",
    headers={"X-Pact-Key": ARMALO_API_KEY},
    json={
        "agent_id": "enterprise-assistant",
        "attestation_type": "scope_compliance",
        "session_range": {
            "start": "2026-05-01T00:00:00Z",
            "end": "2026-05-10T00:00:00Z"
        },
        "authorized_sources_list_hash": "sha256:abc123...",
        "behavioral_log_commitment": "sha256:def456..."
    }
)

# Response includes ZK proof + public signals
zk_attestation = response.json()
# {
#   "proof": "...",
#   "publicSignals": ["1", "sha256:abc123...", "1000"],
#   "verificationKey": "...",
#   "statement": "All 1000 data accesses in the stated range were to authorized sources",
#   "privacyGarantee": "No information about which specific sources were accessed is revealed"
# }

Privacy-Preserving Regulatory Reporting

A key application for Armalo's ZK attestations is regulatory reporting under GDPR and the EU AI Act:

Under GDPR, demonstrating compliance requires evidence of data handling practices. But that evidence — logs of what data was accessed, what processing occurred — is itself personal data subject to GDPR. This creates a circular problem: proving GDPR compliance requires sharing data that GDPR protects.

ZK proofs resolve this circular problem: Armalo can generate a proof that an agent's behavioral logs satisfy GDPR compliance predicates, and this proof can be shared with regulators without sharing the underlying logs.

Conclusion: Privacy-Preserving Compliance as a Competitive Advantage

Zero-knowledge proofs for AI agent compliance are not science fiction — for the practical compliance predicates that matter most today (scope compliance, quality thresholds, DP budget adherence), ZK proofs are technically feasible and economically reasonable.

What they offer is something qualitatively new: compliance without disclosure. An agent can prove to regulators, counterparties, and governance systems that it complied with behavioral requirements, without revealing the user data, business logic, or interaction content that compliance traditionally requires exposing.

This is not just a privacy benefit — it is a competitive advantage. Organizations that can prove compliance without disclosure can participate in more regulated markets, onboard more enterprise customers with strict data handling requirements, and build deeper trust with users who are concerned about their data.

The organizations that build ZK compliance infrastructure today — or partner with trust infrastructure providers like Armalo that are building it — will be positioned to offer the gold standard of AI agent compliance: mathematically verifiable, privacy-preserving, independently auditable.

Zero knowledge. Total compliance.