<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.4.8) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-nennemann-agent-gap-analysis-00" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="Agent Gap Analysis">Gap Analysis for Autonomous Agent Protocols</title>

    <author fullname="Christian Nennemann">
      <organization>Independent Researcher</organization>
      <address>
        <email>ietf@nennemann.de</email>
      </address>
    </author>

    <date year="2026" month="March" day="06"/>

    <area>OPS</area>
    <workgroup>NMOP</workgroup>
    

    <abstract>


<?line 53?>

<t>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.</t>



    </abstract>



  </front>

  <middle>


<?line 65?>

<section anchor="introduction"><name>Introduction</name>

<t>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.</t>

<t>This document provides three contributions:</t>

<t><list style="numbers" type="1">
  <t>A reference architecture that organizes agent
capabilities into layers (Section 3).</t>
  <t>A survey of existing IETF work relevant to autonomous
agents (Section 4).</t>
  <t>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).</t>
</list></t>

<t>The intended audience includes working group chairs,
area directors, and protocol designers evaluating where
autonomous-agent standardization efforts should focus.</t>

</section>
<section anchor="terminology"><name>Terminology</name>

<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>",
"<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP 14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.</t>

<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>

<?line -18?>

<t>The following terms are used throughout this document:</t>

<dl>
  <dt>Agent:</dt>
  <dd>
    <t>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.</t>
  </dd>
  <dt>Autonomous Agent:</dt>
  <dd>
    <t>An agent capable of executing multi-step tasks without
continuous human supervision, including making decisions
based on policy, context, and environmental state.</t>
  </dd>
  <dt>Agent Ecosystem:</dt>
  <dd>
    <t>The set of agents, their principals, the policies that
govern them, and the infrastructure services (identity,
discovery, audit) they rely on.</t>
  </dd>
  <dt>DAG (Directed Acyclic Graph):</dt>
  <dd>
    <t>A graph structure used to represent multi-step agent
execution plans where tasks have dependency ordering
but no circular dependencies.</t>
  </dd>
  <dt>HITL (Human-in-the-Loop):</dt>
  <dd>
    <t>A control pattern in which a human operator must
approve, modify, or reject an agent action before
it takes effect.</t>
  </dd>
  <dt>ECT (Execution Context Token):</dt>
  <dd>
    <t>A cryptographically signed token that carries the
execution context (task identity, delegated authority,
constraints) for an agent action.  See
<xref target="I-D.nennemann-wimse-ect"/>.</t>
  </dd>
  <dt>ACP (Agent Context Policy):</dt>
  <dd>
    <t>A policy document that specifies permitted behaviors,
resource limits, and escalation rules for an agent
within a given execution context.  See
<xref target="I-D.nennemann-agent-dag-hitl-safety"/>.</t>
  </dd>
  <dt>Behavioral Attestation:</dt>
  <dd>
    <t>A verifiable claim that an agent's runtime behavior
conforms to a declared policy or behavioral profile.</t>
  </dd>
  <dt>Cascade Failure:</dt>
  <dd>
    <t>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.</t>
  </dd>
  <dt>Consensus Protocol:</dt>
  <dd>
    <t>A protocol by which multiple agents reach agreement
on a shared decision, state, or action plan.</t>
  </dd>
  <dt>Override Signal:</dt>
  <dd>
    <t>A message from a human operator or supervisory system
that instructs an agent to halt, modify, or roll back
its current action.</t>
  </dd>
</dl>

</section>
<section anchor="reference-architecture"><name>Reference Architecture</name>

<t>The following diagram presents a layered reference
architecture for autonomous agent ecosystems.  Each layer
identifies the relevant gap areas addressed by this
analysis.</t>

<figure title="Agent Ecosystem Reference Architecture" anchor="fig-arch"><artwork type="ascii-art"><![CDATA[
+-------------------------------------------------------------+
|                    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]                          |
+-------------------------------------------------------------+
]]></artwork></figure>

<t>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).</t>

</section>
<section anchor="existing-ietf-work"><name>Existing IETF Work</name>

<t>This section briefly surveys existing IETF efforts relevant
to autonomous agent protocols.</t>

<section anchor="wimse-workload-identity-in-multi-system-environments"><name>WIMSE (Workload Identity in Multi-System Environments)</name>

<t>The WIMSE working group addresses workload identity and
Execution Context Tokens (ECTs) <xref target="I-D.nennemann-wimse-ect"/>.
ECTs provide the foundation for carrying delegated authority
and task context across agent boundaries.</t>

