{"id":114787,"date":"2026-07-22T12:04:09","date_gmt":"2026-07-22T12:04:09","guid":{"rendered":"https:\/\/www.europesays.com\/ai\/114787\/"},"modified":"2026-07-22T12:04:09","modified_gmt":"2026-07-22T12:04:09","slug":"ai-agent-protocol-standard-vote-arrives-thursday-at-ietf-126-in-vienna","status":"publish","type":"post","link":"https:\/\/www.europesays.com\/ai\/114787\/","title":{"rendered":"AI Agent Protocol Standard Vote Arrives Thursday at IETF 126 in Vienna"},"content":{"rendered":"

The body that produced TLS, DNS, BGP, and QUIC is now four days into its 126th meeting in Vienna \u2014 and the most consequential two hours of the week have not happened yet. Wednesday morning, an invited diagnostic session called DMSC finished mapping the problem space for AI agent gateway-mediated collaboration: how agents expose capabilities, forward requests, coordinate across organizational boundaries, and attribute security incidents. Thursday morning, the agentproto Birds-of-a-Feather session opens at 09:00 Central European Summer Time (03:00 ET) to decide whether the Internet Engineering Task Force will charter a Working Group to turn that work into a binding internet standard \u2014 one that would carry the same implementation authority as every RFC the IETF has ever produced, as described in the IETF’s official BoF session listing<\/a>.<\/p>\n

At stake is a question the AI industry has deferred for eighteen months: will inter-domain AI agent communication be standardized by an open, multi-stakeholder internet body, or will Anthropic’s Model Context Protocol and Google’s Agent2Agent Protocol harden into the de facto baseline by deployment momentum alone \u2014 and then be nearly impossible to displace, as happened when the OSI networking stack lost to TCP\/IP in the 1980s? Five competing protocols \u2014 MCP, A2A, the Agent Communication Protocol, the Agent Network Protocol, and Cisco’s Agntcy Framework \u2014 have staked out overlapping territory without any of them clearing the one bar that makes a protocol genuinely interoperable across organizational boundaries: an IETF RFC, as detailed in the IETF 126 BoF session overview<\/a>.<\/p>\n

If Thursday’s session produces rough consensus and a Working Group charter, the IETF is asserting that AI agent communication is an internet-infrastructure problem \u2014 not a product-layer problem. If it surfaces too much disagreement, the community returns to the mailing list and the fragmented landscape continues. The answer will be visible in real time; session recordings will post to the IETF YouTube channel as they conclude.<\/p>\n

What DMSC Found Wednesday and Why It Feeds Tomorrow<\/p>\n

DMSC \u2014 Dynamic Multi-Agent Secured Collaboration \u2014 met this morning at the Hilton Vienna Park from 09:00 to 11:00 CEST as a non-working-group-forming BoF. That classification matters: DMSC was not designed to produce a charter. It was designed to profile the existing landscape and identify gaps that tomorrow’s agentproto session will need to address, as detailed on the DMSC BoF about page<\/a>.<\/p>\n

The problem DMSC mapped is the AI agent gateway model: the architectural layer that sits between an orchestrating agent and the downstream agents or tools it invokes. A gateway handles capability exposure (what can this agent do?), request forwarding (how does the request reach the right downstream service?), coordination and synchronization (how do parallel agent threads reconcile results?), policy control (who can authorize this action?), observability (how does a human audit what the agent did?), and secure inter-agent communication (how does the receiving agent verify the sender’s identity and the integrity of the request?), as laid out in the DMSC BoF agenda<\/a>.<\/p>\n

DMSC did not address any single gap in isolation \u2014 it profiled how existing mechanisms defined elsewhere (in OAuth, WIMSE, DNSOP, and the A2A and MCP specifications themselves) cover parts of the problem, and where coverage is absent. Its findings are expected to sharpen the scope discussion at agentproto tomorrow.<\/p>\n

Why One RFC Would Outweigh All Five Competing Protocols<\/p>\n

The Rosenberg-Jennings Internet-Draft \u2014 the framework document that gave the agentproto work its conceptual foundation \u2014 explicitly positions AI agent protocols as a new application layer sitting above HTTP, SIP, and RTP in the internet stack, as described in the framework document<\/a>. That framing matters architecturally: it says AI agent communication occupies the same position that SIP occupies above TCP and UDP for real-time communications \u2014 and therefore needs the same kind of open internet standard that SIP eventually became.<\/p>\n

Jonathan Rosenberg, who co-authored the framework document as CTO of Five9<\/a>, also wrote RFC 3261 \u2014 the Session Initiation Protocol that governs real-time internet communications today. Cullen Jennings, his co-author, is a longtime Cisco engineer and IETF participant. Their January 2026 IETF blog post describing the problem<\/a> identified five unsolved questions that no current protocol fully addresses: how agents discover each other’s existence and capabilities, how agents delegate tasks and credentials across organizational boundaries, how privacy is preserved when passing user context between systems, how multimodal content (text, audio, images) is handled as context accumulates, and how humans stay in the loop before irreversible actions are committed.<\/p>\n

An IETF 124 side meeting on this work attracted approximately 125 engineers in person and a comparable number online \u2014 an unusually strong turnout for a pre-BoF side meeting, as Jennings noted in the same post<\/a>. That attendance is one reason the agentproto BoF arrived at IETF 126 with a Working Group charter already drafted for community review.<\/p>\n

What MCP and A2A Still Do Not Cover<\/p>\n

MCP and A2A address different layers of the problem. MCP is a client-server protocol: an AI agent connects to a tool, database, or API and requests data or actions using a standardized JSON-RPC 2.0 message format. A2A is a peer-to-peer protocol: agents discover each other’s capabilities via Agent Cards \u2014 JSON documents published at well-known URLs \u2014 then coordinate tasks using HTTP, Server-Sent Events, and JSON-RPC.<\/p>\n

The Rosenberg-Jennings framework<\/a> identifies four gaps that neither protocol currently specifies. First, cross-domain identity federation: how does Organization A’s agent prove to Organization B’s system that it is acting on behalf of a specific authorized user \u2014 not just claiming to be from Organization A? Second, multi-hop lifecycle management: when Agent A delegates to Agent B, which delegates to Agent C, and Agent B fails mid-task, how does the chain recover and who is responsible for the incomplete action? Third, user confirmation requirements before irreversible API calls: the protocol layer does not currently specify when an agent must pause and obtain explicit human authorization, leaving this to application-level conventions that differ by vendor. Fourth, protocol-level security attribution for prompt injection incidents.<\/p>\n

How Prompt Injection Escalates in Multi-Agent Systems<\/p>\n

The security architecture gap that agentproto must address is structurally different from the prompt injection problem in single-agent deployments. In a single-agent system, a malicious user crafts input to override that agent’s instructions. In a multi-agent system, the attack can cascade: malicious input injected into Agent A propagates to Agent B as part of normal operation, because Agent A relays content from the user to Agent B in its standard message format. Agent B \u2014 which trusts Agent A \u2014 then acts on the injected instruction, bypassing defenses entirely. The injected command travels through the inter-agent trust relationship, not through the user’s interface to the agent, as the Rosenberg-Jennings framework<\/a> explains.<\/p>\n

The Rosenberg-Jennings framework does not claim a protocol can prevent prompt injection \u2014 it explicitly calls such attacks “notoriously difficult to prevent.” What a protocol can provide is attribution: logging, traceability, and incident reconstruction so that security teams can determine which agent in a chain executed a malicious instruction and what path the instruction took to reach it. OWASP lists prompt injection as the top security risk<\/a> in its Top 10 for LLM Applications 2025. Documented real-world incidents have involved public Slack channels, GitHub issue trackers, and web pages as injection vectors \u2014 none involving the inter-domain agent cascades that agentproto targets, but pointing toward the risk profile that multi-agent deployment at scale will create.<\/p>\n

Four BoFs Already Concluded: What the Week Produced<\/p>\n

PTTH \u2014 the Protocol for Transposed Transactions over HTTP \u2014 held its working-group-forming session Monday evening. PTTH proposes a standardized, interoperable mechanism for swapping the HTTP client and server roles: when a server should only be accessible to a small number of pre-approved clients that the server can reach directly, and is not publicly accessible due to security or network routing constraints, PTTH would replace the current landscape of proprietary per-vendor workarounds with a single open specification. The session arrived with a proposed Working Group charter; Monday’s discussion tested whether the community reached rough consensus to adopt it, as outlined in the IETF 126 BoF session listing<\/a>.<\/p>\n

DAWN \u2014 Discovery of Agents, Workloads, and Named Entities \u2014 met Tuesday to seek Working Group status for a decentralized, automated discovery mechanism capable of operating at the scale of distributed processing environments where agent components have no pre-configured knowledge of each other. AI agent-to-agent communication is an explicit part of DAWN’s scope. The working-group-forming session aimed to confirm that the community agreed on scope and energy sufficient to charter the work, as described in the IETF 126 BoF session listing<\/a>.<\/p>\n

CURRENT \u2014 Continuous Updating and Ratcheting for Rekeying Encrypted Network Transport \u2014 held its session Tuesday evening. The proposal would use Messaging Layer Security (MLS), already published as RFC 9420 and now adopted by RCS for hundreds of millions of mobile devices<\/a>, as the key management foundation for a two-party security protocol at the network transport layer. MLS provides asynchronous key updates, forward secrecy, and post-compromise security \u2014 properties that current transport protocols (TLS and QUIC) do not offer natively after the initial handshake. MLS has also been formally verified, which is rare for protocol proposals and gives CURRENT a stronger security baseline than most new work. That formal verification pedigree, combined with MLS’s recent deployment across hundreds of millions of mobile devices via the RCS messaging standard, made CURRENT one of the more technically substantive BoFs of the week.<\/p>\n

BGP Security: Why the SIDROPS Draft Matters to Network Operators<\/p>\n

The SIDR Operations Working Group sessions this week are advancing a draft with direct operational implications for network operators who have already deployed RPKI-based BGP route validation. The draft \u2014 currently at revision 07, authored by Job Snijders (BSD), Tobias Fiebig (MPI-INF), and Massimiliano Stucchi (Glevia GmbH) \u2014 addresses a subtle but consequential routing stability problem, as described in the draft itself<\/a>.<\/p>\n

When operators annotate BGP routes with RPKI-derived validation states \u2014 marking routes as VALID, INVALID, or NotFound using transitive BGP path attributes such as communities \u2014 those attributes propagate through the global internet routing fabric. When a Route Origin Authorization is issued or revoked, or when an RPKI-to-Router session terminates, the validation state of affected routes changes, triggering new BGP UPDATE messages for every route carrying the changed community value. Because transitive attributes propagate across autonomous system boundaries, a single ROA change can trigger UPDATE flooding that spreads through provider-edge routers globally, increasing memory pressure and destabilizing aging routes.<\/p>\n

The draft’s recommendation<\/a> is direct: operators should not carry RPKI validation states in transitive path attributes at all. If an operator’s own network validates and enforces RPKI, it should never import INVALID routes in the first place \u2014 meaning there is no legitimate downstream use case for propagating the INVALID tag to neighbors. The only validation states a downstream should ever see are NotFound and Valid, and those should be derived from the downstream’s own RPKI validation infrastructure, not inherited from a transitive attribute set by an upstream. The operational benefit is twofold: reduced memory consumption on provider-edge routers from fewer community values, and no route-age disruption when ROAs change.<\/p>\n

What Post-Quantum DNSSEC Actually Requires from DNS Operators<\/p>\n

The DNS Operations Working Group sessions Monday and Friday this week are evaluating post-quantum algorithm selection for DNSSEC under real operational constraints \u2014 a discussion the IETF community has been working toward since NIST finalized its first three post-quantum cryptography standards in August 2024<\/a>.<\/p>\n

The core constraint is size. NIST’s ML-DSA-44 (FIPS 204) produces signatures of approximately 2,420 bytes and public keys of approximately 1,312 bytes. The ECDSA-P256 signatures that current DNSSEC deployments use are 64 bytes each. DNS has historically used UDP with a practical response size limit of roughly 4,096 bytes via EDNS0 extensions; post-quantum signatures routinely exceed this limit, forcing DNS resolvers to fall back to TCP. TCP DNS incurs meaningful additional latency, adding overhead at a layer where millions of lookups per second require sub-millisecond response times at scale, as analyzed in the PQC DNSSEC strategy draft<\/a>.<\/p>\n

The strategy draft currently under DNSOP discussion (draft-sheth-pqc-dnssec-strategy-01, from Verisign Labs, Virginia Tech, and NLnet Labs) proposes a two-track approach. A low-impact drop-in algorithm \u2014 Falcon-512, with 666-byte signatures \u2014 can be adopted without protocol modifications and provides post-quantum security for routine lookups. A conservatively designed algorithm \u2014 SLH-DSA \u2014 provides a more robust security baseline and functions as a resilient fallback in modes that reduce signature-size impact. A parallel academic paper from Espie, Mayer, and Perret (2026)<\/a> extends this by proposing differentiated algorithm selection for the Zone Signing Key and Key Signing Key roles, enabling algorithms that would otherwise exceed DNS response size limits when both roles used the same scheme.<\/p>\n

What Can I Do With This Information: A Decision Guide for Thursday’s Session<\/p>\n

If you develop or architect multi-agent AI systems, tomorrow’s agentproto session outcome is a direct signal for how you should plan your protocol stack. If the session charters a Working Group, that Working Group will produce Internet-Drafts leading to an RFC \u2014 likely two to three years out. Implementations that align with the emerging standard will claim genuine cross-vendor interoperability. Implementations built solely on MCP or A2A will need to adapt if those protocols’ architectures diverge from what the RFC ultimately specifies. The mailing list archive (agent2agent at mailarchive.ietf.org) and the Datatracker (datatracker.ietf.org\/meeting\/126\/agenda) carry all active drafts and session materials in real time.<\/p>\n

If you operate BGP routing infrastructure, the SIDROPS draft and accompanying IETF route-hijack guidance<\/a> recommends auditing your current use of RPKI validation states in transitive BGP communities. If your network already implements RPKI validation and enforcement, the draft’s argument is that propagating those states to neighbors provides no legitimate downstream benefit and creates unnecessary UPDATE flooding risk.<\/p>\n

If you administer DNSSEC-signed zones, the algorithm selection question is now practically open. Hackathon projects at IETF meetings have already extended resolvers including BIND, NSD, and CoreDNS to support ML-DSA, Falcon, SLH-DSA, and SLH-DSA-MTL. Verisign’s active contributions to the IETF PQC DNSSEC mailing list and side meetings<\/a> provide a practical implementation track for operators who need to evaluate tradeoffs before standards finalize.<\/p>\n

Rest of the Week: Friday’s Remaining Sessions<\/p>\n

Friday’s working group sessions include httpbis (HTTP protocol family maintenance and extensions), TLS (post-quantum hybrid key exchange and certificate format coordination with LAMPS), SCITT (Supply Chain Integrity, Transparency, and Trust \u2014 whose Hackathon project this week implemented COSE_Sign1 agent-action records anchored in a SCITT transparency log for AI agent accountability), aipref (publisher preferences for AI crawlers), and the final IDR session advancing BGP extensions for computing-aware traffic steering.<\/p>\n

The IETF Plenary is tonight, Wednesday July 22, at 18:30 CEST (12:30 ET) in Grand Park Hall 1\/2\/3. It will deliver leadership updates and open the floor for community discussion on cross-cutting topics. The Farewell Reception closes the week Friday afternoon, with the full schedule on the IETF 126 meeting agenda<\/a>.<\/p>\n

IETF 127 is scheduled for November 14\u201320, 2026, in San Francisco at the Hilton Union Square. Whatever Working Groups are chartered this week will hold their first formal sessions there.<\/p>\n

Frequently Asked QuestionsHow does a Birds-of-a-Feather session actually become a Working Group, and what is “rough consensus”?<\/p>\n

A BoF is an open community session that tests whether there is enough agreement, scope clarity, and active participation to charter a new Working Group. The IETF does not vote \u2014 it operates by rough consensus, meaning the session chair assesses whether the community as a whole agrees on a path forward, accounting for both the weight and strength of objections rather than counting heads. If the agentproto BoF chair determines that rough consensus exists on the proposed charter, that charter goes to the Internet Engineering Steering Group for review and approval. If the IESG approves, the Working Group is formally chartered and begins producing Internet-Drafts that will eventually become RFCs \u2014 the binding technical specifications that every implementation must satisfy to claim genuine interoperability.<\/p>\n

What happens to MCP and A2A if agentproto does not produce a Working Group charter?<\/p>\n

If the session surfaces too much disagreement to proceed, there is no RFC timeline, and MCP and A2A continue operating outside the formal IETF process. The risk is incumbency lock-in: both protocols already have substantial deployment (MCP donated to the Linux Foundation in December 2025, A2A donated by Google in June 2025 with broad enterprise supporter lists). The more deeply enterprise systems integrate with one of these protocols, the harder it becomes for a future standard \u2014 even an architecturally superior one \u2014 to displace them. This is the TCP\/IP vs. OSI dynamic: TCP\/IP became the internet’s protocol not because it won a technical competition, but because it had running code, open access, and a growing deployment base before OSI could standardize alternatives. The IETF created TCP\/IP’s successors precisely to prevent that kind of lock-in from repeating.<\/p>\n

What is the specific engineering gap that makes prompt injection more dangerous in multi-agent systems than in single-agent ones?<\/p>\n

In a single-agent deployment, prompt injection targets one system \u2014 the user’s malicious input must trick that single agent. In a multi-agent system, the attack exploits trust relationships between agents. Agent A receives content from a user, processes it, and forwards a portion of that content to Agent B as a normal part of task delegation. If the user’s content contains an injected instruction, Agent B \u2014 which trusts Agent A as an authorized sender \u2014 executes that instruction without recognizing it as attacker-controlled. The attacker does not need to compromise Agent B directly; the inter-agent communication path carries the injection for them. OWASP ranks prompt injection first among LLM security risks. What agentproto’s Working Group charter would require is not a mechanism to prevent injection (which the Rosenberg-Jennings framework calls “notoriously difficult”) but a protocol-level logging and attribution mechanism that lets security teams reconstruct what happened and which agent in the chain executed the malicious instruction \u2014 the foundation for incident response in a multi-vendor agent deployment.<\/p>\n

Why does post-quantum DNSSEC require choosing between a fast algorithm and a conservative one, rather than just adopting the best post-quantum algorithm outright?<\/p>\n

The tension is between security conservatism and operational performance. The most thoroughly designed post-quantum signature schemes \u2014 the ones cryptographers are most confident will remain secure against both classical and quantum adversaries \u2014 tend to produce large signatures. ML-DSA-44 produces approximately 2,420-byte signatures; SLH-DSA-MTL can be smaller in some configurations but with other tradeoffs. DNS over UDP has a practical limit around 4,096 bytes, so large signatures force TCP fallback. Compact algorithms like Falcon-512 (666-byte signatures) can fit in UDP responses but are based on a different mathematical problem \u2014 NTRU lattices \u2014 that has had less time under public scrutiny than the NIST finalists. The two-track strategy under discussion at DNSOP accepts both, using the compact algorithm for routine lookup performance while retaining a conservative algorithm as a fallback \u2014 so that if the compact algorithm is later found vulnerable, DNS security does not collapse entirely while the migration proceeds.<\/p>\n","protected":false},"excerpt":{"rendered":"The body that produced TLS, DNS, BGP, and QUIC is now four days into its 126th meeting in…\n","protected":false},"author":2,"featured_media":114788,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[58615,405,7537,58618,313,24238,58617,14903,58616],"class_list":["post-114787","post","type-post","status-publish","format-standard","has-post-thumbnail","category-agentic-ai","tag-agentproto-bof-ietf-126","tag-ai-agents","tag-artificial-intelligence-agents","tag-bgp-security","tag-cybersecurity","tag-ietf","tag-internet-standards","tag-model-context-protocol-mcp","tag-post-quantum-dnssec"],"_links":{"self":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts\/114787","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/comments?post=114787"}],"version-history":[{"count":0,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts\/114787\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/media\/114788"}],"wp:attachment":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/media?parent=114787"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/categories?post=114787"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/tags?post=114787"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}