The body that produced TLS, DNS, BGP, and QUIC is now four days into its 126th meeting in Vienna — 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 — 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.

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 — and then be nearly impossible to displace, as happened when the OSI networking stack lost to TCP/IP in the 1980s? Five competing protocols — MCP, A2A, the Agent Communication Protocol, the Agent Network Protocol, and Cisco’s Agntcy Framework — 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.

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

What DMSC Found Wednesday and Why It Feeds Tomorrow

DMSC — Dynamic Multi-Agent Secured Collaboration — 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.

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.

DMSC did not address any single gap in isolation — 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.

Why One RFC Would Outweigh All Five Competing Protocols

The Rosenberg-Jennings Internet-Draft — the framework document that gave the agentproto work its conceptual foundation — 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. That framing matters architecturally: it says AI agent communication occupies the same position that SIP occupies above TCP and UDP for real-time communications — and therefore needs the same kind of open internet standard that SIP eventually became.

Jonathan Rosenberg, who co-authored the framework document as CTO of Five9, also wrote RFC 3261 — 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 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.

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

What MCP and A2A Still Do Not Cover

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 — JSON documents published at well-known URLs — then coordinate tasks using HTTP, Server-Sent Events, and JSON-RPC.

The Rosenberg-Jennings framework 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 — 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.

How Prompt Injection Escalates in Multi-Agent Systems

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 — which trusts Agent A — 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 explains.

The Rosenberg-Jennings framework does not claim a protocol can prevent prompt injection — 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 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 — none involving the inter-domain agent cascades that agentproto targets, but pointing toward the risk profile that multi-agent deployment at scale will create.

Four BoFs Already Concluded: What the Week Produced

PTTH — the Protocol for Transposed Transactions over HTTP — 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.

DAWN — Discovery of Agents, Workloads, and Named Entities — 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.

CURRENT — Continuous Updating and Ratcheting for Rekeying Encrypted Network Transport — 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, 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 — 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.

BGP Security: Why the SIDROPS Draft Matters to Network Operators

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 — currently at revision 07, authored by Job Snijders (BSD), Tobias Fiebig (MPI-INF), and Massimiliano Stucchi (Glevia GmbH) — addresses a subtle but consequential routing stability problem, as described in the draft itself.

When operators annotate BGP routes with RPKI-derived validation states — marking routes as VALID, INVALID, or NotFound using transitive BGP path attributes such as communities — 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.

The draft’s recommendation 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 — 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.

What Post-Quantum DNSSEC Actually Requires from DNS Operators

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

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.

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 — Falcon-512, with 666-byte signatures — can be adopted without protocol modifications and provides post-quantum security for routine lookups. A conservatively designed algorithm — SLH-DSA — 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) 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.

What Can I Do With This Information: A Decision Guide for Thursday’s Session

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

If you operate BGP routing infrastructure, the SIDROPS draft and accompanying IETF route-hijack guidance 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.

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 provide a practical implementation track for operators who need to evaluate tradeoffs before standards finalize.

Rest of the Week: Friday’s Remaining Sessions

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

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.

IETF 127 is scheduled for November 14–20, 2026, in San Francisco at the Hilton Union Square. Whatever Working Groups are chartered this week will hold their first formal sessions there.

Frequently Asked QuestionsHow does a Birds-of-a-Feather session actually become a Working Group, and what is “rough consensus”?

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 — 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 — the binding technical specifications that every implementation must satisfy to claim genuine interoperability.

What happens to MCP and A2A if agentproto does not produce a Working Group charter?

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 — even an architecturally superior one — 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.

What is the specific engineering gap that makes prompt injection more dangerous in multi-agent systems than in single-agent ones?

In a single-agent deployment, prompt injection targets one system — 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 — which trusts Agent A as an authorized sender — 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 — the foundation for incident response in a multi-vendor agent deployment.

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?

The tension is between security conservatism and operational performance. The most thoroughly designed post-quantum signature schemes — the ones cryptographers are most confident will remain secure against both classical and quantum adversaries — 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 — NTRU lattices — 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 — so that if the compact algorithm is later found vulnerable, DNS security does not collapse entirely while the migration proceeds.