Zero-Knowledge Predicate Proofs Between AI Agents: A Measured, Cross-Protocol Gateway and the Source-Integrity Gap

• 88% of surveyed organizations reported a confirmed or suspected AI-agent security incident, while 82% of those organizations expressed confidence that existing policies guard against unauthorized agent actions.Source: §I · p. 1
• Raw-data sharing maximizes exposure, while natural-language self-reports are unverifiable, non-deterministic, and offer no meaningful non-repudiation.The paper describes prompt injection as a route to data exfiltration when agents combine private-data access, untrusted input, and external communication.Source: §I · p. 1
• Identity, least-privilege, logging, and runtime-detection controls do not prevent an authenticated agent from sharing data unnecessary for a permitted interaction.Source: §I · p. 1
• Agents exchange zero-knowledge proofs of governance-defined predicates, so the consumer learns whether the predicate holds plus a commitment and audit handle, not the sensitive value.Source: §I · p. 1
• The Proof Gateway adds a proof slot to MCP and Agent2Agent and uses a shared verification path for both protocols.Its components include a governance-owned predicate registry, verifying gateway, prover sidecars, and hash-chained audit log.Source: §I · p. 2
• The retail case proves an order notional is within a pre-trade cap without revealing the amount, implementing GDPR data minimisation as a technical measure,.Source: §I · p. 2
• The prototype measures execution rather than simulation, tests eleven adversarial cases, and verifies prover isolation by observation in a Kubernetes deployment.The evaluation uses interchangeable Sigma-protocol and Rust Bulletproofs engines,.Source: §I · p. 2
• The attestation-bound construction binds an enclave attestation to a predicate proof, and the paper explicitly excludes verifiable LLM inference (zkML) from its scope.Source: §I · p. 2

A. Trust Domains and Actors

• The primary setting is one enterprise whose agents span internal trust boundaries; the threat model assumes the gateway and governance keys remain uncompromised.The adversary may compromise prover context, tamper with or replay messages, register weakened predicates, and edit logs; standard cryptographic assumptions also apply.Source: A. Trust Domains and Actors · p. 2

B. Exposure Across the Pipeline

• Table I maps contemporary agent-pipeline stages to their current exposure and the proposed mitigation.Source: B. Exposure Across the Pipeline · p. 2

C. Why Proofs Rather Than LLM Self-Report

• The section identifies three failure modes for natural-language assertions as a trust primitive and presents verifiable proofs as the alternative.Source: C. Why Proofs Rather Than LLM… · p. 2

1) Prompt injection compromises the claim:

• A compromised agent can make a false compliance assertion, but soundness prevents it from producing a verifiable proof of a false predicate.The paper points to adversarial tests T1 and T7.Source: 1) Prompt injection compromises the… · p. 2

2) Non-determinism and hallucination on verification tasks:

• LLM outputs vary across samples and are unreliable for precise numeric checks, whereas proof verification is deterministic with negligible soundness error in the security parameter.Source: 2) Non-determinism and hallucination… · p. 2

3) No non-repudiation or auditability:

• A Fiat–Shamir transcript binds a proof to the predicate identifier and version, request nonce, authorized action, and both agent identities; the audit log stores the commitment and proof hash for later re-verification.The paper associates these protections with tests T3, T4, and T6.Source: 3) No non-repudiation or auditability · p. 2

A. Zero-Knowledge Proofs

• An interactive proof system requires completeness, soundness, and zero-knowledge; the cited result that every language in NP admits a zero-knowledge proof grounds Boolean compositions of atomic predicates,.Source: A. Zero-Knowledge Proofs · p. 3

B. Sigma Protocols and Fiat–Shamir

• A Sigma protocol uses commit–challenge–respond, while Fiat–Shamir replaces the verifier’s random challenge with a transcript hash in the random-oracle model,.The hash must bind the full statement and context to avoid malleability; OR-composition proves at least one of two statements without revealing which.Source: B. Sigma Protocols and Fiat–Shamir · p. 3

C. Pedersen Commitments

• A Pedersen commitment is perfectly hiding, computationally binding under the discrete-log assumption, and additively homomorphic.Its homomorphism lets the verifier derive a commitment to cap − v from a public cap and the commitment to v without learning v.Source: C. Pedersen Commitments · p. 3

