Only Thirty-Two Percent of the Time Can the Agent Prove It's Itself
· 9 min read

Only Thirty-Two Percent of the Time Can the Agent Prove It's Itself

By Orestes Garcia


We have spent two years arguing about which agent identity standard wins. The better question is whether the agent can run any of them, and the measured answer is that on the weakest model it manages only about a third of the time.

That number is not a metaphor. It comes from a lab, from a real test of agents doing the exact cryptographic dance the standards take for granted. And it reframes the entire debate, because a standard the runtime fails to execute is not a standard. It is a hope with a schema attached.

The gap everyone writes, and the part nobody quotes

The architecture problem is well covered. I have covered it myself, and the shape is now familiar: five competing standards, no convergence path, and the hardest primitive of all still missing. There is no trust primitive in OAuth, SAML, or MCP that lets one agent securely delegate authority to another, a gap that RSAC 2026 named out loud. I laid out the federation version of this in The Agent Identity Federation Gap, the ownership version in The Non-Human Identities Problem, and the abuse version in Agent Impersonation. Four passes at the same wall.

Every one of those pieces, mine included, assumes the same thing: that once the standard exists, the agent runs it. Present a verifiable credential, prove control of a decentralized identifier, sign the challenge, verify the counterparty. The architecture argument treats the execution as a solved subroutine and moves on to governance.

It is not a solved subroutine. That is the part nobody quotes.

What TU Berlin actually measured

Researchers at Technische Universitat Berlin (Rodriguez Garzon et al., 2025) built exactly the system the standards prescribe. Each agent gets a ledger-anchored Decentralized Identifier for self-controlled identity and Verifiable Credentials as tamper-proof attestations. They split the credentials into two tiers: basic VCs carrying rudimentary identity claims issued by a domain orchestrator, and rich VCs carrying detailed role, capability, and authorization information. Agents talk cross-domain over the A2A protocol, exchange proofs through DIF Presentation Exchange, sign with Ed25519 in JSON-LD, and run zero-trust mutual authentication at the start of every dialogue. Textbook decentralized identity, implemented faithfully.

Then they let LLMs drive it and counted how often the workflow finished.

Completion rates ran from 32 percent to 97 percent depending on the model. Not accuracy on a benchmark, completion of the security procedure. Only a third of the time on the weakest model could the agent carry the identity handshake to the end, and the other two-thirds it did not. The failures were not random timeouts either. Agents altered credential data mid-flight. They forgot information they had already retrieved. They dropped steps when the LLM was left holding the orchestration of a security-critical sequence. The paper’s own conclusion is the one line the whole industry should tape to the wall: LLMs are probabilistic systems being asked to execute deterministic security protocols, and the two do not mix.

You can read the full study on arXiv. Read it as a warning label, not a footnote.

Probabilistic actor, deterministic protocol

Diagram contrasting a probabilistic LLM driving the cryptographic protocol directly and breaking it (32 to 97 percent completion) against the fix, where the LLM only orchestrates and a deterministic tool performs the sign and verify steps

Cryptographic identity has no partial credit. A signature verifies or it does not. A credential is intact or it is tampered. A challenge-response either proves control of the key or proves nothing. The protocol was designed for machines that do the same thing every time, because the security property depends on that determinism.

An LLM is the opposite kind of machine by construction. It samples. It is fluent, plausible, and non-deterministic, and those are the traits that make it useful for reasoning and disqualifying for being the thing that executes the handshake. When a model “mostly” completes a verification flow, it has not mostly authenticated. It has produced something that looks like authentication and fails closed, or worse, fails open, some measurable fraction of the time.

The mitigation the TU Berlin team reached for is the right one, and it is worth stating plainly because it inverts the popular framing. Delegate every cryptographic operation to deterministic external tools. Do not let the LLM sign. Do not let the LLM verify. Do not let the LLM hold the state machine of the security procedure. The model can decide it wants to authenticate; a boring, tested, deterministic library must actually do it. The agent orchestrates. It does not execute the crypto. The moment you let the probabilistic component touch the deterministic protocol, you inherit that 32-to-97 band as your security floor.

The wallet-versus-federation fight is downstream of this

Here is where the empirical finding rearranges the standards debate instead of joining it.

