The Login That Lies: Agent Authentication Standards Are Still Built for a Human at the Keyboard

In the second week of September I closed a ninety-day review of two autonomous yield agents running a combined $4.1 million in stablecoin liquidity across four venues. Both agents had passed smart contract audit. Both produced consistent positive P&L across the full measurement window. Both failed the authentication review on the first pass, and neither failure was a bug.

Each agent held a refresh token minted through a standard authorization-code flow. The token was valid. The signature verified. The scope check returned green. And the agent could still route capital into a venue the operator had never approved — because the scope string read transfer, and the consent screen, at the moment of grant, said nothing an operator could act on.

Authentication succeeded. Authorization lied.

That single sentence is the entire structural problem with how the industry is approaching agent identity in 2026. We are shipping machine actors onto irreversible settlement rails while the credentialing layer underneath them still assumes a human being is sitting at a keyboard, reading a consent screen, and exercising judgment at the moment of execution. There is no such human. There hasn't been for two years. The standards have not caught up, and the drafts now circulating in the IETF process address maybe sixty percent of the surface area.

Context: What OAuth 2.1 Actually Changed, and What It Didn't

The lineage matters here, because most operators I speak to believe OAuth was designed for delegation and therefore must already handle agents. It was not, and it does not.

OAuth 2.0 arrived as RFC 6749 in 2012 with bearer tokens in RFC 6750. The bearer-token model is the original sin: possession equals authority. Any party holding the string is the party the resource server believes it is talking to. The implicit flow was deprecated. PKCE (RFC 7636) closed the interception window for public clients. Token exchange (RFC 8693) and Rich Authorization Requests (RFC 9396) added the primitives that matter most for machine actors — structured authorization details rather than flat scope strings, and the ability to trade one grant for a narrower one downstream.

OAuth 2.1, in the draft revision circulated this month, consolidates that work. It removes the implicit grant and the resource-owner password credentials grant outright, mandates PKCE for every authorization-code flow, tightens exact redirect-URI matching, and pushes hard toward sender-constrained tokens. DPoP (RFC 9449) is the reference implementation of that last idea — the client proves possession of a private key on every request, so a stolen token string is worthless without the key.

All of that is correct, and all of it is orthogonal to the agent problem. Every one of those mechanisms assumes the client is a piece of software acting under a human grant that a human can inspect and revoke. Agents break three of those assumptions at once: they persist across sessions, they act when no human is present, and they chain into other agents.

Separately, the IETF draft on agent identity and authorization — circulated mid-September, and which I am reading from a transcription rather than the ratified text — attempts to formalize agent-specific primitives. Verify the source, trust no one: the document is not stable, the identifier space is not settled, and any architectural decision built on the current revision is a decision built on sand. But the shape of the proposal is worth auditing now, because the shape is what will harden.

The proposal, as transcribed, introduces four ideas. Agent identity documents that bind a public key to an operator and a declared capability set. Delegation chains where each hop must narrow, never widen, the authority inherited from the hop above. Intent attestation — a machine-readable statement of what the agent believes it is doing, signed at execution time. And revocation propagation across the chain, so that pulling authority at the root invalidates every downstream grant.

That is a defensible architecture. It is also incomplete in ways that will cost capital.

Core: Four Failure Modes I Find in Every Agent Stack

I audit the code, not the charisma. What follows is drawn from the review window, from the two yield agents, and from six exchange and custody integrations I have examined since Q1. The patterns repeat with enough regularity that I now treat them as a checklist rather than a finding.

Failure 1: Scope is a noun; intent is a verb

A scope string describes an API surface. It does not describe an intention. withdraw, transfer, swap, approve — these are verbs without objects, without limits, and without counterparties. When an operator grants transfer to an agent, the operator has not authorized moving funds to venue X. The operator has authorized moving funds anywhere the API will accept a request.

In the review, one agent held a grant that permitted transfers to any address not on an internal blocklist. The blocklist was maintained manually, in a spreadsheet, by a single operations employee. That is not an authorization control. That is a hope with a filename.

Rich Authorization Requests solved the syntax for this problem in 2022. Almost nobody in DeFi uses it. The reason is economic, not technical: implementing structured authorization details requires the resource server to understand the structure, and most venue APIs are still built around a flat scope string because flat scope strings ship faster. Complexity kills capital, but so does speed.

Failure 2: Refresh tokens are standing authority with a friendly name

A refresh token is not a session. It is a durable, renewable, often non-expiring claim on a user's authority, held in a file on a server. Rotation is specified in the standard and skipped in practice. Reuse detection exists and is rarely enabled. Revocation is coarse — you revoke the client, not the specific grant, and revoking a client breaks every workflow that depended on it.

