The Agent Has Permission. Can It Prove Who Gave It That Authority?

Most of what gets called agent authorization is really credential verification. An agent presents a token, a system checks that the token is valid and has not expired, and the request proceeds. What almost nothing checks is a harder question underneath it: which specific human decided that this specific agent should be allowed to do this specific thing, and can that decision still be proven after the fact.

A preprint posted to arXiv on 4 August 2026 is built entirely around that question. It is not new to us by the calendar, and we want to be direct about that before anything else. We are publishing this analysis on 22 August 2026, more than two weeks after the paper's submission date. Nothing in this piece treats 22 August as when the research happened. The paper was submitted 4 August 2026, and that is the date this record treats as the event.

What BIND actually proposes

The paper is titled Binding Biometrics with AI Agent Identifiers for Delegation of Authority, by Joseph Geo Benjamin, Anil K. Jain and Karthik Nandakumar. The framework it proposes is called BIND, an acronym the authors expand as Biometrics based Identifiers for Non repudiable Delegation of Authority. Its starting premise, stated directly, is that an AI agent should not be allowed to perform critical tasks without explicit authorization by a human operator, and that biometric recognition is one of the most reliable ways to authenticate that the right human gave that authorization.

The mechanism itself has a specific shape, and it is worth preserving precisely rather than summarizing loosely. BIND generates an agent token that encodes two things: the identity of the specific AI agent, and the authority scope, meaning task specific constraints, that human is delegating to it. That agent token is then combined with fresh biometric information captured from the authorizing human at the moment of delegation, producing what the paper calls a delegation token. Later, when the agent actually attempts the authorized action, it presents that delegation token to a component the paper calls an Identity Auditor. The Identity Auditor uses a previously enrolled biometric reference for that human to authenticate them and, from that same delegation token, recover the agent identity and the authority scope that were bound into it at delegation time. What comes out the other side is not a policy decision. It is recovered identity and scope information that can then support authorization of the requested action.

Why the authors think this matters more as agents delegate to each other

The paper's motivating argument is about what happens as authority moves through more than one hop. As an authorized action propagates through multiple agents and tools before it executes, the authors argue that conventional token mechanisms can preserve the permissions attached to a request while the linkage weakens between four things that started out connected: the human who originally authorized the work, the specific agent now holding the token, the task context that authority was scoped to, and the action the token is eventually used to justify. They define identity binding as the property of anchoring a delegated action back to the originating human identity across however many delegation hops occurred in between, and BIND is their proposed way of establishing that anchor cryptographically rather than relying on the token's contents alone.

We want to be precise about how far that argument reaches, because it is easy to overstate. The paper does not claim that OAuth, OIDC or existing token exchange mechanisms are categorically incapable of representing human to agent delegation. Token exchange mechanisms already in use can preserve an actor chain and narrow a scope as a token passes from principal to principal. The question the paper is actually raising, and the one worth taking seriously on its own terms, is narrower and more useful: whether a stronger, independently verifiable binding between the human's authorization, the receiving agent's identity and the delegated task scope is worth the cost of building it, for the specific purpose of agent accountability after something has already happened. That is a design tradeoff argument, not a claim that the incumbent standards are broken.

Where OAuth, OIDC and Token Exchange actually sit in this

The paper discusses OIDC, OAuth 2.0 and OAuth Token Exchange directly, and it is explicit about where BIND stops. The recovered agent identity and delegated scope that come out of the Identity Auditor can, the authors say, be used to establish credentials or issue session tokens through conventional OAuth flows. The authors state plainly that the exact formulation of those downstream mechanisms is outside the scope of their paper. BIND is not presented as a replacement for OAuth, not as an extension to it, and not as a new Internet standard. It is a mechanism for producing a specific kind of evidence, human identity bound to agent identity and delegated scope, that a system could then choose to feed into its existing OAuth based credentialing if it wanted to.

The prototype: face biometrics and a fuzzy commitment

The authors do not stop at the architecture. They built a practical instantiation using face biometrics, and describe a feature adaptation module that transforms real valued face feature embeddings into fixed length binary representations, suitable for a fuzzy commitment construction built on turbo error correcting codes. Fuzzy commitment schemes exist because a live biometric reading never matches an enrolled template exactly. The construction is what lets error tolerant matching happen while the enrolled biometric data itself stays committed rather than stored in the clear.

