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.