Markdown Version | Transcript | Session Recording | Session Materials

DMSC

Summary

The Dynamic Multi-Agent Secured Collaboration (DMSC) session at IETF 126 was held as a non-working-group-forming Birds of a Feather (BoF) session. Co-chaired by Joe Clarke and Laurent Ciavaglia, with Charles Eckel as the responsible Area Director (AD), the session aimed to explore the problem space of "AI agent gateways" mediating cross-domain multi-agent collaboration. The proponents presented use cases, functional requirements, security implications, and a gap analysis of existing IETF standards.

The discussion centered on whether mediating AI collaborations requires new standardized protocols or if the industry can leverage and extend existing work (such as OAuth, WIMSE, RATS, DAWN, and SCITT). While there was strong interest in contributing to this space, the consensus was that the problem statement and requirements are not yet sufficiently defined to begin standardization work.

Key Discussion Points

Part 1: Use Cases, Problem Statement, and Gap Analysis

• 6G Multi-Agent Collaboration: Sean (ZTE) presented 1-1 6G progress on Multi-Agent collaboration, outlining 3GPP’s timelines (SA1, SA2, and CT) and architectural efforts regarding AI agents as automated intelligent entities. The 3GPP study includes technical reports TR 21.906 and TR 23.700-61. Sean highlighted dependencies on IETF protocols for communication between user equipment (UE), core networks, and application layers, emphasizing the need for standard interfaces to reduce protocol translation.
• Agent-Aware Scheduling & LLM Inference: Amber Sung presented 1-2 Agent Aware Scheduling-Why We Need a Gateway, illustrating how multi-agent tasks break traditional stateless per-request forwarding models due to the need for shared state (KV prefix caches). Diverse industry projects (e.g., Mooncake, SGLang, Megatron, LangGraph, OpenTelemetry GenAI) use conflicting definitions of "agent hints," leading to fragmentation. An AI gateway could act as an assembly layer to decouple front-end contracts, back-end states, and cross-cutting policies.
• Enterprise and Telecom Scenarios: Linda Dunbar presented 1-3 DMSC Gateway Scenarios Gap Analysis. She illustrated many-to-many cross-domain challenges using an enterprise banking integration (UnionPay) and a telecom deployment managing physical drone agents. These scenarios require a managed control point for onboarding, trust binding, context-aware auditing, and action-level authorization (e.g., restricting drone operations by time and location).
• Discussion & Chat Feedback:
  • Daniel Gillmor questioned why users would choose a network operator to negotiate on their behalf for AI services. Aijun Wang and Lionel Morand replied that operators help manage communication and network-specific services (connectivity, mobility).
  • Brian Carpenter, recalling the late 1980s, warned that protocol translation gateways often turn into "nightmares" and can degrade performance to the least common denominator.
  • Sam Betts shared details of the LF Agntcy project's SLIM protocol—a decentralized peer-to-peer group messaging system based on Messaging Layer Security (MLS) designed for agents.

Part 2: Required Functions of an AI Agent Gateway

• Gateway Functions: Chen Guang presented 2-1 Required Functions of an AI Agent Gateway. He categorized gateway responsibilities into:
  1. Control Plane (registration, capability directory, and discovery).
  2. Semantic Mediation (semantic routing, agent selection, and context management).
  3. Runtime Data Plane (protocol adaptation, observability, and auditing).
  4. Trust and Security. He noted that Control Plane functions are currently the most viable targets for standardization.
• Security & Trust Requirements: Chao Xiang presented 2-2 Security and Trust Requirements for Gateway-Mediated Collaboration. He identified key security gaps, including agent actions outpacing human oversight, the loss of delegation context across domains, and raw credential exposure within agent runtimes. A security gateway acts as a critical control point to broker credentials, apply rate limiting, validate tasks, and enforce boundaries at the network layer rather than relying purely on application-level checks. Proponents recommended reusing existing frameworks (WIMSE, OAuth, RATS, SCITT) before designing new protocols.

Part 3: Protocol Extensions and Existing Agent Ecosystem

• Trust Model Mapping: Enrique presented 3-1 Protocol Extensions and the Existing Agent Ecosystem, mapping gateway requirements to three boundaries: Session Level (can they talk?), Action Level (can they execute?), and Record Level (what did they do?). Enrique suggested that while existing protocols (OAuth, WIMSE/SPIFFE, SCITT) can be heavily utilized, standard gaps remain at each boundary regarding gateway-specific coordination.
• Alignment with Industry Practices: Aijun Wang presented 3-2 Future DMSC Works when compared with the industry practices. He outlined potential future work for DMSC, focusing on:
  • Agent-to-Gateway interaction protocols (intent-based).
  • Gateway-to-Gateway signaling protocols.
  • Gateway-to-external system protocols. He advocated for a federated, capability-centric routing model where capabilities, rather than endpoints, serve as routing primitives.

Part 4: Open Discussion

• Standardization vs. Product Implementation: Multiple participants (Fleming Andreasen, Peter, Cullen Jennings) questioned whether the gateway features described are product-level implementation requirements rather than protocol standardization requirements. Cullen Jennings noted that successful gateways are typically not standardized directly; instead, they operate on the underlying standardized application protocols.
• Prematurity and Scope: Arnaud Taddei voiced strong concerns that the current proposal is premature and lacks critical considerations regarding safety, resiliency, and the behavioral side-effects of multi-agent interactions. Thomas McCarthy-Howe added that standardizing gateways too early risks violating the end-to-end principle and codifying design decisions that may later be regretted.
• Interoperability and Coordination: Jari Arkko suggested that the discovery and policy elements might be better addressed by expanding the scope of existing efforts, such as the DAWN BoF. George Fletcher emphasized that complex problems in authorization and delegation must be solved first before gateway protocols can be successfully designed.

Decisions and Action Items

No formal protocol or architectural decisions were made during this non-working-group-forming session.

Session Polls

The chairs conducted two polls to gauge the room's sentiment on requirements clarity and participant commitment:

1. Do you believe there is enough clarity on requirements to start standardization work?

   • Yes: 25
   • No: 66
   • No Opinion: 8
   • Total votes: 163

2. Are you willing to actively contribute to that work?

   • Yes: 40
   • No: 32
   • No Opinion: 30
   • Total votes: 162

Next Steps

Based on the polls and floor discussion, the chairs and Area Director Charles Eckel outlined the following steps:

1. Refine the Problem Statement: Proponents must further clarify and narrow the problem space, specifically refining the distinction between enterprise (intranet) and public internet deployment models.
2. Mailing List Discussion: Continued technical discussion and refinement will occur on the DMSC mailing list (dmsc@ietf.org).
3. Coordinate with Existing WGs: pro-actively engage with active and proposed IETF efforts—including DAWN, WIMSE, OAuth, SCITT, and the upcoming Agent-Rx/Agent-Proto work—to see if the identified requirements can be satisfied by existing groups.
4. Future Meetings: Proponents may plan additional side meetings or virtual interim discussions to refine use cases and explore remaining protocol gaps before requesting future BoF sessions.