</section>
<section anchor="rats-remote-attestation-procedures"><name>RATS (Remote ATtestation procedureS)</name>

<t>RATS defines architectures and protocols for remote
attestation <xref target="RFC9334"/>.  Attestation evidence and
appraisal are directly applicable to verifying agent
behavioral claims.</t>

</section>
<section anchor="oauth-and-gnap"><name>OAuth and GNAP</name>

<t>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.</t>

</section>
<section anchor="scitt-supply-chain-integrity-transparency-and-trust"><name>SCITT (Supply Chain Integrity, Transparency, and Trust)</name>

<t>SCITT defines transparency services for supply chain
artifacts.  Its append-only log model is relevant to
agent audit trails and provenance tracking.</t>

</section>
<section anchor="nmop-network-management-operations"><name>NMOP (Network Management Operations)</name>

<t>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.</t>

</section>
<section anchor="industry-protocols-a2a-and-mcp"><name>Industry Protocols: A2A and MCP</name>

<t>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.</t>

</section>
</section>
<section anchor="gap-analysis"><name>Gap Analysis</name>

<t>This section identifies eleven gaps in the current
standards landscape for autonomous agent protocols.
Gaps are classified by severity:</t>

<t><list style="symbols">
  <t>CRITICAL: No existing standard addresses the problem;
failure to standardize poses immediate safety or
interoperability risks.</t>
  <t>HIGH: Partial coverage exists but is insufficient for
production autonomous agent deployments.</t>
  <t>MEDIUM: The gap affects efficiency or completeness but
does not pose immediate safety risks.</t>
</list></t>

<section anchor="gap-1"><name>Gap 1: Agent Behavioral Verification</name>

<dl>
  <dt>Severity:</dt>
  <dd>
    <t>CRITICAL</t>
  </dd>
  <dt>Category:</dt>
  <dd>
    <t>AI Safety</t>
  </dd>
  <dt>Problem Statement:</dt>
  <dd>
    <t>Autonomous agents operating in production environments
currently lack any standardized mechanism for runtime
verification of policy compliance.  While RATS
<xref target="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.</t>
  </dd>
  <dt/>
  <dd>
    <t>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.</t>
  </dd>
  <dt/>
  <dd>
    <t>The gap extends to the absence of standardized
behavioral profiles, verification evidence formats,
and appraisal procedures specific to agent conduct.</t>
  </dd>
  <dt>Impact if Unaddressed:</dt>
  <dd>
    <t>Undetected policy violations in autonomous agents
could cause safety incidents, data breaches, or
cascading failures in critical infrastructure.</t>
  </dd>
  <dt>Existing Partial Coverage:</dt>
  <dd>
    <t>RATS <xref target="RFC9334"/> covers platform attestation but not
behavioral compliance.  ACP-DAG-HITL
<xref target="I-D.nennemann-agent-dag-hitl-safety"/> defines
policies but not verification mechanisms.</t>
  </dd>
  <dt>Companion Draft:</dt>
  <dd>
    <t><xref target="I-D.nennemann-agent-behavioral-verification"/></t>
  </dd>
</dl>

</section>
<section anchor="gap-2"><name>Gap 2: Agent Failure Cascade Prevention</name>

<dl>
  <dt>Severity:</dt>
  <dd>
    <t>CRITICAL</t>
  </dd>
  <dt>Category:</dt>
  <dd>
    <t>AI Safety, Resilience</t>
  </dd>
  <dt>Problem Statement:</dt>
  <dd>
    <t>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.</t>
  </dd>
  <dt/>
  <dd>
    <t>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.</t>
  </dd>
  <dt/>
  <dd>
    <t>The absence of cascade prevention is especially
critical in network management scenarios where agent
failures could propagate to affect live network
operations.</t>
  </dd>
  <dt>Impact if Unaddressed:</dt>
  <dd>
    <t>A single agent failure could cascade through an entire
multi-agent deployment, causing widespread service
disruption with no automated containment.</t>
  </dd>
  <dt>Existing Partial Coverage:</dt>
  <dd>
    <t>ECT <xref target="I-D.nennemann-wimse-ect"/> provides execution
context but no failure containment semantics.</t>
  </dd>
  <dt>Companion Draft:</dt>
  <dd>
    <t><xref target="I-D.nennemann-agent-cascade-prevention"/></t>
  </dd>
</dl>

</section>
<section anchor="gap-3"><name>Gap 3: Multi-Agent Consensus Protocols</name>

