Dataset20262026-10-05arXiv preprint arXiv:2610.06514 [cs.AI, cs.LG]; dataset and code released via an anonymized repository (anonymous.4open.science) at collection timearXiv:2610.06514datasetbenchmarknetwork-trafficagent-auditingobservabilitysecurityagent-internet
The growing adoption of large language model (LLM) agents creates a need for network administrators and security teams to audit agent behavior within organizational networks without inspecting private user content. Network traffic offers an observable source of evidence, but how much it reveals about agent tasks and operations remains unclear. Existing traffic datasets lack the joint task and stage annotations needed to evaluate this question. We introduce ANT (Agent Network Traffic), a dataset providing agent behavior information at risk, scenario, and behavior primitive granularities alongside network traffic. ANT contains 3,114 execution episodes across 20 tasks and five scenarios, comprising 276,417 bidirectional flows and 40,049 behavior primitive segments organized into 47 macro groups. We establish a benchmark for agent risk identification, scenario recognition, and behavior primitive classification using 13 representative traffic analysis baselines. The results show that existing methods recover useful but uneven behavioral signals. They struggle to identify risk when malicious workflows resemble benign tasks and to distinguish scenarios with similar traffic patterns. Primitive classification is more reliable for frequent macro groups and those with distinctive traffic patterns than for rare or semantically similar groups. ANT provides a common basis for developing more precise auditing and forensic analysis of agent behavior from network traffic. Our data and code are available at https://anonymous.4open.science/r/ant-main-suite-7BC0/.
AI agents have increasingly interacted with external environments by invoking tools, with Model Context Protocol (MCP) emerging as a standard interface for connecting agents to heterogeneous tools and services. As organizations deploy agents at scale, MCP gateways have become a critical middleware layer for aggregating, governing, and shaping the tool surface exposed to agents. Despite the growing importance of MCP gateways in agentic systems, no prior work has systematically studied how gateway design affects agent capability, efficiency, and security. To address this gap, we introduce GatewayBench, the first unified evaluation framework and benchmark for MCP gateways. We characterize gateway architectures into two major paradigms: flattened gateways and hierarchical gateways. GatewayBench comprises 524 tasks across six domains, together with a pool of 11,118 real-world tools from 251 authentic MCP servers. To emulate large-scale deployments, we systematically inject task-irrelevant tools sampled from this pool into each agent environment, enabling controlled evaluation as the accessible tool surface scales. Based on GatewayBench, we conduct extensive experiments across seven widely deployed MCP gateways and diverse agent configurations, covering both benign and adversarial tasks. Our results reveal substantial differences across gateway designs in task completion, tool-use efficiency, and resilience to attacks, and further demonstrate that these effects interact strongly with the underlying model and agent harness. These findings highlight the MCP gateway as a consequential yet underexplored component of the agentic AI stack. By enabling controlled evaluation of gateway architectures under realistic tool ecosystems, GatewayBench provides both practical guidance for MCP gateway design and a rigorous testbed for developing more capable, efficient, and secure agentic systems.
Agent interaction protocols such as ACP and A2A have moved LLM-based agents toward multi-agent collaboration, introducing new security threats. A task sent by a remote peer over A2A is treated as a legitimate request, providing a natural channel for indirect prompt injection. Existing agent security evaluations mostly rely on a single metric, the attack success rate (ASR), and cannot distinguish whether an attack failed because the LLM recognized the malicious content or because a mechanism at the agent layer blocked execution. To address this, we propose A2A-TIBA, an attack principle combining indirect prompt injection with bypass circumvention. Through implant-command-exfiltration steps, it induces the target agent to deploy a callback interaction program, after which the attacker issues commands bypassing the agent. To evaluate defenses finer, we design GDA Measurement, a red-team testbed method using raw context capture via an LLM gateway, dual data preservation, and agent-based autonomous judging. We propose four attack outcomes, Class A/B/C/D, extending ASR into semantic refusal rate, semantic breach rate, interception rate, and penetration rate. Experiments reveal the envelope layer -- the channel through which malicious content enters an agent -- as a new defense dimension. We accordingly propose ELA-ITL, a three-layer isomorphic attack-defense model, dividing defense into envelope packaging, LLM recognition, and agent interception, and attack into implant channel, prompt optimization, and execution mechanism. Testing on 15 agent front-end x LLM back-end combinations and building a 1,000-case dataset verifies the attack effectiveness of A2A-TIBA, the evaluation validity of GDA Measurement, and confirms that adding malicious prompt labels to envelope packaging such as A2A, tool, and memory channels significantly improves LLM recognition of malicious content.
Agents are increasingly interacting with other agents that act for different principals (people or organizations on whose behalf they work), such as a buyer's personal agent negotiating with an enterprise's seller agent. In such agent-to-agent (A2A) scenarios, each agent has its own environment and holds information and authority that the other cannot see. Moreover, the interests of each agent may be aligned (cooperative), partly aligned (mixed-motive), or opposed (competitive). Existing multi-agent system failure studies assume one orchestrator, shared workspace, or single principal. We ask how A2A systems fail when these assumptions are removed. We study more than 2,500 recorded runs of A2A systems built from different agent harnesses and models, spanning 488 scenarios across eight families (legal, CRM, security, commerce, etc.). From these traces, we derive $A^2$-Failures, a taxonomy of 20 A2A failure modes in four categories: (i) discovery and delegation, (ii) grounding and record consistency, (iii) verification, and (iv) conduct and fidelity. Three findings hold across every harness, model, and scenario studied: (1) discovery and interaction are driven by the phrasing of the task rather than the availability of peer agents; (2) no agent verifies a peer's factual claim on its own initiative, so an A2A system inherits the reliability of its least reliable participant unless the protocol or mechanism performs the check; and (3) the aggregate outcome score credits the agent completing the task while staying blind to the coordination, verification, and conduct failures beneath it, so A2A systems must be evaluated per agent, against each agent's own principal. We release the run logs behind the taxonomy at https://huggingface.co/datasets/a2a-salesforce/a2-failures.
Security-relevant Agent2Agent (A2A) executions can cross organizational boundaries, leaving investigators without live access to all participating systems. Offline investigation involves checking preserved records and their cross-record relationships for consistency. This paper presents A2A-ForensicTrace, an offline verification layer that converts runtime observations into typed records, derives protocol-relevant relationships, and commits both under an incident-trace root. An Ed25519-signed receipt binds the root and capture digest to the incident context. Evaluation comprised 240 executions through the official A2A software development kit (SDK), with actions selected by a large language model (LLM). These included 120 condition runs and 120 matched controls. All condition runs returned the expected bounded findings. No control produced an indication, and all roots and receipts verified. Median in-memory latency of the full offline verifier was 1.61 ms for the scenario traces. In the separate scaling experiment, it was 30.85 ms at 1,000 committed leaves. Future work will broaden A2A lifecycle coverage.
Multi-agent hosts turn remote Agent Cards into local agents, tools, workflow targets, and broker routes. A2A defines the card's name as human-readable metadata, not as a stable identity, and specifies no collision semantics. The security failure begins when a host nevertheless uses that remote name as a local routing identifier. We traced registration through dispatch and ran isolated regression tests at seven pinned open-source revisions. Six client-style integrations selected an attacker-controlled peer's client or loopback endpoint for a request addressed to a trusted peer's name. A seventh, brokered implementation collapsed both peers onto one name-derived route; queue and access-control state determine whether the result is interception or denial. The common result is wrong-peer dispatch, not universal privilege inheritance. Synthetic credential and tool tests found no A-specific credential transfer in the tested client bindings and no direct transfer of A-owned tools. The broker path forwards a caller-configuration object; delegated identity or tokens reach B only if present and B can consume the route. Two other paths expose a later, model-mediated decision rather than direct execution authority. The necessary conditions assign different responsibilities to the protocol, implementations, and deployments. Hosts should route by an origin-bound stable identity, keep names presentational, and reject ambiguous aliases. The evidence establishes a recurring implementation vulnerability class, not a universal A2A protocol exploit or a count of vulnerable deployments.
The Agent Status Protocol (ASP) defines a lightweight way for heterogeneous AI agents to report their operational state to a status server, and for observers such as dashboards to receive that state as soon as it changes. Agents push small JSON events over HTTP POST; the server exposes the aggregated state to observers over Server-Sent Events (SSE). Because an agent that has crashed, hung or been compromised cannot be trusted to report its own failure, ASP does not rely on self-reports alone: the server infers liveness from missed heartbeats, can detect agents that are alive but no longer making progress, and accepts observations from supervisors, guardrails, operators and peers, some of which take precedence over what the agent says about itself while others are shown alongside it. ASP models state along independent dimensions (lifecycle, health, task, floor, governance), so that an agent can be, for example, online, degraded, working on a task and waiting for the floor at the same time. It reuses existing vocabularies: task states from the Agent2Agent (A2A) protocol, floor states from the Open Floor Protocol (OFP), and attribute conventions from the OpenTelemetry GenAI semantic conventions. This paper presents version 0.1 of ASP as a proposal, not as an approved standard. It is a working draft intended to open a discussion, and the authors invite comments, alternative proposals and independent implementations from the community.
Tool-using artificial intelligence (AI) agents, systems that autonomously invoke application programming interfaces (APIs), databases, browsers, and inter-agent protocols such as the Model Context Protocol (MCP), are becoming production infrastructure. Yet the security model governing when an agent is authorized to act on a human's behalf remains underdeveloped. Trustworthy human-AI systems require that every consequential agent action be traceable to a human principal, bounded by what that human actually delegated, and contestable after the fact; few documented deployments satisfy all three properties reliably and end to end. Existing literature addresses fragments of this problem in isolation, credential management for non-human identities, classical access control models, prompt injection, and audit trails, while giving little attention to the authorization decision point itself, the moment a tool invocation occurs, and mechanisms that make that decision correct, enforceable, and accountable. This review introduces a principal hierarchy spanning human user, operator/deployer, orchestrator agent, sub-agent, and tool endpoint as an organizing framework, and examines five interdependent layers: agent identity and credential lifecycle; delegation and scope propagation across multi-hop chains; runtime enforcement and just-in-time authorization at policy enforcement points (PEPs); prompt injection as an authorization bypass that breaks the principal hierarchy; and auditability, provenance, and non-repudiation. Drawing on a structured narrative review of 89 primary sources screened from approximately 180 candidates published between 2023 and 2026, we propose seven structural requirements, derive a four-layer reference architecture, apply the requirements to three deployable reference configurations, and identify runtime enforcement and aggregation bounds as the principal unresolved gaps.
Autonomous agents built on Large Language Models (LLMs) need standardized protocols to interoperate across systems. Several now exist (A2A, MCP, ACP, ANP, NLIP), but the Natural Language Interaction Protocol (NLIP) has not appeared in any controlled performance study, and no work has measured where an agent protocol's latency is spent. We compare NLIP and the Agent-to-Agent (A2A) protocol empirically, decomposing latency into message creation, connection, and send phases across three independent hardware environments. For lightweight coordination, NLIP is 8.4-9.6x faster than the baseline A2A SDK implementation on two environments and about 4x on a third; the direction of the advantage is consistent, its magnitude depends on the hardware. The advantage is stage-specific: for the end-to-end pipeline, where LLM inference dominates, the protocols are near parity. The difference comes almost entirely from connection setup. To test A2A at its best, we also ran A2A SDK with connection caching enabled; caching narrows its gap with NLIP by a hardware-dependent amount, from 2.75x on one machine to near-parity on faster hardware, where at scale a cache-optimized A2A-SDK matches NLIP. We report these as measured conditions without a single causal account of the residual send-phase cost. Against the more optimized Python-A2A, NLIP leads by about 4x on the same stage. We close with a protocol-selection guide keyed to workload characteristics.
The prospect of fully autonomous transactional agents did not appear on the horizon until the advent of high capability language models. With such models, the operational benefits of adaptive task orchestration and independent (but constrained) decision making are tantalizing for enterprises and individuals alike. However, each such agent carries with it a serious attack surface in the form of prompt injection which can compromise any soft "guard rails" that may have been placed in context. The consequences of these attacks include credential ex-filtration which, if left unmitigated, renders the whole category of such agents unusable due to breach of trust. Furthermore, expecting a growth of autonomous agents, a security framework for them would require a form of decentralization to scale. Drawing on the proposed OAuth Agent Authorization Profile and the W3C DID and VC standards, we propose a framework based on the principles of capability based security with decentralized agent identity whereby agents access services based on tokens that are cryptographically bound to the agent's and issuer's identities and specify their scope. Services can validate that the delegation chain only involves scope attenuation before acting on any given token. We show that such a layer that lives outside the language model's context window in a secure module can enable agents to act within enforceable security boundaries.
Multi-agent systems (MAS) comprise AI agents that collaborate or compete to perform complex, distributed tasks. Their dynamic interactions create opportunities for threat actors to target and impersonate other agents, intercept messages, inject malicious prompts, and exfiltrate sensitive data while simultaneously complicating the detection of anomalous behavior through conventional monitoring. This paper surveys threats and cryptographic challenges in agent-to-agent communication and presents a zero-trust architecture integrating identity, transport security, message integrity, and monitoring. The architecture establishes agent identities via decentralized identifiers and task-scoped verifiable credentials backed by a permissioned ledger, enforcing least-privilege authorization. For transport security, it provides mutually authenticated, crypto-agile TLS with hybrid post-quantum key establishment, and evaluates KEMTLS with pre-distributed public keys to reduce handshake overhead. Signed CBOR envelopes preserve payload integrity across multi-hop exchanges, while zero-knowledge proofs verify declared task constraints without exposing underlying inputs. Context-aware monitoring of inter-agent messages, tool activity, and execution telemetry informs the setting of risk-based trust thresholds and supports the detection of behavioral anomalies. Together, these mechanisms provide an integrated framework for securing and auditing agent communication, with implications for other agentic protocols and prospective 6G semantic communication.
The rapid proliferation of autonomous AI agents in decentralized ecosystems challenges existing identity paradigms. While human identity is traditionally anchored in biological and/or self-asserted attributes and government credentials, AI agents lack a standardized definition of selfhood, creating critical gaps in trust and accountability. This paper introduces a novel framework for establishing Decentralized AI Identity rooted in Self-sovereign identity (SSI) principles. We propose a formal model that clearly distinguishes human users and AI agents, enabling distinct verification logic for each class while maintaining a unified identity calculus. The central to our contribution is the ABCD Framework, a multi-layered approach to agent identification and verification: (A) Algorithmic Fingerprint, which binds the identity to static model architectures and provenance; (B) Behavioural Fingerprint, which verifies dynamic performance metrics over time; (C) Cryptographic Identity, which anchors the agent via Decentralized Identifiers (DIDs) and (D) Delegation, which cryptographically binds agent actions to respective human accountability. By orthogonalizing these dimensions, we model how systems can enforce granular trust policies ranging from simple authentication to complex liability assignment, thereby solving the black box identity problem in the autonomous economic activities of AI agents.
Paper20262026-10-17arXiv preprint [cs.MA; cs.AI]; accepted at the NANDA Workshop, IEEE TPS-ISA 2026arXiv:2610.24833agent-networkconsensusevaluationmulti-agentcommunication
As AI agents become increasingly connected through networks and take on tasks that require negotiation and joint decision-making, a systematic approach is needed to assess how their views converge and what information supports their decisions. We present an evaluation framework that treats consensus formation as the evolution of publicly stated positions toward a shared region, using accumulated communication history as context. The framework tracks position trajectories, group dispersion, and information expressed in public messages. Two case studies examine staffing decisions based on distributed facts and decisions requiring agents to reconcile duplicate information and a cancelled contract. Results from 1,872 completed runs associate sharing explanations with more accurate group decisions, while the second task reveals persistent disagreement despite accurate aggregate answers. Membership-change experiments provide a complementary evaluation. By separating convergence among agents from progress toward a task's full-information answer, the framework relates decision accuracy and bounded disagreement to the information available during the exchange.
AI agents are increasingly being developed and deployed across organizations using heterogeneous agent-development frameworks, AI models, tool interfaces, protocols, and execution environments. To realize their potential social and business impact, these agents must be able to interoperate through a common communication protocol. The Natural Language Interaction Protocol (NLIP), developed by researchers and practitioners across companies and universities and standardized by Ecma International, addresses this need by defining a standards-based application-layer protocol for AI-agent interaction. NLIP provides a lightweight semantic message envelope that can be carried over existing transports such as HTTP/HTTPS, WebSocket, and AMQP, while allowing NLIP-aware agents and gateways to adapt between clients, agents, local context stores, ontologies, tools, enterprise services, and heterogeneous underlying protocols. This paper presents the motivation and design rationale of NLIP, its message model and transport bindings, security-by-design considerations, reference implementation, representative applications, adoption signals, and relationship to emerging agent protocols such as MCP and A2A.
Benchmarks, audits, and agent protocols describe performance, permissions, and repair, but not how observed evidence should change an agent's authority during a consequential task. We call this the assurance-transition gap. We propose a Runtime Assurance Contract (RAC), a policy-level formal schema binding autonomy boundaries, component eligibility, evidence state, transition policy, human-review capacity, and non-compensatory gates. Under RAC, soft metrics may inform routing, whereas a failed or unknown mandatory gate forces retry, switch, escalation, deferral, or stop; aggregate performance cannot authorize action. We define the contract, an evidence record, a permission rule, and five invariants, and illustrate them in clinical, industrial, and judicial failure probes. We then report a deterministic failure-injection study in agentic coding: 280 constructed cases evaluated by a gate conjunction, a score-only rule, and a restricted protocol baseline. At the published example weights and threshold, the score rule admits 80 of 100 block-required injections and all 40 review-required injections. Tuned in hindsight, it matches the conjunction on this corpus. For positive weights, a positive threshold, binary risk signals, zero-signal controls, and an injected case firing each signal alone, we show that exact agreement holds if and only if the threshold does not exceed the smallest weight. A separate set of 18 hand-authored traces checks version-pinned evidence and review transitions against simpler policy variants. In a further prospective synthetic holdout of 24 episodes, two blinded LLM judges assign identical labels to all 72 action attempts; RAC and a separately implemented full stateful baseline both match these labels. These studies test mechanisms on synthetic cases; they establish neither deployed safety nor cross-domain effectiveness.
In a distributed Internet of Agents (IoA) without centralized routing control, routing tasks to capability-matched executors is challenging because destinations are not predetermined and agents have bounded local service views. Discover-then-forward approaches, by contrast, select an executor before network forwarding and therefore do not directly support reselection when additional candidates become visible downstream. We introduce Semantic Potential Field Routing (SPFR), a distributed IoA routing algorithm that integrates executor discovery and reselection into hop-by-hop forwarding. SPFR represents each executor visible in a local semantic forwarding information base (FIB) as a task-conditioned semantic potential source, with utility setting its strength and hop distance inducing exponential attenuation. At each hop, the forwarding agent recomputes these potentials, reselects the dominant executor, and forwards the task one hop toward it. Under task-consistent frozen-FIB conditions, we prove loop freedom and finite-hop termination and derive an explicit additive error bound under bounded visibility relative to the full-visibility objective. Extensive simulations on real-world topologies show that SPFR approaches the realized utility of distributed utility-greedy routing and request-triggered global discovery while using fewer forwarding hops and substantially fewer request-triggered messages, and remains robust under network and service dynamics.
Large-scale multi-agent ecosystems require mechanisms for discovering suitable agents without exposing entire registries to a large language model (LLM) orchestrator. The challenge is not only to retrieve relevant Agent Cards from a growing registry, but also to maintain a compact candidate context, since each additional candidate increases prompt size, inference cost, latency, and the risk of exceeding the model context window. We formulate this problem as candidate-context scalability and propose the Structural Signal Retriever (SSR), our deterministic and training-free retrieval method designed for Agent Card discovery. SSR derives structural lexical signals from capability-bearing Agent Card fields, weights them using inverse document frequency (IDF), and uses an Inverted Signal Index (ISI) for selective candidate scoring. We evaluate SSR using a synthetic agent benchmark, a public MS MARCO adaptation, and end-to-end LLM orchestration. At 1,000 agents, SSR reduces LLM input by 98.8% and orchestration latency by 70.9% relative to full-catalog orchestration. On MS MARCO, IDF improves retrieval effectiveness within the structural representation, while the ISI preserves retrieval effectiveness and reduces explicitly scored passages by 96.8%. End-to-end experiments show that candidate pre-selection maintains a compact candidate context as registry size grows and avoids the operational failures observed with full-catalog orchestration. These results support SSR as an Agent-Card-native, traceable retrieval mechanism for candidate-context scalability.
The Internet of Agents is expected to enable large numbers of autonomous agents to discover, verify, and collaborate with each other across heterogeneous platforms. However, current agent protocols mainly address tool invocation and inter-agent communication, leaving scalable agent registration, trustworthy identification, and capability-oriented discovery largely unresolved. To address this, this paper proposes a scalable trust discovery architecture for the Internet of Agents. The proposed architecture adopts a hierarchical and distributed design consisting of three layers: Agent Root for trusted registry governance, Agent Registry for agent registration and metadata publication, and Agent Resolver for distributed capability discovery and trust-aware resolution. The architecture further introduces a registry-suffix-anchored composite identity scheme, which binds an agent native identifier to a trusted registry suffix to generate a globally discoverable identity. It also incorporates a dual-certificate and multi-level authentication mechanism to strengthen identity trust among agents. We implement a prototype and evaluate it through large-scale agent registration and resolution experiments. The prototype achieves an average registration latency of 58ms and an average discovery latency of 25ms, and it supports more than 19,000 registration requests per second and more than 29,000 agent discovery requests per second. These results demonstrate the feasibility of the proposed architecture, providing a practical approach toward scalable and identity-trusted agent ecosystems in the Internet of Agents.
An industry report argued publicly on 11 September 2026 that agent identity governance must shift from static identity management to continuous trust management: issuing an identity card is not enough, because the system must keep judging at every action who the agent is, whom it belongs to, what it is authorized to do and whether it is currently trustworthy. The report splits identity into three layers — product identity (what it is), runtime identity (which instance is running) and accountable-principal identity (whom it acts for) — and combines four signal classes covering identity, environment, behaviour and task context to produce a continuously updated trust state that adjusts with risk. The accompanying reporting cites CAICT Tier Terminal Laboratory figures: fewer than 5 percent of applications embedded AI agents in 2025 against an expected 40 percent in 2026; the fastest successful attack on an agent took only 27 seconds and the average 29 minutes, while traditional security teams respond in hours. Industry bodies further forecast that by 2028, 90 percent of B2B procurement will be intermediated by AI agents, moving more than 15 trillion US dollars of B2B spend through agent trading platforms.
A ten-chapter research report (published 2026-09-03) mapping the agent-interconnection standards landscape: the three-layer picture (de-facto standards MCP/A2A/AGENTS.md; international formal standards IETF/NIST/ISO-IEC; China national standards GB/Z 185 series), a part-by-part analysis of GB/Z 185.1-185.7 (five concept domains and 12 functional modules in the overall architecture, the OID nine-layer identity-code structure with unified social credit code compatibility, lifecycle identity management, capability profiles, multi-centre discovery with LAN/factory-network auto-discovery, point-to-point/group/hybrid interaction modes, and a five-entity tool-invocation architecture), the MCP 2026-07-28 stateless turn, A2A v1.0 and AAIF governance, the IETF transition from BoF to working group, NIST and other SDO moves, a standards-maturity coordinate reading, security attack surfaces and gaps, and industry implications. Notably disciplined sourcing: chapter 10 traces every quantifiable claim to verifiable references (SAMA announcement No.22 of 2026, MIIT interpretation, openstd.samr.gov.cn, CAICT report). One claim to re-verify before citing: the report counts 8 national standardization guidance documents in the series while other sources say 7 parts.
China Academy of Information and Communications Technology (CAICT), Institute of Cloud Computing and Big Data
Report20262026-10-08Released by CAICT Institute of Cloud Computing and Big Data in early October 2026; key findings reported by 川观新闻 (2026-10-08) and reproduced by 智慧城市网 (afzhan.com)harness-engineeringagent-controlagent-governanceruntime-guardrailsmaturity-modelCAICT
Verbatim from the release summary carried by 川观新闻 (2026-10-08): "近日，中国信通院云计算与数字化研究所发布《驾驭工程：赋能智能原生软件工程 研究报告（2026年）》……驾驭工程作为面向智能体构建约束与反馈闭环的系统工程方法，成为推动智能原生软件工程走向规模化与可信化的关键支撑。" The report defines 驾驭工程 (Harness Engineering) as "为智能体构建运行环境、约束规则与反馈机制，承载统筹协同、规范治理、效率提升、安全保障四大职能，成为 智能原生时代软件工程的核心管控框架"，and describes three paradigm shifts: "智能体从'被动的代码生成器'转变为'主动的工程参与者'；工程管控重心从'流程节点' 下沉至'运行时行为'；治理逻辑由流程驱动转为约束边界+反馈驱动。" Reported data points: "截至2026年5月，已有67.3%的软件相关企业将AI能力投入生产环节， 31.2%的主体完成智能体与核心研发流程的内嵌部署。其中，企业内AI代码生成、自动化测试等关键环节工具渗透率分别达到54.4%和49.1%。" On industry state: "2026年下半年驾驭工程进入开源基础设施爆发期，OpenAI于8月全面开源CodexHarness，DeepSeek同期发布开源Harness框架。" The report proposes "六大设计原则、六类核心技术能力与L1-L5成熟度模型" (per 智慧城市网's reproduction of the release) and forecasts a three-stage evolution: "2026—2027年为概念验证与标准形成期……2027—2028年为平台化与规模化期……2028年以后为基础设施化期，驾驭工程将成为智能原生开发的默认支撑。" It recommends "加快制定跨平台能力描述规范与互操作标准，推动开源生态建设与复合型人才培养". Note: the underlying report PDF was announced by CAICT but no first-party download page was located at collection time; all wording quoted above is from the cited coverage of the CAICT release.
Report20262026-10-15Gartner Research (document 8510777)agent-gatewaymulti-agentpolicy-enforcementagent-governanceanalyst-reportGartner
As multiagent adoption grows, AI gateways must enforce policy across models, tools, and interagent paths. Long-term enterprise value will be driven by interagent governance and securing strategic workflow budgets beyond basic routing.
Report20262026-09-30Gartner press release, Stamford, 2026-09-30; underlying research The Cybersecurity Executive Outlook, 4Q26Gartneragent-governanceagent-accessguardian-agentsagent-identitypost-quantum
Gartner press release of 30 September 2026 identifying five actions CISOs should take by the end of 2026, with two directly relevant to agent identity and access control. Verbatim: "Fifty-four percent of organizations have no defined approach to limit AI agent access, or rely on predefined human access, according to a Gartner survey in 297 cybersecurity leaders in the second quarter of 2026." Verbatim recommendation: "CISOs should govern autonomous multiagent systems based on action privileges rather than model intelligence and safeguard agentic workflows using guardian agents to constrain blast radiuses." The other four actions, also quoted: "Cement Role and Authority in AI Safety" (securing AI infrastructure and understanding the interaction between models and harnesses is more important than the safety of the model itself); "Replace Recognition as Proof of Identity" (discard recognition as an acceptable basis for decision or action authorization, augmenting deepfake detection with contextual signals, additional authentication layers and content-provenance checks); "Budget for Preemptive Cybersecurity Capabilities" (76% of CISOs ranked AI-driven discovery of cyber vulnerabilities among their top 10 emerging risks in a survey of over 300 enterprise risk leaders in Q2 2026); and "Begin Piloting Postquantum Cryptographic Migration" (organizations that do not begin piloting PQC by 2027 will face at least 200% higher full-migration costs; 51% of surveyed CISOs had not begun any PQC-related activity).
Report20262026-10-16Released at the 10th Future Network Development Conference (Nanjing), 2026-10-16, together with a PATN prototype system; the white paper full text is distributed via the "中国联通研究院" WeChat account (reply "PATN")carrierChina-Unicomagent-interconnectionidentitysignallingaddressingwhite-paperChina
Verbatim from the official release text (中国联通研究院, 2026-10-16; republished verbatim by C114): “10月16日，在南京举行的第十届未来网络发展大会成果发布区，中国联通研究院发布《公共智能体电信网（PATN）技术白皮书》暨原型系统。白皮书提出，互联网从‘连接信息’迈向‘连接智能’，智能体正在成为新型网络交互主体；面对智能体互联的三重挑战，智能体互联网缺少的不是互联协议，而是面向公共、电信级、可监管的连接基础设施。” “中国联通立足电信网络的百年沉淀，参考公共交换电话网（PSTN）与IP多媒体子系统（IMS）的演进逻辑，提出公共智能体电信网（PATN，Public Agent Telecommunication Network），融入统一身份标识、基于身份的路由寻址、第三方监管溯源三根支柱，以‘统一身份、信令建连、应答主权、互联互通’回应三重挑战。” On identity: “PATN构建平台无关的电信级身份，由运营商作为中立第三方提供权威鉴权，通过标识映射兼容电话码号、DID等既有方案。” On addressing: “把寻址对象由IP换成身份标识，智能体即便位于内网也能被准确找到，实现位置无关。” On accountability: “把每一次连接登记为可审计的会话记录，连接建立与否由对方显式应答。” On the prototype: “中国联通研究院已完成PATN原型系统研制，并开展了全球首例端到端智能体间互通（First Call）的测试验证。验证覆盖注册发现、发起连接、对方审批、语义交互、数据通道全流程，两端智能体位于不同网络域，全程均未向公网暴露服务，也无需手工配置公网地址或端口。” Scope limitation stated in the release: PATN “是中国联通在CubeMAP智能体互联网协议框架下聚焦网络侧增强的创新实践，目前尚处于架构设想和原型验证阶段”，其产业化仍需在标准、生态与商业模式上探索，跨运营商、跨生态互通尚未打通。 Note on sourcing: only the release text is public; the white paper PDF itself is not openly downloadable at collection time.
Standard20262026-08-293GPP SA6 Study Item (SID under preparation, work plan Aug-Nov 2026)3GPP · SA63GPP6Gapplication-enablementagent标准
SA6 study analysing 6G use cases (per SA1 TR 22.870, including third-party AI agent collaboration) to derive application-enabler level requirements and shape 6G application enablement aligned with the IMT-2030 vision and industry initiatives (GSMA Open Gateway, ETSI OpenCAPIF). Work plan: SA6#68 (Aug 25-29) proposals, moderated discussions Sep/Oct, SA6#70 (Nov 17-21), then SID submission to SA plenary. Output TR 23.xxx will form the basis for normative 6G application enablement work. SID draft: S6-255552 (3GPP FTP; accessible via browser, scripted download returns 403).
Standard20262026-03-013GPP Technical Report (approved at TSG SA#111, March 2026)3GPP · SA13GPP6Gagent需求标准
Stage-1 6G study approved in March 2026 with 200+ use cases, explicitly including "6G AI agent collaboration with third-party AI" as a use case family and requirements such as exposing services to authorised third-party AI agents. TR 22.870 frames AI agents as automated intelligent entities capable of intent understanding, contextual reasoning, self-learning and collaborative decision-making within the 6G system. Anchor reference for Release 21 normative work together with TR 38.914.
北京邮电大学（Beijing University of Posts and Telecommunications）
Standard20262026-08-25Open-source protocol family (Mulan PSL), the open-source implementation supporting the national standard GB/Z 185 "Artificial Intelligence — Agent Interconnection" (AIP)GB/Z智能体互联AIPGB/Z 185ACPs开源协议身份码AICmTLSEd25519重点
China first open-source agent interconnection protocol family aligned with the national standard series Artificial Intelligence — Agent Interconnection (GB/Z 185 / AIP), developed by Beijing University of Posts and Telecommunications and adopted by the China Electronics Standardization Institute as the basis of the AIP national-standard open-source community. Licensed under the Mulan PSL, so enterprises may build commercial versions free of charge. The family is organized into four modules: identity and trust, capability catalogue, task flow, and runtime observability, with a "layered multi-centre" architecture in which each autonomous domain runs its own registry, credential-management and discovery servers, and domains interoperate through inter-domain management nodes, yielding macro-level decentralization while preserving each party autonomy. Security rests on AIC (an OID-based agent identity code), mTLS for mutual certificate verification, and Ed25519 signatures. The v2.2.0 release (August 2026) adds the AMP monitoring protocol (six log classes; a monitor-server consuming Kafka audit topics with signature verification and chained hashing), the AAC access-control specification unifying subject expressions across humans, agents and service accounts, OIDC-based user-to-agent identity binding with delegation chains, strengthened senderId/AIC consistency checks in streaming and notification modes, Ed25519 as the default algorithm, an aliveMap liveness view in discovery, and Ansible-based image/host deployment with independent day-2 operations playbooks. Design philosophy is functional abstraction rather than entity binding, letting vendors choose centralized, layered or distributed implementations.
China Academy of Information and Communications Technology (CAICT)
Standard20262026-10-09Announced 2026-10-09 by CAICT through its official account (中国信通院CAICT); trial operation anchored on agent trusted interconnection centres in Beijing and Xiamen, following the Beijing centre launch on 2026-09-18; access portal agent.idfactory.cnagent-identityagent-namingidentifierDIDverifiable-credentialA2AANPinfrastructureCAICT
Verbatim from the CAICT release "中国信通院智能体标识与身份网络面向社会开放接入" (published 2026-10-09, 中国信通院CAICT official account; full text as carried by 同花顺): "近日，中国信息通信研究院（简称'中国信通院'） 智能体标识与身份网络正式启动试运行，并面向社会开放接入。作为面向多智能体协同的新一代互联网基础设施， 智能体标识与身份网络依托北京、厦门等地智能体可信互联中心，为各类智能体提供标识注册、身份核验、寻址解析、 能力发现和协同验证等服务，帮助不同平台、不同主体的智能体实现可信接入和跨域协同。" On the technical route the release states that the network "是面向智能体原生设计的标识与身份基础设施，遵循需求牵引、开放兼容、对等互认、 互联互通原则，坚持AI原生设计，采用'区块链+DID+超级智能体'的技术路线，兼容符合W3C规范的多种DID方法， 适配A2A、ANP等主流互联协议，使不同技术路线、不同厂商和存量平台的智能体能够低成本接入". Three open-access services are listed — "注册发现服务"（identity and capability registration, issuance/update/status management, unified discovery of agents, Skills and resources）, "解析核验服务"（fusion resolution of multiple DID methods, signing/verification SDK and API, resolving an agent identifier to its service endpoint and verifying credentials and signature status） and "资源对接服务"（authorised access to regional/industry data, enterprise knowledge, industry Skills, MCP services, business systems and compute resources）. Four access targets are defined: agent applications and platforms, data and service resource providers, industry scenario co-builders, and DID/technology ecosystem partners. The registration flow runs from online registration, to requirement confirmation, to technical onboarding (generate a DID, submit registration to a trusted interconnection centre, complete verification and be issued a Verifiable-Credential-based agent identity, then configure it in the agent). Policy basis cited in the release: "2026年7月，工业和信息化部等四部门联合印发《关于推动互联网基础资源高质量发展的指导意见》，明确要求 '开展人工智能、区块链、分布式标识等技术与互联网基础资源融合创新技术攻关''探索构建具备统一通信协议、数据交互 标准和接口规范的智能体互联网络基础设施''加强智能体等联网场景下的网络标识资源规划与科学供给'。"
China Academy of Information and Communications Technology, CCSA TC1WG5
Standard20262026-09-09Telecommunications industry standard, approved at CCSA TC1WG5 43rd meetingCCSA · TC1/WG5 →CCSAindustry-standardoperational-safetyagent-servicesobservabilityresilience
A telecommunications industry standard approved in September 2026 at the 43rd working group meeting of CCSA TC1WG5 and led by CAICT. It targets the production and operation of intelligent information services and applies to intelligent-computing infrastructure, AI platforms, model services, agent services, and supporting systems such as knowledge bases and tool services; it can be used both for capability building and assessment by providers and as a reference for procurement, project acceptance and supplier management. Requirements are organized around operational safety governance, monitoring and observability, capacity and performance assurance, stability protection, change and configuration management, fault and emergency assurance, disaster recovery and business continuity, external dependency and supply chain assurance, and service quality and continuous improvement, with three capability levels (basic, enhanced, advanced). The motivation is the long and tightly coupled service chain from computing resources through model inference and knowledge retrieval to agent orchestration and tool invocation, which is prone to timeouts, performance swings, task failures and cascading faults while monitoring metrics and stability guarantees remain inconsistent across the industry. CAICT scheduled the first workshop for 17 September 2026.
Standard20262026-09-29Released at the Smart Agent Identity and Security Forum of the 7th China Internet Infrastructure Resources Conference; CNNIC official announcement 2026-09-30agent-namingidentifiernaming-spaceagent-identityservice-discoveryCNNICATI
Verbatim from the CNNIC official announcement (2026-09-30): "9月29日，在第七届中国互联网基础资源大会智能体标识与安全论坛上，中国互联网络信息中心正式发布智能体域名系统2.0。" The announcement states the system "采用高扩展性架构设计，打造以域名为枢纽的多标识融合体系，具备全网通用标识、服务发现、安全认证等核心能力", and that it "新增语义标签中文域名服务，提供智能体域名注册API接口，支持智能体检索、发现服务，并围绕地域、行业、企业规模等维度构建智能体观测视图", supporting the construction of the agent trusted infrastructure (ATI) and providing trusted identity authentication for agents. CNNIC states next steps will be supported by the National Engineering Laboratory for Internet Domain Name Management Technology and the Beijing Key Laboratory of Agent Identity and Security Assurance Technology, to support cross-domain service discovery, trusted authentication and secure collaboration. Related coverage of the same conference (Yingguang/CNR, 2026-10-04) reports that CNNIC released the system together with Wantlian Yida, and that nine broker-agent systems of manufacturing enterprises became the first enterprise agents to receive "智域.中国" agent domain-name identities after passing a guideline assessment, described as the first industrial-level application of an agent naming space for global addressability.
Cyber Security Association of China, Ant Group, et al.
Standard20262026-09-09Group standard launched at 2026 Inclusion Bund SummitCSAgroup-standardagent-identityauthorizationdynamic-access-controlidentity-chain
A group standard formally launched on 9 September 2026 at the "Safety Coordinates and Responsibility Boundaries in the Agent Era" forum of the 2026 Inclusion Bund Summit, proposed by the Cyber Security Association of China and drafted by Ant Group together with research institutes, carriers and Internet companies. It addresses the questions of who the agent is, whom it represents and what it may do. The framework builds a multi-layer trusted identity chain among agent, user and runtime environment, issues each agent a unique, trustworthy and continuously verifiable digital identity, and introduces task-intent-based dynamic access control: following least privilege, permissions activate with the task and are reclaimed promptly when the task ends, reducing over-authorization and privilege abuse. It pairs with the "Technical Requirements for Agent Runtime Security" launched the same day.
Cyber Security Association of China, Ant Group, et al.
Standard20262026-09-09Group standard launched at 2026 Inclusion Bund SummitCSAgroup-standardruntime-securityintent-deviationauditagent-gateway
A group standard formally launched on 9 September 2026, proposed by the Cyber Security Association of China and drafted by Ant Group with research institutes, carriers and Internet companies. It focuses on what an agent actually did during execution, whether it deviated from the task, and how risk is remediated in time. Requirements span risk monitoring and control, risk detection and decision, central analysis, and performance and stability, running through the whole chain of user intent, agent planning, tool invocation, system execution and result delivery. Through layered detection and defence in depth, a single unauthorized call, an abnormal chain or a single intent deviation can each be identified, assessed and handled. It forms the runtime half of the "authenticate identity, read intent, guard runtime" baseline, complementing the identity and authorization framework launched the same day, and corresponds directly to the runtime governance duties of an agent gateway.
CAAM proposes a contextual authorization mesh for agents: authorization decisions are bound to invocation context rather than long-lived static tokens, limiting over-broad delegation in agentic systems.
Individual draft enumerating architectural requirements for supporting AI agents on the Internet: how agents are addressed, identified, discovered and how their capabilities are described within existing Internet architecture.
This document describes an infrastructure-assisted approach to AI-agent discovery. An orchestration, placement, or hosting system can publish current deployment and reachability information for available AI-agent services or instances. Separately, network infrastructure can derive an abstract Attachment Scope representing the network context applicable to a requester. A discovery mechanism combines requester intent, currently published AI-agent resources, and the requester's Attachment Scope to identify applicable agent instances. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt xxx, et al. Expires April 16, 2027 [Page 1] Internet-Draft Infrastructure Assisted Discovery The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 13, 2026 . Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction..............................................3 2. Conventions used in this document.........................5 3. Problem Statement.........................................6 4. Gap Analysis: DNS-SD and AI-Agent Discovery...............9 4.1. Service Type Limitations.............................9 4.2. External Deployment State...........................10 4.3. Discovery Domain vs. Network Scope..................11 4.4. Hidden Network Context..............................12 4.5. Discovery vs. Selection.............................12 5. Infrastructure-Assisted Discovery Model..................13 5.1. Requester Criteria..................................14 5.2. Published Resource State............................14 5.3. Requester Scope.....................................15 5.4. Discovery Processing................................16 5.5. Metadata and Deployment State.......................17 5.6. Applicability Versus Selection......................17 5.7. Relationship to Specific Discovery Mechanisms.......17 6. Resource Publication and Update..........................18 6.1. Logical Service vs. Instance Publication............18 6.2. Cloud Deployment Example............................19 Dunbar, et al. Expires Dec 16, 2027 [Page 2] Internet-Draft Infrastructure Assisted Discovery 6.3. 5G Edge Deployment Example..........................20 6.4. Publication Lifecycle...............................20 7. Attachment Scope Determination and Update................21 7.1. Policy-Based Mapping................................21 7.2. Requester Attachment Scope..........................22 7.3. Scope Policy........................................22 7.4. Mobility and Reassociation..........................23 8. Applying the Model to DNS-SD.............................23 8.1. DNS-SD Mapping......................................24 8.2. DNS-SD Publication..................................25 8.3. Applying Attachment Scope...........................26 8.3.1. Scope to Domain Mapping........................26 8.3.2. Filtering Resources After Enumeration..........27 8.4. Agent Metadata in DNS-SD............................28 8.5. Discovery Result....................................29 8.6. Caching and Freshness...............................30 8.7. No Match............................................31 9. Applying the Model to DNS-AID............................32 9.1. DNS-AID Mapping.....................................33 9.2. Applying Attachment Scope to DNS-AID................33 9.3. Relationship to DNS-AID Results.....................34 10. Second-Stage Agent Metadata Retrieval...................35 11. Relationship to Resource Selection......................35 12. Alternative methods.....................................36 13. Security Considerations.................................37 14. IANA Considerations.....................................37 15. References..............................................38 15.1. Normative References...............................38 15.2. Informative References.............................38 16. Acknowledgments.........................................39 Appendix A:.................................................39 1. Introduction AI-agent discovery is being explored in several DAWN documents. The DAWN use-case work describes scenarios in which clients need to discover AI resources and obtain information required for subsequent interaction. Other DAWN contributions examine gaps in existing discovery protocols, identify information that may need to be discoverable, describe local discovery using mDNS/DNS-SD, and propose broader discovery architectures and frameworks. This document complements those efforts by focusing on managed enterprise, cloud, edge-computing, and communication- Dunbar, et al. Expires Dec 16, 2027 [Page 3] Internet-Draft Infrastructure Assisted Discovery network deployments in which infrastructure already maintains information that can assist AI-agent discovery. In such environments, orchestration, placement, hosting, gateway, or management systems can provide current information about which AI-agent services or instances are available and how they can be reached. Separately, network infrastructure can provide an abstract "Attachment Scope" representing the requester's current network applicability context. This document defines two infrastructure integration points: o a "Resource Publication Hook", through which authorized deployment infrastructure makes current AI-agent service or instance information available to the discovery mechanism; and o an "Attachment Context Hook", through which trusted network infrastructure provides the requester's current Attachment Scope. The discovery mechanism combines these infrastructure- provided inputs with requester-supplied discovery criteria and relevant agent metadata to identify AI-agent resources applicable to the request. The proposed hooks are intended to assist existing discovery mechanisms rather than replace them. For example, the local discovery approach described in [DAWN-MDNS] reuses mDNS and DNS-SD for AI-agent discovery. The infrastructure-assisted model described here follows the same principle of reusing existing discovery mechanisms, while adding support for managed deployments in which agent deployment state and requester network context are maintained by infrastructure. The model can similarly complement DNS-AID [DNS-AID] in managed environments by using infrastructure-maintained deployment state and network-derived Attachment Scope without changing the DNS-AID wire format. More generally, the Resource Publication Hook and Attachment Context Hook can provide infrastructure-facing inputs to broader DAWN discovery architectures, such as those described in [DAWN-FRAMEWORK], without requiring those architectures to depend on a particular access, cloud, or mobile-network technology. Dunbar, et al. Expires Dec 16, 2027 [Page 4] Internet-Draft Infrastructure Assisted Discovery The infrastructure assistance described in this document uses authorized control-plane or management information. It does not require infrastructure to inspect, intercept, or participate in agent-to-agent communications. This document does not define a new wire protocol. The model can be applied to DNS-SD, DNS-AID, registries, directories, federated discovery systems, or other AI-agent discovery mechanisms. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following acronyms and terms are used in this document: AI Agent: A software entity that uses artificial intelligence techniques to interpret context, make decisions, and take actions toward achieving one or more goals, possibly by interacting with users and by invoking other agents, tools, or services. Attachment Context Hook: An infrastructure integration point through which trusted network infrastructure provides the requester's current Attachment Scope to the discovery mechanism. Attachment Scope: An abstract network-derived context representing an attachment or reachability domain applicable to a requester or discoverable resource. Discovery Mechanism: A mechanism that receives discovery intent and returns one or more applicable AI- agent resources. The mechanism may use DNS-SD, Dunbar, et al. Expires Dec 16, 2027 [Page 5] Internet-Draft Infrastructure Assisted Discovery DNS-AID, a registry, a directory, a federated discovery system, or another technique. Logical AI-Agent Service: An AI-agent service whose functional identity can remain stable while the number, location, or endpoints of its runtime instances change. Requester: An entity initiating an AI-agent discovery operation. The requester may itself be an AI agent or another application acting on behalf of one. Resource Publication Hook: An infrastructure integration point through which an authorized orchestration, placement, hosting, gateway, or management system makes current AI-agent service or instance information available to the discovery mechanism. 3. Problem Statement AI agents are increasingly deployed as software services in enterprise networks, cloud environments, edge-computing platforms, and communication networks. An AI agent may provide functions such as reasoning, information retrieval, translation, content generation, task execution, or interaction with external tools and services. Although AI agents may use conventional cloud-native deployment techniques, their interaction model can be more heterogeneous than that of many traditional software services. A conventional service is often accessed through a known API or interface contract once its endpoint is located. Different AI agents, however, may support different communication protocols, invocation methods, request or response schemas, authentication procedures, supported modalities, tools, task formats, or agent-specific parameters. A2A provides one example. An A2A Agent Card can describe an agent's identity, supported interfaces, capabilities, skills, security information, and other properties required for interaction. Therefore, locating an AI-agent endpoint and Dunbar, et al. Expires Dec 16, 2027 [Page 6] Internet-Draft Infrastructure Assisted Discovery understanding how to interact with that agent can be separate operations. This creates an opportunity to use a lightweight discovery stage to identify an applicable AI-agent service or instance and then retrieve richer agent metadata through a subsequent agent-specific mechanism. In managed deployments, information relevant to the lightweight discovery stage may be distributed among several infrastructure systems. For example, an orchestration, placement, or hosting system may know: - which AI-agent services or instances currently exist; - where an instance is deployed; - which externally reachable endpoint corresponds to that instance; - whether multiple instances share a common service endpoint; - when an instance is moved or replaced; and - when an instance is withdrawn. The AI-agent application itself need not maintain complete knowledge of this deployment state, particularly when it operates behind a load balancer, service mesh, reverse proxy, gateway, or other hosting infrastructure. Network infrastructure may separately possess information useful for determining which AI-agent resources are applicable to a requester. Such information can include: - access-network attachment; - enterprise or tenant context; - VPN or routing context; - DNN; - network slice; Dunbar, et al. Expires Dec 16, 2027 [Page 7] Internet-Draft Infrastructure Assisted Discovery - serving UPF or UPF group; - edge-computing domain; or - another reachability-related network context. Requiring the requester to understand and explicitly include such network information can couple application-layer discovery to network-specific technologies. Conversely, exposing detailed network topology or low-level identifiers directly through an AI-agent discovery mechanism can create unnecessary complexity and information exposure. Deployment information and rich agent metadata may also change at different rates. For example, an image-analysis agent may move from one edge location to another while retaining the same skills, interfaces, authentication model, and Agent Card. Changes to deployment location or endpoint do not necessarily require changes to the agent's functional metadata, such as its capabilities, skills, supported interfaces, or Agent Card. There is therefore value in separating: - information describing what an AI agent is and how it can be used; - information describing where currently deployed instances can be reached; and - information describing the requester's current attachment or reachability context. There is therefore a need to combine requester-provided discovery criteria and relevant agent metadata with current deployment information and network-derived Attachment Scope, without requiring the requester to understand network specific attachment details. The infrastructure-assisted discovery model described in this document addresses this problem by allowing deployment and network infrastructure to contribute this information to the discovery process. Dunbar, et al. Expires Dec 16, 2027 [Page 8] Internet-Draft Infrastructure Assisted Discovery 4. Gap Analysis: DNS-SD and AI-Agent Discovery DNS-Based Service Discovery [RFC6763] provides a well- established mechanism for discovering instances of a particular service type within a discovery domain. A client identifies a service type and domain and obtains service instances. SRV records identify where an instance can be reached, while TXT records may provide a small amount of additional service-specific information. This model provides a useful foundation for AI-agent discovery. draft-jakab-dawn-agent-discovery-mdns applies this approach to local AI-agent discovery and describes a two-stage model in which DNS-SD performs lightweight enumeration and the agent's native protocol subsequently provides the complete agent description. The model described in this document is compatible with that two-stage approach. However, DNS-SD by itself does not address several deployment conditions relevant to managed AI- agent environments. 4.1. Service Type Limitations For many conventional services, knowing the service type, host, port, and protocol can be sufficient to initiate application-level communication. AI-agent interaction may require additional information before meaningful interaction can begin. For example, an A2A requester may need to obtain an Agent Card describing: o supported interfaces; o skills; o capabilities; o security requirements; o interaction characteristics; and o other agent-specific information. Dunbar, et al. Expires Dec 16, 2027 [Page 9] Internet-Draft Infrastructure Assisted Discovery Trying to represent all such information in DNS-SD TXT records would duplicate metadata that is already available through the agent's native description mechanism and could make the discovery layer unnecessarily complex. A more practical approach in some deployments is to use lightweight discovery to identify an applicable agent instance or endpoint, and then retrieve richer agent-native metadata only when needed before interaction: Lightweight discovery | v Agent instance / endpoint | v Retrieve agent-native metadata | v Interaction 4.2. External Deployment State Traditional DNS-SD commonly assumes that a service or the system hosting it registers the appropriate service-discovery information. Managed AI-agent environments may involve additional deployment abstraction. For example, an orchestration system can create several runtime instances of the same logical A2A service: Vision Agent Service | +-----------+-----------+ | | | v v v Instance-A Instance-B Instance-C The instances may share the same Agent Card and capabilities while having different endpoints or attachment contexts. Alternatively, the three instances may sit behind one stable service endpoint: Dunbar, et al. Expires Dec 16, 2027 [Page 10] Internet-Draft Infrastructure Assisted Discovery Vision Agent Service | Common Endpoint | +--------+--------+ | | | A B C In this case, changes to the backend instances need not change agent metadata or the externally published discovery endpoint. A discovery architecture therefore benefits from distinguishing the logical AI-agent service from currently deployed instances. 4.3. Discovery Domain vs. Network Scope DNS-SD uses a discovery domain to determine where service enumeration occurs. In a managed communication network, however, the set of agent instances applicable to a requester may depend on a network context that is different from a DNS administrative domain. For example, two requesters using the same DNS namespace may be associated with: o different enterprise VPNs; o different DNNs; o different network slices; o different UPFs; o different edge domains; or o different tenant contexts. Those requesters may therefore have access to different edge- resident AI-agent instances even though they query the same general service category. Conversely, several underlying network states may belong to the same discovery applicability domain. For example: Dunbar, et al. Expires Dec 16, 2027 [Page 11] Internet-Draft Infrastructure Assisted Discovery UPF-A + DNN-X + Slice-1 ----+ | UPF-B + DNN-X + Slice-1 ----+--> Attachment Scope X | VPN-X + Enterprise-A -------+ DNS-SD does not itself define such a mapping between requester-side network state and discovery applicability. 4.4. Hidden Network Context A requester can reasonably know what type of AI-agent service it seeks. For example: Service-Category: Vision-Inference It should not necessarily need to know: Serving-UPF DNN S-NSSAI VRF BNG Access Circuit Edge Domain Those properties belong to the infrastructure. Requiring an AI-agent application to understand them creates unnecessary coupling between application discovery and network architecture. 4.5. Discovery vs. Selection Existing service-discovery and service-routing systems often use region, zone, or locality information to steer a request toward a preferred instance. The Attachment Scope described in this document serves a different initial purpose. It identifies the network context within which an AI-agent resource is applicable to a requester. Dunbar, et al. Expires Dec 16, 2027 [Page 12] Internet-Draft Infrastructure Assisted Discovery For example: Requester Intent: Vision-Inference Attachment Scope: AScope-A Published Instances: Agent-A -> AScope-A Agent-B -> AScope-B Agent-C -> Shared-Cloud The discovery mechanism may determine that Agent-A and Agent- C are applicable. A later selection mechanism can choose between them based on latency, load, cost, GPU availability, or another dynamic factor. Thus: Discovery: Which resources are applicable? Selection: Which applicable resource should be used? The two functions are intentionally separated. 5. Infrastructure-Assisted Discovery Model The infrastructure-assisted discovery model combines information from the requester, deployment infrastructure, network infrastructure, and the discovery mechanism. The purpose of the model is to allow infrastructure that already maintains deployment and network state to contribute that information to AI-agent discovery, without requiring the requesting AI agent to understand the underlying deployment or network-specific details. The model uses three primary categories of information: Requester Discovery Criteria Dunbar, et al. Expires Dec 16, 2027 [Page 13] Internet-Draft Infrastructure Assisted Discovery + Published AI-Agent Resource State + Requester Attachment Scope | v Discovery Mechanism | v Applicable AI-Agent Resources 5.1. Requester Criteria The requester provides information describing what it wants to discover. The request may identify: - a specific AI-agent resource; - an AI-agent service category; - a subtype; - a supported interaction protocol; - a capability or skill; - or other agent-related discovery criteria supported by the discovery mechanism. The requester is not required to provide network-specific information such as a serving UPF, DNN, network slice, VPN, access point, or edge domain. 5.2. Published Resource State Deployment infrastructure provides information describing the AI-agent resources currently available for discovery. This information can include: o logical service identifier; o instance identifier; o reachable endpoint; o communication protocol; o current deployment state; o Attachment Scope associated with the resource, when applicable; and o a reference to additional agent metadata. Dunbar, et al. Expires Dec 16, 2027 [Page 14] Internet-Draft Infrastructure Assisted Discovery The Resource Publication Hook described in Section 6 provides this information to the discovery mechanism. The published resource may represent either: o a logical AI-agent service exposed through a stable endpoint; or o an individually reachable runtime instance. The choice depends on how the AI-agent service is deployed and exposed. Deployment infrastructure is responsible for keeping this information consistent with the actual deployment state. 5.3. Requester Scope Trusted network infrastructure determines the requester's current Attachment Scope from network attachment or reachability state. The Attachment Scope abstracts network-specific information such as: o access attachment; o VPN or routing context; o DNN; o network slice; o serving UPF; o tenant context; or o edge domain. The Attachment Context Hook described in Section 7 provides the resulting Attachment Scope to the discovery mechanism. Dunbar, et al. Expires Dec 16, 2027 [Page 15] Internet-Draft Infrastructure Assisted Discovery The Attachment Scope is infrastructure-provided context. It is not required to be supplied by the requester and does not need to be exposed to the requester. 5.4. Discovery Processing The discovery mechanism combines requester discovery criteria with current published resource state and the requester's Attachment Scope. The mechanism can also use agent metadata that it maintains, indexes, or references. Conceptually: Agent Metadata | v Requester Intent --> Candidate Identification | v Candidate Resources | +------------------+ | | v | Attachment Scope | | | +--------+---------+ | v Applicability Processing | v Applicable Resources Agent-related criteria determine which resources can satisfy the requester's functional intent. Attachment Scope determines which of those candidate resources are applicable from the requester's current network context. These two functions are complementary. Dunbar, et al. Expires Dec 16, 2027 [Page 16] Internet-Draft Infrastructure Assisted Discovery 5.5. Metadata and Deployment State Agent metadata and deployment state describe different properties and can change independently. For example, an A2A Agent Card can describe an agent's capabilities, skills, supported interfaces, and security requirements. The same logical agent service can be deployed at several locations or moved between locations without changing those properties. Conversely, deployment infrastructure can update an endpoint, instance identifier, or associated Attachment Scope without requiring the underlying functional description of the agent to change. The discovery mechanism may maintain or reference both kinds of information, but they need not be represented or updated in the same way. 5.6. Applicability Versus Selection The result of infrastructure-assisted discovery is a set of AI-agent resources that are applicable to the requester. The discovery mechanism does not necessarily select the optimal resource from that set. For example, discovery may determine that two AI-agent instances are both applicable: Agent-A Agent-B A subsequent selection function can choose between them based on factors such as latency, network condition, compute load, accelerator availability, cost, or application policy. The distinction between discovery applicability and resource selection is described further in Section 11. 5.7. Relationship to Specific Discovery Mechanisms The infrastructure-assisted model is independent of a particular discovery protocol. Dunbar, et al. Expires Dec 16, 2027 [Page 17] Internet-Draft Infrastructure Assisted Discovery The Resource Publication Hook and Attachment Context Hook provide inputs to the discovery process, while the underlying discovery mechanism can use DNS-SD, DNS-AID, a registry, a directory, a federated discovery system, or another mechanism. Section 8 and 9 describe how the model can be realized using DNS-SD and DNS-AID respectively. The model does not require changes to agent-to-agent communication protocols and does not require infrastructure to inspect the contents of agent communications. 6. Resource Publication and Update The Resource Publication Hook allows deployment infrastructure to maintain information about AI-agent resources currently available for discovery. The procedure can be illustrated using an A2A deployment. An A2A Agent Card describes the agent's interaction-related characteristics. The Resource Publication Hook instead describes current deployment and reachability state. For example: Logical-Service-Identifier: Vision-Inference Instance-Identifier: Vision-Agent-A Service-Category: Vision-Inference Endpoint: https://vision-a.edge.example Attachment-Scope: AScope-A Protocol: A2A Agent-Card-Reference: https://vision-a.edge.example/.well-known/agent-card.json 6.1. Logical Service vs. Instance Publication Where multiple runtime instances share a stable service endpoint: Document-Analysis-Agent | v Stable Service Endpoint Dunbar, et al. Expires Dec 16, 2027 [Page 18] Internet-Draft Infrastructure Assisted Discovery | +----+----+----+ | | | | A B C D the discovery mechanism may publish only: Logical-Service-Identifier: Document-Analysis-Agent Endpoint: https://document-agent.example Protocol: A2A Agent-Card-Reference: https://document-agent.example/.well-known/agent- card.json Scaling from four instances to eight need not modify the discovery publication. If the instances are independently reachable or have different Attachment Scopes, they may instead be published individually. 6.2. Cloud Deployment Example An A2A agent hosted on a Kubernetes-based cloud platform may be exposed through a Kubernetes Service, ingress gateway, or externally assigned endpoint. When the common endpoint remains stable, backend Pod creation or removal need not affect discovery. If the externally visible endpoint changes because the service is moved to another cluster: Before: Endpoint: cluster-a.example/agent After: Endpoint: cluster-b.example/agent the orchestration infrastructure can update the publication while the Agent Card remains unchanged. Dunbar, et al. Expires Dec 16, 2027 [Page 19] Internet-Draft Infrastructure Assisted Discovery 6.3. 5G Edge Deployment Example Consider two runtime instances of the same logical AI-agent service: Edge Orchestrator / \ v v Edge-A Edge-B Agent-A Agent-B | | UPF-A UPF-B The publications may be: Agent-A Logical-Service: Vision-Inference Endpoint: vision-a.edge.example Attachment-Scope: AScope-A and: Agent-B Logical-Service: Vision-Inference Endpoint: vision-b.edge.example Attachment-Scope: AScope-B If Agent-A moves to another edge environment, the infrastructure can change its endpoint and scope or withdraw the old instance and publish a new one. 6.4. Publication Lifecycle Publication events can include: - initial deployment; - new instance creation; - endpoint assignment; - scale-out or scale-in; - migration; - gateway change; - Attachment Scope change; - failure or unavailability; and - withdrawal. Dunbar, et al. Expires Dec 16, 2027 [Page 20] Internet-Draft Infrastructure Assisted Discovery The publication mechanism may be event-driven, controller- driven, registry-based, DNS-based, or implemented through another infrastructure interface. 7. Attachment Scope Determination and Update Attachment Scope abstracts network state that is relevant to discovery applicability. The network may derive Attachment Scope from one or more constructs, including: - access network; - cell or tracking area; - serving UPF or UPF group; - DNN; - network slice; - VPN or VRF; - enterprise or tenant context; - edge domain; or - other network reachability state. For example: UPF: UPF-A DNN: enterprise-ai Slice: Slice-1 Enterprise: Enterprise-A | v Attachment-Scope: AScope-A The discovery mechanism does not need to understand how AScope-A was derived. 7.1. Policy-Based Mapping The mapping can be many-to-one: UPF-A + DNN-X ----+ | UPF-B + DNN-X ----+--> AScope-X | Dunbar, et al. Expires Dec 16, 2027 [Page 21] Internet-Draft Infrastructure Assisted Discovery VPN-X ------------+ This enables a deployment to define discovery applicability independently of a particular network technology. 7.2. Requester Attachment Scope A requester may issue a discovery request such as: Service-Category: Vision-Inference Separately, network infrastructure determines the requester's current Attachment Scope based on network attachment state and provides it to the discovery mechanism: Attachment-Scope: AScope-A The discovery mechanism combines the requester's discovery criteria with the network-provided Attachment Scope when determining applicable AI-agent resources. The requester therefore does not need to know or supply network-specific information such as its serving UPF, network slice, DNN, VPN, or edge-domain association. 7.3. Scope Policy Attachment Scope matching does not require the requester and resource to have identical scope values. A deployment may define policy that determines which resource Attachment Scopes are applicable to a requester's Attachment Scope. For example, a requester associated with AScope-Edge-A may be permitted to discover resources published for the same edge scope, a broader metropolitan scope, or a shared cloud scope: Requester Attachment Scope: AScope-Edge-A Applicable Resource Scopes: AScope-Edge-A AScope-Metro AScope-Shared-Cloud Dunbar, et al. Expires Dec 16, 2027 [Page 22] Internet-Draft Infrastructure Assisted Discovery Such policy allows discovery applicability to reflect deployment relationships among edge, regional, and shared resources without exposing the underlying network-specific information used to derive the requester's Attachment Scope. 7.4. Mobility and Reassociation Attachment Scope can change when the requester: - moves between access areas; - changes serving UPF; - changes DNN; - changes slice; - moves between VPN or tenant contexts; - moves between Wi-Fi and cellular access; or - enters another edge domain. For example: Before: UPF-A -> AScope-A After reassociation: UPF-B -> AScope-B Subsequent discovery can therefore return resources applicable to the requester's new network context. Attachment Scope may be updated through events, queried at discovery time, or cached with an appropriate validity period. 8. Applying the Model to DNS-SD This section describes how the infrastructure-assisted discovery model in Section 5 can be realized using DNS-SD [RFC6763]. The general roles of requester criteria, published resource state, Attachment Scope, and discovery processing are defined in Section 5 and are not repeated here. Dunbar, et al. Expires Dec 16, 2027 [Page 23] Internet-Draft Infrastructure Assisted Discovery In the DNS-SD realization, the Resource Publication Hook maps current AI-agent resource state into DNS-SD service information, while the Attachment Context Hook provides network-derived context used to determine which DNS-SD discovery domains or service instances are applicable to the requester. No change to the DNS-SD query or response protocol is required by this document. 8.1. DNS-SD Mapping DNS-SD [RFC6763] represents service discovery using service types, instance enumeration, and endpoint resolution. The infrastructure-assisted model maps onto those mechanisms as follows: Published AI-Agent Resource State | v DNS-SD Representation PTR -> discoverable service instances SRV -> reachable target and port TXT -> selected discovery attributes or references to agent metadata For example, an AI-agent instance may be represented as: Vision-Agent-A._example-agent._tcp.example.com. with an SRV record identifying: vision-a.edge.example.com.:443 and TXT information such as: protocol=A2A metadata= https://vision-a.edge.example.com/.well-known/agent- card.json Dunbar, et al. Expires Dec 16, 2027 [Page 24] Internet-Draft Infrastructure Assisted Discovery The service type, instance naming convention, and TXT attributes shown above are illustrative. This document does not define a new DNS-SD service type or new TXT keys. 8.2. DNS-SD Publication When DNS-SD is used, the Resource Publication Hook described in Section 6 can populate and update the DNS-SD representation of currently available AI-agent resources. The deployment or orchestration system provides the information needed to create, update, or withdraw the corresponding DNS-SD records as the published AI-agent resource state changes. Conceptually: AI-Agent Deployment State | v Resource Publication Hook | +--> PTR: service-instance enumeration | +--> SRV: reachable target and port | +--> TXT: selected discovery attributes or metadata reference A published resource may represent either a logical AI-agent service or an individually reachable instance, as described in Section 6.1. When a published endpoint changes, the corresponding SRV information can be updated without requiring unrelated agent metadata to change. When a published resource is no longer available, its corresponding DNS-SD information can be withdrawn. An authorized controller may populate and maintain these records on behalf of the AI-agent service. Where Dynamic DNS is used, DNS UPDATE [RFC2136] can be used to add, modify, or remove DNS resource records. Other deployments may use Dunbar, et al. Expires Dec 16, 2027 [Page 25] Internet-Draft Infrastructure Assisted Discovery authoritative DNS management interfaces, orchestration APIs, or controller-specific mechanisms. The interface between the Resource Publication Hook and DNS infrastructure is outside the scope of this document. 8.3. Applying Attachment Scope The requester's Attachment Scope is provided to the discovery function through the Attachment Context Hook described in Section 7. It is not required to be carried in the DNS-SD request itself. When DNS-SD is used, Attachment Scope can be applied in at least two ways: o by mapping the requester's Attachment Scope to one or more DNS-SD discovery domains; or o by filtering enumerated resources according to the requester's Attachment Scope and deployment policy. 8.3.1. Scope to Domain Mapping A deployment can associate an Attachment Scope with one or more DNS-SD discovery domains. For example: Attachment-Scope: AScope-Edge-A | +--> edge-a.agent.example | +--> shared.agent.example A requester may issue only its application-level discovery intent, such as: Service-Category: Vision-Inference Dunbar, et al. Expires Dec 16, 2027 [Page 26] Internet-Draft Infrastructure Assisted Discovery The discovery function combines this request with the network-provided Attachment Scope and determines which DNS-SD domains are applicable. For example: Requester Intent: Vision-Inference Attachment Scope: AScope-Edge-A Applicable Discovery Domains: edge-a.agent.example shared.agent.example DNS-SD enumeration can then be performed within those domains using the procedures defined in [RFC6763]. This approach allows the DNS-SD discovery domain to reflect network applicability without requiring the requester to know which domain corresponds to its current network attachment. The mapping from Attachment Scope to discovery domains is deployment policy. 8.3.2. Filtering Resources After Enumeration Another deployment can use a common DNS-SD discovery domain that contains AI-agent resources associated with multiple Attachment Scopes. For example: Vision-Agent-A Attachment-Scope: AScope-A Vision-Agent-B Attachment-Scope: AScope-B Vision-Agent-C Dunbar, et al. Expires Dec 16, 2027 [Page 27] Internet-Draft Infrastructure Assisted Discovery Attachment-Scope: AScope-Shared The discovery function can first identify resources matching the requester's service-related criteria and then apply policy based on the requester's Attachment Scope. For a requester associated with: Attachment-Scope: AScope-A the applicable resource scopes might be: AScope-A AScope-Shared The resulting resources could therefore be: Vision-Agent-A Vision-Agent-C The Attachment Scope associated with a resource does not need to be exposed to the requester or encoded in a generally visible DNS-SD TXT record. It can instead be maintained by a trusted discovery component or associated infrastructure database. This approach is useful when resources associated with multiple network contexts share a common DNS-SD namespace, or when Attachment Scope information should remain internal to the infrastructure. In both approaches, DNS-SD continues to provide service- instance enumeration and endpoint resolution. The infrastructure-provided Attachment Scope determines which DNS-SD discovery domains or enumerated service instances are applicable to the requester's current network context. 8.4. Agent Metadata in DNS-SD Agent metadata used for discovery matching may be represented directly in DNS-SD, maintained separately by the discovery system, or obtained through a reference to an agent-native metadata mechanism. Dunbar, et al. Expires Dec 16, 2027 [Page 28] Internet-Draft Infrastructure Assisted Discovery A deployment may place selected discovery attributes in DNS- SD TXT records, such as a supported protocol or a reference to richer metadata. For example: protocol=A2A metadata= https://vision-a.edge.example/.well-known/agent- card.json Other attributes, such as skills, capabilities, supported modalities, or authentication characteristics, may be indexed by the discovery system without being encoded directly in DNS-SD. For an A2A deployment, some or all of this information may originate from an Agent Card. The complete Agent Card does not need to be duplicated in DNS-SD TXT records. The choice of which attributes are represented directly in DNS-SD and which are maintained or retrieved separately is deployment-specific. 8.5. Discovery Result The DNS-SD realization returns the service instances that remain applicable after the processing described in Section 8.3 and, where applicable, the metadata matching described in Section 8.4. For an applicable resource, DNS-SD provides the information needed to identify and resolve the published service instance. For example, the resulting information may correspond to: Resource-Identifier: Vision-Agent-A Endpoint: https://vision-a.edge.example Protocol: A2A Metadata-Reference: https://vision-a.edge.example/.well-known/agent- card.json Dunbar, et al. Expires Dec 16, 2027 [Page 29] Internet-Draft Infrastructure Assisted Discovery For DNS-SD, the target host and port are resolved using the normal SRV and address-resolution procedures defined by [RFC6763] and [RFC2782]. The Attachment Scope used to determine applicability does not need to be returned to the requester. It is infrastructure context used during discovery rather than information required for subsequent agent communication. A DNS-SD result may contain multiple applicable service instances. Where SRV records are used, the Priority and Weight procedures defined by [RFC2782] continue to apply. These procedures do not replace a separate resource-selection function when additional criteria such as network condition, compute load, accelerator availability, cost, or application policy are required. Additional agent-specific metadata, such as an A2A Agent Card, may be provided by reference or retrieved subsequently as described in Section 10. This document does not change the DNS-SD response format. 8.6. Caching and Freshness AI-agent deployment state can change after discovery information has been published. For example: o an instance can be withdrawn; o an endpoint can change; o an agent can move to another edge site; o an Attachment Scope associated with a resource can change; or o a requester can move to a different Attachment Scope. The Resource Publication Hook is responsible for reflecting changes to resource deployment state in the discovery system. Dunbar, et al. Expires Dec 16, 2027 [Page 30] Internet-Draft Infrastructure Assisted Discovery When DNS is used, normal DNS TTL semantics apply. [RFC1035] specifies the interval for which a resource record can be cached before the source of the information should be consulted again. Deployments in which agent endpoints or placement change frequently can therefore use TTL values appropriate to the expected lifetime of the published information. Very dynamic deployment information should not be treated as indefinitely valid merely because it was previously returned by discovery. Attachment Scope can have a lifetime that is independent of the lifetime of DNS resource records. For example, a requester may change from: AScope-A to AScope-B. while previously discovered DNS information remains present in a cache. A new discovery operation should therefore use the requester's current Attachment Scope rather than assuming that a previously determined Attachment Scope remains valid. Implementations should avoid treating cached resource information and cached Attachment Scope as having the same validity period unless deployment policy explicitly defines them that way. 8.7. No Match A discovery request can identify no resource that satisfies both the agent-related discovery criteria and the applicable Attachment Scope policy. For example: Requested: Vision-Inference Candidate: Agent-B -> AScope-B Dunbar, et al. Expires Dec 16, 2027 [Page 31] Internet-Draft Infrastructure Assisted Discovery Requester: AScope-A If policy does not permit AScope-A to use resources in AScope-B, the discovery result contains no applicable resource. The discovery mechanism may return an empty result or use mechanisms provided by the underlying discovery system to indicate that no applicable resource was found. A deployment can also define fallback policy. For example, when no edge-local resource is applicable, the discovery mechanism may consider an AI-agent resource published for a shared cloud Attachment Scope. Such fallback behavior is deployment policy and is not mandated by this document. 9. Applying the Model to DNS-AID DNS for AI Discovery (DNS-AID) [DNS-AID] uses existing DNS mechanisms to publish AI-agent connectivity and discovery information. For a known agent, DNS-AID uses SVCB records to provide endpoint, transport, agent-protocol, and capability- related information. When the requester knows an organization but not a specific agent, DNS-AID uses the well-known _index._agents.<domain> entry point to locate an organization-specific agent index. The infrastructure-assisted model in Section 5 can complement DNS-AID in managed enterprise, cloud, edge, and communication-network environments. The Resource Publication Hook can keep DNS-AID-visible agent information aligned with current deployment state, while the Attachment Context Hook can provide network-derived context used to determine which published agents or discovery information are applicable to a requester. The Attachment Scope is not required to be encoded in DNS-AID SVCB records or carried in DNS queries. Infrastructure Dunbar, et al. Expires Dec 16, 2027 [Page 32] Internet-Draft Infrastructure Assisted Discovery assistance is applied around the DNS-AID mechanism and does not change the DNS-AID wire format. 9.1. DNS-AID Mapping The Resource Publication Hook can map current AI-agent deployment state to the information exposed through DNS-AID. Conceptually: AI-Agent Deployment State | v Resource Publication Hook | +--> Agent SVCB record | endpoint / transport / agent protocol | capability metadata or reference | +--> Organization agent index discoverable agent inventory For a known agent, changes to an externally reachable endpoint, supported protocol, or referenced capability information can result in corresponding updates to the published DNS-AID information. When an agent is withdrawn, its published information can likewise be removed or made unavailable. For organization-level discovery, deployment or management infrastructure can keep the organization-specific agent index synchronized with the set of AI-agent services or instances that are currently intended to be discoverable. The exact format and access protocol of that index remain outside the scope of DNS-AID. 9.2. Applying Attachment Scope to DNS-AID In a managed environment, the Attachment Context Hook can provide the requester's current Attachment Scope to the Dunbar, et al. Expires Dec 16, 2027 [Page 33] Internet-Draft Infrastructure Assisted Discovery discovery function before or while DNS-AID information is used. The Attachment Scope can then be applied by deployment policy to determine which DNS-AID-published agents or organization-index results are applicable to the requester. For example, an organization may publish agents reachable from an enterprise edge environment as well as agents reachable through a shared cloud environment. A requester associated with AScope-Edge-A could be permitted to use both edge-local and shared-cloud agents, while a requester associated with another Attachment Scope could receive or use a different applicable set. A deployment can apply this policy when selecting an organization index to consult, when presenting a managed view of an organization index, or when filtering the agents obtained from that index. These are deployment choices; this document does not require Attachment Scope to be published in DNS or returned to the requester. In this way, DNS-AID continues to provide the DNS-based bootstrap and agent connectivity information, while infrastructure-provided Attachment Scope contributes requester-specific applicability information. 9.3. Relationship to DNS-AID Results Infrastructure assistance does not change the DNS-AID result format. For a known-agent lookup, the requester can use the SVCB information published by DNS-AID to locate and connect to the applicable agent. For organization-level discovery, the requester can follow the DNS-AID organization-index entry point and use the resulting index information to identify candidate agents. Where several agents satisfy the requester's criteria and Attachment Scope, the discovery result may contain multiple applicable resources. Subsequent resource selection remains separate, as described in Section 11. Dunbar, et al. Expires Dec 16, 2027 [Page 34] Internet-Draft Infrastructure Assisted Discovery 10. Second-Stage Agent Metadata Retrieval A discovery mechanism may maintain sufficient agent metadata to perform discovery matching. Once an applicable resource has been identified, the requester can retrieve additional protocol-specific information using the agent's native mechanism when needed. For A2A: Discovery Response | v Agent Card Reference | v Retrieve Agent Card | v Identity, Capabilities, Skills, Interfaces, Security, Interaction Requirements Other AI-agent protocols may use different descriptors. This model avoids requiring one general discovery mechanism to reproduce all protocol-specific agent metadata. 11. Relationship to Resource Selection Attachment Scope determines applicability rather than optimization. For example: Discovery Result: Agent-A Agent-B means that both agents are usable within the applicable discovery context. A separate mechanism may select one based on: - latency; - network congestion; Dunbar, et al. Expires Dec 16, 2027 [Page 35] Internet-Draft Infrastructure Assisted Discovery - compute load; - GPU availability; - service cost; - application policy; or - another dynamic metric. Mechanisms such as CATS may be applicable to such subsequent network-aware selection. 12. Alternative methods The infrastructure-assisted model does not depend on a particular discovery protocol. The discovery mechanism may use: - DNS-AID; - DNS-SD; - a centralized registry; - a distributed directory; - a federated discovery mechanism; or - another service-discovery system. The Resource Publication Hook may be implemented by: - Kubernetes or cloud orchestration; - serverless hosting infrastructure; - MEC orchestration; - an application gateway; - a service mesh; - an enterprise AI platform; or - another deployment controller. Attachment Scope may be derived from: - 5G network state; - enterprise VPN/VRF state; - Wi-Fi infrastructure; - cloud networking; - SD-WAN state; - edge-controller state; or - combinations of these. Dunbar, et al. Expires Dec 16, 2027 [Page 36] Internet-Draft Infrastructure Assisted Discovery Resource and Attachment Scope state may be updated through events, queried dynamically, periodically refreshed, or cached. Agent-native metadata may be represented using an A2A Agent Card, MCP metadata, another protocol-specific descriptor, or a deployment-specific format. 13. Security Considerations Attachment Scope may be derived from sensitive network information. The discovery mechanism should receive only the abstraction needed for discovery and should not require unnecessary exposure of: - subscriber identity; - physical access port; - precise geographic location; - internal topology; - routing identifiers; or - detailed network configuration. Infrastructure providing Attachment Scope needs to be trusted by the discovery mechanism. A requester should not be able to obtain unauthorized resources merely by asserting an Attachment Scope in an untrusted request. Likewise, Resource Publication Hooks need authentication and authorization so that unauthorized systems cannot publish, alter, or withdraw AI-agent resource information. Discovery information can reveal the existence and reachability of AI resources. Deployments should therefore apply appropriate visibility and access policies. 14. IANA Considerations TBD Dunbar, et al. Expires Dec 16, 2027 [Page 37] Internet-Draft Infrastructure Assisted Discovery 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 15.2. Informative References [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery," RFC 6763, February 2013. [A2A] Agent2Agent Protocol, "Agent2Agent Protocol Documentation", https://a2a-protocol.org/. [AGENT-ATTACHMENT] Dunbar, L., et al., "Agent Attachment Protocol," Work in Progress. [DAWN-FRAMEWORK] Zhang, B., Dunbar, L. and Y. Yang, "A Framework for Agent Discovery in DAWN", draft- zhang-dawn-agent-discovery-framework-07, Work in Progress. [DAWN-MDNS] Jakab, L. and Brockners, F., "Zero-Configuration Agent Discovery," draft-jakab-dawn-agent-discovery- mdns, Work in Progress. Dunbar, et al. Expires Dec 16, 2027 [Page 38] Internet-Draft Infrastructure Assisted Discovery [DAWN-USE-CASES] King, D., et al., "Use Cases and Applicability for Discovery of Agents With Names," Work in Progress. [DAWN-MDI] Cui, et al., "Minimum Discoverable Information for DAWN," Work in Progress. [DNS-AID] Mozley, Williams, Sarikaya, Schott, and Damick, "DNS for AI Discovery," draft-mozleywilliams-dnsop- dnsaid-02. [MCP] Model Context Protocol, "Model Context Protocol Specification", https://modelcontextprotocol.io/specification/ 16. Acknowledgments Acknowledgements to xxx for their extensive review and suggestions. This document was prepared using 2-Word-v2.0.template.dot. Appendix A: Authors' Addresses Linda Dunbar Futurewei Email: ldunbar@futurewei.com Bin Zhang Pengcheng Laboratory Email: zhangb@pcl.ac.cn Contributors' Addresses Dunbar, et al. Expires Dec 16, 2027 [Page 39]
An individual IETF draft proposing a two-phase addressing scheme and a three-dimension framework for agent identification and addressing on IPv6 networks.
SAIP defines a signed agent identity protocol that cryptographically attests an agent's identity, answering how a peer can prove it is the agent it claims to be.
Standard20262026-10-21IETF Internet-Draft, Intended status: Informational (individual submission, rev -09; Alter Meridian Pty Ltd)IETF →IETFMCPagent-discoveryDNSDNSSECDANEidentity
This document defines a DNS-based mechanism for discovering Model Context Protocol (MCP) servers, the identity of the organisations that operate them, and a cryptographic identity envelope bound to an individual Sovereign-tier ~handle published under the same zone. Three TXT records are defined. _mcp.<domain> advertises an MCP server's endpoint URL, agent protocol family, transport binding, cryptographic identity, and capability profile. _org-alter.<domain> advertises the operator's canonical organisational identity, including its legal entity, registry identifier, regions of operation, and any regulatory framework under which it must refuse external automated access. _alter.<domain> publishes an Ed25519-signed envelope binding a ~handle to a public key, an IdentityLog root reference, and a revocation commitment. DNSSEC validation is REQUIRED for the envelope record, and a DANE TLSA pin on the MCP endpoint is REQUIRED where resolving an envelope and opening an MCP session are one recognition transaction. The mechanism complements HTTPS-based discovery, and follows the precedent set by DKIM, SPF, DMARC, and MTA-STS. A companion alter: URI scheme is provisionally registered with IANA.
Software agents increasingly act on the Internet on behalf of people and organizations: they call APIs, browse websites, and delegate work to other agents. Protocols such as A2A and MCP define how agents communicate, but there is no interoperable way to answer a prior question: _which agent is this, and how can its claims be verified?_ This document defines the agent URI scheme as a stable, human-readable identifier for an agent, a deterministic mapping from that identifier to an HTTPS-hosted Agent Identity Document, anchoring of the agent's keys to a web origin or a Decentralized Identifier, and signed statements that bind the agent to its protocol metadata. It also defines profiles that let an agent prove its identity on HTTP requests, building on HTTP Message Signatures for automated traffic, and that let short-lived agent instances act under the agent's identity using the WIMSE Workload Identity Token format. It deliberately does not define how agents communicate, describe their capabilities, or are invoked.
Defines the Agent Registration and Discovery Protocol: how an agent registers itself, declares its capabilities and endpoints, and how other agents or gateways locate it.
E. Stephan (Ed.), R. Schott, D. Lopez, X. Duan et al.
Standard20262026-10-12IETF Internet-Draft draft-stephan-agentproto-6g-usecases-00 (Agent Communication Protocols WG)IETF · PROTOCOLS →IETF6Gagent-protocol3GPPuse-casesrequirementscarrier
Communication between AI agents and between agent and tools is expected to be pivotal in 6G systems. The 3GPP TR 22.870 outlines various use cases and potential service requirements for AI agent communication within 6G systems. This document provides examples of use cases and service requirements contained in the 3GPP TR 22.870 and extrapolates possible requirements related to agent communication protocols.
Specifies trust, identity and verifiable provenance mechanisms for agent-to-agent interaction, enabling participants to authenticate counterparts and audit what an agent actually did.
Proposes an architecture combining network digital twins with agentic AI for AI-driven network operations, using the twin as a safe substrate for agent reasoning about the production network.
A 31-page individual Internet-Draft proposing a two-layer federated reference architecture for cross-organizational AI agent discovery within the IETF DAWN work. The Local Discovery Plane performs zero-configuration agent advertisement and collection inside a site without mandating a link-local protocol; the Federation Plane links site gateways that already trust each other through lightweight Federation Metadata Records (FMR), a concrete binding of the DAWN Minimum Discoverable Information, while full Capability Cards are fetched on demand over authenticated unicast. Data sovereignty is enforced by an Export Policy Engine in the site gateway, which decides which records reach which peers and which fields are stripped, so one local inventory yields different subsets per peer. The draft is Informational, defines no normative protocol formats and does not compete with ACAP, Agent Directory or ARDP. Note a known gap raised in public review: the FMR carries origin, endpoint, capability, freshness and provenance but no authorized-audience set, redistribution flag or export-policy version, so the origin sharing decision does not travel with the record beyond the first hop.
Defines a gateway-managed capability-directory framework for the Internet of Agents: a control-plane function maintaining validated capability information beyond transient advertisements, static endpoint bindings or external descriptions, with requirements and a common object model.
This document specifies the Federated Agent Metadata Synchronization Protocol (FAMS-P), a normative protocol realization of the "BGP-like structured peering" federation mode (Mode B) defined in the two-layer DAWN discovery architecture (draft-zhang-dawn-agent-discovery-framework). FAMS-P is a peer-to-peer unicast protocol for synchronizing agent discovery metadata between Federation Gateways (FGWs) across administrative domains, in deployments where the preferred DNS delegation model does not meet operational requirements, such as closed trusted federations of approximately 2 to 200 sites. FAMS-P runs over mutually-authenticated TLS 1.3 sessions between peering gateways. It supports initial full metadata synchronization and incremental updates for agent online, offline, and change events. Each gateway maintains a local Federated Agent Directory (FAD). The protocol synchronizes only lightweight Federation Metadata Records (FMRs) — a concrete binding of the DAWN Minimum Discoverable Information (MDI) — and thus transfers only the minimum public discovery information permitted by the DAWN charter; richer capability retrieval is out of scope. The protocol defines complete message formats, a session state machine with connection collision resolution, timestamp-and-replay- protected conflict resolution, mandatory FMR origin signatures, time-to-live aging with bounded refresh jitter, and fine-grained per-peer export policy enforcement.
Agentic systems can carry out tasks using agents, model services, data services, tools, and computing environments distributed across sites and administrative domains. Dependencies among these components create communication and computing requirements that may evolve during execution. Whether a proposed collaboration can satisfy those requirements depends on network connectivity and performance, computing capacity and readiness, data and model locality, and the policies governing resource use and data movement. This document describes a framework for cross-domain agentic collaboration that accounts for task dependencies and the network and computing conditions affecting communication and execution. It outlines the roles and interactions of agents and their runtimes, infrastructure information functions, and resource-management functions. The framework relates task dependencies to communication and computing requirements, with consideration of execution locations, data movement, and constraints spanning dependent activities. It discusses the use of appropriately scoped domain information to assess alternative combinations of agents, services, and tools, together with the abstraction and updating of that information under partial visibility and independent domain policies. The framework also addresses adaptation to evolving dependencies and infrastructure conditions, including information overhead and the stability of decisions in large agent populations.
Standard20262026-09-30National standardization guidance document (GB/Z); release reported by Xinhua on 2026-09-30GB/Znational-standardGB/Zagentcapability-requirementstool-invocationChina
One of five AI-related national standardization guidance documents (GB/Z) whose release was reported by Xinhua on 30 September 2026 (report dateline 2026-09-30, standard release date not separately given; no public full text located at collection time, so scope is stated only as described by the official report). Verbatim from the report: the standard "围绕感知、规划、执行、记忆、工具调用等关键能力提出规范，为智能体自主任务执行提供技术指引" (specifies requirements around key capabilities such as perception, planning, execution, memory and tool invocation, providing technical guidance for autonomous task execution by agents). It was released alongside GB/Z 222-2026 (Artificial Intelligence — Model-as-a-Service (MaaS) performance specification), GB/Z 253-2026 and GB/Z 236-2026 (retrieval-augmented generation technical requirements and evaluation metrics) and GB/Z 228-2026 (home large-model technical requirements). The report notes the five documents provide unified technical specifications for large-model service evaluation, knowledge augmentation, agent capability building and smart-home applications.
IETF (responsible AD: Charles Eckel), agentproto Working Group
Standard20262026-10-02IETF proposed Working Group charter (charter-ietf-agentproto-00-04); on the IESG telechat agenda of 2026-10-08IETF →IETFagentprotoagent-dialogworking-groupcharterMCPA2ASCITTWIMSE
Proposed IETF Working Group charter "Agent Communication Protocols (agentproto)", revision charter-ietf-agentproto-00-04, status "External Review", WG state "Proposed", responsible AD Charles Eckel, listed on the IESG telechat agenda of 2026-10-08. Verbatim from the charter: "The scope of Agent Communication Protocols (agentproto) Working Group is to define a common baseline agentic dialog management protocol and build a reference architecture to integrate related protocol building blocks, enabling interoperability across platforms and vendors." A dialog is defined as "the correlated sequence of interactions between two or more participants over the course of a task", and dialog context as "the identifiers and lifecycle state needed to correlate and maintain an agentic dialog. It does not include the content exchanged with AI models, such as conversation memory, retrieved documents, or prompts." Verbatim: "The agentic dialog management protocol neither replaces application-layer agent communication protocols nor defines a new transport protocol. It defines dialog identifiers, lifecycle semantics, and the propagation of dialog context, together with bindings specifying how that context is carried over existing IETF protocols." Deliverables: an Agentic Dialog Management Protocol (Standards Track) defining dialog management primitives (correlation across multiple hops and trust boundaries; establishment, modification, termination and revocation of propagation relationships; recovery and unreachability handling) and transport bindings over existing IETF protocols such as HTTP, QUIC, WebTransport, WebRTC or MoQ; plus a Reference Architecture (Informational) and Use Cases and Requirements (Informational). Verbatim: "The dialog context is defined so that existing application-layer agent communication protocols (e.g., the Model Context Protocol (MCP) and the Agent2Agent (A2A) protocol) can carry it using their own mechanisms." Key consideration quoted: "AI agents act as autonomous software entities that may need to be authenticated independently of the users who delegated authority to them." Out of scope: agent implementation details, standardization of agent decision-making or planning semantics, agent behavioral security, human-to-agent UX, and audit data structures. Proposed milestones: adopt an informational use-cases draft by December 2026, an informational architecture draft by February 2027, adopt a proposed-standard dialog management protocol draft by March 2027, and submit it to the IESG as a proposed standard by March 2028.
Standard20262026-10-08IETF approved BoF request, last updated 2026-10-08; target BoF at IETF 127 (San Francisco); proposed working-group name AUDIT; responsible AD: SEC ADs; proposed chair: Yaroslav RosomakhoIETF →IETFauditaccountabilitydelegationtraceabilityagent-identityA2ASCITTRATSvConWIMSEworking-group
Verbatim from the IETF BoF request page (Description, retrieved 2026-10-12): "Autonomous and semi-autonomous software agents are increasingly acting on behalf of users across multiple services and administrative domains. These agents interact across multiple administrative or trust domains and can initiate actions without direct human oversight at each step. The increased use of complex agent communications introduces significant challenges for auditability, accountability, transparency. Existing mechanisms, such as system logs, tracing systems, and authorization frameworks, capture individual aspects of system behavior but lack interoperable support for correlating user intent, delegation chains, authorization state, and resulting actions across domains. This creates challenges for fundamental questions required for compliance, operational debugging, and user trust, such as who initiated an action, under which authority it occurred, and how permissions evolved during execution." — "To support governance, compliance, transparency, and trust in such environments, auditing is required that collects and correlates evidence across participating domains rather than relying solely on local agent logs, where no single party has complete visibility into a multi-domain interaction. The scope of such auditing is the observable behavior of agents, including user intent, agent or tool interactions, invoked or declined actions, exchanged data, and resulting outcomes across trust boundaries, but not the auditing of the underlying AI model, training data, or inference mechanisms." — "The AUDIT effort aims to define interoperable protocol mechanisms and data models for auditing and accountability of agents and delegated systems to record, exchange, and verify audit-relevant information across Internet protocols cross all interactions in a communication chain including the user, one or multiple agents or subagents, and tools. This includes an architectural concept, common models for audit records, propagation of audit context across interactions, and integration with existing IETF protocols such as OAuth, HTTP, and attestation and transparency frameworks." The request lists technology overlap with OAUTH, WIMSE, SCITT, RATS, HTTPbis, Webbotauth, DAWN and AgentProto, and cites relevant drafts draft-kuehlewind-audit-architecture-00 and draft-birkholz-verifiable-agent-conversations-00; the mailing list is audit@ietf.org.
Standard20262026-10-02IETF proposed Working Group charter (charter-ietf-dawn-00-08)IETF →IETFDAWNagent-discoveryworking-groupcharterDNSmDNS
Proposed IETF Working Group charter "Discovery of Agents With Names (DAWN)", revision charter-ietf-dawn-00-08. Verbatim from the charter: "Clients often need to discover information about AI systems and resources (e.g., AI agents) before interacting with them. This requires obtaining information about how to reach the resources and what they offer. The focus of the DAWN Working Group (WG) is on how a client can discover public properties of AI resources to facilitate subsequent interactions such as selection, invocation, or communication. DAWN focuses on this initial discovery only and does not include open-ended search, semantic matchmaking, ranking, or selection of an AI resource based on capabilities or user intent." Scope is limited to discovery within immediate proximity, within an organization, and between cooperating parties with trust relationships over the public Internet; the charter states the WG "will specify an interoperable and generic discovery mechanism that builds on existing protocols and tools, benefits from established trust models, supports proven delegation and federation architectures, and allows organizations to have independently published discovery information", and that it "will consider DNS and mDNS as mechanisms upon which to build a discovery protocol". Deliverables: Terminology (Informational), Use Cases and Applicability (Informational), Discovery Architecture (Informational RFC(s)), and Protocol (Standards Track document(s)). Verbatim out-of-scope list for the initial phase: "Exchange of capability information beyond the minimum public discovery information"; "All communication beyond the initial discovery process"; "AI resource indexing and searching across the wider Internet"; "Identity management of AI agents, tools, and skills"; "Trust management and trust evaluation methods beyond secure content exchange between DAWN parties". Proposed milestones: DAWN Protocol specification submitted to the IESG by December 2027; DAWN Architecture by January 2028; optional terminology by June 2027. The charter states the WG will coordinate with WIMSE and OAuth as well as WGs related to DNS, discovery, identities or AI.
Standard20262026-10-22IETF Internet Area Working Group; WG state Active, charter-ietf-dawn-01 state Approved (2026-10-22); chairs Dapeng Liu, Frank Brockners; Area Director Éric VynckeIETF →IETFDAWNagent-discoveryworking-groupcharterDNSmDNS
Verbatim from the approved charter text (charter-ietf-dawn-01): "Clients often need to discover information about AI systems and resources (e.g., AI agents) before interacting with them. This requires obtaining information about how to reach the resources and what they offer." "The focus of the DAWN Working Group (WG) is on how a client can discover public properties of AI resources to facilitate subsequent interactions such as selection, invocation, or communication. DAWN focuses on this initial discovery only and does not include open-ended search, semantic matchmaking, ranking, or selection of an AI resource based on capabilities or user intent." "Note that discovery may be an iterative process, and may use referrals, direct transfer, delegation, or indirection." The charter states the WG "will specify an interoperable and generic discovery mechanism that builds on existing protocols and tools, benefits from established trust models, supports proven delegation and federation architectures, and allows organizations to have independently published discovery information", and that it "will consider DNS and mDNS as mechanisms upon which to build a discovery protocol." Deliverables are Terminology (Informational), Use Cases and Applicability (Informational), Discovery Architecture (Informational RFC(s)) and Protocol (Standards Track document(s)). Verbatim out of scope for the initial phase: "Exchange of capability information beyond the minimum public discovery information, i.e., catalogs of capabilities are out of scope."; "All communication beyond the initial discovery process."; "AI resource indexing and searching across the wider Internet."; "Identity management of AI agents, tools, and skills."; "Trust management and trust evaluation methods beyond secure content exchange between DAWN parties." Status note: this approved charter supersedes the proposed charter charter-ietf-dawn-00-08 already recorded in this library; the document name is unchanged but the revision is now 01 and the charter state is Approved.
Standard20262026-06-09ITU-T SG13 work item (under study)ITU-T · SG13/Q17/13 →ITU-Tagentagent-as-a-service标准
SG13 Q17/13 work item on requirements for AI Agent as a Service (Y.aias-reqts), with 2026-06 contributions from ETRI covering proposed revisions of scope/overview of AI agent and text for AI agent as a service in clause 6.2. Related parallel SG13 items: Y.AMLM-reqts (ML model adaptation), Y.MLPaaS-reqts (ML PaaS). Signifies that agent-as-a-service is entering requirements-stage standardization at ITU-T.
SG13 technical report under study defining the AI-agent communication network (ACN) in IMT-2020 networks and beyond. Presented among SG13 AI-agent achievements alongside YSTR.NAC and Y.IMT2020-DIC; echoes the ACN concept promoted by China Mobile at the 2026 Cloud-Network Intelligence Conference. Note: China Mobile's CN indicator and ITU-T ACN terminology converge on the same problem space — agent-native networking for 6G.
SG13 Q22/13 technical report (target 2026-11) surveying standardization status and roadmap for networking that supports AI agent collaboration across heterogeneous organizations, protocols and data formats; collects related Recommendations and TRs and proposes standardization directions. Companion item: YSTR.NAC (Framework of networking for AI agent collaboration in future networks). Supported by China Telecom, CAICT, China Unicom, BUPT, Zhejiang Lab and NICT; editors include Jingwen LI and Ved P. KAFLE.
Standard20262026-08-28IETF RFC (SPRING WG)10038IETF · spring →IETFRFCSRv6DHCPv6SPRING
RFC 10038 specifies distribution of the Segment Routing over IPv6 (SRv6) locator via DHCPv6, automating locator provisioning and removing a major operational friction in large-scale SRv6 deployments.
Published 2026-03-02, effective 2026-06-01 (project 2025-CCSA-002, TC1/WG1). Defines the capability classification method for AI agent systems and the technical requirements per level; applicable to both agent providers and consumers for grading agent systems. One of 75 group standards approved in the same batch.
An open-source Python framework for building and operating long-running agents, covering tool use, MCP support, the A2A agent-to-agent protocol and durable execution. Its distinguishing feature is durable runs: every step is persisted so another process can finish a run after a crash, or fork it into a new one. Calling serve on an agent enables the A2A protocol automatically, making the agent discoverable to others. It works with any OpenAI-compatible provider including OpenRouter, Groq, Together, vLLM and Ollama. Notable because it treats A2A discoverability and crash-resumable execution as defaults rather than add-ons.
Tool20262026-09-24Open-source protocol suite (Apache-2.0), https://agent-network-protocol.com; v1.2 released 2026-09-24agent-internetprotocol-suiteagent-namingagent-discoveryWNSDIDopen-source
Verbatim from the project README: "ANP aims to become the HTTP of the Agentic Web era: a protocol suite for agent identity, naming, discovery, negotiation, secure messaging, and application-level collaboration." On why it is needed, the README states that current internet infrastructure "is mature, but it still lacks a communication and connection layer designed for large-scale agent networks", and that ANP focuses on three challenges: "Interconnection: enable agents from different platforms and domains to authenticate, discover, and communicate with each other"; "Native interfaces: let AI use APIs, protocol documents, structured descriptions, and negotiated interfaces instead of imitating human browsing"; and "Efficient collaboration: allow agents to self-organize, self-negotiate, and build lower-cost collaboration networks". It is organised as an identity and encrypted-communication layer based on W3C DID and Web infrastructure (ANP-02 DID Authentication, which separates common authentication from DID method validation including did:wba and native did:web; ANP-03 did:wba method; ANP-04 WNS Naming; ANP-09 end-to-end instant messaging plus P1-P9 messaging profiles defining DID addressing and device-bound end-to-end encryption) and an application protocol layer comprising Agent Description, Agent Discovery and Agent Application protocols. The specification index marks Agent Description (ANP-07, covering agent description documents, interface descriptions and capability publication) and Agent Discovery (ANP-08, active `.well-known` discovery and passive registration with search agents) as Released v1.2. Verbatim on positioning: "ANP reuses HTTP, CA, DNS, CDN, Search, and TLS instead of rebuilding a new network stack." The repository is Apache-2.0 licensed; the README carries a notice that the project has not issued any digital currency on any platform or blockchain.
Zijing Mountain Laboratory (紫金山实验室), China Mobile, Jiangsu Future Network Group, Jiangsu Future Network Innovation Research Institute
Tool20262026-10-16Announced at the 10th Future Network Development Conference (Nanjing), 2026-10-16, as one of three headline results released by Liu Yunjie (CAE) and You Xiaohu (CAS)agent-interconnectiondeterministic-networkingsemantic-addressingprotocol-translationcompute-network-schedulingCENIChina
Verbatim from the Jiangsu Provincial Department of Science and Technology release (2026-10-19) on the conference results: “「基于确定性网络的智能体互联平台AXP」由紫金山实验室联合中国移动、江苏未来网络集团、江苏省未来网络创新研究院共同研发，可实现智算网深度融合调度、异构智能体协议统一转换，支持百万级智能体注册接入、十万级智能体同时在线运行，达成秒级故障感知切换、百毫秒级语义寻址响应。刘韵洁院士介绍，依托国家级未来网络试验设施（CENI），平台可完成4000公里以上跨域高精度智能体寻址访问，有效降低20%以上端到端任务执行耗时。目前，紫金山实验室已联合电信运营商、通信设备企业、大型钢铁制造企业等多方主体，开展多场景智能体联合测试与产业化验证。” A parallel report by 通信世界 (2026-10-24) summarises the platform as combining “确定性网络、异构智能体协议统一转换、智算网深度融合调度” on one platform. No open-source repository or public specification has been published at collection time.
Tool20262026-09-28Platform announced by China Unicom in late September 2026 (通信世界 news bulletin, 2026-09-30; weekly industry timeline lists the release on 2026-09-28); described by China Unicom Research Institute as an open agent-internet research platformagent-interconnectionprotocol-frameworkregistrydigital-identityoverlay-networkcarrierChina-Unicom
Verbatim from 通信世界 (Tongxin Shijie) news bulletin, 2026-09-30: "中国联通发布CubeMAP解决方案，旨在解决海量异构智能体 之间的互联互通难题，推动多智能体协同从技术构想走向规模化应用。" An industry weekly timeline (2026-10-03 edition) lists the same event as "9月28日中国联通发布CubeMAP，赋能多智能体互联互通". The platform was described publicly by 曹畅, Director of the Next-Generation Internet Research Department at China Unicom Research Institute, in a conference report carried by 《中华英才》 半月刊 (2026-09-23): "在智能体互联网领域，曹畅指出 AI 正从单体智能迈向群体协同，智能体互联网将重构'连接、架构、认证、服务'核心要素。 为此，中国联通提出原生网络架构与协议框架，并搭建开源开放的智能体互联网科研平台 CubeMAP，提供注册发现、数字身份、协议适配等核心能力。未来，联通将以算、 网资源为基础承载层提供'连接+算力'，融合 Overlay 网络和数字身份技术构建智能体互联网服务层，支撑智能体全域自主互联与协同，培育智算普惠开放生态体系。" Related industry commentary (2026 一周综述) frames CubeMAP as China Unicom aiming at the interconnection layer among heterogeneous agents, i.e. "the TCP/IP layer for agents"; a separate report notes the protocol framework was shown in China Unicom's agent-internet area at MWC Shanghai 2026. No first-party product page was located at collection time; all wording above is quoted from the cited Chinese-language coverage.
Huawei's fully open-sourced multi-agent collaboration platform, built by Huawei 2012 Labs and the Huawei Cloud AgentArts team, targeting a general-purpose AgentOS able to keep millions of agents running stably. Its flagship agent, JiuwenSwarm, concentrates the platform capabilities in harness engineering, multi-agent coordination and self-evolution. Reported figures as of September 2026: more than 40,000 stars, over 650 contributors and more than 3 million downloads, with deployments across 50-plus industries and 10-plus scenarios spanning finance, manufacturing, government, research and telecom; Huawei reported a Prefix Cache hit-rate improvement above 20 percent and a 15 percent reduction in time to first token. A representative case is China Southern Power Grid building a "digital doctor" for equipment on top of openJiuwen, combining hand, eye and brain into one multi-agent coordination architecture with reported accuracy above 90 percent and evaluation time cut to the minute level, shifting operations from experience-driven to agent-driven. Huawei presented the project at AGNTCon + MCPCon China 2026 (Shanghai, 6-7 September 2026) alongside its telecom path from A2A to A2A-T to OpenAN. Mirrors are also hosted on AtomGit.
Tool20262026-09-30Commercial platform with open-source SDKmcpgatewaygovernanceobservabilityenterprise
Announced 30 September 2026, extending Kong's open-source Volcano agent SDK into a full AI-native platform for building, deploying and operating agents. The strategic bet is that agents reach enterprise data through MCP rather than direct API calls, and that the durable position is the governed layer in between — handling authentication, rate limits and observability the way Kong's API gateway does for conventional traffic. The SDK demo builds a query-summarise-post workflow in nine lines; the platform supports models from Anthropic, OpenAI, Azure, AWS and GCP. The open question reported is whether developers adopt Volcano or default to larger incumbent frameworks.
Tool20262026-09-22Microsoft Research · arXiv:2609.26781 · 项目页 aka.ms/Agenshmulti-agentdecentralizedorchestrationself-organizationscaling
A multi-agent harness released by Microsoft Research in September 2026 that removes the central orchestrator entirely, letting up to 1024 agents self-organize. Each agent runs an identical five-step loop — gather shared context, claim an unclaimed subtask, execute independently, self-verify against tests, and merge results — with conflicts resolved by peer-to-peer negotiation rather than a scheduler. The paper's central claim is that agent count becomes an independent scaling dimension for model capability: overall task completion improves with agent count without upgrading the underlying model or lengthening per-agent inference. This directly attacks the scheduling-bandwidth ceiling, single point of failure and rigid task assignment of the prevailing orchestrator-worker architecture.
Released on 30 September 2026, consolidating Microsoft's previously separate Semantic Kernel and AutoGen agent stacks into a single open-source SDK spanning .NET and Python. Multi-agent orchestration is decomposed into explicit patterns — sequential, concurrent, group chat, handoff, and a Magentic-based manager-team mode. At the protocol layer it natively supports both A2A (agent-to-agent) and MCP (agent-to-tool) as complementary rather than competing paths. Engineering additions include checkpointing and resumption, so long-running tasks can continue after interruption and interrupted sessions can be exported for human takeover. Reported significance: it consolidates a fragmented orchestration landscape, and its dual A2A+MCP support signals that agent interoperability protocols are converging on a stable shape.
Linux Foundation Networking, China Mobile, Huawei, ZTE et al.
Tool20262026-06-25Linux Foundation Networking (LFN) candidate project, Apache-2.0open-sourceautonomous-networksA2A-Tagent-registryorchestrationcarrier
The first open-source project for carrier agent collaboration, contributed by China Mobile and Huawei and hosted by Linux Foundation Networking as a candidate project; unveiled at MWC Barcelona in March 2026 and released at MWC Shanghai on 25 June 2026, with the first offline meeting of its eight founding members in Copenhagen on 30 June 2026. It implements A2A-T (Agent to Agent Protocol for Telecom), which extends the general A2A protocol into telecom scenarios across four domains (Task-T, Notification-T, Negotiation-T and Authorization-T), and ships three categories of components: the A2A-T common component (SDK, Registry Centre, Orchestration Centre), an Agent Framework, and an AN ontology that builds a telecom-domain knowledge graph for cross-agent semantic alignment. The registry centre is fully localizable and supports interconnection, discovery and scheduling at the thousand-agent scale, keeping all interaction traffic inside the local network and shrinking the attack surface. China Mobile chairs the project; governance sits with an Adopter Advisory Committee. The stated goal is a virtuous cycle of standards guiding direction, open source accelerating deployment and practice feeding back into standards, aligned with TM Forum autonomous-network reference architecture with commercial verification targeted for 2027.
Verbatim from the Tuskira release announcement (SAN FRANCISCO, October 1, 2026): "Tuskira today released the Tuskira AI Agent Gateway, an open-source, self-hosted project for developers, platform teams and security teams. From one place, teams can configure models and tools, see supported calls, apply policy, control access, track token spend and switch models without reconfiguring their agents. The gateway runs entirely inside an organization's environment. It requires no Tuskira account or hosted service, and the organization retains control of its configuration, policies and logs." The announcement states the problem as: "Teams are adopting AI agents faster than they can manage them. Coding assistants such as Claude Code, Cursor, and Codex; AI productivity assistants such as Claude Desktop; and custom agents built in-house each connect to models and tools using their own settings. As a result, organizations often lack a consistent view of what their agents do, what they access and what they cost." Stated capabilities: "Route LLM calls through one endpoint… Control MCP tool access: Use centralized profiles to manage which MCP servers and tools each agent may use. Enforce access on every call: Each tool call is checked against the agent's profile at execution time. Ungranted calls are denied and every call is logged… Keep records local: Store actions, policy decisions and outcomes inside the organization's environment." The gateway "sits in the path between supported AI agents and the LLMs, MCP servers, and tools they use" and "evaluates supported actions before execution". Source: github.com/Tuskira/tusk-ai-secured-gateway.
A benchmark of 369 real tasks across real operating systems (Ubuntu/Windows/macOS), requiring agents to control GUIs like a human to complete open-ended computer tasks.
Shows that designing the interface through which agents interact with codebases (Agent-Computer Interface) dramatically improves autonomous bug fixing on real GitHub issues.
A benchmark of 466 questions requiring reasoning, multimodal handling, web browsing and tool use — questions simple for humans yet hard for state-of-the-art AI.
The Stanford "Smallville" experiment: 25 LLM agents with memory, reflection and planning living in a simulated town, a landmark in agent society research.
Encodes Standardized Operating Procedures into LLM agent roles, assembling a software company simulation that turns one-line requirements into working programs.