IETF Weighs an AI Agent Protocol Standard in 2026
July 24, 2026
In one line: At IETF 126 in Vienna this week, a Birds-of-a-Feather session called agentproto asked whether the internet's standards body should define how AI agents talk to each other across organizations — the gap that today's dominant protocols, MCP and A2A, leave open.1
TL;DR: For more than a year, vendors shipped competing AI agent protocols — Anthropic's MCP, Google's A2A, and several more — and none of them cleared the one bar that makes a protocol interoperable across organizational boundaries: an IETF RFC. On Thursday, July 23, the agentproto Birds-of-a-Feather (BoF) session at IETF 126 in Vienna brought that question into the Internet Engineering Task Force, with a view toward chartering a Working Group.1 This is not a vote and not a product launch; the IETF works by rough consensus, and any resulting standard is years away.2 What is genuinely new is that agent-to-agent communication is now being treated as an internet-infrastructure problem, not just a vendor feature.
What you'll learn
- What happened at the agentproto BoF at IETF 126, and what a "Birds-of-a-Feather" session actually decides
- Why the IETF works by rough consensus rather than a vote — and why that framing matters here
- How MCP and A2A differ, and the interoperability gap neither one closes
- The specific problems the underlying framework draft says still need a standard
- Why prompt injection is the security test any agent protocol standard has to pass
- The realistic timeline from a BoF to a published RFC, and what to watch next
What happened at the agentproto BoF
The IETF 126 meeting ran 18–24 July 2026 in Vienna, and among the established Working Group sessions the organization scheduled five Birds-of-a-Feather sessions — early, community-wide discussions about work that might be ready for the IETF to take on.1 Three of the five touched AI agents directly. The one with the highest stakes for anyone building multi-agent systems was agentproto (Agent Communication Protocols), held Thursday, 23 July, 09:00–11:00 CEST.1
The IETF's own framing is precise: the past year produced "a rush of competing, overlapping protocols for connecting AI agents to one another and to the tools they use — Model Context Protocol (MCP), Agent2Agent (A2A), the Agent Communication Protocol (ACP), the Agent Network Protocol (ANP), and more." The agentproto session, it says, "brings that conversation into the IETF," building on a well-attended IETF 124 side meeting and on framework and requirements work led by Jonathan Rosenberg and Cullen Jennings, "with a view toward chartering a Working Group to take that work forward."1
That phrase — chartering a Working Group — is the actual object of the meeting. A BoF is not where a standard gets written. It is where the community decides whether there is enough consensus, energy, and a tight enough scope to justify starting the multi-year process that eventually produces one.2
Why it is rough consensus, not a vote
It is tempting to describe Thursday's session as a vote on an IETF AI agent protocol standard. That is the wrong mental model, and the distinction is not pedantic. The IETF does not decide by counting ballots. It decides by "rough consensus and running code" — a working agreement in the room and on the mailing list, backed by implementations that actually run.2 A BoF that is "working-group-forming," as agentproto aims to be, succeeds when it demonstrates that a coherent problem and a willing community exist; it can just as easily send the work back to the mailing list if the discussion reveals too much disagreement about scope.2
This is why an IETF outcome carries weight that a vendor announcement does not. The RFCs that came out of this process define TLS, DNS, and the transport underneath modern web traffic, and they endure precisely because they were not imposed by one company. If the IETF eventually charters an agent-protocol Working Group, it is asserting that an IETF AI agent protocol standard belongs in the same category as those foundational specifications — an internet-layer concern rather than a product-layer one. As of this writing, the formal result of Thursday's session — whether a Working Group is chartered — follows that consensus process; session materials and minutes are posted to the IETF Datatracker as they are finalized, and that is the authoritative place to confirm the outcome rather than early press summaries.
MCP vs A2A: two layers, one missing piece
To see why the IETF is interested at all, you have to see what the existing protocols do and do not cover. They are not really competitors so much as neighbors solving different halves of the problem.
MCP (Model Context Protocol) is a client-server protocol: an agent reaches out to a tool, database, or API and requests data or an action. Anthropic donated MCP to the Agentic AI Foundation — a directed fund under the Linux Foundation — on 9 December 2025, and by that point the protocol reported "over 97 million monthly SDK downloads, 10,000 active servers," with first-class client support across ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, and Visual Studio Code.3 Its next revision, the 2026-07-28 spec, is the largest since launch and, among other things, realigns authorization with OAuth 2.1; we covered that change in depth in our write-up of MCP's stateless 2026-07-28 spec.4
A2A (Agent2Agent) is a peer-to-peer protocol: two agents discover each other's capabilities and delegate tasks. Google donated A2A to the Linux Foundation on 23 June 2025 at Open Source Summit North America, with Amazon Web Services, Cisco, Microsoft, Salesforce, SAP, and ServiceNow among the founding members; the coalition has since grown to over 100 technology companies.56 If you want the hands-on version of how agents advertise capabilities and hand off work, our A2A protocol tutorial walks through it.
Here is the gap. MCP standardizes the agent-to-tool link. A2A standardizes the agent-to-agent link within a broadly cooperating ecosystem. Neither one fully specifies what happens when an agent in your organization needs to prove to an agent in someone else's organization that it is authorized to act on a user's behalf — and to do so in a way both sides can verify without a prior bilateral integration. That cross-domain, no-prior-trust case is exactly the territory internet standards exist to cover.
The problems the framework says still need a standard
The intellectual basis for agentproto is a framework and requirements document authored by Jonathan Rosenberg, of Five9, and Cullen Jennings, of Cisco.7 Rosenberg's involvement is a signal in itself: he is a lead author of RFC 3261, the Session Initiation Protocol that governs much of the internet's real-time voice and video. One procedural caveat worth stating plainly: an Internet-Draft is a proposal, not a standard. The datatracker attaches an explicit disclaimer that such drafts are "not endorsed by the IETF" and have "no formal standing in the IETF standards process," and the early framework draft has already been superseded — the current document is draft-rosenberg-agentproto-usecases.78
With that caveat, the framework's argument is that today's protocols leave a short list of hard problems unsolved, and that these are the ones worth standardizing. Its requirements sections map to them directly: discovery (how agents find each other, especially across domains), authentication and authorization (how identity and credentials are federated so one organization's agent can be trusted by another's), lifecycle management (how a chain of delegated agents is managed across the life of a task), and user confirmation (how a human stays in the loop before an action such as booking a flight is committed).7 The draft frames agent communication as a new application-layer concern — occupying the same tier of the internet stack as HTTP, SIP, and RTP do today.7
Why prompt injection is the security test
The most concrete technical argument for standardizing this at the protocol layer is a security one, and it centers on prompt injection.
In a single-agent system, prompt injection means a user crafts input that overrides the agent's instructions. OWASP ranks it as LLM01 — the number-one risk in its Top 10 for LLM Applications.9 The multi-agent version is structurally worse. A malicious user can craft input for Agent A that is really aimed at Agent B, the agent that A calls next. Because A relays user content to B as part of normal operation, and because B trusts A, the injected instruction can ride the trust relationship straight past A's defenses.7 The framework's position is blunt: prompt injection is notoriously difficult to prevent, so the protocol-level answer is not prevention but attribution — mechanisms for logging, diagnosis, and reconstructing which agent did what when an incident happens.7
That is a requirement no purely application-level defense can satisfy, because the attack crosses a boundary between two independently operated systems. It is also the clearest illustration of why "just use MCP and A2A" is not a complete answer: neither was designed to carry incident attribution across an inter-domain agent cascade.
The realistic timeline — and what to watch
Set expectations accordingly. The IETF process is deliberately slow: a proposal typically moves from a BoF, to a chartered Working Group, through multiple Internet-Draft revisions and reviews, to a published RFC — a path that commonly takes on the order of two to four years.10 Nothing shipped in Vienna this week. What the meeting could produce is a decision to start, and that decision then shapes what the RFC pipeline looks like in 2027 and 2028.
The strategic question underneath is whether an open IETF AI agent protocol standard will define inter-domain agent communication, or whether the market-dominant protocols will harden into de facto standards by deployment momentum alone. MCP's 97-million-downloads-a-month adoption is a real gravitational field, and it is entirely possible that the practical baseline gets set by what is already deployed rather than by what the IETF eventually blesses.3 The tension between those two outcomes is the story worth following. It is also the same interoperability-versus-lock-in tension that regulators are pressing from a different direction, as we covered in the EU's push for AI agent interoperability under the DMA.
For now, the honest status is: the conversation has arrived at the IETF, the problem statement is well-formed, and the outcome of Thursday's session is a matter of public record on the IETF Datatracker rather than of speculation.