<dl>
  <dt>Severity:</dt>
  <dd>
    <t>HIGH</t>
  </dd>
  <dt>Category:</dt>
  <dd>
    <t>A2A Protocols</t>
  </dd>
  <dt>Problem Statement:</dt>
  <dd>
    <t>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.</t>
  </dd>
  <dt/>
  <dd>
    <t>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.</t>
  </dd>
  <dt/>
  <dd>
    <t>Without a standard protocol, multi-agent coordination
relies on proprietary mechanisms that are not
interoperable across vendors or administrative domains.</t>
  </dd>
  <dt>Impact if Unaddressed:</dt>
  <dd>
    <t>Multi-vendor agent deployments cannot coordinate
decisions, limiting autonomous agents to single-vendor
silos.</t>
  </dd>
  <dt>Existing Partial Coverage:</dt>
  <dd>
    <t>No existing IETF work directly addresses multi-agent
consensus.</t>
  </dd>
  <dt>Companion Draft:</dt>
  <dd>
    <t><xref target="I-D.nennemann-agent-consensus"/></t>
  </dd>
</dl>

</section>
<section anchor="gap-4"><name>Gap 4: Real-Time Agent Rollback Mechanisms</name>

<dl>
  <dt>Severity:</dt>
  <dd>
    <t>HIGH</t>
  </dd>
  <dt>Category:</dt>
  <dd>
    <t>Resilience, Operations</t>
  </dd>
  <dt>Problem Statement:</dt>
  <dd>
    <t>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.</t>
  </dd>
  <dt/>
  <dd>
    <t>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.</t>
  </dd>
  <dt/>
  <dd>
    <t>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.</t>
  </dd>
  <dt>Impact if Unaddressed:</dt>
  <dd>
    <t>Operators cannot safely deploy autonomous agents for
critical operations without manual intervention
capability for every action.</t>
  </dd>
  <dt>Existing Partial Coverage:</dt>
  <dd>
    <t>NETCONF confirmed-commit provides rollback for
configuration changes only.</t>
  </dd>
  <dt>Companion Draft:</dt>
  <dd>
    <t><xref target="I-D.nennemann-agent-cascade-prevention"/></t>
  </dd>
</dl>

</section>
<section anchor="gap-5"><name>Gap 5: Federated Agent Learning Privacy</name>

<dl>
  <dt>Severity:</dt>
  <dd>
    <t>HIGH</t>
  </dd>
  <dt>Category:</dt>
  <dd>
    <t>Privacy, Federated Systems</t>
  </dd>
  <dt>Problem Statement:</dt>
  <dd>
    <t>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.</t>
  </dd>
  <dt/>
  <dd>
    <t>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.</t>
  </dd>
  <dt>Impact if Unaddressed:</dt>
  <dd>
    <t>Organizations will be unable to participate in
federated agent ecosystems without unacceptable
privacy risks, limiting the value of multi-domain
agent deployments.</t>
  </dd>
  <dt>Existing Partial Coverage:</dt>
  <dd>
    <t>General privacy frameworks exist but none address
agent-specific federated learning scenarios.</t>
  </dd>
  <dt>Companion Draft:</dt>
  <dd>
    <t><xref target="I-D.nennemann-agent-federation-privacy"/></t>
  </dd>
</dl>

</section>
<section anchor="gap-6"><name>Gap 6: Cross-Domain Agent Audit Trails</name>

<dl>
  <dt>Severity:</dt>
  <dd>
    <t>HIGH</t>
  </dd>
  <dt>Category:</dt>
  <dd>
    <t>Audit, Compliance</t>
  </dd>
  <dt>Problem Statement:</dt>
  <dd>
    <t>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.</t>
  </dd>
  <dt/>
  <dd>
    <t>Execution Audit Tokens <xref target="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.</t>
  </dd>
  <dt/>
  <dd>
    <t>Regulatory and compliance requirements increasingly
demand end-to-end audit trails for automated
decision-making, making this gap urgent for
enterprise deployments.</t>
  </dd>
  <dt>Impact if Unaddressed:</dt>
  <dd>
    <t>Organizations cannot demonstrate compliance for
cross-domain agent operations, blocking adoption
in regulated industries.</t>
  </dd>
  <dt>Existing Partial Coverage:</dt>
  <dd>
    <t>SCITT provides transparency log primitives.
<xref target="I-D.nennemann-exec-audit"/> defines per-action
audit tokens.</t>
  </dd>
  <dt>Companion Draft:</dt>
  <dd>
    <t><xref target="I-D.nennemann-agent-cross-domain-audit"/></t>
  </dd>