The field has split into two camps on what an agent identity even is. The federation camp extends the enterprise identity plane to agents: Microsoft’s Entra Agent ID with its four new object types, the IETF’s draft AIMS framework composing SPIFFE, WIMSE, mTLS, and OAuth into nine layers. Identity is issued to the agent by an authority and governed centrally. The wallet camp goes the other way. ERC-8004, created August 13, 2025 and live on Ethereum mainnet since January 29, 2026, gives each agent a self-sovereign on-chain handle: an Identity Registry built on ERC-721, a Reputation Registry for verifiable track records, and a Validation Registry for independent checks on behavior. It reached Avalanche C-Chain and BNB Chain by February 2026. The agent holds its own identity and carries it across chains, no issuer required.

Argue that fight all you want. It is a real fight and both sides have a case. But notice that both sides hand the agent a cryptographic burden and assume it can carry it. Federation makes the agent present tokens and prove possession. The wallet model makes the agent guard a private key and sign transactions that move value. The TU Berlin number applies to both. A self-sovereign wallet is worthless if the agent driving it fumbles the signing flow a third of the time, and worse than worthless when the fumble spends money. Federation is no safer if the agent mangles the credential on presentation. The camps disagree about who issues identity. They agree, without saying so, that a probabilistic model can be trusted to operate it. That shared assumption is the one the data breaks.

And MCP was never in this conversation to begin with

There is a stubborn category error sitting under all of this, and it is worth correcting sharply because it shapes how people scope the problem.

MCP is not an identity protocol. It gets called one constantly, and it is not. Anthropic shipped the Model Context Protocol in November 2024 as a way to connect agents to tools and data, with an authentication layer bolted to the connection. When an MCP server uses that layer, it triggers authentication of the human in a browser and hands the agent a low-privilege token. Read what that actually establishes. It tells the tool server who the user is. It says nothing about who the agent is. The agent inherits the user’s authority and acts under it, which is convenient and also exactly the accountability hole that shows up the moment one agent calls another and the user context blurs.

So when the standards debate treats MCP as one of the identity contenders, it is comparing a tool-connectivity protocol to identity frameworks and missing that MCP solved a different problem. It authenticates the principal, not the proxy. Agent identity, the thing that would let a counterparty verify the agent itself rather than the person it claims to act for, is precisely the thing MCP does not provide and was never trying to. I made the runtime-visibility version of this argument in Who Scans Whom. This is the identity version: the protocol most people point to as the answer authenticates the wrong entity.

What this means if you are building now

Stop treating agent identity as an architecture decision you will finalize once the standards settle. It is that, but it is also an execution risk you carry today, on every agent already in production, and the execution risk does not wait for convergence.

Three things follow directly from the number.

First, the crypto never runs in the model. If your agent authenticates, signs, or verifies, that work belongs in a deterministic tool the model calls, not in the model’s own reasoning. Treat any design where the LLM holds the security state machine as already failed, because the measured completion floor makes it so.

Second, instrument completion, not just outcome. The TU Berlin failures were silent: altered data, forgotten steps, dropped stages that produced plausible-looking results. You will not catch those by checking whether the agent said it succeeded. You catch them by verifying the cryptographic artifact independently, every time, with something that does not sample.

Third, weight the standards bet on operability, not elegance. When you evaluate ERC-8004 against a federation framework, the deciding question is not which model of identity is philosophically cleaner. It is which one keeps the probabilistic component furthest from the deterministic protocol. The standard that survives contact with a real LLM is the one that lets the agent decide and forbids it from executing.

The identity-federation gap has been written four times, including by me. This is the fifth pass, and it goes underneath the other four. The architecture is unsolved, yes. But even a solved architecture would run on agents that cannot reliably prove they are themselves. Fix the standard and you still have a runtime that fails the handshake two-thirds of the time on a bad day. That is not a governance problem waiting on a committee. It is a systems problem with a measured error rate, and it is the number the whole debate keeps declining to quote.


The standards fight gets the headlines because it feels like the decidable part. The execution rate is the part that will actually decide whether any of this holds, and right now it reads 32 to 97 percent. Build for the low end.

I write about AI-assisted development, enterprise architecture, and the identity plumbing everyone assumes already works. Find me on X @orestesgarcia or LinkedIn /in/setsero.