ai-ml

IETF Weighs an AI Agent Protocol Standard in 2026

July 24, 2026

#IETF #AI agent protocol #agentproto #MCP #A2A #agent interoperability #agentic ai

$\"IETF$

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.¹

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.¹ This is not a vote and not a product launch; the IETF works by rough consensus, and any resulting standard is years away.² 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.¹ 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.¹

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.\"¹

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.²

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.² 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.²

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.³ 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.⁴

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.⁵⁶ If you want the hands-on version of how agents advertise capabilities and hand off work, our A2A protocol tutorial walks through it.

\n\n

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.⁷ 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.⁷⁸

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).⁷ 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.⁷

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.⁹ 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.⁷ 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.⁷

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.¹⁰ 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.³ 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.

\n\n\n\n\n\n\n\n\n\n\n\n

Frequently Asked Questions

Not yet. At IETF 126 in Vienna, the agentproto Birds-of-a-Feather session opened the question of whether the IETF should charter a Working Group to standardize agent-to-agent communication.1 A BoF is an exploratory step, not a standard; even if a Working Group is chartered, a published RFC is typically two to four years out.10 The authoritative outcome of the session is posted to the IETF Datatracker.

2,419 reads

The Identity Layer for AI Agents Is Finally Being Built

July 11th, 2026

$\"Read$ $\"Print$ $\"Read$

$\"en-flag\"$ EN $\"ru-flag\"$ RU $\"ko-flag\"$ KO $\"es-flag\"$ ES $\"zh-flag\"$ ZH $\"fr-flag\"$ FR $\"ja-flag\"$ JA $\"hr-flag\"$ HR $\"ps-flag\"$ PS $\"el-flag\"$ EL $\"ca-flag\"$ CA $\"be-flag\"$ BE $\"lo-flag\"$ LO

$\"featured$

$\"Gus$

In March I published a piece arguing that AI agents don't have identities and that this was already a security crisis. The claim was operational. We were deploying systems that read files, call APIs and chain tools together, while the answer to the most basic security question, who exactly is acting right now, was still a shared account, a reused API key and permissions far broader than any single task required.

Four months later the diagnosis holds. Agent identity is not solved end to end. What changed is that the problem became explicit. Between March and July 2026 it showed up in protocol releases, enterprise features and papers with measured results. The identity layer for AI agents is finally being built. It just isn't finished.

A2A grew up first

The first milestone landed almost on top of my original article. On March 12, the A2A project shipped v1.0.0, its first stable specification. The release touches security directly: it removes the legacy OAuth implicit and password flows, adds Device Code (RFC 8628) and PKCE support, introduces native multi-tenancy, adds mTLS to the security schemes and formalizes Agent Card signature verification using JWS and JSON Canonicalization.

The signed Agent Cards are the piece I care about most. In v0.x, an Agent Card was self-declared metadata. Any agent could claim to be anything. With v1.0, clients can cryptographically verify agent identity and metadata before trusting an interaction across organizational boundaries. The spec also formalizes in-task authorization through the TASK_STATE_AUTH_REQUIRED state, which gives agents a standard fallback when an operation needs human or client approval mid-flight.

The limitation is that Agent Cards remain a declarative layer. The signature proves who published the card. It says nothing about what a specific running instance of that agent is doing right now, or under whose delegated authority. Identity per instance, portable across heterogeneous stacks, still doesn't exist in the spec.

MCP put authorization at the center

MCP moved on a different front. On March 9, the maintainers published their 2026 roadmap, acknowledging that the protocol had outgrown its "connect local tools" phase and was now production infrastructure with governance to match. In April the project expanded its maintainer team, citing the move to the Agentic AI Foundation and a growing volume of Specification Enhancement Proposals. When a protocol starts adding lead maintainers to handle SEP throughput, it has stopped being an experiment.

On May 21, the maintainers published the release candidate for MCP 2026-07-28 and described it as the largest revision since launch. It brings a stateless core, Tasks and MCP Apps as extensions, a formal deprecation policy and six SEPs hardening authorization to align with how OAuth 2.0 and OpenID Connect actually get deployed in production, including issuer validation per RFC 9207.

The most tangible piece landed on June 18, when Enterprise-Managed Authorization went stable. EMA lets organizations control MCP server access centrally through their identity provider. Users log in once and inherit access to every approved server, with no per-app OAuth consent screens. Okta is the first supported IdP through Cross App Access. Anthropic implemented it across Claude, Claude Code and Cowork, Microsoft shipped it in VS Code, and MCP servers from Asana, Atlassian, Figma, Linear and Supabase support it at launch.

EMA fixes something real. Before it, the typical enterprise pattern was a shared service account with a long-lived token in a .env file. No audit trail, no role scoping, no revocation path. EMA replaces that with IdP-governed access: group membership, conditional access rules, deprovisioning on offboarding. For anyone running agents in an enterprise, this is the most important practical improvement since my original article.

What EMA answers is which humans in this org may connect to which servers. What it doesn't answer is which agent instance received which delegated authority to perform which specific action inside a chain of tools. Provisioning and governance improved dramatically. Per-action, per-instance identity did not.

Research went where the protocols don't reach

While the protocols hardened their edges, academic work attacked the middle. Two papers stand out.

