| Internet-Draft | Agent Gap Analysis | March 2026 |
| Nennemann | Expires 7 September 2026 | [Page] |
This document maps the IETF autonomous agent landscape, identifies eleven gap areas where standardization is absent or insufficient, and introduces six companion drafts that address the most critical gaps. Over 260 IETF drafts touch on agent communication, identity, safety, and operations, yet no single reference architecture ties them together. This gap analysis provides a structured roadmap for the standards work needed to enable safe, interoperable, and auditable autonomous agent ecosystems.¶
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
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."¶
This Internet-Draft will expire on 7 September 2026.¶
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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Autonomous software agents are increasingly deployed in network management, cloud orchestration, supply-chain logistics, and AI-driven workflows. Over 260 IETF drafts touch on aspects of agent communication, identity, safety, and operations. However, these efforts remain fragmented: no single reference architecture ties them together, and several critical capabilities lack any standardization at all.¶
This document provides three contributions:¶
A reference architecture that organizes agent capabilities into layers (Section 3).¶
A survey of existing IETF work relevant to autonomous agents (Section 4).¶
A gap analysis identifying eleven areas where new or extended standards are needed, together with a roadmap of six companion drafts that address the most critical gaps (Sections 5 and 6).¶
The intended audience includes working group chairs, area directors, and protocol designers evaluating where autonomous-agent standardization efforts should focus.¶
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following terms are used throughout this document:¶
A software component that acts on behalf of a principal (human or organizational) to perform tasks, communicate with other agents, or interact with external systems.¶
An agent capable of executing multi-step tasks without continuous human supervision, including making decisions based on policy, context, and environmental state.¶
The set of agents, their principals, the policies that govern them, and the infrastructure services (identity, discovery, audit) they rely on.¶
A graph structure used to represent multi-step agent execution plans where tasks have dependency ordering but no circular dependencies.¶
A control pattern in which a human operator must approve, modify, or reject an agent action before it takes effect.¶
A cryptographically signed token that carries the execution context (task identity, delegated authority, constraints) for an agent action. See [I-D.nennemann-wimse-ect].¶
A policy document that specifies permitted behaviors, resource limits, and escalation rules for an agent within a given execution context. See [I-D.nennemann-agent-dag-hitl-safety].¶
A verifiable claim that an agent's runtime behavior conforms to a declared policy or behavioral profile.¶
A failure mode in which an error in one agent propagates through a multi-agent workflow, causing successive agents to fail or produce incorrect results.¶
A protocol by which multiple agents reach agreement on a shared decision, state, or action plan.¶
A message from a human operator or supervisory system that instructs an agent to halt, modify, or roll back its current action.¶
The following diagram presents a layered reference architecture for autonomous agent ecosystems. Each layer identifies the relevant gap areas addressed by this analysis.¶
+-------------------------------------------------------------+ | HUMAN OPERATORS | | [Override & HITL Layer -- GAP 7] | +-------------------------------------------------------------+ | AGENT INTERACTION LAYER | | +---------+ +---------+ +---------+ +---------+ | | | Agent A |<>| Agent B |<>| Agent C |<>| Agent D | | | +----+----+ +----+----+ +----+----+ +----+----+ | | | GAP 3: | GAP 10: | GAP 1: | | | | Consensus | Cap.Neg. | Behav. | | | | | | Verif. | | +-------+------------+------------+------------+--------------+ | EXECUTION LAYER (ECT) | | DAG Execution | Checkpoints | Rollback | Circuit Breakers | | [GAP 2: Cascade Prevention] [GAP 4: Rollback] | +-------------------------------------------------------------+ | POLICY & GOVERNANCE LAYER | | ACP-DAG-HITL | Trust Scoring | Assurance Profiles | | [GAP 5: Federated Privacy] [GAP 6: Cross-Domain Audit] | +-------------------------------------------------------------+ | INFRASTRUCTURE LAYER | | Identity | Discovery | Registration | Protocol Bridges | | [GAP 8: Cross-Protocol] [GAP 9: Resource Accounting] | | [GAP 11: Performance Benchmarking] | +-------------------------------------------------------------+
The Human Operators layer provides override and human-in-the-loop controls (Gap 7). The Agent Interaction layer is where agents communicate, negotiate capabilities (Gap 10), reach consensus (Gap 3), and undergo behavioral verification (Gap 1). The Execution layer manages DAG-based workflows with cascade prevention (Gap 2) and rollback (Gap 4). The Policy and Governance layer enforces privacy in federated learning (Gap 5) and cross-domain audit trails (Gap 6). The Infrastructure layer handles identity, discovery, cross-protocol migration (Gap 8), resource accounting (Gap 9), and performance benchmarking (Gap 11).¶
This section briefly surveys existing IETF efforts relevant to autonomous agent protocols.¶
The WIMSE working group addresses workload identity and Execution Context Tokens (ECTs) [I-D.nennemann-wimse-ect]. ECTs provide the foundation for carrying delegated authority and task context across agent boundaries.¶
RATS defines architectures and protocols for remote attestation [RFC9334]. Attestation evidence and appraisal are directly applicable to verifying agent behavioral claims.¶
OAuth 2.0 and the Grant Negotiation and Authorization Protocol (GNAP) provide authorization frameworks. Transaction tokens and token exchange mechanisms are relevant to agent-to-agent delegation chains.¶
SCITT defines transparency services for supply chain artifacts. Its append-only log model is relevant to agent audit trails and provenance tracking.¶
The NMOP working group focuses on network management operations including intent-based management and autonomous network functions. Agent-driven network management is a primary use case for the gaps identified in this document.¶
The Agent-to-Agent (A2A) protocol and Model Context Protocol (MCP) are emerging industry standards for agent communication. While not IETF specifications, they inform the gap analysis by highlighting capabilities that lack standardized, interoperable definitions.¶
This section identifies eleven gaps in the current standards landscape for autonomous agent protocols. Gaps are classified by severity:¶
CRITICAL: No existing standard addresses the problem; failure to standardize poses immediate safety or interoperability risks.¶
HIGH: Partial coverage exists but is insufficient for production autonomous agent deployments.¶
MEDIUM: The gap affects efficiency or completeness but does not pose immediate safety risks.¶
CRITICAL¶
AI Safety¶
Autonomous agents operating in production environments currently lack any standardized mechanism for runtime verification of policy compliance. While RATS [RFC9334] provides attestation for platform integrity, no equivalent exists for verifying that an agent's observed behavior conforms to its declared behavioral profile or policy constraints.¶
Without behavioral verification, operators cannot distinguish between an agent that faithfully executes its policy and one that has drifted, been compromised, or is operating outside its intended parameters. This is especially dangerous in multi-agent workflows where one misbehaving agent can corrupt downstream results.¶
The gap extends to the absence of standardized behavioral profiles, verification evidence formats, and appraisal procedures specific to agent conduct.¶
Undetected policy violations in autonomous agents could cause safety incidents, data breaches, or cascading failures in critical infrastructure.¶
RATS [RFC9334] covers platform attestation but not behavioral compliance. ACP-DAG-HITL [I-D.nennemann-agent-dag-hitl-safety] defines policies but not verification mechanisms.¶
CRITICAL¶
AI Safety, Resilience¶
Multi-agent workflows create dependency chains where a failure in one agent can propagate to downstream agents, causing cascade failures. No standardized mechanism exists for circuit breakers, failure isolation, or cascade containment in agent-to-agent interactions.¶
Current practice relies on ad-hoc timeout and retry logic that is neither interoperable nor sufficient for complex DAG-structured workflows. Agents from different vendors or administrative domains have no common way to signal failure states or trigger containment procedures.¶
The absence of cascade prevention is especially critical in network management scenarios where agent failures could propagate to affect live network operations.¶
A single agent failure could cascade through an entire multi-agent deployment, causing widespread service disruption with no automated containment.¶
ECT [I-D.nennemann-wimse-ect] provides execution context but no failure containment semantics.¶
HIGH¶
A2A Protocols¶
When multiple agents must agree on a shared decision (e.g., a network configuration change, a resource allocation plan, or a coordinated response to an incident), no standardized consensus protocol exists for agent-to-agent agreement.¶
Distributed systems consensus protocols (Raft, Paxos) are designed for replicated state machines, not for heterogeneous agents with different capabilities, trust levels, and policy constraints. Agent consensus requires additional semantics such as weighted voting, capability-based participation, and policy-constrained proposals.¶
Without a standard protocol, multi-agent coordination relies on proprietary mechanisms that are not interoperable across vendors or administrative domains.¶
Multi-vendor agent deployments cannot coordinate decisions, limiting autonomous agents to single-vendor silos.¶
No existing IETF work directly addresses multi-agent consensus.¶
HIGH¶
Resilience, Operations¶
When an autonomous agent takes an action that produces unintended consequences, no standardized mechanism exists for rolling back the action and restoring the previous state. This is particularly important for network management agents that modify device configurations.¶
Rollback requires standardized checkpointing, state snapshots, and undo semantics that work across agent boundaries and administrative domains. Current rollback mechanisms (e.g., NETCONF confirmed-commit) are protocol-specific and do not generalize to arbitrary agent actions.¶
The lack of rollback is compounded in multi-agent workflows where multiple agents may have taken coordinated actions that must be reversed as a unit.¶
Operators cannot safely deploy autonomous agents for critical operations without manual intervention capability for every action.¶
NETCONF confirmed-commit provides rollback for configuration changes only.¶
HIGH¶
Privacy, Federated Systems¶
Agents that participate in federated learning or share operational data across administrative domains require privacy guarantees that go beyond transport encryption. No IETF specification addresses the privacy requirements of federated agent learning, including differential privacy parameters, data minimization for shared agent telemetry, and consent management for cross-domain data sharing.¶
As agents are deployed across organizational boundaries, the data they generate and share can reveal sensitive information about network topology, operational patterns, and business logic. Privacy- preserving mechanisms specific to agent interactions are needed.¶
Organizations will be unable to participate in federated agent ecosystems without unacceptable privacy risks, limiting the value of multi-domain agent deployments.¶
General privacy frameworks exist but none address agent-specific federated learning scenarios.¶
HIGH¶
Audit, Compliance¶
When agents operate across multiple administrative domains, their actions must be auditable end-to-end. No standardized format exists for cross-domain agent audit trails that preserves causal ordering, links related actions across domain boundaries, and provides tamper-evident logging.¶
Execution Audit Tokens [I-D.nennemann-exec-audit] provide per-action audit records, but no standard defines how these records are aggregated, correlated, and queried across domains. SCITT provides transparency log primitives but does not define agent-specific audit semantics.¶
Regulatory and compliance requirements increasingly demand end-to-end audit trails for automated decision-making, making this gap urgent for enterprise deployments.¶
Organizations cannot demonstrate compliance for cross-domain agent operations, blocking adoption in regulated industries.¶
SCITT provides transparency log primitives. [I-D.nennemann-exec-audit] defines per-action audit tokens.¶
HIGH¶
AI Safety, Human Control¶
Autonomous agents must always be subject to human override, but no cross-vendor protocol exists for sending override signals to agents. Override requirements include emergency stop, graceful pause, parameter modification, and forced rollback.¶
Current override mechanisms are vendor-specific and cannot be used in multi-vendor agent deployments. ACP-DAG-HITL [I-D.nennemann-agent-dag-hitl-safety] defines when human approval is required but does not specify the protocol for delivering override signals to running agents.¶
The absence of a standard override protocol creates a significant safety risk: if an agent misbehaves, the operator may not have a reliable way to stop it if the agent comes from a different vendor than the management platform.¶
Operators lose the ability to control autonomous agents in emergency situations, creating unacceptable safety risks.¶
ACP-DAG-HITL [I-D.nennemann-agent-dag-hitl-safety] defines HITL policies but not override delivery.¶
MEDIUM¶
Interoperability¶
Agents may need to migrate between protocol environments (e.g., from an A2A-based system to an MCP-based system) while preserving execution context, identity, and accumulated state. No standard defines how agent context is translated or preserved across protocol boundaries.¶
As the agent ecosystem matures, agents will increasingly operate in heterogeneous protocol environments. Without migration standards, agents are locked into specific protocol ecosystems.¶
Agent deployments become fragmented across protocol silos, reducing interoperability and increasing operational complexity.¶
ECT [I-D.nennemann-wimse-ect] provides a protocol-neutral context token but does not define migration procedures.¶
MEDIUM¶
Operations, Economics¶
Autonomous agents consume computational, network, and API resources across administrative domains. No standardized mechanism exists for tracking, reporting, and reconciling resource consumption by agents, especially in multi-domain scenarios where an agent's actions incur costs in domains other than its own.¶
Resource accounting is a prerequisite for sustainable multi-domain agent ecosystems where organizations need to track and charge for agent resource usage.¶
Organizations cannot accurately track or bill for agent resource consumption, hindering commercial multi-domain agent deployments.¶
No existing IETF work addresses agent-specific resource accounting.¶
MEDIUM¶
A2A Protocols¶
When agents interact, they need to discover and negotiate each other's capabilities dynamically. No standardized capability negotiation protocol exists for agents to advertise their functions, agree on interaction protocols, and establish compatible communication parameters.¶
Well-known URI [RFC8615] and HTTP [RFC9110] provide discovery primitives, but agent capability negotiation requires richer semantics including versioning, conditional capabilities, and policy- constrained capability advertisement.¶
Agent interactions require pre-configured knowledge of peer capabilities, limiting dynamic composition and ad-hoc agent collaboration.¶
HTTP content negotiation and well-known URIs provide basic discovery but not agent-specific capability negotiation.¶
MEDIUM¶
Operations, Metrics¶
No standardized metrics or benchmarking methodology exists for evaluating autonomous agent performance. Without common metrics, operators cannot compare agent implementations, set performance baselines, or detect performance degradation.¶
Agent performance encompasses multiple dimensions: task completion accuracy, latency, resource efficiency, safety compliance rate, and behavioral consistency. Standardized metrics and measurement procedures are needed for each dimension.¶
Operators cannot objectively evaluate or compare autonomous agent implementations, hindering procurement and deployment decisions.¶
No existing IETF work addresses agent performance benchmarking.¶
The following table maps each companion draft to the gaps it addresses and its priority level:¶
| Companion Draft | Gaps | Priority |
|---|---|---|
| draft-nennemann-agent-behavioral-verification | 1, 11 | CRITICAL |
| draft-nennemann-agent-cascade-prevention | 2, 4 | CRITICAL |
| draft-nennemann-agent-consensus | 3, 10 | HIGH |
| draft-nennemann-agent-cross-domain-audit | 6, 9 | HIGH |
| draft-nennemann-agent-override-protocol | 7 | HIGH |
| draft-nennemann-agent-federation-privacy | 5, 8 | HIGH |
The dependency relationships between companion drafts are shown below:¶
behavioral-verification ---+
| |
v |
cascade-prevention |
| |
v v
override-protocol cross-domain-audit
| |
v v
consensus federation-privacy
The behavioral-verification draft (Companion A) is foundational because its behavioral attestation format is used by the cascade-prevention and cross-domain-audit drafts. The cascade-prevention draft (Companion B) defines failure containment that the override-protocol (Companion E) builds upon. The consensus draft (Companion C) extends behavioral verification with multi-agent agreement. The cross-domain-audit draft (Companion D) provides the audit infrastructure that federation-privacy (Companion F) adds privacy controls to.¶
The gaps identified in this document have direct security implications:¶
Without runtime behavioral verification, compromised or malfunctioning agents cannot be detected, creating opportunities for attacks that exploit trusted agent identities to perform unauthorized actions.¶
The absence of cascade containment creates a denial- of-service vector where an attacker can compromise a single agent to disrupt an entire multi-agent workflow.¶
Without standardized override protocols, safety- critical agent actions may not be stoppable, creating an unacceptable risk profile for autonomous deployments.¶
Gaps in audit trails across domain boundaries create opportunities for agents to take actions that evade detection and accountability.¶
Sharing agent operational data across domains without adequate privacy controls can expose sensitive organizational information, network topology, and business logic.¶
Implementers of autonomous agent systems SHOULD treat the CRITICAL and HIGH severity gaps as security requirements and prioritize their resolution.¶
This document has no IANA actions.¶
The author thanks the participants of the WIMSE, RATS, and NMOP working groups for discussions that informed this analysis.¶