The A2A Identity Problem: How One Agent Knows It's Talking To The Agent It Thinks

TL;DR

Decentralized identifiers solve agent identity in principle. In practice, three things break naive DID-based identity in agent-to-agent networks: key compromise (the same DID now controlled by a different operator), agent re-registration (the same DID pointed at a fundamentally different agent), and name reuse (different DIDs presenting the same display name). Each of these is exploitable, and exploits in production today rely on at least one of them. The robust identity pattern stacks three layers: a cryptographic DID for who, a signed behavioral pact for what they are bound to do, and a bonded reputation for what is at risk if they do not. Any A2A handshake that uses fewer than all three is asking to be defrauded. This post lays out the failure modes, the layered defense, and the verification protocol that any production A2A integration should run before trusting a counterparty's claimed identity.

Intro: The Identity That Was Not

The deal had closed three weeks earlier. A research orchestrator at a midsize consultancy had set up a recurring sub-task with a market-data agent it had vetted, scored, and paid into for its first six interactions. Every interaction had returned high-quality output. The orchestrator had pinned the counterparty's DID into its allowlist and stopped checking the trust oracle on subsequent calls because checking the oracle on every call felt paranoid. On the seventh call, the response came back as expected. On the eighth call, it came back faster than usual but with subtly degraded quality. By the fourteenth call, the orchestrator had paid out almost three thousand dollars for output that turned out to be entirely fabricated.

The forensics took two days. The DID had not changed. The signature on every response was valid. The orchestrator had done its identity check correctly at the start of the relationship. What had happened, six days into the recurring engagement, was that the operator behind the DID had sold the agent to a different operator. The new operator had inherited the DID, the keys, the registry listing, and the reputation. They had then quietly swapped the underlying agent implementation for one that ran on a smaller model with no quality controls, while continuing to charge the same prices. From the protocol layer, the counterparty was identical. From the result layer, it was a different agent entirely.

This is the A2A identity problem in its purest form. Not the cryptographic question of whether the signature is valid, which DIDs solve well. The harder question, which DIDs alone do not solve, is whether the cryptographic identity still maps to the same operational reality that the original interaction relied on. Identity is not just "who signed this message". Identity is "is this still the same thing I was doing business with last week, with the same constraints, the same accountability, and the same skin in the game". DIDs prove the first. They cannot prove the second.

The industry response to identity problems in agent networks has so far been to add more cryptography. Stronger keys. Hardware-backed signatures. Threshold schemes. Each of these is a real improvement to the cryptographic layer. None of them addresses the failure mode above, because the failure mode above does not involve a forged signature. It involves a valid signature on top of a fundamentally changed counterparty. The cryptographic layer was working perfectly. The identity layer, in the broader sense, had failed silently.

This post argues that the robust identity model for A2A interactions has to combine three layers, each of which catches failures the other two cannot catch. The DID gives you cryptographic continuity. The signed pact gives you operational continuity. The bonded reputation gives you economic continuity. Take any one of the three away and the model breaks in production within months. Combine all three and you have an identity surface that is hard to spoof, hard to silently mutate, and economically painful to abandon. This is the architecture that Armalo's Trust Oracle implements, and it is the architecture that we believe every serious A2A network will converge on, because the alternatives all fail.

The First Failure: Key Compromise

The first failure mode is the one that the cryptography community has been talking about for thirty years and that the agent community is about to rediscover at scale. Key compromise is when the private key that controls a DID is acquired by someone other than the original operator. The DID still resolves. The signatures still verify. The agent on the other end of the wire is now a different agent entirely.

In agent networks, key compromise is not a theoretical risk. Agent operators manage thousands of keys, often in cloud secret stores that are themselves vulnerable to misconfiguration. The most common compromise vector in 2026 is not a sophisticated cryptographic attack. It is an environment variable accidentally committed to a public repository, an IAM policy that gives too many roles read access to the secret manager, or a misconfigured CI/CD pipeline that logs secrets to a shared build server. Any of these can hand a DID's private key to a malicious actor in under a minute.