The headline result the abstract reports is a best configuration achieving a True Match Rate of 96 percent at a False Match Rate of zero, with the construction supporting 1024 bit agent tokens. We are stating those figures as the paper reports them, and we want to be careful about what they do and do not establish. Zero False Match Rate in a reported experimental setting describes the outcome of that specific evaluation, on whatever dataset and test protocol the authors used, not a proof that the system can never falsely authenticate someone. Direct access to arxiv.org is blocked in our tooling environment, so we were not able to independently read the paper's full dataset description, test protocol or sample size beyond what the abstract itself reports and what is independently corroborated through search engine results quoting that abstract directly. We are not in a position to characterize the evaluation conditions in more detail than that, and readers should treat the 96 percent and zero percent figures as belonging to one reported experimental configuration rather than as a general property of the system.

What "non repudiable" means here, and what it does not

The authors describe the resulting mechanism, in their own words as corroborated through the abstract, as providing non repudiable proof of human control and delegation of authority. That is the authors' claim about their own construction. We are attributing it to them directly rather than adopting it as an established fact. Non repudiation, in the cryptographic sense the paper is invoking, means a signed or bound artifact that a party cannot later credibly deny having produced. Whether BIND's specific construction delivers that property in the strong sense the term implies, under adversarial conditions, is a claim the paper makes and a prototype evaluation demonstrates in one setting. It is not the same as an independently established legal or security guarantee, and nothing in what we could verify elevates it to that status.

What stage this work is actually at

It is worth being explicit about that, because the distance between a research proposal and a production accountability mechanism is large and easy to collapse in summary. What exists, as far as we can verify: a research proposal describing the BIND architecture, a prototype implementation of the face biometric instantiation, and an experimental evaluation of that prototype reported by the authors themselves. What we did not find: an independent reproduction of the reported results by anyone outside the author group, a public code repository or otherwise separately usable implementation, integration with any real authorization infrastructure, a production deployment, or evidence of production adoption. We searched specifically for a public implementation and did not find one; the absence of a result is not proof that no code exists anywhere, but we are not willing to assert public availability we could not confirm. arXiv's own listing for this paper describes it as accepted for a session at IJCB 2026, the IEEE and IAPR's biometrics conference, which is a peer venue acceptance, not a claim of deployment.

Where this sits against what we have already tracked

This publication has spent the past two weeks reading several distinct answers to related questions, and BIND is not a restatement of any of them. GitLab's composite identity is a production mechanism that authorizes the intersection of a human's role and a service account's role at execution time, with no biometric involved and no claim about proving who originally delegated the underlying task. Alipay's agentic commerce launch is about whether one human's authorization survives being passed through several agents before a payment executes, a multi agent propagation problem rather than a single delegation event. Claude Code's subagent forking is about which permissions an agent that creates another agent hands down automatically, a software inheritance question with no human biometric step at all. The IETF draft and PACE preprint we have already covered are about proving that one specific transaction matches what was approved at the moment it executes, evidence bound to an action rather than to the identity of the person who delegated it.

BIND's distinctive claim sits underneath all four: a verifiable binding, established with fresh biometric information at the moment authority is delegated, between the specific human doing the delegating, the specific agent receiving it, and the specific scope being handed over. None of the records above make that claim, and BIND does not make theirs. That is a different layer of the same underlying problem, not a duplicate of it.

A live protocol tests the same claim outside a laboratory

BIND is a prototype. What follows is not. On 25 August 2026, Algorand Foundation publicly launched AC2, the Agentic Communication and Control Protocol: a public specification, a reference implementation, an AC2 Wallet proof of concept built by Pera, and an OpenClaw plugin, all live the same day. Moona Intelligence is verifying this four days later, on 29 August 2026, directly against the specification text and the canonical repositories rather than against the launch announcement's own framing. Nothing here treats 29 August as the date AC2 launched, and nothing treats the specification's own internal creation date, 1 April 2026, as its launch date either. Those are three separate dates, and this record keeps them separate throughout.

The specification itself, read directly from algorandfoundation/ac2 on GitHub, states its own status plainly: Draft. Its own creation date field reads 1 April 2026, the document was committed to the repository on 23 April 2026 under the message "docs: init ac2 spec", and that file has carried exactly one commit since, meaning the normative text this record verified is the same text that has existed since April. Its conformance section is marked TBD. Algorand's own launch material calls AC2 an open protocol and, in places, an open standard. Both things are true at once and describe different facts: a specification can be openly published, openly licensed and still carry a Draft status line with an unfinished conformance section, and this record grades AC2 by what its own text says about itself rather than by how the launch describes it. AC2 is a public open draft protocol with a reference implementation. It is not an IETF, W3C or other standards body document, and nothing found here shows that status has changed since verification.

