Cryptographically verifiable authorization for autonomous AI agents: a falsifiable hypothesis and proof of concept

1 Introduction

Autonomous AI agents are no longer passive software clients. They are increasingly designed to invoke tools, call APIs, access protected resources, construct multi-step action sequences, delegate subtasks, and act on external resources with limited human supervision. This transition from deterministic client behavior to autonomous, context-dependent request generation changes the security object over which authorization mechanisms must reason. In such systems, it is insufficient to establish only who or what an agent is, or whether a credential has been delegated; the system must determine whether a concrete request, produced by a concrete agent under a concrete execution context, satisfies an applicable policy.

Let A_*i* ∈ A denotes an autonomous agent, q_*i* an authorization request issued by A_*i*, α a requested action to execute, res a concrete resource to access, c an execution context, and P_*j* an applicable policy (the symbol P is reserved for the set of policies, Subsection 3.1). The distinction motivating this study can be expressed as

AuthN(Ai)⇏AuthZ(Ai,α,res,c,Pj)(1)

or in its simplified form:

AuthN(Ai)⇏AuthZ(qi).(2)

The symbol ⇏ in Equations 1 and 2 is used intentionally. It does not denote message flow, but logical non-implication: Authentication or delegation may be necessary for authorization, but neither is sufficient to establish that a concrete request is authorized.

Similarly, if a principal user U delegates a capability κ to agent A_*i*:

Delegate(U,Ai,κ)⇏AuthZ(qi).(3)

As Equation 3 indicates, delegation may establish authority over a broad class of operations, while the permissibility of a concrete request q_*i* may still depend on the target resource (res ∈ R), the execution context (c, which may encode risk level, environment classification, or session state), the applicable policy version (pid_*j*), and temporal validity (t). These attributes are defined formally as components of the authorization request in Subsection 3.1; they are enumerated here to make explicit that delegation alone does not determine the permissibility of any specific request.

This observation is not isolated to the present work. Recent institutional analyses have characterized what ISACA (Gupta V., 2025) terms “the looming authorization crisis” (the systematic failure of existing IAM frameworks, including OAuth 2.0 (Hardt, 2012), OpenID Connect, and SAML) when applied to agentic systems that violate their foundational assumptions of deterministic behavior and a single authenticated principal. The OpenID Foundation (South et al., 2025) has similarly identified the insufficiency of adapting existing protocols and proposed new identity management primitives for agentic contexts. The present work complements these analyses by providing a formal characterization of the gap: not merely as an architectural insufficiency, but as a missing security property: namely, the absence of a cryptographically verifiable relation binding a specific agent request to policy satisfaction.

This gap has become consequential only recently, as AI agents have transitioned from controlled pipelines to open agentic architectures, that is, systems in which an agent may autonomously select tools, construct multi-step action plans, and act upon external resources in ways not anticipated at deployment time. In this setting, the permissibility of a concrete request cannot be determined at authentication time but must be evaluated at request time against a policy that may depend on dynamic runtime attributes.

Recent work has advanced decentralized agent identity (Liu et al., 2025), accountable execution (Lin et al., 2025), zero-trust agent architectures (Huang et al., 2026), ZKP-based policy compliance (Adapala and Alugubelly, 2025), delegation, and privacy-preserving audit. A zero-knowledge proof (ZKP) is a cryptographic protocol in which a prover demonstrates the truth of a statement to a verifier without revealing any information beyond the validity of that statement itself (Goldwasser et al., 2019). The contribution of this study is therefore not the generic application of zero-knowledge proofs to agentic systems. Instead, we investigate a narrower and more precise question: whether authorization itself can be represented as a request-bound cryptographically verifiable relation, distinct from identity authentication, capability delegation, and **post-hoc audit**. The relevant statement is therefore not merely that an agent owns a credential, corresponds to a registered identity, or executes approved code. The statement of interest is whether a specific authorization request is supported by private attributes and contextual information that satisfy an applicable policy.

We formulate the following central hypothesis:

• H1—Cryptographically Verifiable Agent Authorization Hypothesis. Authorization decisions for autonomous AI agents can be represented as cryptographically verifiable relations that jointly bind an agent principal, a concrete authorization request, an execution context, and satisfaction of an applicable policy, while selectively preserving the confidentiality of private authorization attributes.