I have now found unrotated refresh tokens in four of six integrations. In two of them, the token file was readable by the same process that executed agent-generated code. In one, the token had been issued eleven months earlier and had never been re-consented.

This is the single highest-severity finding in the agent stack, and it is boring. Nobody writes a conference talk about refresh token rotation. Liquidity dries up faster than hope, and so does an operator's balance sheet when a token sitting in a container since last November gets exfiltrated.

Failure 3: Delegation chains collapse into token passthrough

Agents call agents. A routing agent hands a request to an execution agent, which hands it to a settlement agent. At each hop, the practical implementation is to pass the original bearer token downstream, because re-issuing a narrowed grant requires the downstream service to implement token exchange, and it usually does not.

The result is that the terminal service cannot distinguish between authority granted by the human operator and authority asserted by an intermediate agent. Every hop becomes a confused deputy. If the routing agent is compromised — or simply wrong — the execution agent has no mechanism to detect that the authority it is exercising was never intended for this request.

The draft's narrowing-delegation rule addresses exactly this. It will not help until the resource servers enforce it, and resource servers enforce what their customers demand, and customers demand what their auditors flag. The chain runs backwards from the audit report.

Failure 4: Human-presence checks get routed around, not solved

Step-up authentication, consent screens, CAPTCHAs, device confirmation — these exist to insert a human judgment at a consequential moment. Agents cannot complete them. So integrators do the rational thing: they create a service account, mint an API key, and attach it to the agent. That key has no user binding, no consent record, and no revocation path tied to a person.

I have seen this pattern produce withdrawal-enabled exchange keys on three separate occasions. The proximate cause was always the same: the read-only key hit rate limits, the agent's strategy degraded, and the fix that shipped in the next commit was a key with broader permissions. Nobody made a bad decision. A series of individually reasonable decisions produced an unowned credential with withdrawal rights.

That is what a standards gap looks like in production. Not a dramatic exploit. An accumulation of workarounds around a control that was never designed for the actor using it.

What the drafts actually fix, and what they leave open

The narrowing-delegation rule and revocation propagation are genuine improvements, and if enforced they close failures 3 and part of 2. Intent attestation is the most interesting primitive in the set, because it moves the audit trail from the operator's logs to the counterparty's verification path. An agent that signs a statement of intent before execution creates a record that the venue can check, not just the operator.

Five gaps remain, and I want them on the record before the revision hardens.

One: trust anchors are unspecified. The draft requires an agent identity document bound to a public key. It does not say who signs that document, or why a counterparty should believe the signer. In practice this will resolve to the same handful of certificate authorities and custodians that already dominate TLS and exchange custody. That is not a criticism; it is a prediction with capital implications.

Two: liability allocation is absent. If an agent with a valid identity document and a valid delegation chain executes an unauthorized trade, who pays? The signed chain proves the operator authorized something. It does not prove the operator authorized this. Without an allocation rule, the signature becomes a liability instrument pointed at the user.

Three: key custody for agents is hand-waved. Agents run in containers. They cannot hold hardware keys. Software key custody means the identity document is only as strong as the process isolation around the private key, which in most deployments is a Docker boundary and an environment variable. DPoP does not help if the key it proves possession of is sitting in plaintext next to the code that uses it.

Four: recursive delegation is unbounded. The draft describes agent-to-agent chains but does not cap depth or require disclosure of intermediate parties. A three-hop chain where the middle hop is an unaffiliated third-party agent is functionally a credential laundering path.

Five: revocation latency is not modeled against economic finality. On-chain settlement is irreversible in seconds. Revocation propagation across a delegation chain takes minutes at best, and the draft specifies no bound. A revoked agent can settle a trade that the revocation was meant to prevent. Any standard that treats revocation as eventual is a standard that assumes reversibility the settlement layer does not offer.

The audit record: what the two yield agents actually did

I want to be concrete about the review, because abstraction is where these findings die.

Agent A ran a delta-neutral basis strategy across two venues and one lending market. Its credential set included a refresh token with no rotation, a read scope on venue one, and a trade scope on venue two issued through a consent flow that the operator had completed eight months earlier and could not describe in detail. The agent's rebalance loop recalculated every four minutes against a volatility threshold. The threshold was documented. The credential was not.

