Agent Protocol Security Needs Threat Models Before Standards Harden
MCP, A2A, ANP, and related protocols are moving faster than the trust models around them. The window to shape secure defaults is now.
Continue the reading path
Topic hub
MCP SecurityThis page is routed through Armalo's metadata-defined mcp security hub rather than a loose category bucket.
Next Read
Google A2A and the Missing Trust Layer: Identity, Verification, and Reputation Integration
Google's A2A protocol standardizes how AI agents communicate — but communication is not trust. This deep-dive covers the five trust layers A2A deliberately excludes, the concrete attack vectors each gap creates, and a production reference architecture for layering behavioral identity, obligation tracking, and reputation above the protocol.
Turn this trust model into a scored agent.
Start with a 14-day Pro trial, register a starter agent, and get a measurable score before you wire a production endpoint.
The standards race has a trust gap
Agent protocols are becoming the connective tissue of the agent economy. MCP standardizes tool and context access. A2A standardizes agent-to-agent coordination. ANP, ACP, and adjacent efforts explore discovery, networking, and interoperability. This is good for builders, but it also freezes assumptions. Once a protocol shape becomes normal, insecure defaults become harder to unwind.
The immediate threat is not that one protocol is bad. The threat is that protocol adoption outruns protocol threat modeling. Teams integrate because the protocol works. Security review arrives later and discovers that identity, delegation, scope, replay, logging, and recourse were treated as integration details.
Google introduced A2A as an open protocol for agent interoperability (https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/). MCP documentation positions MCP as a standard way for applications to provide context and tools to LLMs (https://modelcontextprotocol.io/). A 2026 comparative threat-modeling paper on MCP, A2A, Agora, and ANP argues that these emerging protocols reshape communication among agents, tools, and services (https://arxiv.org/abs/2602.11327). The protocol layer is becoming important enough to deserve first-class trust receipts.
The protocol threat model
Every agent protocol should be reviewed across seven questions: who is speaking, who authorized the delegation, what scope applies, what evidence travels, what can be replayed, what can be disputed, and what happens when a downstream agent fails.
Every claim in this post becomes a Sentinel eval. Add adversarial trust checks to your CI in 10 minutes.
Add Sentinel to CI →That may sound like governance language, but it is protocol design. If the wire format cannot carry enough trust context, every platform will invent incompatible patches above the protocol.
Protocol review table
| Protocol surface | Failure mode | Trust field to require |
|---|---|---|
| Discovery | Fake or stale agent identity | Signed identity and freshness |
| Delegation | Confused deputy across agents | Delegator, delegatee, scope, and reason |
| Tool access | Tool called under wrong authority | Tool receipt and caller authority |
| Streaming updates | Partial output treated as final | State and acceptance markers |
| Memory/context | Cross-boundary context leakage | Tenant, source, and allowed-use labels |
| Error handling | Failure hidden as retry noise | Failure class and recovery status |
| Settlement | Output accepted without proof | Pact, acceptance, dispute window |
This table is the minimum review object for protocol adoption. It keeps teams from confusing interoperability with trust.
The default that will haunt the ecosystem
Protocol defaults have a way of becoming culture. If early agent protocols normalize calls without durable delegation context, many vendors will build user experiences that make the missing context invisible. Later, when fraud, disputes, and compliance questions appear, teams will bolt on logs that were never part of the original trust event.
The protocol layer should not carry every business rule. It should carry enough proof context that business rules can be applied later. That means agent identity is not enough. The receiving system needs to know whether the agent is acting for a user, another agent, an organization, a scheduled workflow, a marketplace pact, or a recovery process. It also needs to know whether the delegation was broad, narrow, fresh, revoked, paid, disputed, or constrained to a tool.
This is why agent protocol security should borrow more from payments, supply chains, and incident response than from chat APIs. In payments, "who sent this?" is only the beginning. You also need authorization, amount, merchant, settlement state, chargeback path, and fraud monitoring. Agent work will need the same layered idea: identity, authority, evidence, acceptance, and recourse.
Builder checklist before adopting an agent protocol
Before rolling a protocol into production, a team should run five uncomfortable checks.
First, simulate a confused deputy. Can a low-trust agent cause a high-trust agent to call a tool under the high-trust agent's authority?
Second, simulate stale discovery. If an agent card, capability listing, or endpoint metadata was valid last week, can it still be replayed after revocation?
Third, simulate partial completion. Can an intermediate stream event be mistaken for a final accepted result?
Fourth, simulate context oversharing. Does the protocol event preserve enough tenant, purpose, and allowed-use labels to prevent a downstream agent from treating private context as reusable knowledge?
Fifth, simulate dispute reconstruction. If the recipient rejects the output two days later, can both sides reconstruct the same chain of delegation and evidence?
Protocol adversary replay lab
Armalo should build a protocol threat-model replay harness. Take representative MCP and A2A flows: tool call, agent discovery, delegated task, streaming result, failed tool, retry, and dispute. For each flow, replay attacks that strip identity, replay stale agent cards, downgrade scope, substitute tool outputs, or mislabel partial completion.
The metric should be receipt completeness: what percentage of adversarial protocol flows preserve enough evidence to decide who acted, under what authority, with what scope, and what consequence. The promotion gate is not zero attacks. It is a measurable increase in receipt completeness without breaking legitimate flows.
This is the kind of experiment that would let Armalo write from proof rather than opinion. Protocol security is too important for vibes.
The harness should produce two artifacts: a developer-facing compatibility report and an operator-facing risk report. Developers need to know which fields are missing. Operators need to know whether a real dispute could be resolved.
The interoperability trust layer
Armalo should not try to replace MCP or A2A. That would be fragmentation. The better position is to supply the trust layer those protocols will need: evidence receipts, delegation records, trust scores, dispute states, and recourse logic that can travel with protocol events.
If the protocol says agents can communicate, Armalo should help counterparties decide whether that communication deserves reliance.
FAQ
Should builders wait for protocols to settle?
No. Builders should adopt useful standards while instrumenting trust receipts around them. Waiting gives up learning; integrating blindly creates debt.
Which protocol is safest?
That is the wrong first question. Ask which deployment preserves identity, delegation scope, evidence, and dispute state for the workflows you actually run.
What is the high-leverage standard contribution?
Push for trust context fields in protocol events before the ecosystem normalizes minimal messages that cannot support audit or recourse.
The strategic point
Agent protocol standards will shape the market's default trust posture. The teams that run threat models now will influence the defaults everyone else has to live with later.
The Trust Score Readiness Checklist
A 30-point checklist for getting an agent from prototype to a defensible trust score. No fluff.
- 12-dimension scoring readiness — what you need before evals run
- Common reasons agents score under 70 (and how to fix them)
- A reusable pact template you can fork
- Pre-launch audit sheet you can hand to your security team
Turn this trust model into a scored agent.
Start with a 14-day Pro trial, register a starter agent, and get a measurable score before you wire a production endpoint.
Put the trust layer to work
Explore the docs, register an agent, or start shaping a pact that turns these trust ideas into production evidence.
Comments
Loading comments…