ZK in agents: threat model, guarantees, and engineering practice

Hold the complete threat model in view — assumptions, goals, the induced-delegator case, and what is explicitly out of scope — map each security goal to a property that does or does not hold, understand the structural tensions and limitations that remain open, and translate all of it into concrete, transferable practices for anyone building verifiable or secure agent systems.

Track

Research

Module

5 · Research case studies

Prerequisites

ZK in agents: the delegated-authorization problem · ZK in agents: evaluation, measured in detail · ZK in agents: results, limits and open problems

The setting is mutually distrusting organizations. A root authority issues the first credential; intermediaries sub-delegate; a leaf agent acts; a verifier — another agent, an auditor, or a contract on a public ledger — decides whether the action was authorized. The guarantees are only as good as the assumptions, so state them first.

• ▸Cryptographic assumptions: existential unforgeability under chosen-message attack (EUF-CMA) for the signature scheme, collision resistance of the hash, and knowledge soundness of the proof system under its own stated assumptions.
• ▸Execution assumption: the verifier executes correctly.
• ▸Explicitly NOT assumed: that the root authority is reachable at verification time. Authorization must be checkable offline (requirement R1).

The model names six goals. Keeping them explicit is what lets the property table later say honestly which are met and which are only partly met.

G1 Scope containment

No chain authorizes an action outside the root’s scope.

G2 No cross-binding

No party can present a chain that terminates in another party.

G3 Integrity

Forged or tampered artefacts are rejected.

G4 Replay bound

An intercepted note is accepted at most once.

G5 Non-equivocation

A registry cannot present two histories undetected.

G6 Disclosure-free demonstration

An optional lane discloses nothing about the chain beyond the statement being proved.

This is the case that matters most for agent systems and the one most easily overstated. An INDUCED delegator is an agent whose deciding component is manipulated — for example by prompt injection against a language-model planner — into issuing a delegation it would not otherwise issue.

what the layer does and does not do for an induced delegator (didactic)
GUARANTEED (G1):  the induced credential cannot exceed the issuer's OWN scope.
                  attenuation is enforced per hop, so a manipulated B still cannot grant
                  more than A granted B.

NOT PREVENTED:    the induced delegation is still ISSUED. Within B's legitimate scope,
                  a manipulated B can delegate to the wrong party, at the wrong time,
                  for the wrong purpose — and every check (V1-V5, A1-A10) will pass,
                  because nothing was violated: the action type is in scope.

A threat model is as much about what it excludes as what it covers. The paper places the following out of scope, and a deployment must address them by other means or accept them.

• ▸Misuse of legitimately held authority (an agent using real authority to do harm within scope).
• ▸Collusion within granted scopes.
• ▸Key compromise (a stolen signing key forges within the compromised party’s authority).
• ▸Correctness of self-reported outcomes (the layer attests authority, not truth of results).
• ▸The reasoning quality of any stochastic component — whether the agent decided well.

This is the heart of the honesty. The paper tabulates seven properties with status; here is the map from guarantee to reality. “Holds” means a test suite constructs a violation and the system rejects it — not a formal proof.

goal -> property -> status (didactic summary)
P1 No hop widens authority        HOLDS (tested, both lanes)        -> supports G1
P2 No reuse of another's chain     HOLDS (tested)                   -> supports G2
G3 integrity (forgery/tamper)      HOLDS (tested: bad sig rejected) -> via V3 / A3
P3 A note accepted at most once    HOLDS after a correction          -> supports G4
                                   (uniqueness-constrained insert, concurrency-safe)
P4 Chain topology stays hidden     PARTLY: per-depth circuit family
                                   leaks depth via the verification key -> weakens G6
P5 Proof reflects current validity FAILS: no instant in public signals;
                                   a proof verifies after expiry/revocation
P6 Revocation applies on proof lane FAILS: revocation ranges over the hidden chain
P7 Proof binds stored credentials  FAILS by construction (curve translation)

Two pairs of requirements pull against each other. One is resolved by design; the other the paper could not resolve and reports as a limitation. Recognizing tensions as tensions — rather than assuming a clever design dissolves them — is itself a transferable skill.

• ▸Non-disclosure (R4) vs enforcement at line rate (R5): non-disclosure is expensive, enforcement is hot. RESOLVED by the two-lane design — cheap cleartext enforcement on the hot path, optional zero-knowledge proof on a cold lane invoked only on request. The design principle "accept if and only if provable" keeps the lanes from diverging.
• ▸Non-disclosure (R4) vs revocation (implied by R2): revocation checking must range over the chain, but the proof lane hides the chain. NOT RESOLVED — this is exactly why P6 fails. Restoring it would need a non-membership argument against a revocation accumulator, listed as open work. The paper reports this as a guarantee that does NOT compose, overturning the naive intuition that a zero-knowledge lane strictly dominates a cleartext one.

Beyond the failed properties, three deployment-level limitations and a specification gap remain open. None is claimed solved.