Agent B ran a stablecoin liquidity rotation and was, in effect, an automated version of incentive farming. It moved capital toward whatever pool advertised the highest headline APY, rebalanced every twelve hours, and held no view on whether the emissions backing that APY were sustainable. Yields are calculated, not guaranteed — and the agent was not calculating them. It was reading a number off an endpoint and treating it as an input rather than an advertisement. When I modeled emissions-adjusted returns across the window, the agent's realized yield was 210 basis points below its reported yield, because it was rotating into pools whose headline number decayed within the epoch.

The authentication finding on Agent B was worse. Because the rotation strategy needed to reach a venue whose API did not support scoped keys, the operator had attached a general key. That key could withdraw. The agent never withdrew. The agent did not need to withdraw. The key simply could.

Neither agent had a signed intent record. Neither agent's logs were verifiable by the venues it traded against. Both operators believed they had delegated authority. Neither could produce a document that specified what authority, for how long, or under what conditions it terminated.

The seven-point authentication review

This is the checklist I now run before any agent touches capital. It takes two days and it has never come back clean on the first pass.

1. Enumerate every credential the agent process can read. Not the ones it should read. The ones it can. Diff the container filesystem against the declared configuration.
2. Confirm refresh token rotation is enabled and reuse detection is on. If rotation is off, treat the credential as permanently compromised and re-issue from a fresh consent.
3. Map every scope to a maximum loss. If a scope cannot be bounded to a dollar figure, it is not a scope, it is an open door. Replace it with a structured authorization request or remove it.
4. Trace the delegation chain to its terminal hop and verify narrowing at each step. If any hop passes the original token downstream unchanged, the chain is broken.
5. Test revocation end to end and time it. Pull the root grant, then attempt a settlement. Measure the window. If the window exceeds the settlement finality of the venue, the control is decorative.
6. Verify that withdrawal permissions are structurally absent, not policy-absent. A key that cannot withdraw cannot be misused to withdraw. A key that merely is not used to withdraw is a key that will eventually be used to withdraw.
7. Require a signed intent record per execution and store it outside the operator's infrastructure. Self-attested logs are not evidence. They are narrative.

Smart contracts don't negotiate. They execute what they are told, and they do not distinguish between an authorized instruction and an unauthorized one that carries a valid signature. The authentication layer is the only place where that distinction can be made, and right now the authentication layer is making it badly.

Contrarian: A Ratified Standard Is a Liability Transfer, Not a Safety Upgrade

The consensus position is that agents are unsafe because authentication is immature, and that once the standards land, agents become safe. I think that is backwards in a way that will be expensive.

Consider what a ratified agent identity standard actually produces. An agent with a verifiable identity document. A signed delegation chain from the operator down to the terminal hop. A signed intent record at execution. Every element of that stack is designed to answer one question: was this action authorized? And the answer, once the standard is enforced, will be yes — because the operator signed the root grant.

The standard does not make the action correct. It makes the action attributable. Those are different properties, and the industry is treating them as the same one.

The moment a court, an insurer, or a counterparty can point to a cryptographically verified chain running from the operator's key to the disputed settlement, the liability question is settled against the operator. Today, an operator can argue that the credential model was ambiguous, that the venue's API permitted an unbounded scope, that no reasonable party could have known. That argument disappears the day the delegation chain is standard, signed, and auditable.

We are not building a safety layer. We are building an evidence layer, and the evidence points at the party who signed.

This is also why the custodial venues will win the agent market. An operator who wants real delegation controls — bounded scopes, enforced narrowing, revocation with a latency guarantee, key custody that does not depend on a container environment variable — needs an institution with the balance sheet and the compliance apparatus to offer them. That is a licensing problem before it is an engineering problem, and the entry ticket is not priced for startups. The venues that survived their enforcement actions will be the ones selling agent-grade delegation, because they are the only counterparties whose signature carries weight in a dispute.

Takeaway: Bound the Authority Before You Bound the Loss

Chop is for positioning, and the same discipline applies to infrastructure. In a sideways tape the market stops paying for narrative and starts paying for the layer that survives the next drawdown. Agent authentication is that layer, and it is currently being built by people optimizing for the demo rather than the post-mortem.

The operational answer is unglamorous. Bound every scope to a dollar figure. Rotate every refresh token. Make withdrawal structurally impossible rather than procedurally discouraged. Time your revocation window against your settlement finality and treat any gap as an unhedged position.

Strategy beats speculation every time — and the strategy here is to assume the standard will arrive late, arrive incomplete, and arrive with the liability pointed at whoever signed the root grant. Which raises the question I have not seen anyone in the working group answer: when an agent signs a statement of intent, and the intent is wrong, and the delegation chain is valid, and the settlement is final — who is holding the loss?