</dl>

</section>
<section anchor="gap-7"><name>Gap 7: Human Override Standardization</name>

<dl>
  <dt>Severity:</dt>
  <dd>
    <t>HIGH</t>
  </dd>
  <dt>Category:</dt>
  <dd>
    <t>AI Safety, Human Control</t>
  </dd>
  <dt>Problem Statement:</dt>
  <dd>
    <t>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.</t>
  </dd>
  <dt/>
  <dd>
    <t>Current override mechanisms are vendor-specific and
cannot be used in multi-vendor agent deployments.
ACP-DAG-HITL <xref target="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.</t>
  </dd>
  <dt/>
  <dd>
    <t>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.</t>
  </dd>
  <dt>Impact if Unaddressed:</dt>
  <dd>
    <t>Operators lose the ability to control autonomous
agents in emergency situations, creating unacceptable
safety risks.</t>
  </dd>
  <dt>Existing Partial Coverage:</dt>
  <dd>
    <t>ACP-DAG-HITL <xref target="I-D.nennemann-agent-dag-hitl-safety"/>
defines HITL policies but not override delivery.</t>
  </dd>
  <dt>Companion Draft:</dt>
  <dd>
    <t><xref target="I-D.nennemann-agent-override-protocol"/></t>
  </dd>
</dl>

</section>
<section anchor="gap-8"><name>Gap 8: Cross-Protocol Agent Migration</name>

<dl>
  <dt>Severity:</dt>
  <dd>
    <t>MEDIUM</t>
  </dd>
  <dt>Category:</dt>
  <dd>
    <t>Interoperability</t>
  </dd>
  <dt>Problem Statement:</dt>
  <dd>
    <t>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.</t>
  </dd>
  <dt/>
  <dd>
    <t>As the agent ecosystem matures, agents will
increasingly operate in heterogeneous protocol
environments.  Without migration standards, agents
are locked into specific protocol ecosystems.</t>
  </dd>
  <dt>Impact if Unaddressed:</dt>
  <dd>
    <t>Agent deployments become fragmented across protocol
silos, reducing interoperability and increasing
operational complexity.</t>
  </dd>
  <dt>Existing Partial Coverage:</dt>
  <dd>
    <t>ECT <xref target="I-D.nennemann-wimse-ect"/> provides a
protocol-neutral context token but does not define
migration procedures.</t>
  </dd>
  <dt>Companion Draft:</dt>
  <dd>
    <t><xref target="I-D.nennemann-agent-federation-privacy"/></t>
  </dd>
</dl>

</section>
<section anchor="gap-9"><name>Gap 9: Agent Resource Accounting and Billing</name>

<dl>
  <dt>Severity:</dt>
  <dd>
    <t>MEDIUM</t>
  </dd>
  <dt>Category:</dt>
  <dd>
    <t>Operations, Economics</t>
  </dd>
  <dt>Problem Statement:</dt>
  <dd>
    <t>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.</t>
  </dd>
  <dt/>
  <dd>
    <t>Resource accounting is a prerequisite for sustainable
multi-domain agent ecosystems where organizations
need to track and charge for agent resource usage.</t>
  </dd>
  <dt>Impact if Unaddressed:</dt>
  <dd>
    <t>Organizations cannot accurately track or bill for
agent resource consumption, hindering commercial
multi-domain agent deployments.</t>
  </dd>
  <dt>Existing Partial Coverage:</dt>
  <dd>
    <t>No existing IETF work addresses agent-specific
resource accounting.</t>
  </dd>
  <dt>Companion Draft:</dt>
  <dd>
    <t><xref target="I-D.nennemann-agent-cross-domain-audit"/></t>
  </dd>
</dl>

</section>
<section anchor="gap-10"><name>Gap 10: Agent Capability Negotiation</name>

<dl>
  <dt>Severity:</dt>
  <dd>
    <t>MEDIUM</t>
  </dd>
  <dt>Category:</dt>
  <dd>
    <t>A2A Protocols</t>
  </dd>
  <dt>Problem Statement:</dt>
  <dd>
    <t>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.</t>
  </dd>
  <dt/>
  <dd>
    <t>Well-known URI <xref target="RFC8615"/> and HTTP <xref target="RFC9110"/>
provide discovery primitives, but agent capability
negotiation requires richer semantics including
versioning, conditional capabilities, and policy-
constrained capability advertisement.</t>
  </dd>
  <dt>Impact if Unaddressed:</dt>
  <dd>
    <t>Agent interactions require pre-configured knowledge