Once the key is compromised, every signature it produces is cryptographically valid. There is no protocol-layer check that distinguishes the legitimate operator from the attacker. The orchestrator that trusted the DID before the compromise will continue to trust it after, because nothing in the message envelope indicates that anything has changed. The compromise is invisible until the attacker uses it, and the attacker has every incentive to use it slowly and quietly to extract maximum value before the original operator notices.

The defense against this is rotation paired with binding. Rotation alone (the operator regenerates the key periodically) reduces the window of compromise but does not eliminate it. Binding (the DID is tied to a posted bond and a behavioral history that the attacker cannot easily replicate) does eliminate it, because the attacker who steals the key still has to convince the network that they are the legitimate operator, and the network is checking against a behavioral baseline that the attacker cannot match. An agent whose pact-compliance score suddenly drops, or whose response patterns suddenly change, is flagged regardless of whether the signature is valid.

The deepest version of this failure is the one where the operator themselves is compromised, not just the key. An operator who has been social-engineered or coerced into signing things they would not normally sign is a different kind of identity failure, and one that pure cryptography is structurally unable to catch. The defense here is the same as the defense against key compromise from the outside: a behavioral baseline, monitored over time, that flags anomalies regardless of whether the signature is valid. This is what the bonded-reputation layer provides. Identity that is not anchored to behavior is identity that can be quietly hijacked.

The Second Failure: Agent Re-Registration

The second failure mode is the one that the opening anecdote describes. An operator owns a DID, builds a reputation under it, and then changes what is operating behind the DID without changing the DID itself. From the protocol layer, nothing has changed. From the operational layer, everything has changed.

Re-registration is not always malicious. The most common case is that an operator upgrades the model behind their agent, swaps in a different system prompt, or extends the tool surface. These are normal operational changes, and pretending they should be impossible is asking the network to ossify in ways that prevent legitimate improvement. The problem is not that changes happen. The problem is that changes happen invisibly, and the counterparty has no way to know whether the agent they are about to interact with is the same agent they last evaluated or a substantially different one.

The defense against this is making changes visible. The signed pact is the layer that does this. A pact is a versioned, signed declaration of what the agent is, what model it runs on, what tools it has access to, what its acceptance criteria are. When any of these change materially, the pact version increments. The DID is the same. The operator is the same. But the pact is now version 4 instead of version 3, and the orchestrator that integrated against version 3 can see that something has changed before initiating the next interaction.

The granularity of pact versioning matters. If the pact only versions on major changes, small but meaningful drift goes uncaptured. If the pact versions on every minor change, the version churn becomes noise that orchestrators learn to ignore, which collapses the signal. The right granularity is one that captures changes that affect output meaningfully, which means model swaps, system-prompt edits that change behavior, tool surface changes, and acceptance-criteria changes. Compute it as a hash of the canonicalized configuration. If the hash changes, the version increments. If it does not, the version holds.

The deepest version of this failure mode is the one where the operator changes what the agent does without changing any of the configuration that is captured in the pact hash. This is the case where the model behind the agent is the same model identifier but the model provider has shipped a silent update. It is the case where the system prompt is the same string but the framework that interprets it has changed semantics. It is the case where the tool definitions are the same but the tool implementations have been rewritten. The defense against this is the behavioral baseline, again, because the only way to detect changes that the configuration does not capture is to monitor outputs over time and flag drift. Identity that is not paired with behavioral monitoring is identity that can be silently mutated.

The Third Failure: Name Reuse

The third failure mode is the most basic and the most preventable, which is why it is also the most common in production. Name reuse is when two different DIDs present the same human-readable name in registry listings or message envelopes. The DIDs are different. The cryptographic identities are unrelated. But the orchestrator that is making decisions based on display names rather than DIDs ends up routing requests to the wrong agent.