PAuth (arXiv 2603.17170, March 17) goes straight at overprivilege. Its argument: OAuth scopes are bound to operators, not operations. If your agent needs to transfer $100 to Bob, OAuth forces you to grant a blanket TRANSFER permission that covers any amount to any recipient. PAuth proposes task-scoped implicit authorization instead. Submitting a natural-language task authorizes only the concrete operations required to execute it faithfully. In the AgentDojo evaluation, all benign tasks complete without extra permissions and all injected attack operations trigger warnings, with zero false positives and zero false negatives. This is the operation-level policy layer I sketched in March, now with a working prototype.

AIP (arXiv 2603.24775, March 25) is the most direct confirmation of the original thesis. The paper states that neither MCP nor A2A natively verifies agent identity, and cites a Knostic scan of roughly 2,000 internet-exposed MCP servers in which every single one lacked authentication. Its answer is Invocation-Bound Capability Tokens: an append-only chain that fuses identity, attenuated authorization and provenance into one cryptographic artifact, with bindings for MCP, A2A and plain HTTP. The measured overhead is 2.35ms in a real multi-agent deployment, 0.086% of end-to-end latency, with a 100% rejection rate across 600 adversarial attempts. AIP is now also an IETF Internet-Draft, which tells you where this conversation is heading.

Around these two, a broader research cluster is forming: decentralized identity approaches built on DIDs and verifiable credentials, IETF drafts on attenuating authorization tokens for delegation chains, and work reframing the problem from "who are you" to "what portable authority can you prove". None of it is deployed at scale. All of it targets the layers the protocols still leave open.

Scoring my March claims

The original article made five claims. This is how they held up.

Agents don't fit the identity models for humans, services or bots. Confirmed. Every serious paper published since starts from this exact insufficiency and proposes agent-specific frameworks.

Delegation on behalf of a user is badly modeled*.* Confirmed, with nuance. MCP's authorization is still built on standard OAuth 2.1 flows. EMA improves the enterprise operation of those flows enormously without introducing universal agentic identity. Better plumbing, same conceptual gap.

Multi-tool composition creates emergent privileges nobody approved. Confirmed and expanded. MCP elevated tool annotations as a risk vocabulary, threat modeling work flagged tool poisoning as a critical client-side vulnerability, and A2A added in-task authorization. The ecosystem now agrees this is where attacks live.

You can't reliably audit who did what*.* Partially mitigated. Signed Agent Cards and AIP-style completion records add provenance. There is still no dominant standard for per-instance audit across stacks.

The fix is a layered stack, not a single patch. Confirmed. MCP is building the authorization layer. A2A is building declarative identity and inter-agent trust. Research is building task scoping, verifiable delegation and portable authority. Nobody is shipping one magic fix, because there isn't one.

The right question for July 2026

The question is no longer whether agents have an identity crisis. They do, and now everyone from protocol maintainers to IETF draft authors says so in writing. The right question is which parts of the stack finally exist and which parts remain aspirational.

My answer today: enterprise authorization for MCP exists and works. A serious foundation for inter-agent trust exists in A2A v1.0. Measured proposals exist for task scoping and verifiable delegation. What still doesn't exist is the layer that binds them into an interoperable default: identity per running instance, authority that attenuates correctly across multi-hop delegation and provenance you can audit end to end without trusting every intermediary.

In March I wrote that the best time to close this gap was before deployment, and the second best time was now. That line deserves an update. We're no longer starting from zero. We're starting from an ecosystem that finally admits, in specs and in code, that an agent can't keep being treated as a weird user or as just another service. An agent needs verifiable identity, bounded authority and auditable provenance. Until that's the default behavior in production, the crisis hasn't ended. It has started to professionalize.

References

Original article: AI Agents Don't Have Identities, and That's a Security Crisis (HackerNoon, March 2026)
The 2026 MCP Roadmap (MCP Blog, March 9, 2026)
A2A Protocol v1.0 announcement and What's New in v1.0
PAuth: Precise Task-Scoped Authorization For Agents (arXiv, March 17, 2026)
AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A (arXiv, March 25, 2026) and IETF draft-prakash-aip
The 2026-07-28 MCP Specification Release Candidate (MCP Blog, May 21, 2026)
Enterprise-Managed Authorization: Zero-touch OAuth for MCP (MCP Blog, June 18, 2026)

← Previous

AI Agents Don’t Have Identities and That’s a Security Crisis

About Author

$\"Gus$

byGus Aragón|@garagon

Founder at Oktsec.com

Founder @ Oktsec | Security for AI agent work | AAIF Ambassador | Cybersecurity | Open Source

Read my stories About @garagon

TOPICS

cybersecurity

#ai-agents #ai-security #a2a-protocol #mcp-server #ai-agent-identity #oauth-2.1 #enterprise-ai #hackernoon-top-story

IETF Weighs an AI Agent Protocol Standard in 2026

What you'll learn

What happened at the agentproto BoF

Why it is rough consensus, not a vote

MCP vs A2A: two layers, one missing piece

The problems the framework says still need a standard

Why prompt injection is the security test

The realistic timeline — and what to watch

Frequently Asked Questions

Related Posts

Adobe + Claude: 50+ Creative Tools From One Prompt

Claude Managed Agents: Build Production AI Agents in Days

Agentic Testing in 2026: What Slack's 200-Run Data Shows

Pinecone Nexus: Is RAG Ending for AI Agents? (2026)

The Identity Layer for AI Agents Is Finally Being Built

A2A grew up first

MCP put authorization at the center

Research went where the protocols don't reach

Scoring my March claims

The right question for July 2026

References

About Author

TOPICS

Light-Mode

Classic

Newspaper

Proof of Usefulness

Dark-Mode

Neon Noir

Minty

Startups of the Year