ZK in agents: the delegated-authorization problem

Understand why delegated authorization across mutually distrusting organizations is hard for autonomous agent populations, the threat model a zero-knowledge delegation layer is built against, and the exact requirements and conditions of applicability the reference paper sets out — including what such a layer deliberately does NOT secure.

Track

Research

Module

5 · Research case studies

Prerequisites

Digital signatures · What is a zero-knowledge proof · Delegation chains

An autonomous agent performs an action on a resource it does not own. Later, a third party — an auditor, a peer, a contract on a public ledger — asks a single question: was this authorized, and by whom? In a population of agents belonging to mutually distrusting organizations, that question has no deployed answer. The case study this lesson is based on is an engineering paper that builds an accountability layer for exactly this setting, and reports what building it taught. We transform its concepts here; we do not copy it, and we mark throughout which claims are proven, which are only tested, and which are only measured.

Three mechanisms are used in practice today, and each fails structurally. A bearer token certifies that its holder may act, but records neither the granting authority nor the limits of the grant. An audit log records that an event occurred, but it is produced by the very party whose conduct is in question. A per-tenant policy table states that an action is permitted under local policy, which gives a party in a different administrative domain no reason to believe anything at all.

Delegation between programs is old; cross-domain authorization is old. What is new is the shape of the deployment, in four respects the paper names. The first three hold for any population of autonomous agents regardless of internal architecture; the fourth holds specifically when the plan-proposing component is stochastic (for example a language model inside a belief-desire-intention runtime).

The delegating principal may be stochastic

Classical delegation assumes the authorizing entity is deterministic software whose scope decisions follow from its code. A component that proposes plans from context an adversary can partly control does not satisfy that assumption: prompt injection can induce a delegation that no bug caused and no code review would catch. So attenuation must be a containment mechanism that holds BY CONSTRUCTION, not by trusting a possibly-manipulated component to bound itself.

Chains are generated at run time, not designed

In a public-key infrastructure, chain depth is an institutional artefact: small, stable, known in advance. In an agent population, an orchestrator spawns sub-agents per task, so depth and shape are data-dependent and vary between executions. Depth therefore becomes a property of how a task was decomposed.

Identities are ephemeral

Sub-agents are created and discarded within a single task, at rates and lifetimes for which revocation-list infrastructure is the wrong instrument. Short validity windows and freshness bounds do the work revocation lists would do elsewhere.

Crossing organizational boundaries is the default

Tool-invocation and agent-to-agent protocols place calls across administrative domains as ordinary behaviour, and surveyed practice shows authentication at those boundaries is largely absent.

Put together, the requirement moves: record who acted in order to prove, to a party outside the exchange, that the action was within an authority no participant could have widened — while the root authority is offline and intermediaries keep their internal structure private.

The paper is careful to state what must hold for the mechanism to transfer to a reader’s own setting, rather than let it be inferred. Three conditions must hold:

• ▸A1 — Authority is delegated across a trust boundary, so that the party checking is not the party that granted.
• ▸A2 — Principals hold signing keys and are willing to be bound by their signatures.
• ▸A3 — The actions to be authorized are expressible as a finite set over which containment (is this action-type inside that scope?) is decidable.

A3 is where a deployment succeeds or fails, and it is a modelling condition, not a cryptographic one. The layer authorizes action TYPES, so the deployment must supply a type system — a set of action names over which containment is decidable — fixed before any credential is issued. What does NOT have to hold: any particular agent architecture, the presence of a stochastic component, a shared secret between parties, or the granting authority being reachable at verification time.

This is the most important honesty point in the whole case study, and the paper states it plainly: the layer does not secure agents and should not be described as doing so. What it produces is a set of guarantees about the credential and the reception path, not about the agent that presented them. Those guarantees survive the agent being replaced, retrained, misconfigured, or induced — because none of them was ever a statement about the agent.

Securing the agent itself (its reasoning quality, its resistance to manipulation, the correctness of its self-reported outcomes) remains a separate discipline with a separate literature. The delegation layer neither substitutes for it nor waits on it. A valid proof of delegation is proof of authority, never proof of judgement.

The setting is mutually distrusting organizations. A root authority issues the first credential of a chain; intermediaries sub-delegate; a leaf agent acts; a verifier — another agent, an auditor, or a contract on a public ledger — decides. The analysis assumes EUF-CMA security of the signature scheme, collision resistance of the hash, knowledge soundness of the proof system under its stated assumptions, and correct execution by the verifier. It does NOT assume the root authority is reachable at verification time.

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.

The paper also models an INDUCED delegator: an agent whose deciding component is manipulated into issuing a delegation it would not otherwise issue. Here G1 bounds the damage — the induced credential cannot exceed the issuer’s own scope — but it does NOT prevent the delegation itself. The layer bounds what an induced agent can authorize, not what it can be induced to attempt within that bound.

Explicitly out of scope: misuse of legitimately held authority, collusion within granted scopes, key compromise, the correctness of self-reported outcomes, and the reasoning quality of any stochastic component.

From that deployment context, the case study derives six requirements. Two of them are in tension, which is itself a finding rather than a flaw.

1. 1R1 Offline root — authorization must be checkable without contacting the root authority.
2. 2R2 Structural attenuation — no participant may widen authority, and this must hold by construction, not by the delegating agent’s compliance.
3. 3R3 Third-party verifiability — a party outside the exchange must be able to check authorization without privileged access to any participant’s infrastructure.
4. 4R4 Optional non-disclosure — a delegator must be able to demonstrate authorization without revealing its internal delegation structure.
5. 5R5 Enforcement at line rate — the reception path must decide per message at live rates, concurrently, without an authorization-server round trip.
6. 6R6 Substitutability of cryptography — no architectural commitment to a single proof system, since the right choice is an open question and expected to change.

Expected direction: Examples: (1) it does not establish the action was correct or safe — authorization is over the action TYPE, not its content, so a harmful-but-in-scope order verifies; (2) it does not establish the delegating agent was not manipulated — an induced delegator is bounded by G1 but not prevented, so the delegation may be one it would not otherwise have issued; (3) depending on the lane, it may not establish the credential is still valid — a proof can attest a past authorization shape without reflecting current expiry or revocation (covered in later lessons).

Why do a bearer token, an audit log, and a per-tenant policy table each fail as answers to “was this authorized, and by whom?” across a trust boundary?

A bearer token records neither the granting authority nor the grant’s limits; an audit log is produced by the party whose conduct is in question; a policy table asserts only local permission, giving a party in another domain no reason to believe anything.

What exactly does condition A3 require, and why is it the make-or-break condition?

A3 requires the authorizable actions to form a finite set over which containment is decidable; the layer authorizes action types, so the deployment must supply that type ontology up front. It is make-or-break because the guarantee’s strength is bounded above by the granularity of that ontology.

For an induced delegator, what does the layer guarantee and what does it not?

It guarantees (G1) the induced credential cannot exceed the issuer’s own scope; it does not prevent the induced delegation from being issued at all.

Which two requirements are in unresolved tension, and what is the consequence?

Optional non-disclosure (R4) and the revocation obligation implied by structural attenuation (R2); the paper reports it could not compose them and carries it as a known limitation, not a solved problem.