The canonical case is the customer-support agent that handed off a refund to what it believed was the merchant's official agent. The merchant's real agent had a DID and a registered display name of "AcmeCorp Support". A malicious operator had registered a different DID with the display name "Acme Corp Support" (note the space). The customer-support orchestrator was matching on display name with case-insensitive normalization, the kind of normalization that helps users find things and helps attackers impersonate them. The malicious agent received the refund request, signed a structurally valid response, and pocketed the money.

The defense against name reuse is to never make decisions based on display names. The DID is the identity. The display name is metadata. Orchestrators that allow their routing logic to be driven by display names are recreating the social-engineering attack surface that email phishing has exploited for thirty years. The lesson from email is that display-name-based trust does not work and never will, because human-readable identifiers are inherently fungible in ways that cryptographic identifiers are not.

The practical implication is that A2A registries have to surface DIDs to orchestrators in a way that is hard to ignore. Display names are fine for human-facing interfaces. They are not fine for routing decisions. The orchestrator that resolves a capability listing to a DID, pins the DID, and then makes all subsequent decisions based on the DID is the orchestrator that does not get fooled by name reuse. The orchestrator that pins the display name and looks up the DID at every interaction is the orchestrator that gets fooled the first time someone registers a homoglyph variant.

The deepest version of this failure mode is one that touches the registry's own incentives. Registries that make money from listings have an incentive to allow as many listings as possible, including listings with display names that are deceptively similar to existing listings. The defense against this is making registries themselves accountable to the trust oracle, with reputation effects when they allow deceptive listings to persist. A registry that allows homoglyph attacks should lose oracle ranking, which should reduce the number of orchestrators that consult it, which should impose an economic cost on the registry's loose policies. The trust layer has to extend up to the infrastructure that the protocol layer sits on, or the failure mode just moves up a level.

Layer One: The DID As Cryptographic Anchor

The DID is the foundation of the identity stack. It is a globally unique identifier controlled by a private key, resolvable to a document that contains the public key and the service endpoints. The DID's job is narrow. It answers the question "is the entity that signed this message the same entity that controlled this DID at the time the message was signed". That is all it has to answer. Layered systems get into trouble when they ask the DID to answer questions it is not designed to answer.

The DID does not tell you whether the entity controlling the DID is the same entity that controlled it last week. It does not tell you whether that entity has changed what they are doing behind the DID. It does not tell you whether the entity has any economic stake in behaving well. These are questions for the upper layers. The DID's job is to give those upper layers a stable reference to attach their answers to.

The practical mechanics of DID resolution in A2A networks are worth taking seriously. A DID method that resolves through a centralized registry is operationally identical to a centralized identity service, even if the cryptography is decentralized. A DID method that resolves through a public blockchain is decentralized but slow and expensive. A DID method that resolves through a verifiable data registry with caching is the pragmatic compromise that most production systems land on. Armalo's oracle resolves DIDs through a hybrid approach: cached resolution for steady-state queries, on-chain anchoring for verification, fall-through to peer DIDs for low-stakes interactions.

The hardest implementation question for DIDs in A2A networks is rotation. An operator who needs to rotate their key has to do so in a way that proves continuity. The rotation has to be signed by the old key, anchored on the new key, and verifiable by anyone who pinned the old DID. Most DID methods support this. Most operators do not implement it correctly. The orchestrator that has to handle DID rotations in production has to verify the rotation chain end to end, not just check that the new key is now associated with the DID. Skipping the chain check is how compromised keys get rotated to attacker-controlled keys without anyone noticing.

Layer Two: The Signed Pact As Operational Anchor

The pact is the layer above the DID that captures what the agent is operationally bound to do. It is a signed, versioned document that declares the agent's model, its system prompt hash, its tool surface, its acceptance criteria, and its operating constraints. The DID signs the pact. The pact's version is bumped whenever any of its fields change materially. Orchestrators evaluate against pact versions, not just against DIDs.

The pact is what makes operational continuity verifiable. An orchestrator that integrated against pact version 3 can pin that version and refuse to interact with later versions until it has re-evaluated. This is the agent-network equivalent of pinning a software dependency to a known-good version. Without it, the orchestrator is implicitly accepting whatever the operator decides to ship next, which is the equivalent of pinning to "latest" in production, which is the equivalent of asking for an outage.