D. Range Proofs and Bulletproofs

• A range proof establishes that a committed value lies in [0, 2^n); Bulletproofs have logarithmic proof size and require no trusted setup.The cited dalek ristretto255 implementation uses 32(9 + 2 log2 n) bytes, while Bulletproofs+ reports a 576-byte 64-bit proof,.Source: D. Range Proofs and Bulletproofs · p. 3

1) Predicate registry (governance-owned):

• The predicate registry stores governance-signed definitions, and the gateway verifies signatures at publication and again in the orchestration loop.Governance ownership prevents agents from registering weakened checks; the LLM is removed from the trust path.Source: 1) Predicate registry (governance-owned) · p. 3, 5) Requesting and providing agents · p. 4

B. Protocol Flow

• The protocol flow runs from request and context issuance through source fetch, commitment, proof, verification, audit append, and decision, with proofs bound to the exact action context.Gateway-issued nonces prevent precomputation for future requests unless pre-staging is explicitly allowed.Source: B. Protocol Flow · p. 4

C. Source Integrity: What a ZKP Does and Does Not Bind

• A range proof binds a predicate to a committed value, not to the system-of-record value; source-side proving is preferred, while agent-side attestation is less secure but avoids source-system changes.Both topologies assume the governed channel is the only path to the protected action, with middleware denying actions that lack a valid attachment.Source: C. Source Integrity: What a ZKP Does… · p. 4
• The proof-attachment slot lets tool calls and handoffs omit sensitive arguments or replace them with a reference, and registered predicates deny by default when a required attachment is absent.An attestation payload can occupy the same envelope as an optional member rather than requiring a new schema version.Source: Figure 2 · p. 4

E. Composition Across Multi-Hop Chains

• At m=16, one 928-byte aggregate replaces 10,752 bytes of separate proofs and roughly halves verification time, while ∼173 ms proving favors asynchronous aggregation over in-loop use.Per-hop proofs preserve full audit granularity but add latency at each hop; aggregation trades that granularity for one boundary verification.Source: E. Composition Across Multi-Hop Chains · p. 4

F. Scalability and Decentralized Verification

• Verification can be scaled across replicas or verifier-side sidecars, but audit completeness still requires signed receipts to a shared append-only log; policy definition remains centralized by design.The audit-chain head remains a serialization point, addressable with per-domain chains or a transparency-log design.Source: F. Scalability and Decentralized… · p. 4

A. Scenario and Regulatory Grounding

• The retail case checks whether a $7.35M order notional meets a $10M cap without disclosing the amount, aligning the proof with GDPR data minimisation and privacy-preserving predicate disclosure described in EU law.The paper distinguishes the AI Act's logging-capability requirement from cryptographic tamper-evidence, which its hash-chained audit exceeds.Source: A. Scenario and Regulatory Grounding · p. 5

B. Predicate Construction

• The threshold proof reduces v ≤ cap to two range statements, proving v and cap − v are each in [0, 2^n), with the transcript bound to the predicate version, nonce, order reference, and agent pair.The Sigma baseline uses bit commitments and OR-composed Schnorr proofs; Bulletproofs proves the same two statements directly or as one 2-aggregate.Source: B. Predicate Construction · p. 5

C. What Crosses the Boundary

• The 608-byte Bulletproofs envelope includes the schema tag, predicate version, engine, request context, commitment, and proof, but omits the notional, order, and position data.The risk agent receives ALLOW and an audit handle; for a false predicate, the honest prover API refuses to generate a proof.Source: C. What Crosses the Boundary · p. 5

A. Experimental Setup

• The prototype includes an auditable Python Sigma engine and a Rust dalek Bulletproofs engine over ristretto255.The paper identifies Bulletproofs as the practical path and the Sigma engine as an auditable, pedagogical baseline.Source: A. Experimental Setup · pp. 5–6
• Measurements are medians from a single logged run on one virtualized vCPU, so the authors present them as feasibility evidence rather than production benchmarks.The reported host includes 4 GB RAM, Linux kernel 6.18, Python 3.12, and rustc 1.75 with opt-level=3 and LTO.Source: A. Experimental Setup · p. 6

C. End-to-End Case Study and Latency Budget

