How the inter-agent and tool-protocol layer is being built

This rides alongside the groundwork post on inter-agent and tool protocols: that one is the controls, this one is the build-out, as of June 2026. The disclosure at the foot sets the terms; please read it first.

This layer is unusual: the protocols themselves are the main event, and they are young. The security around them is younger still. Several controls here have no product behind them at all.

The standards are the story

• MCP, the Model Context Protocol, is the agent-to-tool standard, with a dedicated MCP Authorization profile that treats each tool server as an OAuth 2.1 resource server, binds tokens to a specific server (RFC 8707) so a token stolen from one server cannot be replayed against another, and advertises discovery metadata (RFC 9728) so a client can safely learn how to authenticate.
• A2A, the Agent2Agent protocol, is the agent-to-agent standard, now at version 1.0.0 under the Linux Foundation, with optional signed Agent Cards (using JSON Web Signatures, JWS, over a canonicalized form of the document, JCS) so a receiver can verify the card has not been tampered with.
• Ed25519 signing and SBOMs carry the supply-chain side; CISA's SBOM-for-AI minimum elements set the bar for what a bill of materials should record; OWASP LLM05 frames untrusted-output handling.

The headline: the standards are consolidating fast (MCP and A2A have become the prominent interoperability specs in the mapped ecosystem), but the specific security primitives they ship (Agent Card signing in A2A, token binding in MCP authorization) are optional rather than required, which puts the burden on you to turn them on.

Who is building what, by control

Agent-to-agent authentication (PT-01). The A2A spec itself [standard], under the Linux Foundation, defines the signing mechanism. (Beyond Identity's Ceros [public preview] brings device-bound passkeys to MCP trust, which is agent-to-tool, PT-02 territory, not the A2A peer authentication PT-01 is about, so it belongs with the next control, not this one.)

MCP authorization and registry (PT-02). Anthropic stewards MCP and its authorization profile; Microsoft's open-source Agent Governance Toolkit works the registry-governance and gateway side, and CrowdStrike contributes AI-agent and MCP discovery and runtime visibility.

Manifest signing (PT-03). Microsoft's Agent Governance Toolkit signs plugins (Ed25519); CrowdStrike contributes agent and MCP-server discovery on the runtime side.

Tool input/output validation (PT-04). Google and Anthropic both publish guardrail guidance [published guidance] for treating tool results as untrusted, guidance to build against, not a shipping control that does it for you.

Where there is no product yet

Three controls here are framework-level with no commercial owner: output encoding for downstream systems (PT-05), semantic sanitization of model-written tool parameters (PT-06), and tool-description integrity against hidden instructions (PT-07). These are the subtle, high-value controls, the ones that catch an exploit hiding inside a perfectly valid tool call or a poisoned tool description. The corpus carries a reference implementation for the parameter-sanitization idea precisely because I found nothing off the shelf that does it, as of this snapshot, and that reference is experimental: semantic sanitization is probabilistic defense-in-depth, not a solved control. If you need these, you are building them.

Where implementation activity is concentrated

The energy is in the protocols maturing under neutral foundations, MCP and A2A both moved fast in the last year, and in newcomers bringing identity rigor to agent-to-agent trust (Beyond Identity's passkey angle). The disintermediation pattern to watch runs the other way from most layers: standardization itself is the disintermediator. As MCP and A2A adoption continues, they erode any proprietary agent-connection layer a vendor might have hoped to own. For defenders that erodes proprietary lock-in, while concentrating importance in the few signing and authorization primitives the standards define.

Consolidating or fragmenting?

Both, on different axes. The protocols are consolidating hard; the security around them is fragmented and immature, optional signing, half the controls without a product. The risk is a world where everyone speaks MCP and A2A fluently while leaving the signing and validation switched off. The job for now is to require the optional security the standards already allow.

The handoff

The protocol standards define how to authenticate a tool or an agent. No product in the map owns the next question, constraining a correctly-authenticated-but-malicious tool, which belongs to the containment and governance layers. The handoff between "verified" and "allowed to act" is unowned, the same point the groundwork post makes: a signature proves who, not whether the call is safe.

See the protocol groundwork post for the controls and validation steps, and explore the protocol controls in Apeiris Security at apeiris.ai.

Sources

• A2A Protocol v1.0.0 · Model Context Protocol · MCP Authorization (OAuth 2.1 + RFC 9728 + RFC 8707)
• Microsoft, Agent Governance Toolkit · CrowdStrike, What security teams need to know about OpenClaw
• CISA, SBOM for AI: Minimum Elements · OWASP Top 10 for Agentic Applications 2026

---

How to read this. Snapshot dated 21 June 2026. A product appears here because it maps to a control, not as a recommendation or independently validated efficacy; vendor figures are their own claims; status tags mark what kind of thing each entry is. The full neutrality statement and method are in the capstone.