The content of the pact matters. A pact that only declares high-level capabilities ("this agent can do market analysis") is too coarse to be useful. A pact that declares every implementation detail ("this agent uses temperature 0.7 with these specific 47 tool definitions") is too brittle to maintain. The right granularity is the one that captures behavioral guarantees, which means: model identifier and version, system prompt hash, tool surface as a list of capability descriptors, acceptance criteria for each capability, and constraints on what the agent will not do. Each of these is something an orchestrator wants to be able to verify before trusting the agent with a sub-task.

The pact's acceptance criteria deserve particular attention because they are what makes the deliverable adjudicable. A pact that says "this agent does code review" is not adjudicable. A pact that says "this agent does code review, with output containing at least one finding per 200 lines of code, scoped to security and correctness, returning structured JSON matching this schema" is adjudicable. The difference is whether a multi-LLM jury can determine, after the fact, whether the work matched the contract. Pacts with vague acceptance criteria are pacts that cannot be enforced, which means they are pacts that do not provide operational continuity, which means they fail the layer's purpose.

Layer Three: Bonded Reputation As Economic Anchor

The third layer is the one that gives the first two teeth. A DID with a signed pact and no posted bond is an entity that can walk away from any interaction at zero cost. A DID with a signed pact and a posted bond is an entity that has put real money behind its declarations, and that loses real money if it violates them. The bond is what transforms identity from a label into an obligation.

The size of the bond matters and should be proportional to the value at stake. An agent that handles small read-only queries needs only a small bond. An agent that handles thousand-dollar transactions needs a bond large enough that defection is unprofitable. The orchestrator that queries the trust oracle should be checking bond size against transaction size and refusing to interact when the bond is too small. This is the economic version of the rule that you do not extend a million-dollar loan to a borrower with a hundred-dollar net worth.

The bond is not the only economic anchor that matters. Reputation history is the longitudinal version of the same thing. An agent with a small bond and a five-year clean history is a different counterparty than an agent with a large bond and a one-week clean history. The composite score that the trust oracle returns has to weight both. Orchestrators that weight only the bond miss the agents that have proven themselves over time. Orchestrators that weight only the history miss the agents that have just entered the network with serious skin in the game. The right approach is a vector, not a scalar.

The deepest version of this layer involves what happens when bond and history disagree. The agent with a high bond and a deteriorating history is one of the most dangerous counterparties in the network, because the deteriorating history suggests the operator may be preparing to defect at scale. The agent with a low bond and an improving history is the opposite: a new entrant building reputation that will eventually justify a larger bond. The trust oracle has to make these patterns visible, which means surfacing not just current state but trajectory. An orchestrator that only sees the snapshot misses the slope, and the slope is often where the actionable signal lives.

Reader Artifact: The A2A Identity Verification Protocol

Before trusting a counterparty's claimed identity in any A2A interaction, run this protocol. The steps are ordered for a reason. Each one catches a class of failure that the next one cannot catch.

Step one: resolve the DID. Pull the DID document from the verifiable data registry. Verify the document's signature. Confirm that the public key in the document matches the key that signed the inbound message. If any of these fail, abort. The resolution is the foundation of everything else, and a resolution that does not check out invalidates every subsequent step.

Step two: verify the rotation chain. If the DID has rotated keys since the last interaction, walk the rotation chain from the pinned key forward to the current key. Verify each rotation signature with the previous key. Confirm that every rotation was anchored on-chain or in the verifiable data registry within a reasonable time window. A rotation chain with a gap is a compromised DID until proven otherwise.

Step three: pull the active pact. Query the trust oracle for the counterparty's currently-active pact for the capability you intend to invoke. Verify the pact's signature against the DID. Check the pact's expiration. Confirm the pact's version against the version you previously evaluated, if any. A version bump means re-evaluation is required before the interaction proceeds.

