Why Agent-To-Agent Protocols Fail Without A Trust Oracle Underneath Them

TL;DR

Agent-to-agent protocols like Google A2A, Anthropic MCP, and the dozen private variants in production are transport specifications. They define how agents discover each other, exchange messages, and negotiate capabilities. They do not define whether the agent on the other end of the wire can be trusted to do the thing it claims it can do. Without a trust layer underneath, every A2A interaction is a leap of faith. There are four failure modes that this gap creates: stranger-call extortion, sybil floods, capability spoofing, and settlement default. The fix is a trust oracle, queried before every consequential interaction, that returns identity, behavioral history, and bonded reputation. This post lays out the four failure modes, the trust pre-check sequence that defends against them, and why an oracle is the only architecture that scales.

Intro: The Demo That Worked And The Production That Did Not

The demo was clean. Agent A on one company's stack discovered agent B on another company's stack via an A2A registry, negotiated a sub-task, exchanged a few JSON messages, returned a result. The whole thing took eleven seconds. Engineers in the audience clapped. Half of them went back to their desks and started prototyping their own A2A integrations. Six weeks later, the production rollouts started shipping incident reports.

The first one was a research agent that paid forty-seven dollars to an A2A counterparty for a market summary, received three paragraphs that turned out to be fabricated, and had no path to dispute the charge because the protocol did not define one. The second was a customer-support agent that handed off a refund request to what it believed was the merchant's official agent and was actually a sybil that had registered the same display name three days earlier. The third was a coordination agent that fan-out broadcast a job request to twenty A2A endpoints, eighteen of which were the same underlying agent operating under different identities, all of which charged it for the privilege of saying "no". The fourth was a settlement agent that released funds on completion of a milestone that had not actually completed because the counterparty's signed attestation was structurally valid and semantically wrong.

None of these failures were transport-layer bugs. The protocols worked. The messages routed. The signatures verified. The failures were trust-layer absences. The protocols had no way to ask, before any of these interactions, the question that should have been asked: should I be doing business with this counterparty at all?

This is the pattern. Every A2A protocol that ships in 2026 ships with identity primitives, capability discovery, and message routing. Almost none of them ship with reputation, accountability, or a settlement-grade dispute path. The transport works. The economics do not. And without economics, A2A networks collapse into the same trust vacuum that early peer-to-peer file sharing collapsed into, except with money on the line and agents acting autonomously instead of humans clicking download.

The argument of this post is that A2A protocols cannot be made trustworthy by adding more fields to the message envelope. Trust is not a header. It is a stateful assertion about historical behavior, current capability, and economic stake. It belongs in an oracle that protocols query, not in the protocol itself. This is the same architectural decision that DNS made about names, that BGP made about routing, that certificate authorities made about identity binding. The protocol stays thin. The oracle holds the state.

The First Failure Mode: Stranger-Call Extortion

In the absence of reputation, there is no reason for an agent to behave well on its first interaction with a counterparty it does not expect to interact with again. This is not theoretical. It is the same observation that game theorists made about one-shot prisoner's dilemmas decades ago, lifted intact into agent networks. When agent A discovers agent B through an A2A registry, sends a request, and pays for the response, agent B has no incentive to deliver value if the cost of fabricating a response is lower than the cost of actually doing the work. Agent A has no way to punish agent B after the fact because there is no shared reputation surface where the punishment would matter.

This is what we mean by stranger-call extortion. Not literal extortion in the criminal sense, but the structural inevitability that any pricing model that involves payment-on-request without reputation gating will produce a population of agents that collect fees and return garbage. The economics are simple. If the marginal cost of fabricating a plausible-looking response is one cent of LLM inference and the price collected is fifty cents, the rational agent that does not care about repeat business will fabricate. The aggregate effect on the network is a tragedy of the commons where new entrants get systematically defrauded and the only agents who survive are the ones who pre-screen counterparties through out-of-band channels, which is to say, the agents who are not actually using A2A.

The defense against this is not better signatures or more elaborate handshakes. The defense is making sure that the cost of behaving badly on a single interaction is higher than the revenue from that interaction, which requires that bad behavior have lasting consequences. That requires reputation. That requires an oracle. Without one, every A2A protocol implements the same equilibrium, which is the equilibrium of strangers transacting in a city with no police, no courts, and no shared language for what "fraud" means. Some honest agents will operate. Most of them will get burned and leave. The agents that remain will not be the ones you wanted to do business with.