We denote by R_*CVA* the relation underlying cryptographically verifiable authorization (CVA). At a high level, x encodes the public authorization statement (comprising the agent's public identifier), a commitment to the requested action, a context commitment, a policy identifier, and freshness parameters, while w encodes the private witness, including the agent's secret, private authorization attributes, and the preimages of the public commitments. We define cryptographically verifiable authorization as the ability of a prover to produce evidence π showing that a public authorization statement x is supported by private witness data w that satisfy an authorization relation R_*CVA*, without revealing w.

Formally, we postulate the existence of a relation:

RCVA(x,w)∈{0,1}.(4)

Let λ denotes the cryptographic security parameter. The proof-system parameters are generated with respect to the authorization relation:

pp←Setup(1λ,RCVA),(5)

where pp abstracts the public parameter material required for proving and verification, such as circuit-specific proving and verification keys in a SNARK implementation. Let π denotes the generated proof. Then:

π←Prove(pp,x,w),(6)

and a verifier accepts if:

VerifyAuth(pp,x,π)=1.(7)

VerifyAuth denotes authorization-level proof verification. Intuitively, x captures what the verifier is allowed to know, while w captures what the prover must know but should not disclose. VerifyAuth invokes the verifier of the underlying ZKP system over the public statement x and proof π. Stateful checks, such as replay protection, are modeled separately. This proof system enables a verifier to establish that an authorization relation holds without learning the private witness, yielding the following conceptual separation:

Identity Evidence≢Authorization Evidence≢Execution Evidence.(8)

We use the term evidence object to denote the cryptographic, procedural, or runtime artifact presented to justify a security-relevant claim about an agent. In agentic systems, as Equation 8 indicates, different evidence objects support different claims. Identity evidence supports claims about who or what an agent is. Delegation evidence supports claims about authority transferred from a principal to an agent. Authorization evidence supports claims about whether a concrete request satisfies a policy under a given context. Execution evidence supports claims about what action was actually executed at runtime. Audit evidence supports claims about historical traceability after execution.

We refer to this missing object as authorization evidence: evidence that a concrete agent request, rather than merely an agent identity or delegated credential, satisfies an applicable policy under a given context.

This study makes three contributions. First, it introduces a preliminary formal abstraction of cryptographically verifiable agent authorization as a request-bound security relation. Second, it defines a compact set of candidate properties addressing soundness, principal binding, request binding, policy binding, and replay resistance. Third, it maps an existing zero-knowledge authorization prototype to the abstraction and uses it as evidence of constructive feasibility.

2 Related work and positioning

Zero-knowledge proofs have progressively moved from foundational interactive protocols (Goldwasser et al., 2019) to practical non-interactive constructions suitable for real-world deployment. Groth16 (Groth, 2016) established the basis for efficient pairing-based non-interactive arguments; STARKs (Ben-Sasson et al., 2018) removed trusted-setup requirements at the cost of larger proofs; Bulletproofs (Bünz et al., 2018) provided efficient range proofs without trusted setup. Systematic surveys (Sheybani et al., 2025; Gupta S., 2025) confirm the increasing maturity of ZKP frameworks and tooling, while applied work demonstrates their viability in distributed authentication contexts (Nait Cherif et al., 2023; Mo et al., 2025; Xiang et al., 2025; Gopal, 2025).

In the agentic domain, DIAP (Liu et al., 2025) addresses decentralized agent identity and ownership via ZKP over a hybrid P2P stack. Huang et al. (2026) investigate zero-trust identity architectures and fine-grained access control for agentic AI. Binding Agent ID (Lin et al., 2025) advances user-to-agent-to-code binding with execution provenance. The Aegis Protocol (Adapala and Alugubelly, 2025) incorporates ZKP-based policy compliance into a broader agent security architecture combining decentralized identifiers and post-quantum cryptography. Adjacent work explores privacy-preserving audit of agent communications (Jing and Qi, 2025) and verifiable delegation in agent interaction protocols. These works establish the cryptographic feasibility of proving private statements without disclosure; however, the authorization object studied here is not a generic statement but a request-specific relation involving principal, request, context, and policy.

These systems demonstrate that agent identity, execution provenance, delegation, and policy compliance can be made verifiable. The remaining question addressed in this study is whether authorization itself can be isolated as an independent cryptographic relation.

The resulting landscape motivates an explicit separation among identity, delegation, policy compliance, audit, ZKP-based verification, and request-specific authorization, as summarized in Table 1.

Table 1. Positioning of related work with respect to authorization-relevant security properties.

The intended gap is deliberately narrow: existing study substantially advances identity, delegation, policy compliance, and audit, whereas request-bound cryptographically verifiable authorization remains insufficiently characterized as an independent security abstraction. This study focuses specifically on the relation among principal, request, context, and policy. Table 1 reveals that while ZKP-based approaches have been applied to agent identity, code binding, policy compliance, and audit, no existing work explicitly models authorization as a request-bound cryptographically verifiable relation. This motivates the abstraction introduced in Section 3. As noted in Section 1, this claim concerns the explicit formalization of authorization as a request-bound cryptographic relation, not the novelty of applying zero-knowledge proofs to agentic systems in general, which DIAP, Aegis, and Huang et al. already establish (see Table 1).

Adjacent work by Prakash (2026) introduces Invocation-Bound Capability Tokens for verifiable delegation across MCP and A2A, demonstrating sub-millisecond verification overhead in reference implementations evaluated in a real multi-agent deployment. While AIP advances the delegation and identity layers with cryptographic token chains, it does not model authorization as a request-bound relation with verifiable policy satisfaction and private witness; the two contributions address complementary layers of the agentic trust stack.

The general phenomenon underlying this gap is not new: It is structurally related to the classical confused-deputy problem (Hardy, 1988) and to time-of-check-to-time-of-use (TOCTOU) race conditions (Bishop and Dilger, 1996) and has recently been shown to manifest concretely in LLM-enabled agents (Lilienthal and Hong, 2025). To our knowledge, however, no existing work formalizes this gap (the question of whether the action authorized at verification time is the same action subsequently executed) as a structural property of a cryptographically verifiable authorization relation, distinguishing authorization-request binding from runtime execution binding within a ZKP-based construction. This structural observation, formalized in Subsection 4.5, is not explicitly addressed in current agentic security frameworks and motivates a distinct line of formal inquiry.

3 Preliminary formal model

3.1 System and request model

We model an agentic authorization environment as a tuple:

S=(A,G,T,R,P),(9)

where A is the set of autonomous agents, G the set of authorization gateways or verifiers, T the set of external tools or callable services, R the set of protected resources, and P the set of authorization policies. To refer to a specific protected resource in Equation 9, we write res ∈ R. Unless otherwise stated, the model developed in this section addresses a single agent-gateway authorization interaction; its extension to multi-hop delegation chains is discussed as a structural limitation in Section 6.

Let λ denotes the cryptographic security parameter. The notation {0, 1}^λ denotes the set of bitstrings of length λ. An agent A_*i* ∈ A holds private key material denoted as sk:

ski∈{0,1}λ,(10)

and exposes a public identity commitment:

idi=CommitID(ski,ρi)(11)

where CommitID denotes a randomized cryptographic commitment scheme for agent identity, sk_*i* in Equation 10 is the private secret of A_*i*, and ρ_*i* is the commitment randomness, with ρi∈{0,1}λ. In standard cryptographic notation, this corresponds to a commitment of the form Com(m; r). This formulation (Pedersen, 1992) is consistent with privacy-preserving and anonymous authentication protocols, where commitments allow a prover to bind to secret information without disclosing it. The commitment-based identifier of Equation 11 allows the model to represent agent binding without requiring direct disclosure of the underlying secret material. In the proof-of-concept implementation, this abstraction is instantiated in simplified form as id_*i* = Poseidon(sk_*i*) (Grassi et al., 2021), primarily for ZK-circuit efficiency. This provides principal binding under hash assumptions but does not realize the randomized hiding semantics of the general commitment-based model; this distinction is acknowledged as a limitation.

We define an authorization request as

qi=(idi,α,res,c,pidj,n,t)(12)

where the tuple q_*i* is designed to be minimal but sufficient: id_*i* commits to the requesting agent A_*i*, α is the requested action, res ∈ R identifies the concrete protected resource, c, the execution context, captures runtime-dependent attributes that may affect policy evaluation, n is a nonce, and t is a validity epoch or timestamp. We reserve P for the set of authorization policies. A concrete policy is denoted as P_*j* ∈ P, following the same indexing convention as A_*i* ∈ A. The versioned policy identifier pid_*j* = H_*P*(policy_code_*j* ∥ version_*j*) (not to be confused with the proof π introduced in Equation 6) is a compact cryptographic reference to P_*j*, used in the public statement to bind the proof to a specific policy version without encoding the full policy in the circuit. Additional attributes such as risk scores or session identifiers may be incorporated into c without modifying the core model structure.

An action may be decomposed as

α=(tool,operation,args), tool∈T.(13)

Where request data are sensitive, the public commitment is computed as

hq=Hq(Encode(domain,tool,operation,res,args)),(14)

where Encode denotes a deterministic canonical serialization function. We denote by

qpriv:=(domain,tool,operation,res,args)(15)

the private canonical representation of the request committed in Equation 14; the execution context c is committed separately through h_*c* (see Subsection 3.2), while the remaining fields of q_*i* (id_*i*, pid_*j*, n, t) appear in the clear in the public statement. Canonical encoding of the representation in Equation 15 is required to avoid ambiguity between semantically equivalent but byte-distinct requests. Without canonical encoding, two semantically equivalent requests may yield different commitments, while two differently serialized requests may create ambiguity about what was actually authorized. Throughout the study, H_*q*, H_*c*, and H_*P* denote domain-separated collision-resistant hash functions, or domain-separated invocations of the same underlying hash primitive. The subscript identifies the semantic domain of the commitment: request, context, or policy. The lowercase values h_*q*, h_*c*, and pid_*j* denote the resulting public commitments or identifiers.

3.2 Public statement and private witness

The public statement is defined as

x=(idi,hq,hc,pidj,n,t).(16)

As established in Subsection 3.1, h_*q* = H_*q*(Encode(q_*priv*)) is the public commitment to the authorization request, as defined in Equation 14. Similarly, h_*c* = H_*c*(Encode(c_*priv*)) is a commitment to security-relevant contextual attributes, where H_*c* is a collision-resistant hash function applied to a canonical serialization of the private context. The inclusion of h_*c* in the public statement extends the binding surface of the relation beyond the request itself to encompass runtime-dependent conditions (such as environment classification, resource state, or session attributes) that may affect policy evaluation. While h_*c* is part of the formal model, its implementation is left open in the current proof of concept and identified as a priority for future implementation.

The private witness is

w=(ski,ρi,attrsi,qpriv,cpriv)(17)

where attrs_*i* encodes private authorization attributes not revealed to the verifier, q_*priv* denotes the private canonical request known by the prover, while h_*q* is its public commitment. Similarly, c_*priv* denotes private contextual attributes, while h_*c* is their public commitment. The value ρ_*i* in Equation 17 is the randomness required to open the identity commitment id_*i*.

The separation between x and w captures the privacy objective of the model: the verifier observes the statement required for authorization, while sensitive attributes and preimages remain private.

3.3 Core authorization relation

The preliminary CVA relation is defined as R_*CVA*(x, w) = 1 if and only if the following constraints are jointly satisfied:

CommitID(ski,ρi)=idi,(18)

Hq(Encode(qpriv))=hq(19)

and

Hc(Encode(cpriv))=hc(20)

where h_*c* is the context commitment introduced in Equation 16 and

Pj(attrsi,qpriv,cpriv)=1.(21)

Here each policy P_*j* ∈ P is modeled as a deterministic predicate over (attrs_*i*, q_*priv*, c_*priv*), and P_*j* is the policy referenced by the identifier pid_*j* contained in the public statement x. In compact form:

RCVA=BindPrincipal∧BindRequest∧BindContext∧SatisfyPolicy.(22)

We define BindPrincipal as

BindPrincipal:=[CommitID(ski,ρi)=idi].(23)

The intended proof of knowledge is

π=PoK{(ski,ρi,attrsi,qpriv,cpriv):RCVA(x,w)=1}.(24)

Equivalently, Equation 24 states that π proves knowledge of a witness w satisfying R_*CVA*(x, w) = 1. Each conjunct in R_*CVA* rules out a distinct class of transfer attack. Omitting BindPrincipal, Equation 23, enables cross-principal reuse; omitting BindRequest enables policy-satisfying proofs to authorize unintended actions; omitting BindContext weakens context-dependent authorization; and omitting SatisfyPolicy decouples the proof from the authorization decision itself. Their conjunction is the minimal condition for request-specific authorization verifiability.

This construction proves satisfaction of a committed-request relation; it does not prove the internal reasoning or deliberative process of the agent:

Request Commitment≠Internal Agent Intent.(25)

Equation 25 therefore delimits the semantic scope of the evidence produced. Freshness depends on external mutable state and is therefore separated from the stateless cryptographic core:

Accept(x,π)=VerifyAuth(pp,x,π)∧Fresh(n,t,N)(26)

where N is the set of previously consumed nonces maintained by the gateway.

3.4 Threat model

We consider a probabilistic polynomial-time adversary Adv operating against the CVA authorization workflow. The adversary may observe, intercept, and replay authorization statements and proofs; substitute or forge public agent identifiers; modify or substitute request commitments; present proofs under policy contexts different from those for which they were generated; and control unauthorized or partially authorized agents. The adversary cannot break the assumed cryptographic primitives, directly obtain honest party secrets, or compromise the trusted authorization gateway. Although gateway compromise falls outside the adversary's assumed capabilities, we note for robustness that, where the gateway compromised, freshness enforcement (see Subsection 4.4) would be voided, since nonce-set and timestamp-window state are maintained gateway-side. However, principal binding, authorization-request binding, and policy binding remain governed by the cryptographic core of Equations 18–21 and are not weakened by gateway compromise, since these guarantees depend on SNARK verification over the public statement, not on gateway-held state.

These capabilities identify five primary attack classes against the proposed abstraction. First, proof forgery: the adversary attempts to produce an accepting proof for a statement for which no valid witness exists, addressed by Authorization Soundness (see Subsection 4.1). Second, cross-principal transfer: the adversary attempts to reuse a valid proof generated for principal id_*i* to authorize a request under a different principal id_*k*, addressed by Principal Binding (see Subsection 4.2). Third, cross-request transfer: the adversary attempts to reuse a proof bound to request q_*i* to authorize a distinct request qi′, addressed by Authorization-Request Binding (see Subsection 4.3). Fourth, cross-policy transfer: the adversary attempts to present a proof generated under one policy identifier as evidence under another policy identifier, addressed by Policy Binding in Equation 31. Fifth, replay: the adversary reuses a previously accepted proof to obtain a second authorization, addressed by Replay Resistance (see Subsection 4.4). The goal of this adversary model is not to cover all failures of autonomous execution but to isolate attacks that target authorization evidence itself. A complete symbolic adversary model for multi-agent authorization chains is left as future work.

4 Candidate security properties

The following properties are intended to address the principal attack vectors identified in the threat model of Subsection 3.4: proof forgery without a valid witness, cross-principal proof transfer, cross-request proof transfer, cross-policy proof transfer, and proof reuse. Complete reductions of these properties to standard cryptographic assumptions, in particular the soundness and knowledge-soundness of the underlying proof system and the binding property of CommitID, are left as part of the future research agenda. The separation between authorization-request binding and runtime execution binding in Subsection 4.5 is included as a structural observation rather than a game-based property since it identifies a limitation of the ZKP authorization layer itself. Two further properties assessed in Table 2 are not stated as separate games: Attribute privacy is inherited directly from the zero-knowledge property of the underlying proof system, and context binding is captured structurally as the conjunct (Equation 20) of R_*CVA*, with its transfer-resistance form given in Equation 36. Accordingly, each property formalized in Subsections 4.1–4.4 is stated as a candidate definition: Its status as an established security guarantee, rather than a well-motivated design target, remains contingent on the reduction arguments discussed at the end of this section.

Table 2. Mapping between formal candidate properties and prototype mechanisms.

4.1 Authorization soundness

Let Adv denotes a probabilistic polynomial-time adversary; the adversary should not be able to produce an accepted proof for a statement for which no valid witness exists. The adversary wins the authorization soundness game GameAdvauth-sound(λ) if it outputs (x^⋆, π^⋆) such that:

VerifyAuth(pp,x⋆,π⋆)=1∧∄ w:RCVA(x⋆,w)=1.(27)

A secure construction requires

AdvAdvauth-sound(λ)≤negl(λ).(28)

The bound of Equation 28 follows from two assumptions. First, the underlying proof system must satisfy knowledge-soundness: An accepting proof for a statement should imply the existence of an extractable witness for the encoded relation. Second, the implemented circuit and verification metadata must correctly encode and bind the intended relation R_*CVA*. Thus, an adversary that wins the game in Equation 27 must either violate knowledge-soundness of the proof system or exploit a mismatch between the intended CVA relation and its encoded implementation. A complete reduction, including explicit extractor and simulation arguments, is left for future work.

4.2 Principal binding

We use Pr[·] to denote the probability of an event over the randomness of the adversary, the proof system, and the experiment. Let x_*i* = (id_*i*, h_*q*, h_*c*, pid_*j*, n, t) and x_*k* = (id_*k*, h_*q*, h_*c*, pid_*j*, n, t) with id_*i* ≠ id_*k*. A proof π_*i* generated for principal id_*i* must not verify under x_*k*:

Pr[VerifyAuth(pp,xk,πi)=1]≤negl(λ).(29)

Principal binding relies on the binding property of CommitID and on the soundness of the proof system.

4.3 Authorization-request binding

Let qi≠qi′ be two distinct requests whose private canonical components differ, with commitments h_*q* = H_*q*(Encode(q_*priv*)) and hq′=Hq(Encode(qpriv′)). Let π_*q* denotes a proof generated for the statement x_*q* containing h_*q*, and xq′ the statement containing hq′. A proof bound to q_*i* must not authorize qi′:

Pr[VerifyAuth(pp,xq′,πq)=1]≤negl(λ).(30)

This property is central to the proposed abstraction: abstract policy satisfaction alone is insufficient if the authorization evidence can be detached from the specific request to which it applies.

A related condition, which we term Policy Binding, establishes that a proof generated under policy version pid_*j* must not verify as valid evidence under a distinct policy version pid_*k*:

pidj≠pidk⇒Pr[VerifyAuth(pp,xpidk,πpidj)=1]≤negl(λ).(31)

This property is enforced by including pid_*j* in the public statement x and constraining the circuit to evaluate the policy identified by pid_*j* as defined in Subsection 3.1.

An analogous condition, which we term Context Binding, requires that a proof generated under one context commitment must not verify under a statement carrying a distinct context commitment. Let

hc=Hc(Encode(cpriv))(32)

and

hc′=Hc(Encode(cpriv′)), cpriv≠cpriv′.(33)

Under collision resistance of H_*c*, cpriv≠cpriv′ implies hc≠hc′, as given in Equations 32 and 33. Let

xc=(idi,hq,hc,pidj,n,t)(34)

and

xc′=(idi,hq,hc′,pidj,n,t).(35)

A proof π_*c* generated for x_*c* in Equation 34 must not verify under xc′ in Equation 35:

Pr[VerifyAuth(pp,xc′,πc)=1]≤negl(λ).(36)

This property relies on the collision resistance of H_*c*, canonical context encoding, and the correct inclusion of h_*c* as a constrained public input of R_CVA. Context Binding prevents substitution of the context commitment at authorization time; it does not, by itself, prevent context drift between authorization and subsequent execution, which is addressed separately as a TOCTOU limitation in Section 6.

4.4 Replay resistance

Let N denotes the consumed nonce set defined in Equation 26. Once a request with nonce n has been successfully accepted, the gateway updates its replay-control state as follows:

N←N∪{n},(37)

The complete freshness predicate is defined as

Fresh(n,t,N)=1⇔(n∉N)∧(tmin≤t≤tmax)(38)

Fresh(n,t,N)=0⇔(n∈N) ∨ (t<tmin)∨ (t>tmax)(39)

n∈N⇒Fresh(n,t,N)=0.(40)

Equation 38 defines acceptance: a nonce is fresh if it has not been previously consumed and the timestamp falls within the authorized validity window, delimited by the gateway-defined bounds t_min and t_max. Equation 39 captures both replay via nonce reuse and replay via deferred presentation outside the validity window as rejection conditions. Subsequent reuse of n is therefore rejected, as in Equation 40. Equations 39, 40 are the explicit contrapositive forms of Equation 38, stated separately to make the rejection conditions directly enforceable at the gateway.

Replay resistance is a property of the complete authorization workflow and depends on stateful external enforcement at the gateway. The consequence of Fresh(n, t, N) = 0 is that the full acceptance predicate of Equation 26 evaluates to false, regardless of proof validity. The ZK proof binds the request to the public statement, while the gateway enforces single-use semantics through mutable nonce state of Equation 37 and temporal validity checks. Note that gateway-side freshness is meaningful only because n and t are bound to the proof as components of the public statement x: A proof not bound to its nonce could be re-presented by an adversary under a fresh nonce n′ ∉ N, voiding replay control. Statement binding of n and t is therefore a precondition of Subsection 4.4, not an optional design choice.

4.5 Authorization binding is not equivalent to execution binding

A valid proof establishes that a committed request satisfies the authorization relation:

VerifyAuth(pp,xq,π)=1.(41)

This does not imply that the runtime subsequently executes the same request. Formally,

VerifyAuth(pp,xq,π)=1⇏qexec=qauth(42)

where q_*auth* denotes the request committed in the verified statement x_*q*, and q_*exec* denotes the request actually executed by the runtime. Therefore,

Authorization Request Binding≢ Runtime Execution Binding.(43)

The gap recorded in Equation 43 is structural rather than incidental. A ZK circuit is evaluated at proof generation time over a committed representation of the intended request; it has no access to the runtime state at execution time and cannot constrain what the agent subsequently does with the authorization it receives. Closing this gap requires a trust anchor that operates at execution time rather than at proof generation time. Establishing runtime consistency requires an additional trusted evidence mechanism, such as remote attestation, a trusted execution environment, or verifiable execution receipts, beyond the guarantees of the ZKP authorization relation. This constitutes an open problem and is identified as part of the research agenda.

4.6 Informal reduction sketches

The following arguments sketch, at an informal level, how a successful adversary against each of the four properties above could be used to construct an adversary against a standard cryptographic assumption. Since Groth16 is knowledge-sound (Groth, 2016), it is in particular sound: The existence of a knowledge extractor for accepting proofs directly implies that no accepting proof exists for a false statement except with negligible probability. We write AdvGroth16sound(λ) to denote the advantage of a probabilistic polynomial-time algorithm in producing an accepting Groth16 proof for a false statement, AdvHcoll(λ) to denote the advantage of finding a collision under a hash function H, and AdvCommitIDbind(λ) to denote the advantage of finding an alternate opening of CommitID. We invoke knowledge-soundness directly in Subsection 4.1, where witness extraction is required, and rely on the weaker, directly implied soundness property in the remaining sketches, where only the non-existence of an accepting proof for an altered public input is needed. Consistent with Limitation 1 in Section 7, these sketches are informal and do not include an explicit extractor or simulator construction; a complete formal treatment remains future work.

• Authorization Soundness (Subsection 4.1). Let Adv be the adversary defined in Subsection 4.1, winning the game of Equation 27 with non-negligible advantage. By knowledge-soundness of Groth16, there exists a probabilistic polynomial-time extractor Ext that, given the same input distribution as Adv,

Pr[RCVA(x⋆,w)=1:w←Ext(x⋆,π⋆)]≥1-negl(λ).(44)

If extraction succeeds as in Equation 44, then RCVA(x⋆,w)=1 by correctness of the circuit encoding, contradicting the assumption that no valid witness exists for x^⋆; if extraction fails, Adv directly yields an adversary against knowledge-soundness of Groth16. Either branch bounds Adv's advantage by the knowledge-soundness advantage of Groth16, up to the caveat, already noted at the end of Subsection 4.1, that the circuit must correctly encode the intended relation R_*CVA*.

• Principal Binding (Subsection 4.2). An adversary winning the game of Equation 29 can succeed via one of two avenues. First, it may present a proof π_*i*, honestly generated for the statement x_*i* containing id_*i*, as evidence under a statement x_*k* differing only in the identity coordinate (id_*k* ≠ id_*i*). Since Groth16's verification equation is a fixed linear combination over the public inputs, accepting the same proof under two distinct values of a public-input coordinate directly contradicts soundness of Groth16, provided id_*i* is correctly wired as a distinguishing public input in the circuit (the same encoding-correctness caveat as above). Second, the adversary may attempt to find an alternate opening (ski′,ρi′)≠(ski,ρi) with CommitID(ski′,ρi′)=idi, i.e., break the binding property of the identity commitment; since CommitID follows the Pedersen construction (Pedersen, 1992), this reduces directly to the hardness of the discrete logarithm problem in the underlying group. Both avenues combine into the following bound:

AdvAdvprincipal-bind(λ)≤AdvGroth16sound(λ)+AdvCommitIDbind(λ).(45)

• Authorization-Request Binding and Policy Binding (Subsection 4.3). By the same public-input rigidity argument that produced Equation 45, consider an adversary winning either the request-binding game of Equation 30 or the policy-binding game of Equation 31. In either case, the adversary breaks soundness of Groth16 with respect to the corresponding public-input coordinate (h_*q* or pid_*j*, respectively) or breaks collision-resistance of the corresponding hash function (H_*q* or H_*P*). Both properties therefore satisfy the same bound, up to substitution of the coordinate and hash function in Equation 46:

↘AdvAdvreq/policy-bind(λ)≤AdvGroth16sound(λ)+AdvHcoll(λ), H∈{Hq,HP}.(46)

• Replay Resistance (Subsection 4.4). This property is structurally different from the three above and should not be read as reducing to a single hardness assumption. Its cryptographic component follows the same public-input rigidity argument applied to the (n, t) coordinates of the public statement: detaching a proof from its bound nonce and timestamp, and re-presenting it under fresh values, breaks soundness of Groth16 with respect to those coordinates. Its remaining component is not cryptographic but procedural: Given that (n, t) are correctly bound to the proof, replay resistance additionally requires that the gateway correctly and continuously enforces the freshness predicate of Equations 38–40 over its nonce set N. As already noted in Subsection 3.4, this second component depends on gateway integrity and falls outside the cryptographic core of the construction:

AdvAdvreplay(λ)≤AdvGroth16sound(λ)+εgateway,(47)

where ε_gateway denotes the probability that the gateway fails to correctly maintain or enforce the freshness state. If the gateway is compromised, this term of Equation 47 –but not principal, request, or policy binding– is voided.

5 Proof-of-concept implementation

5.1 Scope

To assess the constructive feasibility of selected elements of the CVA abstraction, an executable zero-knowledge authorization prototype was developed and publicly presented at RootedCON Madrid (Llambí-Morillas, 2026a), an independent security conference, prior to the formalization introduced in this study (Llambí-Morillas, 2026b). This artifact is the experimental precursor from which the present hypothesis emerged.

The prototype is not presented as a complete validation of the CVA abstraction. It demonstrates that selected bindings and private policy predicates can be instantiated in an executable pre-authorization workflow, providing constructive evidence of feasibility for the principal- and plan-level binding conjuncts of the CVA abstraction. The architecture follows the conceptual flow shown in Figure 1.

The implementation employs the Groth16 zk-SNARK construction (Groth, 2016) over the bn128 curve, with circuits written in Circom 2.x and proof generation via snarkjs. Groth16 was selected for its minimal proof size and constant verification time, properties favorable for gateway-side enforcement. The trusted setup requirement and the absence of post-quantum security are acknowledged limitations; alternative schemes are identified as part of the comparative evaluation agenda in Section 6. The gateway is implemented as a FastAPI service performing stateless proof verification and stateful replay control.

5.2 Prototype relation

The proof of concept instantiates a restricted version of the general CVA relation introduced in Section 3. As noted in Subsection 3.1, the formal model uses a randomized commitment CommitID(sk_*i*, ρ_*i*); the prototype instantiates this using a randomized two-input Poseidon hash rather than a Pedersen-style commitment, for ZK-circuit efficiency. Therefore, the prototype should be interpreted as an implementation of principal binding and request binding under a hash-based hiding assumption, not as a full realization of the discrete-logarithm-based generalized commitment model.

The public statement verified by the gateway is defined as

xPoC=(idi,hplan,n,t)(48)

where id_*i* denotes the public identifier of the agent, h_*plan* is the public commitment to the plan or requested action sequence, n is a nonce, and t is the validity timestamp or epoch. The public statement of Equation 48 contains only the information required for the verifier to bind the proof to a specific agent, a specific committed plan, and a freshness window; in particular, n and t are bound to the proof as public inputs of the verified statement, as required by the replay precondition of Subsection 4.4.

The corresponding private witness is

wPoC=(ski,ρi,attrsi,plan)(49)

where sk_*i* and ρ_*i* are the private secret and commitment randomness of the agent jointly opening the identity commitment of Equation 51, attrs_*i* denotes private authorization attributes, and plan represents the action sequence or request structure whose public commitment is h_*plan*. These values remain private to the prover and are not disclosed to the gateway.

The prototype relation is defined as

RPoC(xPoC,wPoC)=1(50)

if the following three constraints on Equation 50 are satisfied.

First, the prover must demonstrate knowledge of the private secret corresponding to the public agent identifier. Instantiating Equation 18,

Poseidon(ski,ρi)=idi(51)

this constraint instantiates principal binding in the prototype using the randomized two-input construction Poseidon(sk_*i*, ρ_*i*). Unlike the deterministic single-input form used in an earlier iteration of the prototype, this construction provides randomized hiding under a hash-based assumption on Poseidon (informally, that Poseidon behaves as a random oracle with respect to ρ_*i*), distinct from the discrete-logarithm-based hiding of the general Pedersen-style CommitID construction discussed in Subsection 3.1 and invoked in the reduction sketch of Subsection 4.6. The two constructions satisfy the same functional binding requirement but rest on different cryptographic assumptions; we do not claim the discrete-logarithm reduction of Subsection 4.6 applies to this concrete instantiation.

The randomized two-input construction adds 102 constraints (531 vs. 429) relative to the earlier single-input form, an increase attributable primarily to the additional Poseidon input together with an unrelated policy-check correction applied in the same revision; this overhead is negligible relative to total circuit size and does not measurably affect the witness- or proof-generation times reported in Table 3 (see Subsection 5.5).

Table 3. Proof-of-concept performance characterization (mean ± standard deviation, n = 20 runs, single circuit configuration: 531 constraints, 537 wires, nine private inputs, and five outputs).

All timings have been measured via command-line invocation and therefore include Node.js process startup overhead; they are not library-level microbenchmarks and should not be compared directly against figures obtained via in-process API calls. Measured on an AMD Ryzen 7 7700 (8-core, 3.8 GHz base) with 32 GB RAM, using the WASM prover backend.

Second, the proof must be bound to the plan that the gateway is expected to authorize. As a partial implementation of Equation 19,

SHA256(plan)=hplan(52)

this constraint, Equation 52, provides request binding at the level of the committed plan. It prevents a proof generated for one plan from being reused for a different committed plan, assuming collision resistance of the hash function and canonical encoding of the plan.

Third, the private authorization attributes and the committed plan must satisfy the policy encoded in the circuit. Instantiating Equation 21

PPoC(attrsi,plan)=1.(53)

This condition, Equation 53, represents the policy-satisfaction component of the prototype. The predicate P_*PoC* is implemented as arithmetic constraints in the ZK circuit and therefore captures only the policy logic explicitly encoded at circuit generation time.

Freshness and replay protection are enforced outside the circuit by the authorization gateway:

Fresh(n,t,N)=1(54)

where N is the gateway-maintained set of previously consumed nonces. The separation of Equation 54 is intentional: Proof verification is stateless, whereas replay resistance requires mutable enforcement state. Consequently, freshness is treated as a property of the complete authorization workflow rather than as a guarantee provided solely by the ZK circuit.

In compact form, the proof of concept instantiates

RPoC=BindPrincipalPoseidon∧BindPlanSHA256∧SatisfyPolicyCircuit(55)

with replay resistance enforced externally by the gateway as defined in Equations 38, 39.

The PoC of Equation 55 therefore supports the constructive plausibility of principal binding, plan-level request binding, and private policy satisfaction, while leaving full context binding and runtime execution binding outside the implemented scope. The prototype should therefore be read as an executable witness of the abstraction's feasibility, not as an empirical demonstration that the abstraction is complete.

5.3 Property coverage assessment

The conservative characterization is intentional. The purpose of Table 2 is to expose the distance between the preliminary formal model and the current artifact rather than to overstate prototype coverage.

5.4 Preliminary validation strategy

Property-oriented validation derives test cases directly from the candidate properties. Representative cases include the following: (i) a valid principal issuing a policy-compliant request; (ii) an invalid agent secret; (iii) substitution of the public identity commitment; (iv) modification of the request hash; (v) private attributes failing the encoded policy predicate; (vi) reuse of a previously consumed nonce; and (vii) tampering with public signals. These cases provide structured coverage of the instantiated properties but do not constitute complete empirical security evaluation against arbitrary adversaries.

5.5 Preliminary performance characterization

To ground the operational-viability discussion of Section 6 (RQ3) in concrete data rather than qualitative expectation alone, Table 3 reports circuit size and timing characteristics of the current prototype instantiation.

These figures characterize a single circuit configuration and are not intended to demonstrate empirical scaling behavior across constraint counts; the theoretical constant-time verification property of Groth16 with respect to circuit size is an established property of the proof system, not a claim this benchmark sets out to validate independently. Instructions and the underlying measurement script are included in the associated repository (Llambí-Morillas, 2026b).

6 Discussion and research agenda

The purpose of the preliminary model is not only to propose a construction but also to identify where the guarantees provided by ZKP-based authorization end.

The preliminary model supports four principal observations.

First, the separation among binding layers:

Identity Binding≢Authorization Request Binding ≢Runtime Execution Binding.(56)

A system may correctly authenticate an agent yet fail to bind authorization evidence to a specific request. It may likewise bind evidence to a request without guaranteeing that the same request is executed at runtime. These are structurally distinct security properties requiring separate mechanisms.

Second, the correctness of a proof must not be confused with the normative correctness of the encoded policy. If the implemented relation R_*CVA* does not faithfully encode the intended organizational policy P_*intended* (that is, if R_*CVA*(x, w) = 1 as defined in Equation 4 does not imply P_*intended*(attrs_*i*, q_*priv*, c_*priv*) = 1), then a valid proof may correspond to an incorrectly authorized decision. Policy governance, versioning via pid_*j*, circuit governance, and verification-key distribution therefore constitute first-class security concerns orthogonal to the cryptographic guarantees of the proof system.

Third, dynamic execution introduces a time-of-check-to-time-of-use problem. If verification occurs at time t_*v* and execution at t_*e* > t_*v*, the relevant context may change:

ctv≠cte.(57)

Given the context drift of Equation 57, let Authorized(q, c) denotes the predicate that holds when request q is authorized under context c; formally, when Accept(x_*q*, π) = 1 for a proof π generated under context c, as defined in Equation 26. Consequently,

Authorized(q,ctv)=1⇏Authorized(q,cte)=1.(58)

Equation 58 is thus a context-specific instance of the general authorization-execution gap already identified in Equation 43: whereas Equation 42 concerns drift in the identity of the executed request, (Equation 58) concerns drift in the context under which a fixed request was authorized.

Fourth, a structural observation concerns multi-agent delegation chains. The present model defines the CVA relation for a single agent-gateway interaction, where a prover A_*i* generates a proof for a single authorization request q_*i*. In practice, autonomous agents increasingly operate in orchestrated architectures where A_*i* may delegate a subtask to another agent A_*k*, which may in turn delegate further. In such chains, the authorization question becomes compositional: A_*k* must not only prove that its local request q_*k* satisfies a CVA relation, but also that the delegation from A_*i* to A_*k* preserves, constrains, or attenuates the authorization scope granted upstream.

The current conjuncts of R_*CVA* in Equation 22, including BindPrincipal, BindRequest, and SatisfyPolicy, remain necessary but are not sufficient for multi-hop authorization soundness. A proof that A_*k* satisfies a local policy does not by itself establish that A_*k* was authorized to act under the scope delegated by A_*i*, or that scope has not been expanded across hops. Addressing this gap would require an additional delegation-binding component, such as BindDelegationScope, together with either (i) recursive proof composition—in which each hop proves that it extends and constrains the previous authorization state—or (ii) a delegation-aware witness structure encoding the relevant authorization chain. Informally, extending Equation 22 to a delegation chain A₁ → A₂ → ⋯ → A_*n* would require each hop k to jointly satisfy its local relation and a delegation-binding condition scope_*k* ⊆ scope_*k*−1, ensuring that authorization scope is preserved or narrowed, never expanded, across hops. We deliberately leave this condition unformalized here as its full formalization falls outside the scope of the present work and is reserved for the compositional security analysis identified as future work.

These four observations directly motivate the research questions that structure the future empirical and formal agenda:

RQ1—Necessary Bindings. Which dimensions must be cryptographically bound to prevent proof transfer across principals, requests, contexts, policies, and execution domains? In particular, the present model includes context binding through h_*c* as a formal conjunct in R_*CVA*, but its implementation and the characterization of which contextual attributes are necessary and sufficient for policy-relevant binding remain open. RQ1 subsumes this as a central sub-question. A candidate resolution to the implementation gap noted in RQ1 involves one of two constructions. First, fixed-length canonical padding with domain separation: context attributes are serialized into a fixed-size vector prior to hashing, with unused slots padded to a canonical null value, avoiding the ambiguity that variable-length inputs would otherwise introduce into the arithmetic circuit. Second, a Poseidon-sponge-based construction supporting variable-length absorption, following the general sponge paradigm, would allow h_*c* to commit to a context of arbitrary length without a fixed upper bound at circuit-compilation time, at the cost of additional constraint overhead per absorbed block. Both constructions remain unimplemented in the current prototype and are proposed here as design directions rather than validated mechanisms.

RQ2—Representable Policies. Which classes of agent authorization policies can be efficiently represented as arithmetic ZK relations under practical circuit complexity constraints?

RQ3—Operational Viability. What overhead is introduced by request-bound ZKP authorization under different proof systems and agent workload profiles?

Preliminary evidence from the proof of concept suggests that, for the selected Groth16 implementation (Groth, 2016), gateway-side verification remains effectively constant with respect to circuit constraint count (see Table 3 for measured verification time on the current prototype instantiation). In contrast, proof generation scales with the number of arithmetic constraints and is therefore expected to dominate end-to-end authorization latency as policy expressiveness increases. Operational viability consequently depends not only on the selected proof system but also on the authorization frequency of the deployment model. A low-frequency model, in which a proof is generated once per task plan and verified once at the gateway, presents a fundamentally different latency budget from a high-frequency model in which each tool invocation triggers an independent authorization cycle. RQ3 should therefore be evaluated across at least three axes: proof-system selection, circuit complexity as a function of policy expressiveness, and authorization frequency as a function of the agent workload profile. This distinction also reinforces the separation between authorization evidence and runtime execution evidence: Reducing authorization frequency may improve latency, but it increases the importance of binding the authorized plan to subsequent execution.

These observations suggest that CVA should be evaluated along two separate axes: cryptographic validity of the authorization evidence, and operational consistency between authorization and execution. The first can be studied through proof-system soundness, binding properties, and circuit correctness; the second requires additional runtime evidence mechanisms and cannot be obtained from the authorization proof alone.

7 Limitations

We explicitly acknowledge the following limitations:

• The formal model is preliminary; complete security reductions for the proposed candidate properties to standard cryptographic assumptions remain as future work.
• The prototype has not been subjected to independent cryptographic circuit audit.
• Groth16 requires a trusted setup ceremony; the resulting common reference string constitutes an external trust assumption. The system is additionally not post-quantum secure under current assumptions.
• The encoded policy language is constrained to static arithmetic circuits; dynamic or procedural policies are not representable without circuit recompilation.
• Context binding is included in the formal model through H_*c*(Encode(c_*priv*)) = h_*c* but is not implemented in the current prototype.
• Runtime execution binding is an open problem not addressed by the ZKP authorization layer alone, as formalized in Equations 41, 42.
• No comparative empirical benchmark across proof systems has been conducted.
• No multi-agent or multi-principal delegation chain has been evaluated.
• The authorization gateway is partially trusted; its compromise is outside the threat model of the core cryptographic construction.
• The prototype's request binding uses a single plan-level commitment (SHA256(plan)) rather than the model's decomposition of the request into distinct resource (see Equation 12) and action components (see Equation 13).

8 Conclusion

This study argues that authorization for autonomous AI agents should be studied as a cryptographically verifiable security relation, rather than solely as a consequence of authenticated identity or delegated credentials. We hypothesize that a meaningful class of authorization decisions can be represented through relations jointly binding an agent principal, a concrete authorization request, an execution context, and the satisfaction of an applicable policy, while selectively preserving private authorization attributes.

Table 1, discussed in Section 2, positions the proposed abstraction relative to existing work: while prior contributions advance identity, delegation, policy compliance, and audit, the CVA abstraction targets the orthogonal property of request-bound verifiable authorization, which remains uncharacterized as an independent security relation in the surveyed literature.

To support this hypothesis, we introduced a preliminary formal model, defined a compact set of candidate security properties, and mapped an executable zero-knowledge proof of concept to selected elements of the abstraction. The artifact is presented as constructive evidence of feasibility for the implemented principal- and request-binding conjuncts, rather than complete formal or empirical validation of the full CVA relation.

The central conclusion is the explicit separation defined in Equation 56:

Identity Binding≢Authorization Request Binding ≢Runtime Execution Binding.

This distinction clarifies both the contribution and the limits of zero-knowledge authorization: a proof may establish that a committed request satisfies an encoded policy but cannot by itself establish that the same request was subsequently executed. The resulting abstraction provides a falsifiable basis for future formal security analysis, comparative evaluation across proof systems, and integration with trusted runtime execution evidence.

Beyond the specific research questions identified in Section 6, the CVA abstraction suggests a broader reorientation of how authorization is studied in agentic systems: not as a configuration problem solved at deployment time but as a per-request cryptographic property that must be established, verified, and composed across agent interactions. As autonomous agents become infrastructure (invoking tools, delegating tasks, and acting upon protected resources at scale), the gap between authenticated identity and verified authorization is likely to widen. Closing it requires not only formal foundations of the kind proposed here but also a broader effort to develop authorization evidence as a first-class security primitive alongside identity, delegation, and runtime execution evidence.

Generative AI statement

The author(s) declared that Generative AI was used in the creation of this manuscript. Claude Opus 5 (Anthropic, https://claude.ai) was used on specific passages for English-language editing and proofreading. The manuscript was written entirely by the author(s), who reviewed and edited all output and take full responsibility for the content of the publication.

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher's note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Footnotes

Edited by: Tanja Pavleska, Institut Jožef Stefan (IJS), Slovenia

Reviewed by: Konstantinos Sgantzos, Mediterranea University of Reggio Calabria, Italy

Oleksandr Kushnerov, Sumy State University, Ukraine