of peer capabilities, limiting dynamic composition
and ad-hoc agent collaboration.</t>
  </dd>
  <dt>Existing Partial Coverage:</dt>
  <dd>
    <t>HTTP content negotiation and well-known URIs provide
basic discovery but not agent-specific capability
negotiation.</t>
  </dd>
  <dt>Companion Draft:</dt>
  <dd>
    <t><xref target="I-D.nennemann-agent-consensus"/></t>
  </dd>
</dl>

</section>
<section anchor="gap-11"><name>Gap 11: Agent Performance Benchmarking</name>

<dl>
  <dt>Severity:</dt>
  <dd>
    <t>MEDIUM</t>
  </dd>
  <dt>Category:</dt>
  <dd>
    <t>Operations, Metrics</t>
  </dd>
  <dt>Problem Statement:</dt>
  <dd>
    <t>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.</t>
  </dd>
  <dt/>
  <dd>
    <t>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.</t>
  </dd>
  <dt>Impact if Unaddressed:</dt>
  <dd>
    <t>Operators cannot objectively evaluate or compare
autonomous agent implementations, hindering
procurement and deployment decisions.</t>
  </dd>
  <dt>Existing Partial Coverage:</dt>
  <dd>
    <t>No existing IETF work addresses agent performance
benchmarking.</t>
  </dd>
  <dt>Companion Draft:</dt>
  <dd>
    <t><xref target="I-D.nennemann-agent-behavioral-verification"/></t>
  </dd>
</dl>

</section>
</section>
<section anchor="companion-draft-roadmap"><name>Companion Draft Roadmap</name>

<t>The following table maps each companion draft to the
gaps it addresses and its priority level:</t>

<texttable title="Companion Draft Roadmap" anchor="tab-roadmap">
      <ttcol align='left'>Companion Draft</ttcol>
      <ttcol align='center'>Gaps</ttcol>
      <ttcol align='center'>Priority</ttcol>
      <c>draft-nennemann-agent-behavioral-verification</c>
      <c>1, 11</c>
      <c>CRITICAL</c>
      <c>draft-nennemann-agent-cascade-prevention</c>
      <c>2, 4</c>
      <c>CRITICAL</c>
      <c>draft-nennemann-agent-consensus</c>
      <c>3, 10</c>
      <c>HIGH</c>
      <c>draft-nennemann-agent-cross-domain-audit</c>
      <c>6, 9</c>
      <c>HIGH</c>
      <c>draft-nennemann-agent-override-protocol</c>
      <c>7</c>
      <c>HIGH</c>
      <c>draft-nennemann-agent-federation-privacy</c>
      <c>5, 8</c>
      <c>HIGH</c>
</texttable>

<t>The dependency relationships between companion drafts
are shown below:</t>

<figure title="Companion Draft Dependencies" anchor="fig-deps"><artwork type="ascii-art"><![CDATA[
  behavioral-verification ---+
          |                   |
          v                   |
  cascade-prevention          |
          |                   |
          v                   v
  override-protocol    cross-domain-audit
          |                   |
          v                   v
      consensus        federation-privacy
]]></artwork></figure>

<t>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.</t>

</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<t>The gaps identified in this document have direct security
implications:</t>

<dl>
  <dt>Behavioral Verification (Gap 1):</dt>
  <dd>
    <t>Without runtime behavioral verification, compromised
or malfunctioning agents cannot be detected, creating
opportunities for attacks that exploit trusted agent
identities to perform unauthorized actions.</t>
  </dd>
  <dt>Cascade Prevention (Gap 2):</dt>
  <dd>
    <t>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.</t>
  </dd>
  <dt>Human Override (Gap 7):</dt>
  <dd>
    <t>Without standardized override protocols, safety-
critical agent actions may not be stoppable, creating
an unacceptable risk profile for autonomous
deployments.</t>
  </dd>
  <dt>Cross-Domain Audit (Gap 6):</dt>
  <dd>
    <t>Gaps in audit trails across domain boundaries create
opportunities for agents to take actions that evade
detection and accountability.</t>
  </dd>
  <dt>Federated Privacy (Gap 5):</dt>
  <dd>
    <t>Sharing agent operational data across domains without
adequate privacy controls can expose sensitive
organizational information, network topology, and
business logic.</t>
  </dd>
</dl>

<t>Implementers of autonomous agent systems <bcp14>SHOULD</bcp14> treat the
CRITICAL and HIGH severity gaps as security requirements
and prioritize their resolution.</t>