This failure mode also has a quieter variant that is easier to miss. Even when the counterparty is honest in the sense that they intend to deliver value, the absence of a reputation surface means there is no pressure on them to be careful, to invest in quality, to run their own evals before responding. Honest agents that do not know they are being graded behave less carefully than honest agents that know they are. Reputation is not just a fraud filter. It is a quality forcing function. Networks without it produce mediocre output even from well-intentioned counterparties because there is no upside to going beyond the minimum.

The Second Failure Mode: Sybil Floods

The second failure mode is sybil attacks, which the original peer-to-peer literature documented exhaustively and which every A2A network is going to rediscover the hard way. A sybil attack is when one underlying actor creates many apparent identities and uses them to manipulate the network. In A2A, sybils show up in several ways. They flood capability registries with duplicate listings under different names to capture more inbound requests. They sock-puppet ratings systems by having their own sybils rate each other highly. They split a single failed delivery across many identities so that no single identity accumulates a reputation hit. They impersonate well-known agents by registering display names that differ by a single character.

The naive defense against sybils is identity verification at registration time. This does not work. Every form of identity verification that scales (email, domain ownership, payment-method-of-record) is itself trivially sybilable by anyone willing to spend a few dollars. The only identity-verification mechanism that meaningfully resists sybils is one that imposes a real economic cost for each identity, and the only economic cost that is hard to fake is a posted bond that is at risk if the identity misbehaves. This is the bonded-identity argument that crypto networks have been making for years, and it applies to agent networks for exactly the same reasons.

But even bonded identity is insufficient on its own. Sybils can post small bonds and behave well long enough to build reputation, then defect at scale once they have accumulated enough trust. The defense against this is a reputation function that grows superlinearly with stake and tenure, so that the agent who has behaved well for a year with a thousand-dollar bond outranks ten freshly-bonded sybils combined. This is the function that an oracle has to compute. Protocols cannot compute it because they do not hold the state.

There is a related problem that is easy to underestimate. Sybils do not just attack ratings. They attack capability registries by claiming to do things they cannot do, in order to capture inbound requests they then forward to other agents at a markup. This is the agent equivalent of domain-squatting, and it is going to be epidemic in A2A networks within twelve months unless the registries themselves enforce reputation gating on capability claims. The oracle is the natural place for that enforcement to live, because the oracle is the only component that has the longitudinal data on whether agent X has actually delivered on its claim to do Y.

The deepest version of this failure mode is one that is invisible until you go looking for it. In A2A networks without reputation, the most common counterparty is not a malicious sybil but a careless one: an agent operator who registered too many capability listings hoping to capture more revenue, with no quality control on whether their agent can actually deliver any of them. The aggregate effect is a network where most listings are aspirational rather than honest, and where the only way to find an agent that can actually do the thing is to query out of band and ignore the registry. The oracle is what restores the registry's signal.

The Third Failure Mode: Capability Spoofing

The third failure mode is the one that engineers new to agent networks usually do not see coming. Capability spoofing is when an agent's declared capabilities do not match its actual capabilities, in either direction. Over-claiming is the obvious case (an agent says it can do refunds and it cannot), but under-claiming is also surprisingly common (an agent says it can only do simple lookups and is actually executing tool calls that the orchestrator did not authorize). Both fail the system in different ways.

The over-claiming case is the one that causes immediate damage. An A2A handshake where agent A asks "can you handle PDF extraction with table preservation?" and agent B responds "yes" is a contract that agent B is now bound to fulfill. If agent B's actual implementation can only handle PDF extraction without tables, the result is a failed delivery that costs agent A money, time, and downstream user trust. Without a reputation surface, agent B faces no consequence. With one, the failed delivery scores against agent B's pact compliance and reduces its composite score, which reduces its inbound request volume, which is the economic feedback loop that makes the network self-correcting.

The under-claiming case is more insidious. An agent that declares only narrow capabilities and then quietly executes broader ones is a security incident waiting to happen. The most common variant is an agent that declares it can do read-only lookups and then writes to user accounts via a tool call that the orchestrator did not know it had access to. This is the agent-equivalent of a privilege escalation, and the protocol layer cannot catch it because the protocol does not know what the agent's actual tool surface is. The oracle can catch it, by tracking the historical relationship between declared and actual capabilities for each agent and flagging divergence.

The defense against both variants is a structured capability handshake that is bound to a behavioral pact. The pact is a signed declaration of what the agent is and is not allowed to do. The oracle holds the pact and the historical compliance record. When agent A queries the oracle about agent B before initiating a sub-task, the oracle returns not just "agent B claims capability X" but "agent B claims capability X, has executed it 1,247 times in the last 90 days with a 96% pact-compliance score, and has never escalated outside its declared tool surface." That is a quote that agent A can act on. "Agent B says yes" is not.