• ▸Clock dependence: the freshness condition is two-sided, so clock skew between independent organizations consumes the acceptance window and produces legitimate rejections indistinguishable from attack. Synchronization becomes part of the security model, and the retention-vs-freshness bound must be maintained as an explicit invariant.
• ▸Audit durability: persistence of the audit record is best-effort and drops events precisely under peak load — the regime one most wants recorded. A drop counter is the minimum and a durable outbox the correct answer; neither is implemented.
• ▸Evaluation scale: all figures are from a bench. Validation under intended conditions — several independent organizations each running an agent population continuously for days over a shared backbone, with frontier models deciding and delegating — has NOT been performed.
• ▸Specification gap: the cleartext layer is specifiable (the ordered checks, the closed-by-default invariant, the retention/freshness relation, the rejection vocabulary, the public-statement format). The circuit is not specifiable on the same terms — two implementations that both “produce a proof” do not interoperate unless their constraint systems agree constraint by constraint — and a responsible specification would need conformance vectors and a second independent implementation that do not yet exist. The source is also not publicly available at the time of writing except for the exercisable test-network verifier.

Strip away the specific cryptography and the following engineering practices generalize to any accountable or verifiable agent system. Each is drawn from a concrete finding in the case study.

Enforce containment below the agent, not in it

If a plan-proposing component can be manipulated, it cannot be trusted to bound its own delegations. Make attenuation hold by construction (per-hop scope-containment checks), so the guarantee survives a manipulated or misconfigured agent.

Accept if and only if provable

When you run both a cleartext enforcement path and a proof path, never let the enforcement path accept something the proof path cannot demonstrate. It costs expressiveness — pay it explicitly rather than let the paths silently diverge.

Fail closed, and make the absence of a bypass the control

A check you can route around is not a control. The guarantee lives in there being no alternate path and no caller-side shortcut — and in verify() returning false rather than throwing.

Make at-most-once an atomic operation

Express replay prevention as a single uniqueness-constrained insertion, not check-then-write; share the store across replicas; and fail closed (reject) when the store is unreachable, because a local fallback loses the property, not just durability.

Enumerate each lane’s guarantee set

Do not assume a privacy-preserving lane dominates a cleartext one. List what each lane guarantees and compare explicitly — some guarantees (like revocation) do not compose with hiding the witness.

Default accountability layers to advisory

A layer that can veto silently is itself an authority needing its own accountability. Default to audit-and-trace; make blocking opt-in.

Treat canonical encoding as part of the mechanism

Once signatures exist, byte-level encoding differences break interoperability silently. Specify the exact bytes.

Attribute every measurement; specify separately from testing

Report numbers as “the prototype reports … under these conditions,” never as universal properties. And write the specification down: three real defects here surfaced only when guarantees were stated precisely, after passing tests and review.

A synthetic, didactic checklist for a team considering a verifiable-delegation layer — derived from this case study’s conditions, properties and limitations.

1. 1Confirm the preconditions: authority is delegated across a trust boundary (A1), principals hold and honour signing keys (A2), and your actions form a finite set over which containment is decidable (A3). If A3 does not hold, stop — the guarantee’s strength is bounded by your action ontology.
2. 2Decide the action granularity deliberately: coarse types mean an in-scope-but-harmful action is admitted correctly. Choose the finest ontology whose containment you can actually decide.
3. 3Pick lanes: cleartext enforcement for the hot path; add the proof lane only where third parties need disclosure-free verification. Remember the proof lane does not carry revocation or current-validity.
4. 4Choose a proof backend by its declared property vector (ZK? succinct? ceremony? quantum-resistant? proves full check or fragment?) — and verify it proves the FULL check if you need signatures attested.
5. 5Make the replay guard atomic and shared, set retention > freshness + clock skew, and refuse to start if the relation does not hold.
6. 6Treat clock skew as a security parameter, add a drop counter (or a durable outbox) for audit, and do not present bench numbers as production guarantees.
7. 7Write the specification down before you ship, and keep enforcement and proof paths in lockstep under “accept iff provable.”

Expected direction: Honest claims: (1) an injected agent still cannot authorize beyond its own granted scope (G1/P1, enforced per hop); (2) forged or tampered artefacts and reused chains are rejected (G3/P2); (3) a third party can verify a delegation proof without being shown the chain (G6), including via a read-only on-chain verifier. Non-guarantees: (A) the injected agent is NOT prevented from issuing a wrong-but-in-scope delegation — the layer bounds what it can authorize, not what it can be induced to attempt; (B) a proof does NOT establish current validity or support revocation (P5/P6 fail) and does not bind the exact stored credentials (P7), so “still valid” cannot be shown on the proof lane alone.

Which cryptographic assumptions underlie the guarantees, and what is pointedly NOT assumed?

EUF-CMA security of the signature scheme, collision resistance of the hash, and knowledge soundness of the proof system (plus correct verifier execution); it is NOT assumed that the root authority is reachable at verification time.

For an induced (manipulated) delegator, state the guarantee and the non-guarantee.

Guaranteed: the induced credential cannot exceed the issuer’s own scope (G1). Not guaranteed: the induced delegation is still issued — within legitimate scope a manipulated agent can delegate wrongly and every check passes.

Which two requirements fail to compose, and what property fails as a result?

Optional non-disclosure (R4) and revocation (implied by R2) do not compose, because revocation must range over the chain the proof lane hides; property P6 fails as a result.

Why should an accountability layer default to advisory rather than blocking?

Because a layer able to veto silently is itself an authority that would require its own accountability; defaulting to audit-and-trace keeps it observable, with blocking as an explicit opt-in.