</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<t>This document has no IANA actions.</t>

</section>


  </middle>

  <back>


<references title='References' anchor="sec-combined-references">

    <references title='Normative References' anchor="sec-normative-references">



<reference anchor="RFC2119">
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname="S. Bradner" initials="S." surname="Bradner"/>
    <date month="March" year="1997"/>
    <abstract>
      <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="2119"/>
  <seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname="B. Leiba" initials="B." surname="Leiba"/>
    <date month="May" year="2017"/>
    <abstract>
      <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
    </abstract>
  </front>
  <seriesInfo name="BCP" value="14"/>
  <seriesInfo name="RFC" value="8174"/>
  <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>



    </references>

    <references title='Informative References' anchor="sec-informative-references">



<reference anchor="RFC9334">
  <front>
    <title>Remote ATtestation procedureS (RATS) Architecture</title>
    <author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
    <author fullname="D. Thaler" initials="D." surname="Thaler"/>
    <author fullname="M. Richardson" initials="M." surname="Richardson"/>
    <author fullname="N. Smith" initials="N." surname="Smith"/>
    <author fullname="W. Pan" initials="W." surname="Pan"/>
    <date month="January" year="2023"/>
    <abstract>
      <t>In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="9334"/>
  <seriesInfo name="DOI" value="10.17487/RFC9334"/>
</reference>
<reference anchor="RFC7519">
  <front>
    <title>JSON Web Token (JWT)</title>
    <author fullname="M. Jones" initials="M." surname="Jones"/>
    <author fullname="J. Bradley" initials="J." surname="Bradley"/>
    <author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
    <date month="May" year="2015"/>
    <abstract>
      <t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="7519"/>
  <seriesInfo name="DOI" value="10.17487/RFC7519"/>
</reference>
<reference anchor="RFC8615">
  <front>
    <title>Well-Known Uniform Resource Identifiers (URIs)</title>
    <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
    <date month="May" year="2019"/>
    <abstract>
      <t>This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.</t>
      <t>In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.</t>
    </abstract>
  </front>
  <seriesInfo name="RFC" value="8615"/>
  <seriesInfo name="DOI" value="10.17487/RFC8615"/>
</reference>
<reference anchor="RFC9110">
  <front>
    <title>HTTP Semantics</title>
    <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
    <author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
    <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
    <date month="June" year="2022"/>
    <abstract>
      <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
      <t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
    </abstract>
  </front>
  <seriesInfo name="STD" value="97"/>
  <seriesInfo name="RFC" value="9110"/>
  <seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference>

<reference anchor="I-D.nennemann-wimse-ect" target="https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/">
  <front>
    <title>Execution Context Tokens for Distributed Agentic Workflows</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="I-D.nennemann-agent-dag-hitl-safety" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/">
  <front>
    <title>Agent Context Policy Token: DAG Delegation with Human Override</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="I-D.nennemann-exec-audit" target="https://datatracker.ietf.org/doc/draft-nennemann-exec-audit/">
  <front>
    <title>Cross-Domain Execution Audit Tokens</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="I-D.nennemann-agent-behavioral-verification" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-behavioral-verification/">
  <front>
    <title>Agent Behavioral Verification and Performance Benchmarking</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="I-D.nennemann-agent-cascade-prevention" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-cascade-prevention/">
  <front>
    <title>Agent Failure Cascade Prevention and Rollback</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="I-D.nennemann-agent-consensus" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-consensus/">
  <front>
    <title>Multi-Agent Consensus and Capability Negotiation Protocols</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="I-D.nennemann-agent-cross-domain-audit" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-cross-domain-audit/">
  <front>
    <title>Cross-Domain Agent Audit Trails and Resource Accounting</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="I-D.nennemann-agent-override-protocol" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-override-protocol/">
  <front>
    <title>Standardized Human Override Protocol for Autonomous Agents</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="I-D.nennemann-agent-federation-privacy" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-federation-privacy/">
  <front>
    <title>Federated Agent Learning Privacy and Cross-Protocol Migration</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>


    </references>

</references>


<?line 791?>

<section anchor="acknowledgments"><name>Acknowledgments</name>

<t>The author thanks the participants of the WIMSE, RATS,
and NMOP working groups for discussions that informed
this analysis.</t>

</section>


  </back>

<!-- ##markdown-source:
[encoded data, 11529 characters]
fNv59sUHLE0Y/Xf0/83j4s17yAZZFaR8+0vo/h/lDEb/d2gAAA==

-->

</rfc>