The architecture is the part that matters most, and it is worth stating exactly as the specification defines it rather than as the launch material paraphrases it. AC2 defines a Controller, the human's own wallet or app, carrying a FIDO2 and WebAuthn compatible signing interface, and an Agent, which can only build a signing request and receive back whatever the Controller returns. The specification states, without qualification, that agents cannot sign transactions autonomously and that users must explicitly approve every signing operation, with no caching of a prior approval across requests. That is the current model, stated as a present tense requirement, not an aspiration. Algorand's own launch material separately describes bounded standing delegation, letting an agent act repeatedly inside a preset limit without a fresh approval each time, as a future direction. Nothing found in the specification or the repositories shows that shipped yet, and this record does not credit AC2 with delegated authority it has not yet built.

Messages between Controller and Agent must be DIDComm version 2.0 compliant, travel peer to peer over a WebRTC DataChannel with no relay server in between, and depend on Liquid Auth, Algorand's existing passkey based authentication layer, as the required transport. A signing operation requires WebAuthn user verification before the Controller will sign, which is a real, phishing resistant authentication ceremony. It is not the same claim as biometric approval being mandatory; WebAuthn user verification can be satisfied by a PIN or another authenticator mechanism depending on what device the Controller is running on, and this record does not narrow that to biometrics where the specification itself does not.

The message schema is where illustrative content is easiest to mistake for a requirement, so it is worth separating the two directly from the text. A SigningRequest's normative fields are a human readable description, an opaque base64 encoded payload, an encoding scheme and a schema reference, and the specification requires that description be shown to the user in both raw and human readable form. An amount, a recipient or a purpose, the kind of context a payment approval would want to show, appear only inside the specification's own x402 payment example, not as fields the schema itself requires. A SigningResponse carries only a signature. Scope appears exactly once in the document, inside one illustrative delegation example, with no definition of what it constrains or how a downstream system would enforce it. None of expiry, single use consumption or recipient binding is defined as a guarantee of the response itself; the message envelope's own expires_time field governs how long a message stays valid, which is a different fact from a delegation's own validity. Reading scope or expiry as a shipped guarantee here would be promoting an example into a requirement the text does not make.

Algorand's launch material also describes an agent constructing and submitting a Google AP2 IntentMandate for a controller's sign off, so that a shopping agent, once its mandate is signed, can act inside the mandate's own limits without asking again for each purchase. That example does not appear anywhere in the AC2 specification's own text, which never mentions AP2. AC2 signing a mandate is a real, useful thing for AC2 to be able to do: it lets a controller's passkey backed signature authorize a document another protocol defines. It is not the same claim as AC2 enforcing what that mandate constrains once signed. Whatever AP2's IntentMandate promises downstream remains AP2's mechanism to keep, not AC2's.

The strongest and narrowest claim AC2 actually supports is the one this record has been circling since BIND: the Controller's underlying signing key never leaves the Controller, and the Agent receives a signature rather than a credential it could reuse on its own authority. That is real, and it is the same structural move BIND's authors argue for with a biometric instead of a passkey. It should not be broadened past what AC2 actually isolates. The specification says nothing about API tokens, DIDs, session credentials or WebRTC signaling credentials the agent may still hold for everything outside an AC2 gated signing operation. Private key isolation here means the specific signing key used for AC2 protected operations does not need to be injected into the agent runtime. It does not mean the agent runtime holds no credentials at all.

The public implementation is real code, not only an announcement, and it is worth being precise about where each piece lives. The canonical algorandfoundation/ac2 repository, verified directly, carried 207 commits and stood at 18 stars and 4 forks with 2 open pull requests at the time of this verification, licensed Apache 2.0 at the workspace level while the specification text itself carries the W3C Software and Document License. Its packages include an SDK, a command line client, and both a reference and a server package for the OpenClaw integration, with a commit dated 25 August 2026, the launch day itself, adding a single line install script for OpenClaw plus the AC2 plugin. A separate repository, algorandfoundation/ac2-controller, also Apache 2.0 licensed, holds a reference Controller onboarding flow built on Algorand's own wallet provider library, covering key generation, backup and device native secure storage. That is the reference implementation this record can independently confirm exists and runs as code.