• The end-to-end E2 flow is bounded by ≈6 ms prove + 1 ms verify + I/O, compared with E1 p50 1,514 ms and p95 1,538 ms.The authors assess E2 as fitting a 10–50 ms real-time tool-call budget; E1 is described as suitable only for offline audit.Source: C. End-to-End Case Study and Latency… · p. 6

B. Results

• E2 grows by 64 bytes per doubling of n, while E1 grows linearly, matching the reported O(log n) versus O(n) proof-size separation.Fig. 4 plots proof size, generation, and verification against bit-width on a log scale.Source: Figure 4 · p. 6, B. Results · p. 6
• For composition pattern (b), at m=16, the aggregate is 11.6× smaller and verifies about 2.1× faster than sixteen single proofs, with prover time 173 ms, supporting asynchronously computed boundary-level aggregation.Source: B. Results · p. 6

D. Adversarial Experiments

• All eleven adversarial experiments behaved as required, and nineteen protocol checks passed across MCP and Agent2Agent using one verification chain and audit log.The tests include tampering, replay, weakened predicates, forgery attempts, and live attachment scenarios; T7 is an implementation sanity check, not a security proof.Source: D. Adversarial Experiments · p. 6

VII. ATTESTATION-BOUND PREDICATE PROOFS

• The attestation flow reuses one gateway nonce for proof context and enclave attestation, binding the commitment to the attestation and the proof to the attestation.The section identifies the unresolved source-integrity issue: a range proof binds a statement to a committed value, not to the binary that read it.Source: Figure 6 · p. 7, §VII · p. 7

A. Mutual Binding

• Attestation report_data commits to the commitment, predicate, version, nonce, and action reference, while the proof transcript commits to the attestation document.The two bindings prevent substitution in either direction; the authors state that both are necessary for a jointly verified artifact.Source: A. Mutual Binding · p. 7

B. Nonce Unification

• The same gateway-issued nonce, with identical expiry, serves the proof context and enclave attestation call, preventing the two artifacts from being paired across different freshness contexts.The passage warns that divergent nonces could pair a fresh attestation with a stale valid proof, or vice versa.Source: B. Nonce Unification · p. 7

C. Governance-Signed Prover Identity

• A governance-signed, versioned prover_measurement predicate makes the permitted binary’s expected measurement part of policy under the same authority that signs business rules.The passage says a compromised agent cannot substitute a prover any more than it can loosen a cap.Source: C. Governance-Signed Prover Identity · p. 7

D. Verification and Implementation Status

• The verification chain validates attestation and measurement, checks nonce freshness and report_data, verifies the bound proof, and records the attestation digest in the audit entry.Whether a measurement is required comes from the registry; whether the envelope carries an attestation independently selects the attested or unattested transcript.Source: D. Verification and Implementation… · p. 7
• The Rust implementation is wired into both MCP and A2A, with 21 unit tests, but its attestation authority is a mock rather than a hardware root of trust.The mock uses an Ed25519-signed document and a publicly derivable root seed; AWS Nitro Enclaves and GCP Confidential Space remain to be tested.Source: D. Verification and Implementation… · p. 7
• The bidirectionally bound artifacts verify only when both bindings hold, and the full verification sequence runs end to end on both protocol surfaces.An early implementation failed when prover and gateway chose different transcripts; the fix makes transcript choice envelope-driven and measurement policy registry-driven.Source: D. Verification and Implementation… · p. 8

1) Only structured predicates reduce to circuits:

• Structured range, set-membership, threshold, and Boolean predicates fit the approach, but fuzzy or judgment-based criteria cannot be made provable by the architecture.Where an LLM must judge, the system can bind and audit the judgment’s inputs and outputs, but not prove the judgment itself.Source: 1) Only structured predicates reduce… · p. 8

3) Metadata leakage:

• Predicate proofs hide the witness, not which predicate was invoked, by whom, how often, or when; padding, batching, and private information retrieval were not evaluated.The passage notes that a burst of pretrade_notional_cap checks can reveal trading activity.Source: 3) Metadata leakage · p. 8

4) Governance is a socio-technical open problem:

• The proposal leaves predicate ownership, policy-version migration windows, and proof-failure handling unresolved, supplying a mechanism rather than an operating model.The possible failure responses named are hard denial or human escalation.Source: 4) Governance is a socio-technical… · p. 8