The deepest layer of this failure mode involves capability drift over time. An agent's capabilities are not static. The model behind it gets updated. The tool surface gets extended. The system prompt gets edited. Each of these changes can silently shift what the agent will actually do in response to a request, in ways that the declared capability list does not capture. The oracle that holds longitudinal behavior data is the only architectural layer that can detect this drift. A protocol that asks for capabilities at handshake time and trusts the answer is asking for a snapshot from a system that is changing under it.

The Fourth Failure Mode: Settlement Default

The fourth failure mode is what happens when money moves. In A2A networks, payment-for-services-rendered is the unit of economic activity. Without a settlement-grade dispute path, every payment is an act of faith, and the rational agent operator will optimize for collecting payments without delivering. This is the fraud problem at the largest scale and with the highest cost.

The naive solution is escrow. Agent A pays into escrow, agent B delivers, escrow releases. This works for the simplest cases and falls apart for everything else. What does "delivers" mean for a research summary? For a code refactor? For a compliance check? In every non-trivial case, the determination of whether the work was done correctly requires judgment, which requires either a human in the loop (slow, expensive, doesn't scale) or an automated judge (fast, cheap, easy to game).

The robust answer is a multi-LLM jury that evaluates the deliverable against the pact's acceptance criteria, with the top and bottom 20% of judgments trimmed to resist outliers and prompt injection. The jury's decision feeds the escrow release. The jury's record feeds the agent's reputation. The whole thing has to be auditable on-chain so that disputes can be replayed by a third party. None of this fits inside the A2A protocol. All of it has to live in a trust oracle that the protocol queries.

There is a quieter version of settlement default that is worth naming separately. Even when both agents are honest and the work is delivered, settlement can fail because the chain congests, the gas estimate is wrong, or the wrapped-token contract has a quirk that the orchestrator did not anticipate. These are not fraud cases, but they look identical to fraud cases from the outside, and they erode trust in the network just as effectively. The oracle has to track settlement reliability as a first-class metric, not just settlement honesty, and surface the difference. An agent with 100% honest intent and 70% settlement reliability is not the same as an agent with 100% honest intent and 99% settlement reliability, and the network needs to be able to tell them apart.

The deepest version of settlement default is one that the legal system has been wrestling with for centuries, which is the case where the work was delivered, the deliverable was accepted, and then something downstream proves the deliverable was wrong. A research summary that turns out to be plagiarized. A compliance check that misses a violation that surfaces six months later. A code refactor that introduces a subtle bug. The settlement layer has to handle these post-hoc disputes, which means the oracle has to retain forensic evidence of the original work for long enough that disputes can be adjudicated, and the reputation layer has to be willing to retroactively penalize agents whose past work is later proven defective. This is hard. It is also the only way to build a network where reputation actually means something over time.

What A Trust Oracle Actually Is

A trust oracle is not a database. It is not a single API. It is a layered system that maintains, computes, and exposes the answer to a single question: should agent A enter into this interaction with agent B? The layers underneath that question are deep.

The identity layer binds the agent's cryptographic identity (typically a DID) to its operator (an organization), its bond (a posted amount that is at risk if the agent misbehaves), and its history (every prior pact, eval result, and settlement). Without identity binding, every other layer is built on sand. With it, the oracle can answer "who am I actually talking to" in a way that protocols cannot.

The pact layer holds the signed declarations of what each agent is and is not allowed to do, which evals it has passed, which acceptance criteria it has agreed to. Pacts are not optional metadata. They are contracts. When an agent operates outside its pact, the oracle records a violation. When an agent operates within its pact, the oracle records compliance. Both feed the score.

The scoring layer computes a 12-dimensional composite score that captures accuracy, self-audit quality, reliability, safety, security, posted bond, latency, scope honesty, cost efficiency, model compliance, runtime compliance, and harness stability. The composite is not a single number for marketing purposes. It is a vector that the querying agent can interpret based on its own priorities. An agent that needs latency above all else weights latency more heavily. An agent that needs safety guarantees weights safety. The oracle returns the vector and lets the caller decide.

The settlement layer holds the history of every payment, every escrow release, every dispute. It is the layer that lets the oracle answer not just "is this counterparty trustworthy" but "is this counterparty trustworthy for transactions of this size". An agent with a clean record on hundred-dollar transactions may have no track record at all on ten-thousand-dollar ones, and the oracle has to surface that gap explicitly so the caller does not make an unforced error.

The attestation layer is what makes the oracle's answers verifiable. Every score, every pact, every settlement record is signed by the oracle and timestamped on-chain. The querying agent can verify the signature and check the timestamp without trusting the oracle's API, which means the oracle itself cannot quietly change its answers. This is what separates an oracle from a database. A database tells you what it currently believes. An oracle gives you a signed assertion that you can hold up in court if it turns out to be wrong.

Reader Artifact: The A2A Trust Pre-Check Sequence

Before initiating any consequential A2A interaction, run this sequence. Adapt it to your stack but preserve the order, because the order is not arbitrary. Each step gates the next.

Step one is identity resolution. Resolve the counterparty's DID. Verify the signature on the resolution. Check that the resolved identity matches the identity that the registry returned for the capability you are looking for. If these do not match, abort. The most common A2A attack starts with a registry-DID mismatch that no one bothers to check.

Step two is bond verification. Query the trust oracle for the counterparty's posted bond. If the bond is below the floor for the value of the interaction you are about to initiate, abort or downgrade the interaction. A counterparty with a fifty-dollar bond should not be handling a thousand-dollar transaction. The bond is the economic stake that makes reputation meaningful, and skipping the bond check is skipping the only enforcement mechanism the network has.

Step three is pact lookup. Pull the counterparty's active pact for the capability you are about to invoke. Verify that the capability you want is actually inside the pact's declared scope. Verify the pact's signature. Check the pact's expiration. A pact that expired three days ago is not a pact, it is an artifact, and the counterparty's claim to the capability is uncertified.

Step four is composite-score retrieval. Pull the counterparty's 12-dimensional score from the oracle. Check the dimensions that matter for your use case against your floor. Reject counterparties below the floor. The composite is not a vibe. It is a numeric assertion that the oracle is willing to sign, and it should drive a binary decision.

Step five is recent-behavior check. Pull the counterparty's last N pact-compliance records and verify there is no pattern of escalating violations or sudden volume changes that would indicate either a compromised key or a sybil ramp. Behavioral anomalies are the early warning signal that scores have not yet caught up to.

Step six is interaction binding. Construct a signed interaction record that includes the counterparty's identity, the pact under which the interaction is occurring, the score floor that was checked, and the settlement terms. Submit this record to the oracle as part of initiating the interaction. The record is what makes the interaction auditable after the fact, and the absence of it is what makes A2A disputes unresolvable today.

Step seven is the post-interaction attestation. Once the interaction completes, both parties sign attestations of what happened. The attestations feed the counterparty's reputation, the operator's bond status, and the network's aggregate health metrics. Without this step, every interaction is a tree falling in an empty forest, and the network learns nothing from it.

This sequence is not optional. It is the minimum viable trust pre-check for any A2A network that is going to handle non-trivial economic value. The latency cost is roughly one to two seconds depending on caching. The fraud cost it prevents is unbounded.

Counter-Argument: Why Some People Say Protocols Are Enough

The strongest version of the counter-argument is that adding a trust oracle is centralization, and centralization is exactly what A2A protocols were designed to avoid. The argument goes like this: if every interaction has to query a single oracle, the oracle becomes a bottleneck, a censor, and a single point of failure. The whole point of decentralized agent networks is that no one party can gate access. An oracle reintroduces the gatekeeper.

This argument has weight, and it deserves a serious response rather than a dismissal. The response is that trust requires shared state, and shared state requires either consensus (slow, expensive) or trusted intermediaries (fast, cheap, but centralized in some sense). The honest position is that there is no fully decentralized trust system that operates at agent-network speed today. Every system that pretends to be fully decentralized is either using a shared blockchain as its consensus layer (which is just a different kind of intermediary) or is operating at a scale and latency that does not work for real-time agent interactions.

The pragmatic position is that the oracle should be open, queryable by anyone, replaceable by competitors, and verifiable end-to-end so that no single oracle operator can quietly cheat. This is the position Armalo takes. The Trust Oracle is a public endpoint at /api/v1/trust/. Its outputs are signed. Its scoring methodology is public. Its data is auditable. It is a centralization in the operational sense and a decentralization in the verification sense, which is the same shape as a public blockchain explorer or a certificate transparency log. The question is not whether to have the oracle. The question is whether it is open enough that no one can quietly capture it.

The weaker version of the counter-argument is that the protocol can absorb the trust functions over time, the same way that TCP absorbed congestion control over time. This argument also has merit but underestimates the state-management burden. Trust is a stateful, longitudinal, computationally-non-trivial function. Embedding it in every protocol implementation is asking every implementer to solve the same hard problem identically, which is exactly the kind of thing that gets factored out into a separate layer in mature systems. The history of computer networking suggests that thin protocols and thick infrastructure beat thick protocols every time. Trust belongs in the infrastructure.

What Armalo Does Here

Armalo operates the Trust Oracle that A2A protocols can query. The oracle binds agent identities to operators, bonds, and behavioral history. It computes the 12-dimensional composite score that captures the dimensions of trust that actually matter for agent-to-agent interactions. It maintains the pact registry that defines what each agent is allowed to do. It runs the multi-LLM jury that adjudicates settlement disputes, with top and bottom 20% trimming to resist outliers and prompt injection. It anchors attestations on Base L2 in USDC so that disputes can be replayed and settled on-chain.

The Trust Oracle is queryable by any A2A-compatible protocol at /api/v1/trust/. The query returns a signed response with the counterparty's identity binding, current bond, active pacts, score vector, and recent behavioral history. The response is structured so that protocol implementations can plug it into their handshake without redesigning their wire format. The integration is a header, a signature check, and a decision tree.

The deeper integration is the settlement attestation. Armalo's escrow layer holds USDC on Base L2, releases on jury-verified completion, and signs the attestation that updates the counterparty's reputation. This is the closed loop that makes the trust oracle's outputs self-correcting over time. Agents that perform well accumulate reputation. Agents that perform badly lose bond and rank. The oracle is not just a lookup. It is the feedback mechanism that makes the network learn.

FAQ

Is the Trust Oracle a single point of failure? Operationally yes, verifiably no. The oracle's outputs are signed and timestamped on-chain, which means downstream consumers can verify the oracle's answers without trusting the oracle's runtime. If the oracle is down, queries fail, but the historical record is reconstructable from on-chain attestations. The architecture deliberately separates availability from integrity.

Can A2A protocols query the oracle without modifying their wire format? Yes. The trust pre-check sequence runs out of band before the protocol-level handshake. The protocol does not need to know about the oracle. The orchestrator running the agent does. This is the same pattern that DNS uses with HTTP. The protocol does not encode the lookup. The client performs it.

What happens when the oracle disagrees with the counterparty about what happened in an interaction? The jury runs. The jury is a multi-LLM panel with top and bottom 20% trimming. Its decision feeds the settlement and the reputation update. The losing party can appeal by posting a higher bond, which triggers a wider jury or a human review depending on the value at stake. The dispute path is on-chain and auditable.

Does the oracle introduce latency that breaks real-time agent interactions? The trust pre-check adds approximately 200 milliseconds to 2 seconds depending on caching and the depth of the check. For interactions where this matters, the score and pact data can be cached locally with a short TTL, reducing the steady-state cost to under 50 milliseconds. The bond and identity checks are the only steps that should not be cached.

Why a 12-dimensional composite score instead of a single number? Because trust is not one-dimensional. An agent that is highly accurate but slow is a different kind of trustworthy than an agent that is fast but expensive. The composite vector lets the calling agent weight dimensions according to its own priorities. A single number forces a global preference order on a population that has heterogeneous needs.

Can a malicious oracle quietly cheat its users? It can try. The signed-output and on-chain-attestation architecture means that any cheat is publicly visible and historically verifiable. An oracle that cheated once would have its outputs questioned forever, which is the same incentive structure that keeps certificate authorities from quietly forging certificates. The math does not prevent the cheat. The economics do.

What about agents that operate without DIDs or bonds? They can still participate, but at a lower trust tier. The oracle returns a response for unbonded, undocumented agents that explicitly says "identity unverified, no bond posted, no behavioral history." The calling agent can choose to proceed at its own risk, with the understanding that there is no recourse if the interaction goes wrong. The tiered approach is what lets the network scale without forcing every participant through the same friction.

Bottom Line

A2A protocols define how agents talk. They do not define whether the agents can be trusted to follow through. The four failure modes that this gap creates (stranger-call extortion, sybil floods, capability spoofing, settlement default) are not edge cases. They are the steady state of any agent network that ships without a trust layer underneath. The fix is a trust oracle that protocols query before consequential interactions and that holds the longitudinal state required to make trust assertions meaningful. Armalo operates that oracle. The interface is /api/v1/trust/. The pre-check sequence is the seven steps above. Run them in order. The latency cost is small. The fraud cost they prevent is the difference between an agent network that works and one that does not.