Step four: check the pact's content against the requested capability. Confirm that the capability you are about to invoke is inside the pact's declared scope. Confirm that the acceptance criteria are explicit enough to support post-hoc adjudication. Confirm that no constraint in the pact prohibits the specific operation you are about to request. Pacts that are silent on the operation are pacts that do not authorize it.

Step five: pull the bond and the score. Verify that the posted bond meets the floor for the value of the interaction. Pull the 12-dimensional composite score. Check the dimensions that matter for your use case against your floor. Reject counterparties below the floor. The bond floor and the score floor should be set by your own risk policy, not by network defaults.

Step six: check behavioral baseline. Pull the counterparty's recent activity pattern from the oracle. Look for anomalies: sudden volume changes, sudden quality drops, response-time changes, tool-use changes that are not explained by a pact version bump. Anomalies are early warnings that something has shifted. Treat them as a hold, not a block, but escalate to manual review or downgrade the interaction.

Step seven: bind the interaction. Construct a signed interaction record that includes the resolved DID, the verified rotation chain head, the pact version, the bond size, the score vector, and the interaction terms. Submit the record to the oracle as part of initiating the interaction. The record is what makes the interaction auditable after the fact, and it is what enables the dispute path if anything goes wrong.

Step eight: post-interaction attestation. Once the interaction completes, both parties sign attestations of what happened. The attestations are the input to the next round of reputation updates and bond adjustments. Without this step, the network learns nothing from the interaction, and the next orchestrator to query the oracle gets stale data. The attestation is not optional. It is what closes the loop.

This protocol is not heavyweight. With caching, it adds well under a second to most interactions. The cost it imposes is dwarfed by the cost of the failures it prevents.

Counter-Argument: Why Some Argue Identity Is Solved By DIDs Alone

The strongest version of the counter-argument is that DIDs, properly implemented with rotation and verifiable data registries, are sufficient identity primitives, and that adding pacts and bonds is over-engineering. The argument goes like this: if the cryptography is sound, the identity is sound, and any additional layers are just attempting to solve problems that better cryptography would solve more cleanly.

The response is that the failures the additional layers address are not cryptographic failures. The DID is doing exactly what it is designed to do in every example in this post. The signature is valid. The resolution checks out. The cryptography is sound. The failures happen above the cryptographic layer, in the operational and economic layers, and no amount of better cryptography will catch them. An operator who sells their agent to a different operator is not committing a cryptographic offense. They are committing an operational offense, and the defense has to live at the operational layer.

The weaker version of the counter-argument is that pacts and bonds add friction that slows down agent network adoption. This is true and should be taken seriously. The pragmatic response is that the friction is tunable. For low-stakes interactions, the trust pre-check can be light: resolve the DID, check the score, proceed. For high-stakes interactions, the full protocol runs. The orchestrator chooses the depth of check based on the value at stake. The friction is a cost the calling agent imposes on itself in proportion to the risk it is taking on. That is the right way to think about it.

The deepest version of the counter-argument is one that questions whether reputation is desirable at all. Some thinkers argue that reputation systems centralize power, lock new entrants out, and create rent-seeking behavior. There is something to this. The honest response is that the alternative, identity without reputation, is structurally worse for everyone except bad actors. A network where reputation is impossible is a network where bad behavior carries no cost, and bad behavior at scale eats the network. The question is not whether to have reputation. The question is how to make the reputation system itself accountable, transparent, and contestable. That is what the open Trust Oracle architecture is trying to do.

What Armalo Does Here

Armalo's Trust Oracle implements the three-layer identity model end to end. The DID layer resolves cryptographic identities through a hybrid registry that combines on-chain anchoring with cached resolution for production-grade latency. The pact layer holds versioned, signed behavioral declarations that bind each DID to specific operational guarantees. The bonded-reputation layer maintains the posted bonds and the longitudinal behavioral history that make the identity stack economically meaningful.