5) Attestation is implemented but not yet hardwarevalidated:

• Real-hardware evaluation remains outstanding: certificate-chain cost, attestation-envelope size, and measurement churn have not been measured.Until then, source integrity rests on the deployment discipline of topology A or B; Table IV marks hardware evaluation as deferred.Source: 5) Attestation is implemented but not… · p. 8, Table IV · p. 9

6) Enclave input imposes a deployment requirement:

• The enclave must authenticate the source through an end-to-end encrypted channel terminated inside measured memory, with its trust anchor in the measured image and any required credential released under attestation.The parent host may relay ciphertext and delay or deny traffic, but the stated conditions prevent it from reading or altering the source exchange.Source: 6) Enclave input imposes a deployment… · p. 8

7) Verifiable LLM inference is out of scope:

• Verifiable inference for a 13B-parameter LLM takes approximately 15 minutes to generate, versus 6.2 ms for predicate proofs, so zkML is out of scope for agent loops.The paper limits its claim to data-plane predicates being provable today, not model reasoning or inference.Source: 7) Verifiable LLM inference is out of… · p. 8

IX. RELATED WORK

• Against the closest systems, the paper distinguishes execution rather than simulation, carriage on two protocols, and an explicit characterization of the source-integrity assumption.Table IV frames source integrity as whether the construction binds the proved value to the system of record.Source: §IX · p. 8, Table IV · p. 9

1) Zero-knowledge architecture in deployed systems:

• The contribution is an end-to-end, measured, governance-complete realization of agent-policy ZKPs, not new cryptography or the first such application.The passage contrasts this inter-agent deployment with minimal-disclosure cryptography already used at scale outside agent systems.Source: 1) Zero-knowledge architecture in… · p. 8

2) Agentic-security mainstream:

• The Proof Gateway complements frameworks that govern whether interactions occur by minimizing the data carried in permitted interactions,,,,.These frameworks focus on identity, privilege, visibility, and detection, while the gateway addresses data exposure during an allowed interaction.Source: 2) Agentic-security mainstream · p. 9

3) ZKPs applied to agent systems:

• Unlike Aegis [31], whose proof latencies are simulated rather than measured, this gateway synchronously sends a transparent-setup predicate proof instead of the sensitive value.The related-work discussion also distinguishes systems focused on identity, tool-call execution, and post-session auditing from this data-payload approach.Source: 3) ZKPs applied to agent systems · p. 9
• Stantchev describes the gap as architectural, while Section VII binds attestation and proof bidirectionally under a governance-signed expected prover measurement.The passage contrasts this construction with approaches where attestation and proof remain independently substitutable.Source: 3) ZKPs applied to agent systems · p. 9

4) Verifiable machine learning:

• The paper excludes proofs of inference: its proofs concern exchanged data, not the models doing the exchange,, [29],.Source: 4) Verifiable machine learning · p. 9

REPRODUCIBILITY STATEMENT

• The results come from one logged run on a virtualized single-vCPU host, so timings are feasibility evidence rather than production benchmarks.The deterministic tests are included with the release, and Kubernetes network-policy isolation was confirmed by observing connections fail with the policy applied and succeed after it was withdrawn.Source: REPRODUCIBILITY STATEMENT · p. 9

X. CONCLUSION

• When a sensitive value is not needed to establish trust, the preventive complement makes that trust-establishing interaction unable to expose the value.Source: §X · p. 9
• 608-byte proofs, single-digit-millisecond generation, and millisecond verification are compatible with real-time agent loops for financial bit-widths; all eleven adversarial experiments behaved as required.Next steps include testing the attestation construction on real enclave hardware and benchmarking a broader catalog of predicates.Source: §X · p. 10

• For x=7, y=13, nonce w=3, challenge e=5, and response z=5, the example's modular verifier check accepts.Source: Appendix A · p. 10
• The example presents the response tuple (a, e, z) as simulatable without secret x, illustrating its stated zero-knowledge property.Source: Appendix A · p. 10
• Fiat–Shamir derives e from the transcript to remove interaction, and the paper's bit proofs use OR-compositions of the same template,.Source: Appendix A · p. 10