The AC2 Wallet itself, the proof of concept Algorand's launch names directly, is published on Google Play under Pera Wallet's own app.perawallet.ac2 package, and Algorand's 27 August 2026 follow up material describes it as built on Rocca, the wallet infrastructure Algorand also used to rebuild Pera Wallet 7.0 the same month. Moona Intelligence could not fetch algorand.co or the Play Store listing directly in this session, both are blocked at this session's network egress proxy, so that specific product to infrastructure link is recorded here as corroborated through independent search passes returning consistent detail, not as independently read primary text. What this record can confirm directly is narrower and does not depend on trusting that link: a real, source available Controller reference implementation exists on GitHub, and a packaged AC2 Wallet app exists on Google Play under Pera's publisher account.

Two gaps are worth stating as plainly as the claims above. No independent security audit or formal verification of AC2 was found anywhere in the material available to this session. And beyond Algorand Foundation and Pera Wallet building the reference AC2 Wallet, this record found no independently confirmed organization adopting AC2. Repository forks are not a separate implementation, and a specification existing is not evidence of broad production adoption. Independent adoption is not established.

Read against the same dimensions this record already applies to BIND, AC2's Authority Provenance evidence separates cleanly by layer. The authority grantor is the Controller, meaning the specific device and passkey that produced the signature, which this record keeps distinct from the resource owner, the organization and the agent itself. Mandate representation is partial: a SigningRequest's description field is shown to the human and can carry a human readable purpose, but nothing in the specification ties that description to a verified corporate office, an account ownership right or any other organizational mandate, so organizational mandate is unknown and external to what AC2 defines. Delegated scope, on the evidence read directly, is per signature today, not a standing bounded grant, whatever the launch material says is coming next. The explicit limit this record can actually verify is key non possession: the Agent never receives the Controller's signing key. Expiry, one time consumption and recipient binding are not established as guarantees of the response itself, only as illustrative content in one example. Revocation is undocumented: this session found no dedicated security considerations section, no revocation endpoint and no stated rule for whether an already issued signature can be invalidated after the fact. Replay protection is similarly undocumented in the normative schema; a requestId exists only inside the Liquid Auth extension for WebAuthn challenge correlation, not as a stated defense against reuse. Challenge authority sits with the Controller for whichever specific signing operations are actually routed through AC2, not for every action an agent takes broadly. Recovery is limited to what is written down: a SigningRejected message carries a reason field, and nothing beyond that describes timeout behavior, duplicate request handling or what happens to a request the Controller never answers.

Set beside two records this desk has already published, AC2 sharpens rather than restates each one. Altana's session keys on BNB Chain also keep an owner's underlying keys off the agent, but bound a standing session, spending limit, contract allowlist and expiry set once in advance, the bounded delegation model AC2's own launch material describes only as future work. Slack Code's production sign off is a described workflow inside an ordinary chat channel, with no cryptographic binding shown between the message a person reads and the deployment that follows it. AC2's controller signature is a categorically stronger artifact than a chat message: it is produced by a WebAuthn ceremony over a specific payload, not typed agreement in a thread. x401 answers a related but different question, whether a generic HTTP resource accepts a credential result as sufficient proof, with Agent binding and delegation evidence left optional by design. AC2 is narrower and more specific: one wallet, one controller, one signing key, one request at a time, with no equivalent yet to x401's composable delegation evidence layer.

None of that closes the gap this record exists to track. A WebAuthn ceremony proves the Controller's own authenticator participated in producing a signature over a specific payload. It does not, on anything read here, prove that the person behind that authenticator was entitled, under whatever policy actually governs the wallet, the treasury or the repository at stake, to authorize the action the signature approves. AC2 makes the first claim considerably stronger than a chat approval or a bare API credential ever could. It leaves the second claim exactly where BIND, x401 and every other record in this cluster leave it: open, and outside what any signature alone can settle.

The question worth keeping

Strip the face recognition out of this paper and the interesting part is still there. Once a human hands authority to software, and that authority might later justify a consequential action, systems increasingly need evidence that preserves three things together: who authorized the delegation, which specific agent received it, and what authority scope that human actually delegated. An agent holding a valid token can already prove the third of those, sometimes. Proving the first two, and proving they were bound to the third at the moment of delegation rather than assembled afterward from separate logs, is the harder problem BIND is aimed at.

The agent has permission. Can it prove who gave it that authority, for that specific task, at the moment the authority was handed over? BIND is one research answer to that question, tested in one prototype, in one reported setting. It is not yet an answer anyone has built into production.