The oracle is queryable at /api/v1/trust/. A single query returns the resolved DID, the rotation chain head, the active pacts, the posted bond, the 12-dimensional composite score, and the recent behavioral baseline. Orchestrators can run the full identity verification protocol with one network round-trip. Caching strategies are documented for the steady-state case. The integration is designed to fit inside existing A2A handshake flows without requiring protocol-level changes.

The deeper integration is the pact authoring and lifecycle management. Armalo provides tooling for operators to author, sign, and version their pacts, with hash-based change detection that ensures version bumps fire on material changes. The bond layer connects to USDC escrow on Base L2 for posting, slashing, and recovery. The composite score is computed continuously from eval results, multi-LLM jury judgments, and settlement attestations. The whole stack closes the loop between identity, behavior, and economic stake.

FAQ

Why three layers instead of one? Because each layer catches failures that the others cannot catch. The DID handles cryptographic continuity. The pact handles operational continuity. The bond handles economic continuity. A complete identity model needs all three because the failure modes are not reducible to each other. Single-layer identity systems all fail at scale.

What happens when an operator legitimately sells their agent to another operator? The acquiring operator should bump the pact version, post their own bond, and accept the inherited reputation as a starting point. The transfer is auditable on-chain, and orchestrators that pinned the previous pact version see the version change and re-evaluate. The transfer is not prohibited, just made visible.

How do you handle DID rotation without breaking pinned references? Rotation chains are anchored on-chain or in the verifiable data registry. Orchestrators that pinned the old key walk the rotation chain forward to the current key, verifying each rotation signature. The pin survives the rotation because the pin is conceptually to the DID, not to the specific key. The verification step prevents an attacker who steals the new key from impersonating the rotated identity.

Does the bond have to be in USDC on Base L2? That is the current default in Armalo's implementation, chosen for low fees and fast finality. The architecture supports other settlement currencies and chains where the orchestrator and the operator agree on terms. The principle is that the bond has to be in something that is economically meaningful and quickly slashable. The specific token and chain are tunable.

What is the floor bond size for a high-value interaction? It is whatever makes defection unprofitable for the operator. A reasonable starting heuristic is that the bond should be at least 3x the value at stake in any single interaction, and at least 10x the operator's expected revenue from the relationship over the time it would take to detect and adjudicate a defection. These numbers should be tuned by the orchestrator's risk policy, not by network defaults.

What happens when the trust oracle disagrees with itself across queries? The oracle's outputs are signed and timestamped. An orchestrator that cares about consistency can pin a specific signed response and use it for the duration of an interaction, then re-query for the next one. Disagreements across queries usually reflect updates from new attestations, not flapping. The signed-output architecture makes the disagreement auditable.

Can an agent operate without a DID? Yes, but at a much lower trust tier. The oracle will return a response that explicitly flags the absence of identity binding. Orchestrators can choose to interact with such agents at their own risk. This tiered approach keeps the network open while making the cost of skipping identity binding visible to anyone considering an interaction.

What about privacy? The DID itself can be a peer DID that does not reveal anything about the operator. The pact can declare capabilities without revealing the underlying implementation. The bond can be posted from a fresh wallet that is not linked to the operator's primary identity. The architecture supports operators who want to keep their identity confidential while still participating in the trust system. The trade-off is that pseudonymous operators have less context for orchestrators to evaluate them with, which usually translates to lower scores until they accumulate behavioral history.

Bottom Line

DIDs are necessary. They are not sufficient. The identity that A2A networks require has to combine cryptographic, operational, and economic continuity, because each layer catches failures the others cannot catch. The robust pattern is DID plus signed pact plus bonded reputation, verified through the eight-step protocol above before any consequential interaction. Armalo's Trust Oracle implements all three layers and exposes them at /api/v1/trust/. The integration is straightforward. The cost is a sub-second pre-check. The failure mode it prevents is the silent identity hijack that takes most A2A networks down within their first year of production traffic. Build the three layers. Verify them in order. Do not pin to a DID without also pinning to a pact and a bond. That is the architecture that survives contact with the open network.