c/ietf-draft-analyzer
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: add draft data, gap analysis report, and workspace config
Some checks failed
CI / test (3.11) (push) Failing after 1m37s
Details
CI / test (3.12) (push) Failing after 57s
Details

Browse Source
This commit is contained in:
Christian Nennemann
2026-04-06 18:47:15 +02:00
parent 4f310407b0
commit 2506b6325a
189 changed files with 62649 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

35
workspace/drafts/gap-analysis/.refcache/reference.I-D.ietf-scitt-architecture.xml Normal file
View File

@@ -0,0 +1,35 @@
<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.ietf-scitt-architecture" target="https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-22">
<front>
<title>An Architecture for Trustworthy and Transparent Digital Supply Chains</title>
<author initials="H." surname="Birkholz" fullname="Henk Birkholz">
<organization>Fraunhofer SIT</organization>
</author>
<author initials="A." surname="Delignat-Lavaud" fullname="Antoine Delignat-Lavaud">
<organization>Microsoft Research</organization>
</author>
<author initials="C." surname="Fournet" fullname="Cedric Fournet">
<organization>Microsoft Research</organization>
</author>
<author initials="Y." surname="Deshpande" fullname="Yogesh Deshpande">
<organization>ARM</organization>
</author>
<author initials="S." surname="Lasker" fullname="Steve Lasker">
</author>
<date month="October" day="10" year="2025" />
<abstract>
<t> Traceability in supply chains is a growing security concern. While
verifiable data structures have addressed specific issues, such as
equivocation over digital certificates, they lack a universal
architecture for all supply chains. This document defines such an
architecture for single-issuer signed statement transparency. It
ensures extensibility, interoperability between different
transparency services, and compliance with various auditing
procedures and regulatory requirements.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-scitt-architecture-22" />
</reference>

23
workspace/drafts/gap-analysis/.refcache/reference.I-D.nennemann-wimse-ect.xml Normal file
View File

@@ -0,0 +1,23 @@
<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.nennemann-wimse-ect" target="https://datatracker.ietf.org/doc/html/draft-nennemann-wimse-ect-00">
<front>
<title>Execution Context Tokens for Distributed Agentic Workflows</title>
<author initials="C." surname="Nennemann" fullname="Christian Nennemann">
<organization>Independent Researcher</organization>
</author>
<date month="February" day="25" year="2026" />
<abstract>
<t> This document defines Execution Context Tokens (ECTs), a JWT-based
extension to the WIMSE architecture that records task execution
across distributed agentic workflows. Each ECT is a signed record of
a single task, linked to predecessor tasks through a directed acyclic
graph (DAG). ECTs reuse the WIMSE signing model and are transported
in a new Execution-Context HTTP header field alongside existing WIMSE
identity headers.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-nennemann-wimse-ect-00" />
</reference>

13
workspace/drafts/gap-analysis/.refcache/reference.RFC.2119.xml Normal file
View File

@@ -0,0 +1,13 @@
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/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>

14
workspace/drafts/gap-analysis/.refcache/reference.RFC.7515.xml Normal file
View File

@@ -0,0 +1,14 @@
<reference anchor="RFC7515" target="https://www.rfc-editor.org/info/rfc7515">
<front>
<title>JSON Web Signature (JWS)</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 Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7515"/>
<seriesInfo name="DOI" value="10.17487/RFC7515"/>
</reference>

14
workspace/drafts/gap-analysis/.refcache/reference.RFC.7519.xml Normal file
View File

@@ -0,0 +1,14 @@
<reference anchor="RFC7519" target="https://www.rfc-editor.org/info/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>

17
workspace/drafts/gap-analysis/.refcache/reference.RFC.8126.xml Normal file
View File

@@ -0,0 +1,17 @@
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 5226.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>

13
workspace/drafts/gap-analysis/.refcache/reference.RFC.8174.xml Normal file
View File

@@ -0,0 +1,13 @@
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/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>

13
workspace/drafts/gap-analysis/.refcache/reference.RFC.8615.xml Normal file
View File

@@ -0,0 +1,13 @@
<reference anchor="RFC8615" target="https://www.rfc-editor.org/info/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>

16
workspace/drafts/gap-analysis/.refcache/reference.RFC.9110.xml Normal file
View File

@@ -0,0 +1,16 @@
<reference anchor="RFC9110" target="https://www.rfc-editor.org/info/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>

16
workspace/drafts/gap-analysis/.refcache/reference.RFC.9334.xml Normal file
View File

@@ -0,0 +1,16 @@
<reference anchor="RFC9334" target="https://www.rfc-editor.org/info/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>

243
workspace/drafts/gap-analysis/arxiv/main.aux Normal file
View File

@@ -0,0 +1,243 @@
\relax
\providecommand\hyper@newdestlabel[2]{}
\providecommand\HyperFirstAtBeginDocument{\AtBeginDocument}
\HyperFirstAtBeginDocument{\ifx\hyper@anchor\@undefined
\global\let\oldnewlabel\newlabel
\gdef\newlabel#1#2{\newlabelxx{#1}#2}
\gdef\newlabelxx#1#2#3#4#5#6{\oldnewlabel{#1}{{#2}{#3}}}
\AtEndDocument{\ifx\hyper@anchor\@undefined
\let\newlabel\oldnewlabel
\fi}
\fi}
\global\let\hyper@last\relax
\gdef\HyperFirstAtBeginDocument#1{#1}
\providecommand\HyField@AuxAddToFields[1]{}
\providecommand\HyField@AuxAddToCoFields[2]{}
\citation{openai2023gpt4}
\citation{wang2024survey-llm-agents}
\citation{wooldridge2009multiagent}
\citation{jennings1998agent-applications}
\citation{autogen}
\citation{crewai}
\citation{a2a-protocol}
\citation{mcp-protocol}
\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction}{1}{section.1}\protected@file@percent }
\newlabel{sec:intro}{{1}{1}{Introduction}{section.1}{}}
\citation{id-wimse-ect}
\citation{rfc7519}
\citation{rfc9334}
\citation{a2a-protocol}
\@writefile{toc}{\contentsline {subsection}{\numberline {1.1}Contributions}{2}{subsection.1.1}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {1.2}Paper Organization}{2}{subsection.1.2}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {2}Background and Related Work}{2}{section.2}\protected@file@percent }
\newlabel{sec:background}{{2}{2}{Background and Related Work}{section.2}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}IETF Standards Landscape}{2}{subsection.2.1}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.1.1}WIMSE --- Workload Identity in Multi-System Environments}{2}{subsubsection.2.1.1}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.1.2}RATS --- Remote ATtestation procedureS}{2}{subsubsection.2.1.2}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.1.3}OAuth 2.0 and GNAP}{2}{subsubsection.2.1.3}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.1.4}SCITT --- Supply Chain Integrity, Transparency, and Trust}{2}{subsubsection.2.1.4}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.1.5}NMOP --- Network Management Operations}{2}{subsubsection.2.1.5}\protected@file@percent }
\citation{mcp-protocol}
\citation{autogen}
\citation{crewai}
\citation{wooldridge2009multiagent}
\citation{dorri2018mas-iot}
\citation{jennings1998agent-applications}
\citation{ongaro2014raft}
\citation{lamport1998paxos}
\citation{castro1999pbft}
\citation{mcmahan2017fedavg}
\citation{kairouz2021fedlearning-advances}
\citation{dwork2006diffprivacy}
\citation{nygard2018releaseit}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}Industry Protocols}{3}{subsection.2.2}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.1}Google A2A Protocol}{3}{subsubsection.2.2.1}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.2}Anthropic MCP}{3}{subsubsection.2.2.2}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.2.3}Multi-Agent Frameworks}{3}{subsubsection.2.2.3}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {2.3}Academic Foundations}{3}{subsection.2.3}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.3.1}Multi-Agent Systems}{3}{subsubsection.2.3.1}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.3.2}Distributed Consensus}{3}{subsubsection.2.3.2}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.3.3}Federated Learning and Privacy}{3}{subsubsection.2.3.3}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.3.4}Circuit Breakers and Fault Tolerance}{3}{subsubsection.2.3.4}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {3}Reference Architecture}{3}{section.3}\protected@file@percent }
\newlabel{sec:architecture}{{3}{3}{Reference Architecture}{section.3}{}}
\citation{a2a-protocol}
\citation{mcp-protocol}
\citation{id-wimse-ect}
\citation{id-dag-hitl-safety}
\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Agent Ecosystem Reference Architecture. Each layer identifies the gap areas addressed by this analysis.}}{4}{figure.1}\protected@file@percent }
\newlabel{fig:arch}{{1}{4}{Agent Ecosystem Reference Architecture. Each layer identifies the gap areas addressed by this analysis}{figure.1}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}Human Control Layer}{4}{subsection.3.1}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {3.2}Agent Interaction Layer}{4}{subsection.3.2}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {3.3}Execution Layer}{4}{subsection.3.3}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {3.4}Policy and Governance Layer}{4}{subsection.3.4}\protected@file@percent }
\citation{rfc9334}
\@writefile{toc}{\contentsline {subsection}{\numberline {3.5}Infrastructure Layer}{5}{subsection.3.5}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {4}Gap Analysis}{5}{section.4}\protected@file@percent }
\newlabel{sec:gaps}{{4}{5}{Gap Analysis}{section.4}{}}
\@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces Summary of Identified Gaps}}{5}{table.1}\protected@file@percent }
\newlabel{tab:gap-summary}{{1}{5}{Summary of Identified Gaps}{table.1}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {4.1}CRITICAL Gaps}{5}{subsection.4.1}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.1.1}Gap 1: Agent Behavioral Verification}{5}{subsubsection.4.1.1}\protected@file@percent }
\newlabel{sec:gap1}{{4.1.1}{5}{Gap 1: Agent Behavioral Verification}{subsubsection.4.1.1}{}}
\@writefile{toc}{\contentsline {paragraph}{Problem Statement}{5}{section*.2}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Evidence and Examples}{5}{section*.3}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Impact Assessment}{5}{section*.4}\protected@file@percent }
\citation{rfc9334}
\citation{id-dag-hitl-safety}
\citation{nygard2018releaseit}
\citation{nygard2018releaseit}
\citation{id-wimse-ect}
\citation{autogen}
\citation{ongaro2014raft}
\citation{lamport1998paxos}
\citation{castro1999pbft}
\citation{wooldridge2009multiagent}
\citation{rfc6241}
\@writefile{toc}{\contentsline {paragraph}{Existing Partial Solutions}{6}{section*.5}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.1.2}Gap 2: Agent Failure Cascade Prevention}{6}{subsubsection.4.1.2}\protected@file@percent }
\newlabel{sec:gap2}{{4.1.2}{6}{Gap 2: Agent Failure Cascade Prevention}{subsubsection.4.1.2}{}}
\@writefile{toc}{\contentsline {paragraph}{Problem Statement}{6}{section*.6}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Evidence and Examples}{6}{section*.7}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Impact Assessment}{6}{section*.8}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Existing Partial Solutions}{6}{section*.9}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {4.2}HIGH Gaps}{6}{subsection.4.2}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.2.1}Gap 3: Multi-Agent Consensus Protocols}{6}{subsubsection.4.2.1}\protected@file@percent }
\newlabel{sec:gap3}{{4.2.1}{6}{Gap 3: Multi-Agent Consensus Protocols}{subsubsection.4.2.1}{}}
\@writefile{toc}{\contentsline {paragraph}{Problem Statement}{6}{section*.10}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Evidence and Examples}{6}{section*.11}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Impact Assessment}{6}{section*.12}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Existing Partial Solutions}{6}{section*.13}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.2.2}Gap 4: Real-Time Agent Rollback Mechanisms}{6}{subsubsection.4.2.2}\protected@file@percent }
\newlabel{sec:gap4}{{4.2.2}{6}{Gap 4: Real-Time Agent Rollback Mechanisms}{subsubsection.4.2.2}{}}
\@writefile{toc}{\contentsline {paragraph}{Problem Statement}{6}{section*.14}\protected@file@percent }
\citation{rfc6241}
\citation{mcmahan2017fedavg}
\citation{dwork2006diffprivacy}
\citation{kairouz2021fedlearning-advances}
\citation{id-exec-audit}
\citation{id-exec-audit}
\@writefile{toc}{\contentsline {paragraph}{Evidence and Examples}{7}{section*.15}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Impact Assessment}{7}{section*.16}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Existing Partial Solutions}{7}{section*.17}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.2.3}Gap 5: Federated Agent Learning Privacy}{7}{subsubsection.4.2.3}\protected@file@percent }
\newlabel{sec:gap5}{{4.2.3}{7}{Gap 5: Federated Agent Learning Privacy}{subsubsection.4.2.3}{}}
\@writefile{toc}{\contentsline {paragraph}{Problem Statement}{7}{section*.18}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Evidence and Examples}{7}{section*.19}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Impact Assessment}{7}{section*.20}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Existing Partial Solutions}{7}{section*.21}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.2.4}Gap 6: Cross-Domain Agent Audit Trails}{7}{subsubsection.4.2.4}\protected@file@percent }
\newlabel{sec:gap6}{{4.2.4}{7}{Gap 6: Cross-Domain Agent Audit Trails}{subsubsection.4.2.4}{}}
\@writefile{toc}{\contentsline {paragraph}{Problem Statement}{7}{section*.22}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Evidence and Examples}{7}{section*.23}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Impact Assessment}{7}{section*.24}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Existing Partial Solutions}{7}{section*.25}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.2.5}Gap 7: Human Override Standardization}{7}{subsubsection.4.2.5}\protected@file@percent }
\newlabel{sec:gap7}{{4.2.5}{7}{Gap 7: Human Override Standardization}{subsubsection.4.2.5}{}}
\@writefile{toc}{\contentsline {paragraph}{Problem Statement}{7}{section*.26}\protected@file@percent }
\citation{id-dag-hitl-safety}
\citation{id-dag-hitl-safety}
\citation{a2a-protocol}
\citation{mcp-protocol}
\citation{id-wimse-ect}
\citation{rfc8615}
\citation{rfc9110}
\citation{a2a-protocol}
\citation{rfc9110}
\@writefile{toc}{\contentsline {paragraph}{Evidence and Examples}{8}{section*.27}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Impact Assessment}{8}{section*.28}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Existing Partial Solutions}{8}{section*.29}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {4.3}MEDIUM Gaps}{8}{subsection.4.3}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.3.1}Gap 8: Cross-Protocol Agent Migration}{8}{subsubsection.4.3.1}\protected@file@percent }
\newlabel{sec:gap8}{{4.3.1}{8}{Gap 8: Cross-Protocol Agent Migration}{subsubsection.4.3.1}{}}
\@writefile{toc}{\contentsline {paragraph}{Problem Statement}{8}{section*.30}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Impact Assessment}{8}{section*.31}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Existing Partial Solutions}{8}{section*.32}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.3.2}Gap 9: Agent Resource Accounting and Billing}{8}{subsubsection.4.3.2}\protected@file@percent }
\newlabel{sec:gap9}{{4.3.2}{8}{Gap 9: Agent Resource Accounting and Billing}{subsubsection.4.3.2}{}}
\@writefile{toc}{\contentsline {paragraph}{Problem Statement}{8}{section*.33}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Impact Assessment}{8}{section*.34}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Existing Partial Solutions}{8}{section*.35}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.3.3}Gap 10: Agent Capability Negotiation}{8}{subsubsection.4.3.3}\protected@file@percent }
\newlabel{sec:gap10}{{4.3.3}{8}{Gap 10: Agent Capability Negotiation}{subsubsection.4.3.3}{}}
\@writefile{toc}{\contentsline {paragraph}{Problem Statement}{8}{section*.36}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Impact Assessment}{8}{section*.37}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Existing Partial Solutions}{8}{section*.38}\protected@file@percent }
\citation{id-behavioral-verification}
\citation{id-cascade-prevention}
\citation{id-consensus}
\citation{id-cross-domain-audit}
\citation{id-override-protocol}
\citation{id-federation-privacy}
\citation{id-behavioral-verification}
\citation{id-cascade-prevention}
\citation{id-consensus}
\citation{ongaro2014raft}
\citation{lamport1998paxos}
\citation{id-cross-domain-audit}
\citation{id-exec-audit}
\citation{id-override-protocol}
\citation{id-federation-privacy}
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.3.4}Gap 11: Agent Performance Benchmarking}{9}{subsubsection.4.3.4}\protected@file@percent }
\newlabel{sec:gap11}{{4.3.4}{9}{Gap 11: Agent Performance Benchmarking}{subsubsection.4.3.4}{}}
\@writefile{toc}{\contentsline {paragraph}{Problem Statement}{9}{section*.39}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Impact Assessment}{9}{section*.40}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Existing Partial Solutions}{9}{section*.41}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {5}Proposed Solution Framework}{9}{section.5}\protected@file@percent }
\newlabel{sec:solutions}{{5}{9}{Proposed Solution Framework}{section.5}{}}
\@writefile{lot}{\contentsline {table}{\numberline {2}{\ignorespaces Companion Draft Roadmap}}{9}{table.2}\protected@file@percent }
\newlabel{tab:roadmap}{{2}{9}{Companion Draft Roadmap}{table.2}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {5.1}Companion A: Behavioral Verification}{9}{subsection.5.1}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {5.2}Companion B: Cascade Prevention}{9}{subsection.5.2}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {5.3}Companion C: Consensus Protocol}{9}{subsection.5.3}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {5.4}Companion D: Cross-Domain Audit}{9}{subsection.5.4}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {5.5}Companion E: Override Protocol}{9}{subsection.5.5}\protected@file@percent }
\citation{id-wimse-ect}
\citation{a2a-protocol}
\citation{mcp-protocol}
\@writefile{toc}{\contentsline {subsection}{\numberline {5.6}Companion F: Federation Privacy}{10}{subsection.5.6}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {5.7}Dependency Analysis}{10}{subsection.5.7}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {6}Discussion}{10}{section.6}\protected@file@percent }
\newlabel{sec:discussion}{{6}{10}{Discussion}{section.6}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {6.1}Cross-Cutting Themes}{10}{subsection.6.1}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Trust Propagation}{10}{section*.42}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Safety vs.\ Autonomy Trade-off}{10}{section*.43}\protected@file@percent }
\@writefile{toc}{\contentsline {paragraph}{Cross-Domain Operations}{10}{section*.44}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {6.2}Prioritization Rationale}{10}{subsection.6.2}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {6.3}Relationship to Industry Protocols}{10}{subsection.6.3}\protected@file@percent }
\bibstyle{plain}
\bibdata{references}
\bibcite{mcp-protocol}{1}
\bibcite{rfc9334}{2}
\bibcite{castro1999pbft}{3}
\bibcite{crewai}{4}
\bibcite{dorri2018mas-iot}{5}
\@writefile{toc}{\contentsline {subsection}{\numberline {6.4}Limitations}{11}{subsection.6.4}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {7}Conclusion and Future Work}{11}{section.7}\protected@file@percent }
\newlabel{sec:conclusion}{{7}{11}{Conclusion and Future Work}{section.7}{}}
\bibcite{dwork2006diffprivacy}{6}
\bibcite{rfc6241}{7}
\bibcite{rfc9110}{8}
\bibcite{a2a-protocol}{9}
\bibcite{jennings1998agent-applications}{10}
\bibcite{rfc7519}{11}
\bibcite{kairouz2021fedlearning-advances}{12}
\bibcite{lamport1998paxos}{13}
\bibcite{mcmahan2017fedavg}{14}
\bibcite{id-behavioral-verification}{15}
\bibcite{id-dag-hitl-safety}{16}
\bibcite{id-cascade-prevention}{17}
\bibcite{id-cross-domain-audit}{18}
\bibcite{id-exec-audit}{19}
\bibcite{id-wimse-ect}{20}
\bibcite{id-federation-privacy}{21}
\bibcite{id-consensus}{22}
\bibcite{id-override-protocol}{23}
\bibcite{rfc8615}{24}
\bibcite{nygard2018releaseit}{25}
\bibcite{ongaro2014raft}{26}
\bibcite{openai2023gpt4}{27}
\bibcite{wang2024survey-llm-agents}{28}
\bibcite{wooldridge2009multiagent}{29}
\bibcite{autogen}{30}
\gdef \@abspage@last{13}

161
workspace/drafts/gap-analysis/arxiv/main.bbl Normal file
View File

@@ -0,0 +1,161 @@
\begin{thebibliography}{10}
\bibitem{mcp-protocol}
{Anthropic}.
\newblock Model context protocol ({MCP}) specification, 2024.
\newblock Open protocol for LLM tool and context integration.
\bibitem{rfc9334}
Henk Birkholz, Dave Thaler, Michael Richardson, Ned Smith, and Wei Pan.
\newblock Remote {ATtestation} procedures ({RATS}) architecture.
\newblock RFC 9334, January 2023.
\bibitem{castro1999pbft}
Miguel Castro and Barbara Liskov.
\newblock Practical {Byzantine} fault tolerance.
\newblock {\em Proceedings of the Third Symposium on Operating Systems Design
and Implementation (OSDI)}, pages 173--186, 1999.
\bibitem{crewai}
{crewAI Inc.}
\newblock {CrewAI}: Framework for orchestrating role-playing autonomous {AI}
agents, 2024.
\bibitem{dorri2018mas-iot}
Ali Dorri, Salil~S. Kanhere, and Raja Jurdak.
\newblock Multi-agent systems: A survey.
\newblock {\em IEEE Access}, 6:28573--28593, 2018.
\bibitem{dwork2006diffprivacy}
Cynthia Dwork.
\newblock Differential privacy.
\newblock {\em Proceedings of the 33rd International Colloquium on Automata,
Languages and Programming (ICALP)}, pages 1--12, 2006.
\bibitem{rfc6241}
Rob Enns, Martin Bjorklund, Juergen Schoenwaelder, and Andy Bierman.
\newblock Network configuration protocol ({NETCONF}).
\newblock RFC 6241, June 2011.
\bibitem{rfc9110}
Roy Fielding, Mark Nottingham, and Julian Reschke.
\newblock {HTTP} semantics.
\newblock RFC 9110, June 2022.
\bibitem{a2a-protocol}
{Google}.
\newblock Agent-to-agent ({A2A}) protocol specification, 2025.
\newblock Open specification for agent interoperability.
\bibitem{jennings1998agent-applications}
Nicholas~R. Jennings, Katia Sycara, and Michael Wooldridge.
\newblock A roadmap of agent research and development.
\newblock In {\em Autonomous Agents and Multi-Agent Systems}, volume~1, pages
7--38, 1998.
\bibitem{rfc7519}
Michael Jones, John Bradley, and Nat Sakimura.
\newblock {JSON} web token ({JWT}).
\newblock RFC 7519, May 2015.
\bibitem{kairouz2021fedlearning-advances}
Peter Kairouz, H.~Brendan McMahan, et~al.
\newblock Advances and open problems in federated learning.
\newblock {\em Foundations and Trends in Machine Learning}, 14(1--2):1--210,
2021.
\bibitem{lamport1998paxos}
Leslie Lamport.
\newblock The part-time parliament.
\newblock {\em ACM Transactions on Computer Systems}, 16(2):133--169, 1998.
\bibitem{mcmahan2017fedavg}
Brendan McMahan, Eider Moore, Daniel Ramage, Seth Hampson, and
Blaise~Ag{\"u}era y~Arcas.
\newblock Communication-efficient learning of deep networks from decentralized
data.
\newblock {\em Proceedings of the 20th International Conference on Artificial
Intelligence and Statistics (AISTATS)}, pages 1273--1282, 2017.
\bibitem{id-behavioral-verification}
Christian Nennemann.
\newblock Agent behavioral verification and performance benchmarking.
\newblock Internet-Draft draft-nennemann-agent-behavioral-verification, 2025.
\bibitem{id-dag-hitl-safety}
Christian Nennemann.
\newblock Agent context policy token: {DAG} delegation with human override.
\newblock Internet-Draft draft-nennemann-agent-dag-hitl-safety, 2025.
\bibitem{id-cascade-prevention}
Christian Nennemann.
\newblock Agent failure cascade prevention and rollback.
\newblock Internet-Draft draft-nennemann-agent-cascade-prevention, 2025.
\bibitem{id-cross-domain-audit}
Christian Nennemann.
\newblock Cross-domain agent audit trails and resource accounting.
\newblock Internet-Draft draft-nennemann-agent-cross-domain-audit, 2025.
\bibitem{id-exec-audit}
Christian Nennemann.
\newblock Cross-domain execution audit tokens.
\newblock Internet-Draft draft-nennemann-exec-audit, 2025.
\bibitem{id-wimse-ect}
Christian Nennemann.
\newblock Execution context tokens for distributed agentic workflows.
\newblock Internet-Draft draft-nennemann-wimse-ect, 2025.
\bibitem{id-federation-privacy}
Christian Nennemann.
\newblock Federated agent learning privacy and cross-protocol migration.
\newblock Internet-Draft draft-nennemann-agent-federation-privacy, 2025.
\bibitem{id-consensus}
Christian Nennemann.
\newblock Multi-agent consensus and capability negotiation protocols.
\newblock Internet-Draft draft-nennemann-agent-consensus, 2025.
\bibitem{id-override-protocol}
Christian Nennemann.
\newblock Standardized human override protocol for autonomous agents.
\newblock Internet-Draft draft-nennemann-agent-override-protocol, 2025.
\bibitem{rfc8615}
Mark Nottingham.
\newblock Well-known uniform resource identifiers ({URIs}).
\newblock RFC 8615, May 2019.
\bibitem{nygard2018releaseit}
Michael~T. Nygard.
\newblock {\em Release It!: Design and Deploy Production-Ready Software}.
\newblock Pragmatic Bookshelf, 2nd edition, 2018.
\bibitem{ongaro2014raft}
Diego Ongaro and John Ousterhout.
\newblock In search of an understandable consensus algorithm.
\newblock {\em Proceedings of the 2014 USENIX Annual Technical Conference
(ATC)}, pages 305--319, 2014.
\bibitem{openai2023gpt4}
{OpenAI}.
\newblock {GPT-4} technical report, 2023.
\bibitem{wang2024survey-llm-agents}
Lei Wang, Chen Ma, Xueyang Feng, et~al.
\newblock A survey on large language model based autonomous agents.
\newblock In {\em Frontiers of Computer Science}, volume~18, 2024.
\bibitem{wooldridge2009multiagent}
Michael Wooldridge.
\newblock An introduction to {MultiAgent} systems.
\newblock 2009.
\bibitem{autogen}
Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu,
Li~Jiang, Xiaoyun Zhang, and Chi Wang.
\newblock {AutoGen}: Enabling next-gen {LLM} applications via multi-agent
conversation, 2023.
\end{thebibliography}

50
workspace/drafts/gap-analysis/arxiv/main.blg Normal file
View File

@@ -0,0 +1,50 @@
This is BibTeX, Version 0.99d (TeX Live 2023)
Capacity: max_strings=200000, hash_size=200000, hash_prime=170003
The top-level auxiliary file: main.aux
The style file: plain.bst
Database file #1: references.bib
Warning--can't use both volume and number fields in jennings1998agent-applications
Warning--can't use both volume and number fields in wang2024survey-llm-agents
Warning--empty journal in wooldridge2009multiagent
You've used 30 entries,
2118 wiz_defined-function locations,
635 strings with 7999 characters,
and the built_in function-call counts, 8532 in all, are:
= -- 816
> -- 392
< -- 7
+ -- 162
- -- 128
* -- 466
:= -- 1404
add.period$ -- 87
call.type$ -- 30
change.case$ -- 152
chr.to.int$ -- 0
cite$ -- 33
duplicate$ -- 299
empty$ -- 730
format.name$ -- 128
if$ -- 1821
int.to.chr$ -- 0
int.to.str$ -- 30
missing$ -- 12
newline$ -- 150
num.names$ -- 60
pop$ -- 235
preamble$ -- 1
purify$ -- 122
quote$ -- 0
skip$ -- 269
stack$ -- 0
substring$ -- 377
swap$ -- 74
text.length$ -- 7
text.prefix$ -- 0
top$ -- 0
type$ -- 118
warning$ -- 3
while$ -- 81
width$ -- 32
write$ -- 306
(There were 3 warnings)

840
workspace/drafts/gap-analysis/arxiv/main.log Normal file
View File

@@ -0,0 +1,840 @@
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023) (preloaded format=pdflatex 2026.3.6) 7 MAR 2026 07:39
entering extended mode
restricted \write18 enabled.
%&-line parsing enabled.
**main.tex
(./main.tex
LaTeX2e <2022-11-01> patch level 1
L3 programming layer <2023-02-22>
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2022/07/02 v1.4n Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size11.clo
File: size11.clo 2022/07/02 v1.4n Standard LaTeX file (size option)
)
\c@part=\count185
\c@section=\count186
\c@subsection=\count187
\c@subsubsection=\count188
\c@paragraph=\count189
\c@subparagraph=\count190
\c@figure=\count191
\c@table=\count192
\abovecaptionskip=\skip48
\belowcaptionskip=\skip49
\bibindent=\dimen140
)
(/usr/share/texlive/texmf-dist/tex/latex/geometry/geometry.sty
Package: geometry 2020/01/02 v5.9 Page Geometry
(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
Package: keyval 2022/05/29 v1.15 key=value parser (DPC)
\KV@toks@=\toks16
)
(/usr/share/texlive/texmf-dist/tex/generic/iftex/ifvtex.sty
Package: ifvtex 2019/10/25 v1.7 ifvtex legacy package. Use iftex instead.
(/usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
Package: iftex 2022/02/03 v1.0f TeX engine tests
))
\Gm@cnth=\count193
\Gm@cntv=\count194
\c@Gm@tempcnt=\count195
\Gm@bindingoffset=\dimen141
\Gm@wd@mp=\dimen142
\Gm@odd@mp=\dimen143
\Gm@even@mp=\dimen144
\Gm@layoutwidth=\dimen145
\Gm@layoutheight=\dimen146
\Gm@layouthoffset=\dimen147
\Gm@layoutvoffset=\dimen148
\Gm@dimlist=\toks17
)
(/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty
Package: inputenc 2021/02/14 v1.3d Input encoding file
\inpenc@prehook=\toks18
\inpenc@posthook=\toks19
)
(/usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
Package: fontenc 2021/04/29 v2.0v Standard LaTeX package
)
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsmath.sty
Package: amsmath 2022/04/08 v2.17n AMS math features
\@mathmargin=\skip50
For additional information on amsmath, use the `?' option.
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amstext.sty
Package: amstext 2021/08/26 v2.01 AMS text
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsgen.sty
File: amsgen.sty 1999/11/30 v2.0 generic functions
\@emptytoks=\toks20
\ex@=\dimen149
))
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty
Package: amsbsy 1999/11/29 v1.2d Bold Symbols
\pmbraise@=\dimen150
)
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty
Package: amsopn 2022/04/08 v2.04 operator names
)
\inf@bad=\count196
LaTeX Info: Redefining \frac on input line 234.
\uproot@=\count197
\leftroot@=\count198
LaTeX Info: Redefining \overline on input line 399.
LaTeX Info: Redefining \colon on input line 410.
\classnum@=\count199
\DOTSCASE@=\count266
LaTeX Info: Redefining \ldots on input line 496.
LaTeX Info: Redefining \dots on input line 499.
LaTeX Info: Redefining \cdots on input line 620.
\Mathstrutbox@=\box51
\strutbox@=\box52
LaTeX Info: Redefining \big on input line 722.
LaTeX Info: Redefining \Big on input line 723.
LaTeX Info: Redefining \bigg on input line 724.
LaTeX Info: Redefining \Bigg on input line 725.
\big@size=\dimen151
LaTeX Font Info: Redeclaring font encoding OML on input line 743.
LaTeX Font Info: Redeclaring font encoding OMS on input line 744.
\macc@depth=\count267
LaTeX Info: Redefining \bmod on input line 905.
LaTeX Info: Redefining \pmod on input line 910.
LaTeX Info: Redefining \smash on input line 940.
LaTeX Info: Redefining \relbar on input line 970.
LaTeX Info: Redefining \Relbar on input line 971.
\c@MaxMatrixCols=\count268
\dotsspace@=\muskip16
\c@parentequation=\count269
\dspbrk@lvl=\count270
\tag@help=\toks21
\row@=\count271
\column@=\count272
\maxfields@=\count273
\andhelp@=\toks22
\eqnshift@=\dimen152
\alignsep@=\dimen153
\tagshift@=\dimen154
\tagwidth@=\dimen155
\totwidth@=\dimen156
\lineht@=\dimen157
\@envbody=\toks23
\multlinegap=\skip51
\multlinetaggap=\skip52
\mathdisplay@stack=\toks24
LaTeX Info: Redefining \[ on input line 2953.
LaTeX Info: Redefining \] on input line 2954.
)
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amssymb.sty
Package: amssymb 2013/01/14 v3.01 AMS font symbols
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/amsfonts.sty
Package: amsfonts 2013/01/14 v3.01 Basic AMSFonts support
\symAMSa=\mathgroup4
\symAMSb=\mathgroup5
LaTeX Font Info: Redeclaring math symbol \hbar on input line 98.
LaTeX Font Info: Overwriting math alphabet `\mathfrak' in version `bold'
(Font) U/euf/m/n --> U/euf/b/n on input line 106.
))
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
Package: graphicx 2021/09/16 v1.2d Enhanced LaTeX Graphics (DPC,SPQR)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
Package: graphics 2022/03/10 v1.4e Standard LaTeX Graphics (DPC,SPQR)
(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
Package: trig 2021/08/11 v1.11 sin cos tan (DPC)
)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/graphics.cfg
File: graphics.cfg 2016/06/04 v1.11 sample graphics configuration
)
Package graphics Info: Driver file: pdftex.def on input line 107.
(/usr/share/texlive/texmf-dist/tex/latex/graphics-def/pdftex.def
File: pdftex.def 2022/09/22 v1.2b Graphics/color driver for pdftex
))
\Gin@req@height=\dimen158
\Gin@req@width=\dimen159
)
(/usr/share/texlive/texmf-dist/tex/latex/url/url.sty
\Urlmuskip=\muskip17
Package: url 2013/09/16 ver 3.4 Verb mode for urls, etc.
)
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
Package: hyperref 2023-02-07 v7.00v Hypertext links for LaTeX
(/usr/share/texlive/texmf-dist/tex/generic/ltxcmds/ltxcmds.sty
Package: ltxcmds 2020-05-10 v1.25 LaTeX kernel commands for general use (HO)
)
(/usr/share/texlive/texmf-dist/tex/generic/pdftexcmds/pdftexcmds.sty
Package: pdftexcmds 2020-06-27 v0.33 Utility functions of pdfTeX for LuaTeX (HO
)
(/usr/share/texlive/texmf-dist/tex/generic/infwarerr/infwarerr.sty
Package: infwarerr 2019/12/03 v1.5 Providing info/warning/error messages (HO)
)
Package pdftexcmds Info: \pdf@primitive is available.
Package pdftexcmds Info: \pdf@ifprimitive is available.
Package pdftexcmds Info: \pdfdraftmode found.
)
(/usr/share/texlive/texmf-dist/tex/latex/kvsetkeys/kvsetkeys.sty
Package: kvsetkeys 2022-10-05 v1.19 Key value parser (HO)
)
(/usr/share/texlive/texmf-dist/tex/generic/kvdefinekeys/kvdefinekeys.sty
Package: kvdefinekeys 2019-12-19 v1.6 Define keys (HO)
)
(/usr/share/texlive/texmf-dist/tex/generic/pdfescape/pdfescape.sty
Package: pdfescape 2019/12/09 v1.15 Implements pdfTeX's escape features (HO)
)
(/usr/share/texlive/texmf-dist/tex/latex/hycolor/hycolor.sty
Package: hycolor 2020-01-27 v1.10 Color options for hyperref/bookmark (HO)
)
(/usr/share/texlive/texmf-dist/tex/latex/letltxmacro/letltxmacro.sty
Package: letltxmacro 2019/12/03 v1.6 Let assignment for LaTeX macros (HO)
)
(/usr/share/texlive/texmf-dist/tex/latex/auxhook/auxhook.sty
Package: auxhook 2019-12-17 v1.6 Hooks for auxiliary files (HO)
)
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
Package: nameref 2022-05-17 v2.50 Cross-referencing by name of section
(/usr/share/texlive/texmf-dist/tex/latex/refcount/refcount.sty
Package: refcount 2019/12/15 v3.6 Data extraction from label references (HO)
)
(/usr/share/texlive/texmf-dist/tex/generic/gettitlestring/gettitlestring.sty
Package: gettitlestring 2019/12/15 v1.6 Cleanup title references (HO)
(/usr/share/texlive/texmf-dist/tex/latex/kvoptions/kvoptions.sty
Package: kvoptions 2022-06-15 v3.15 Key value format for package options (HO)
))
\c@section@level=\count274
)
\@linkdim=\dimen160
\Hy@linkcounter=\count275
\Hy@pagecounter=\count276
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def
File: pd1enc.def 2023-02-07 v7.00v Hyperref: PDFDocEncoding definition (HO)
Now handling font encoding PD1 ...
... no UTF-8 mapping file for font encoding PD1
)
(/usr/share/texlive/texmf-dist/tex/generic/intcalc/intcalc.sty
Package: intcalc 2019/12/15 v1.3 Expandable calculations with integers (HO)
)
(/usr/share/texlive/texmf-dist/tex/generic/etexcmds/etexcmds.sty
Package: etexcmds 2019/12/15 v1.7 Avoid name clashes with e-TeX commands (HO)
)
\Hy@SavedSpaceFactor=\count277
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/puenc.def
File: puenc.def 2023-02-07 v7.00v Hyperref: PDF Unicode definition (HO)
Now handling font encoding PU ...
... no UTF-8 mapping file for font encoding PU
)
Package hyperref Info: Hyper figures OFF on input line 4177.
Package hyperref Info: Link nesting OFF on input line 4182.
Package hyperref Info: Hyper index ON on input line 4185.
Package hyperref Info: Plain pages OFF on input line 4192.
Package hyperref Info: Backreferencing OFF on input line 4197.
Package hyperref Info: Implicit mode ON; LaTeX internals redefined.
Package hyperref Info: Bookmarks ON on input line 4425.
\c@Hy@tempcnt=\count278
LaTeX Info: Redefining \url on input line 4763.
\XeTeXLinkMargin=\dimen161
(/usr/share/texlive/texmf-dist/tex/generic/bitset/bitset.sty
Package: bitset 2019/12/09 v1.3 Handle bit-vector datatype (HO)
(/usr/share/texlive/texmf-dist/tex/generic/bigintcalc/bigintcalc.sty
Package: bigintcalc 2019/12/15 v1.5 Expandable calculations on big integers (HO
)
))
\Fld@menulength=\count279
\Field@Width=\dimen162
\Fld@charsize=\dimen163
Package hyperref Info: Hyper figures OFF on input line 6042.
Package hyperref Info: Link nesting OFF on input line 6047.
Package hyperref Info: Hyper index ON on input line 6050.
Package hyperref Info: backreferencing OFF on input line 6057.
Package hyperref Info: Link coloring OFF on input line 6062.
Package hyperref Info: Link coloring with OCG OFF on input line 6067.
Package hyperref Info: PDF/A mode OFF on input line 6072.
(/usr/share/texlive/texmf-dist/tex/latex/base/atbegshi-ltx.sty
Package: atbegshi-ltx 2021/01/10 v1.0c Emulation of the original atbegshi
package with kernel methods
)
\Hy@abspage=\count280
\c@Item=\count281
\c@Hfootnote=\count282
)
Package hyperref Info: Driver (autodetected): hpdftex.
(/usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def
File: hpdftex.def 2023-02-07 v7.00v Hyperref driver for pdfTeX
(/usr/share/texlive/texmf-dist/tex/latex/base/atveryend-ltx.sty
Package: atveryend-ltx 2020/08/19 v1.0a Emulation of the original atveryend pac
kage
with kernel methods
)
\Fld@listcount=\count283
\c@bookmark@seq@number=\count284
(/usr/share/texlive/texmf-dist/tex/latex/rerunfilecheck/rerunfilecheck.sty
Package: rerunfilecheck 2022-07-10 v1.10 Rerun checks for auxiliary files (HO)
(/usr/share/texlive/texmf-dist/tex/generic/uniquecounter/uniquecounter.sty
Package: uniquecounter 2019/12/15 v1.4 Provide unlimited unique counter (HO)
)
Package uniquecounter Info: New unique counter `rerunfilecheck' on input line 2
85.
)
\Hy@SectionHShift=\skip53
)
(/usr/share/texlive/texmf-dist/tex/latex/booktabs/booktabs.sty
Package: booktabs 2020/01/12 v1.61803398 Publication quality tables
\heavyrulewidth=\dimen164
\lightrulewidth=\dimen165
\cmidrulewidth=\dimen166
\belowrulesep=\dimen167
\belowbottomsep=\dimen168
\aboverulesep=\dimen169
\abovetopsep=\dimen170
\cmidrulesep=\dimen171
\cmidrulekern=\dimen172
\defaultaddspace=\dimen173
\@cmidla=\count285
\@cmidlb=\count286
\@aboverulesep=\dimen174
\@belowrulesep=\dimen175
\@thisruleclass=\count287
\@lastruleclass=\count288
\@thisrulewidth=\dimen176
)
(/usr/share/texlive/texmf-dist/tex/latex/xcolor/xcolor.sty
Package: xcolor 2022/06/12 v2.14 LaTeX color extensions (UK)
(/usr/share/texlive/texmf-dist/tex/latex/graphics-cfg/color.cfg
File: color.cfg 2016/01/02 v1.6 sample color configuration
)
Package xcolor Info: Driver file: pdftex.def on input line 227.
(/usr/share/texlive/texmf-dist/tex/latex/graphics/mathcolor.ltx)
Package xcolor Info: Model `cmy' substituted by `cmy0' on input line 1353.
Package xcolor Info: Model `hsb' substituted by `rgb' on input line 1357.
Package xcolor Info: Model `RGB' extended on input line 1369.
Package xcolor Info: Model `HTML' substituted by `rgb' on input line 1371.
Package xcolor Info: Model `Hsb' substituted by `hsb' on input line 1372.
Package xcolor Info: Model `tHsb' substituted by `hsb' on input line 1373.
Package xcolor Info: Model `HSB' substituted by `hsb' on input line 1374.
Package xcolor Info: Model `Gray' substituted by `gray' on input line 1375.
Package xcolor Info: Model `wave' substituted by `hsb' on input line 1376.
)
(/usr/share/texlive/texmf-dist/tex/latex/tools/array.sty
Package: array 2022/09/04 v2.5g Tabular extension package (FMi)
\col@sep=\dimen177
\ar@mcellbox=\box53
\extrarowheight=\dimen178
\NC@list=\toks25
\extratabsurround=\skip54
\backup@length=\skip55
\ar@cellbox=\box54
)
Package hyperref Info: Option `colorlinks' set `true' on input line 23.
(/usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
File: l3backend-pdftex.def 2023-01-16 L3 backend support: PDF output (pdfTeX)
\l__color_backend_stack_int=\count289
\l__pdf_internal_box=\box55
)
(./main.aux)
\openout1 = `main.aux'.
LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 25.
LaTeX Font Info: ... okay on input line 25.
LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 25.
LaTeX Font Info: ... okay on input line 25.
LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 25.
LaTeX Font Info: ... okay on input line 25.
LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 25.
LaTeX Font Info: ... okay on input line 25.
LaTeX Font Info: Checking defaults for TS1/cmr/m/n on input line 25.
LaTeX Font Info: ... okay on input line 25.
LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 25.
LaTeX Font Info: ... okay on input line 25.
LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 25.
LaTeX Font Info: ... okay on input line 25.
LaTeX Font Info: Checking defaults for PD1/pdf/m/n on input line 25.
LaTeX Font Info: ... okay on input line 25.
LaTeX Font Info: Checking defaults for PU/pdf/m/n on input line 25.
LaTeX Font Info: ... okay on input line 25.
*geometry* driver: auto-detecting
*geometry* detected driver: pdftex
*geometry* verbose mode - [ preamble ] result:
* driver: pdftex
* paper: <default>
* layout: <same size as paper>
* layoutoffset:(h,v)=(0.0pt,0.0pt)
* modes:
* h-part:(L,W,R)=(54.2025pt, 505.89pt, 54.2025pt)
* v-part:(T,H,B)=(54.2025pt, 686.56499pt, 54.2025pt)
* \paperwidth=614.295pt
* \paperheight=794.96999pt
* \textwidth=505.89pt
* \textheight=686.56499pt
* \oddsidemargin=-18.06749pt
* \evensidemargin=-18.06749pt
* \topmargin=-55.06749pt
* \headheight=12.0pt
* \headsep=25.0pt
* \topskip=11.0pt
* \footskip=30.0pt
* \marginparwidth=4.0pt
* \marginparsep=10.0pt
* \columnsep=10.0pt
* \skip\footins=10.0pt plus 4.0pt minus 2.0pt
* \hoffset=0.0pt
* \voffset=0.0pt
* \mag=1000
* \@twocolumntrue
* \@twosidefalse
* \@mparswitchfalse
* \@reversemarginfalse
* (1in=72.27pt=25.4mm, 1cm=28.453pt)
(/usr/share/texlive/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
\scratchcounter=\count290
\scratchdimen=\dimen179
\scratchbox=\box56
\nofMPsegments=\count291
\nofMParguments=\count292
\everyMPshowfont=\toks26
\MPscratchCnt=\count293
\MPscratchDim=\dimen180
\MPnumerator=\count294
\makeMPintoPDFobject=\count295
\everyMPtoPDFconversion=\toks27
) (/usr/share/texlive/texmf-dist/tex/latex/epstopdf-pkg/epstopdf-base.sty
Package: epstopdf-base 2020-01-24 v2.11 Base part for package epstopdf
Package epstopdf-base Info: Redefining graphics rule for `.eps' on input line 4
85.
(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv
e
))
Package hyperref Info: Link coloring ON on input line 25.
(./main.out) (./main.out)
\@outlinefile=\write3
\openout3 = `main.out'.
LaTeX Font Info: Trying to load font information for U+msa on input line 36.
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/umsa.fd
File: umsa.fd 2013/01/14 v3.01 AMS symbols A
)
LaTeX Font Info: Trying to load font information for U+msb on input line 36.
(/usr/share/texlive/texmf-dist/tex/latex/amsfonts/umsb.fd
File: umsb.fd 2013/01/14 v3.01 AMS symbols B
)
LaTeX Font Info: Trying to load font information for T1+cmtt on input line 3
6.
(/usr/share/texlive/texmf-dist/tex/latex/base/t1cmtt.fd
File: t1cmtt.fd 2022/07/10 v2.5l Standard LaTeX font definitions
)
Underfull \vbox (badness 10000) has occurred while \output is active []
Underfull \hbox (badness 1292) in paragraph at lines 77--78
\T1/cmr/m/n/10.95 in-clud-ing WIMSE (Work-load Iden-tity in Multi-
[]
Underfull \vbox (badness 10000) has occurred while \output is active []
[1{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}{/usr/share/texlive/texmf
-dist/fonts/enc/dvips/cm-super/cm-super-t1.enc}
]
Underfull \hbox (badness 4416) in paragraph at lines 101--101
[]\T1/cmr/bx/n/10.95 WIMSE --- Work-load Iden-tity in
[]
Underfull \hbox (badness 4454) in paragraph at lines 111--112
\T1/cmr/m/n/10.95 Grant Ne-go-ti-a-tion and Au-tho-riza-tion Pro-to-col
[]
Underfull \hbox (badness 1796) in paragraph at lines 113--113
[]\T1/cmr/bx/n/10.95 SCITT --- Sup-ply Chain In-tegrity,
[]
Underfull \hbox (badness 3058) in paragraph at lines 115--116
\T1/cmr/m/n/10.95 SCITT de-fines trans-parency ser-vices based on
[]
[2]
Overfull \hbox (72.22682pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 +-----------------------------------------------------------+
[]
[]
Overfull \hbox (77.47554pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | HUMAN OPERATORS
|[]
[]
Overfull \hbox (77.47554pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | [Override & HITL Layer -- GAP 7]
|[]
[]
Overfull \hbox (72.22682pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 +-----------------------------------------------------------+
[]
[]
Overfull \hbox (77.47554pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | AGENT INTERACTION LAYER
|[]
[]
Overfull \hbox (72.22682pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | +--------+ +--------+ +--------+ +--------+ |
[]
[]
Overfull \hbox (77.47554pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | |Agent A |<>|Agent B |<>|Agent C |<>|Agent D |
|[]
[]
Overfull \hbox (72.22682pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | +---+----+ +---+----+ +---+----+ +---+----+ |
[]
[]
Overfull \hbox (72.22682pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | | GAP 3: | GAP 10: | GAP 1: | |
[]
[]
Overfull \hbox (77.47554pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | | Consens. | Cap.Neg. | Behav.V. |
|[]
[]
Overfull \hbox (72.22682pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 +------+----------+----------+----------+-------------------+
[]
[]
Overfull \hbox (77.47554pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | EXECUTION LAYER (ECT)
|[]
[]
Overfull \hbox (77.47554pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | DAG Execution | Checkpoints | Rollback | Circuit Breakers
|[]
[]
Overfull \hbox (72.22682pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | [GAP 2: Cascade Prevention] [GAP 4: Rollback] |
[]
[]
Overfull \hbox (72.22682pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 +-----------------------------------------------------------+
[]
[]
Overfull \hbox (77.47554pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | POLICY & GOVERNANCE LAYER
|[]
[]
Overfull \hbox (72.22682pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | ACP-DAG-HITL | Trust Scoring | Assurance Profiles |
[]
[]
Overfull \hbox (72.22682pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | [GAP 5: Federated Privacy] [GAP 6: Cross-Domain Audit] |
[]
[]
Overfull \hbox (72.22682pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 +-----------------------------------------------------------+
[]
[]
Overfull \hbox (77.47554pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | INFRASTRUCTURE LAYER
|[]
[]
Overfull \hbox (72.22682pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | Identity | Discovery | Registration | Protocol Bridges |
[]
[]
Overfull \hbox (72.22682pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | [GAP 8: Cross-Protocol] [GAP 9: Resource Accounting] |
[]
[]
Overfull \hbox (77.47554pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 | [GAP 11: Performance Benchmarking]
|[]
[]
Overfull \hbox (72.22682pt too wide) in paragraph at lines 187--187
[]\T1/cmtt/m/n/10 +-----------------------------------------------------------+
[]
[]
Underfull \hbox (badness 4660) in paragraph at lines 194--195
\T1/cmr/m/n/10.95 The top-most layer pro-vides human-in-the-loop
[]
[3]
Underfull \hbox (badness 3138) in paragraph at lines 210--211
\T1/cmr/m/n/10.95 The Ex-e-cu-tion Layer man-ages DAG-structured
[]
Underfull \hbox (badness 4378) in paragraph at lines 210--211
\T1/cmr/m/n/10.95 agent work-flows. Ex-e-cu-tion Con-text To-kens
[]
[4{/usr/share/texlive/texmf-dist/fonts/enc/dvips/cm-super/cm-super-ts1.enc}]
Underfull \hbox (badness 1552) in paragraph at lines 232--233
[]\T1/cmr/bx/n/10.95 Gap 9 (Re-source Ac-count-ing): \T1/cmr/m/n/10.95 Track-
[]
Underfull \hbox (badness 2134) in paragraph at lines 233--234
[]\T1/cmr/bx/n/10.95 Gap 11 (Per-for-mance Bench-mark-ing):
[]
Overfull \hbox (54.56638pt too wide) in paragraph at lines 255--274
[][]
[]
[5] [6]
Underfull \hbox (badness 10000) in paragraph at lines 348--349
[]\T1/cmr/bx/n/10.95 Existing Par-tial So-lu-tions[] \T1/cmr/m/n/10.95 NET-CON
F
[]
Underfull \hbox (badness 4686) in paragraph at lines 348--349
\T1/cmr/m/n/10.95 confirmed-commit pro-vides roll-back for con-fig-
[]
Underfull \hbox (badness 2189) in paragraph at lines 348--349
\T1/cmr/m/n/10.95 well-known in dis-tributed sys-tems but lacks a
[]
Underfull \hbox (badness 4608) in paragraph at lines 365--366
[]\T1/cmr/bx/n/10.95 Existing Par-tial So-lu-tions[] \T1/cmr/m/n/10.95 Gen-era
l pri-vacy
[]
Underfull \hbox (badness 1221) in paragraph at lines 376--377
\T1/cmr/m/n/10.95 kens [[]] pro-vide per-action au-dit records, and
[]
Underfull \hbox (badness 10000) in paragraph at lines 381--382
[]\T1/cmr/bx/n/10.95 Impact As-sess-ment[] \T1/cmr/m/n/10.95 Or-ga-ni-za-tions
can-not
[]
Underfull \hbox (badness 2608) in paragraph at lines 381--382
\T1/cmr/m/n/10.95 demon-strate com-pli-ance for cross-domain agent
[]
Underfull \hbox (badness 3713) in paragraph at lines 384--385
[]\T1/cmr/bx/n/10.95 Existing Par-tial So-lu-tions[] \T1/cmr/m/n/10.95 SCITT p
ro-vides
[]
[7]
Underfull \hbox (badness 10000) in paragraph at lines 403--404
[]\T1/cmr/bx/n/10.95 Existing Par-tial So-lu-tions[] \T1/cmr/m/n/10.95 ACP-DAG
-
[]
Underfull \hbox (badness 1132) in paragraph at lines 426--427
[]\T1/cmr/bx/n/10.95 Problem State-ment[] \T1/cmr/m/n/10.95 Au-tonomous agents
con-
[]
[8]
Underfull \hbox (badness 2285) in paragraph at lines 459--460
[]\T1/cmr/bx/n/10.95 Impact As-sess-ment[] \T1/cmr/m/n/10.95 Op-er-a-tors can-
not ob-jec-
[]
Underfull \hbox (badness 1264) in paragraph at lines 462--463
\T1/cmr/m/n/10.95 ML model eval-u-a-tion bench-marks ex-ist but do
[]
[9] [10]
Underfull \hbox (badness 1377) in paragraph at lines 577--578
\T1/cmr/m/n/10.95 behavioral ver-i-fi-ca-tion and cas-cade prevention---
[]
Underfull \hbox (badness 1596) in paragraph at lines 579--580
\T1/cmr/m/n/10.95 oped to ad-dress the most press-ing gaps, with
[]
Underfull \hbox (badness 3482) in paragraph at lines 579--580
\T1/cmr/m/n/10.95 a dependency-ordered im-ple-men-ta-tion roadmap.
[]
Underfull \hbox (badness 1418) in paragraph at lines 587--588
[]\T1/cmr/bx/n/10.95 Performance Eval-u-a-tion: \T1/cmr/m/n/10.95 Mea-sur-ing t
he
[]
Underfull \hbox (badness 2961) in paragraph at lines 588--589
\T1/cmr/m/n/10.95 anal-y-sis to rel-e-vant IETF work-ing groups
[]
(./main.bbl [11]
Underfull \hbox (badness 2080) in paragraph at lines 30--34
\T1/cmr/m/it/10.95 on Au-tomata, Lan-guages and Pro-gram-ming
[]
Underfull \hbox (badness 3635) in paragraph at lines 51--55
[]\T1/cmr/m/n/10.95 Nicholas R. Jen-nings, Ka-tia Sycara, and
[]
Underfull \hbox (badness 10000) in paragraph at lines 57--60
[]\T1/cmr/m/n/10.95 Michael Jones, John Bradley, and Nat
[]
Underfull \hbox (badness 5147) in paragraph at lines 68--71
\T1/cmr/m/it/10.95 ACM Trans-ac-tions on Com-puter Sys-tems\T1/cmr/m/n/10.95 ,
[]
Underfull \hbox (badness 4403) in paragraph at lines 81--84
[]\T1/cmr/m/n/10.95 Christian Nen-ne-mann. Agent be-hav-ioral
[]
Underfull \hbox (badness 10000) in paragraph at lines 81--84
\T1/cmr/m/n/10.95 ver-i-fi-ca-tion and per-for-mance bench-mark-
[]
Underfull \hbox (badness 1521) in paragraph at lines 81--84
\T1/cmr/m/n/10.95 ing. Internet-Draft draft-nennemann-agent-
[]
Underfull \hbox (badness 10000) in paragraph at lines 96--99
\T1/cmr/m/n/10.95 Draft draft-nennemann-agent-cross-domain-
[]
Underfull \hbox (badness 6978) in paragraph at lines 111--114
[]\T1/cmr/m/n/10.95 Christian Nen-ne-mann. Fed-er-ated agent
[]
Underfull \hbox (badness 3735) in paragraph at lines 111--114
\T1/cmr/m/n/10.95 learn-ing pri-vacy and cross-protocol mi-gra-
[]
Underfull \hbox (badness 4403) in paragraph at lines 121--124
[]\T1/cmr/m/n/10.95 Christian Nen-ne-mann. Stan-dard-ized hu-
[]
[12]) [13
] (./main.aux)
Package rerunfilecheck Info: File `main.out' has not changed.
(rerunfilecheck) Checksum: 0DC0B998212202D24540FE5609D8F21A;10916.
)
Here is how much of TeX's memory you used:
11000 strings out of 477985
167933 string characters out of 5839381
1873388 words of memory out of 6000000
30890 multiletter control sequences out of 15000+600000
528777 words of font info for 77 fonts, out of 8000000 for 9000
14 hyphenation exceptions out of 8191
75i,11n,76p,816b,551s stack positions out of 10000i,1000n,20000p,200000b,200000s
</usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb></us
r/share/texlive/texmf-dist/fonts/type1/public/cm-super/sfbx1000.pfb></usr/share
/texlive/texmf-dist/fonts/type1/public/cm-super/sfbx1095.pfb></usr/share/texliv
e/texmf-dist/fonts/type1/public/cm-super/sfbx1200.pfb></usr/share/texlive/texmf
-dist/fonts/type1/public/cm-super/sfbx1440.pfb></usr/share/texlive/texmf-dist/f
onts/type1/public/cm-super/sfrm1000.pfb></usr/share/texlive/texmf-dist/fonts/ty
pe1/public/cm-super/sfrm1095.pfb></usr/share/texlive/texmf-dist/fonts/type1/pub
lic/cm-super/sfrm1200.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/cm-
super/sfrm1728.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/cm-super/s
fti1095.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/cm-super/sftt1000
.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/cm-super/sftt1200.pfb>
Output written on main.pdf (13 pages, 325182 bytes).
PDF statistics:
556 PDF objects out of 1000 (max. 8388607)
510 compressed objects within 6 object streams
156 named destinations out of 1000 (max. 500000)
433 words of extra memory for PDF output out of 10000 (max. 10000000)

54
workspace/drafts/gap-analysis/arxiv/main.out Normal file
View File

@@ -0,0 +1,54 @@
\BOOKMARK [1][-]{section.1}{\376\377\000I\000n\000t\000r\000o\000d\000u\000c\000t\000i\000o\000n}{}% 1
\BOOKMARK [2][-]{subsection.1.1}{\376\377\000C\000o\000n\000t\000r\000i\000b\000u\000t\000i\000o\000n\000s}{section.1}% 2
\BOOKMARK [2][-]{subsection.1.2}{\376\377\000P\000a\000p\000e\000r\000\040\000O\000r\000g\000a\000n\000i\000z\000a\000t\000i\000o\000n}{section.1}% 3
\BOOKMARK [1][-]{section.2}{\376\377\000B\000a\000c\000k\000g\000r\000o\000u\000n\000d\000\040\000a\000n\000d\000\040\000R\000e\000l\000a\000t\000e\000d\000\040\000W\000o\000r\000k}{}% 4
\BOOKMARK [2][-]{subsection.2.1}{\376\377\000I\000E\000T\000F\000\040\000S\000t\000a\000n\000d\000a\000r\000d\000s\000\040\000L\000a\000n\000d\000s\000c\000a\000p\000e}{section.2}% 5
\BOOKMARK [3][-]{subsubsection.2.1.1}{\376\377\000W\000I\000M\000S\000E\000\040\040\024\000\040\000W\000o\000r\000k\000l\000o\000a\000d\000\040\000I\000d\000e\000n\000t\000i\000t\000y\000\040\000i\000n\000\040\000M\000u\000l\000t\000i\000-\000S\000y\000s\000t\000e\000m\000\040\000E\000n\000v\000i\000r\000o\000n\000m\000e\000n\000t\000s}{subsection.2.1}% 6
\BOOKMARK [3][-]{subsubsection.2.1.2}{\376\377\000R\000A\000T\000S\000\040\040\024\000\040\000R\000e\000m\000o\000t\000e\000\040\000A\000T\000t\000e\000s\000t\000a\000t\000i\000o\000n\000\040\000p\000r\000o\000c\000e\000d\000u\000r\000e\000S}{subsection.2.1}% 7
\BOOKMARK [3][-]{subsubsection.2.1.3}{\376\377\000O\000A\000u\000t\000h\000\040\0002\000.\0000\000\040\000a\000n\000d\000\040\000G\000N\000A\000P}{subsection.2.1}% 8
\BOOKMARK [3][-]{subsubsection.2.1.4}{\376\377\000S\000C\000I\000T\000T\000\040\040\024\000\040\000S\000u\000p\000p\000l\000y\000\040\000C\000h\000a\000i\000n\000\040\000I\000n\000t\000e\000g\000r\000i\000t\000y\000,\000\040\000T\000r\000a\000n\000s\000p\000a\000r\000e\000n\000c\000y\000,\000\040\000a\000n\000d\000\040\000T\000r\000u\000s\000t}{subsection.2.1}% 9
\BOOKMARK [3][-]{subsubsection.2.1.5}{\376\377\000N\000M\000O\000P\000\040\040\024\000\040\000N\000e\000t\000w\000o\000r\000k\000\040\000M\000a\000n\000a\000g\000e\000m\000e\000n\000t\000\040\000O\000p\000e\000r\000a\000t\000i\000o\000n\000s}{subsection.2.1}% 10
\BOOKMARK [2][-]{subsection.2.2}{\376\377\000I\000n\000d\000u\000s\000t\000r\000y\000\040\000P\000r\000o\000t\000o\000c\000o\000l\000s}{section.2}% 11
\BOOKMARK [3][-]{subsubsection.2.2.1}{\376\377\000G\000o\000o\000g\000l\000e\000\040\000A\0002\000A\000\040\000P\000r\000o\000t\000o\000c\000o\000l}{subsection.2.2}% 12
\BOOKMARK [3][-]{subsubsection.2.2.2}{\376\377\000A\000n\000t\000h\000r\000o\000p\000i\000c\000\040\000M\000C\000P}{subsection.2.2}% 13
\BOOKMARK [3][-]{subsubsection.2.2.3}{\376\377\000M\000u\000l\000t\000i\000-\000A\000g\000e\000n\000t\000\040\000F\000r\000a\000m\000e\000w\000o\000r\000k\000s}{subsection.2.2}% 14
\BOOKMARK [2][-]{subsection.2.3}{\376\377\000A\000c\000a\000d\000e\000m\000i\000c\000\040\000F\000o\000u\000n\000d\000a\000t\000i\000o\000n\000s}{section.2}% 15
\BOOKMARK [3][-]{subsubsection.2.3.1}{\376\377\000M\000u\000l\000t\000i\000-\000A\000g\000e\000n\000t\000\040\000S\000y\000s\000t\000e\000m\000s}{subsection.2.3}% 16
\BOOKMARK [3][-]{subsubsection.2.3.2}{\376\377\000D\000i\000s\000t\000r\000i\000b\000u\000t\000e\000d\000\040\000C\000o\000n\000s\000e\000n\000s\000u\000s}{subsection.2.3}% 17
\BOOKMARK [3][-]{subsubsection.2.3.3}{\376\377\000F\000e\000d\000e\000r\000a\000t\000e\000d\000\040\000L\000e\000a\000r\000n\000i\000n\000g\000\040\000a\000n\000d\000\040\000P\000r\000i\000v\000a\000c\000y}{subsection.2.3}% 18
\BOOKMARK [3][-]{subsubsection.2.3.4}{\376\377\000C\000i\000r\000c\000u\000i\000t\000\040\000B\000r\000e\000a\000k\000e\000r\000s\000\040\000a\000n\000d\000\040\000F\000a\000u\000l\000t\000\040\000T\000o\000l\000e\000r\000a\000n\000c\000e}{subsection.2.3}% 19
\BOOKMARK [1][-]{section.3}{\376\377\000R\000e\000f\000e\000r\000e\000n\000c\000e\000\040\000A\000r\000c\000h\000i\000t\000e\000c\000t\000u\000r\000e}{}% 20
\BOOKMARK [2][-]{subsection.3.1}{\376\377\000H\000u\000m\000a\000n\000\040\000C\000o\000n\000t\000r\000o\000l\000\040\000L\000a\000y\000e\000r}{section.3}% 21
\BOOKMARK [2][-]{subsection.3.2}{\376\377\000A\000g\000e\000n\000t\000\040\000I\000n\000t\000e\000r\000a\000c\000t\000i\000o\000n\000\040\000L\000a\000y\000e\000r}{section.3}% 22
\BOOKMARK [2][-]{subsection.3.3}{\376\377\000E\000x\000e\000c\000u\000t\000i\000o\000n\000\040\000L\000a\000y\000e\000r}{section.3}% 23
\BOOKMARK [2][-]{subsection.3.4}{\376\377\000P\000o\000l\000i\000c\000y\000\040\000a\000n\000d\000\040\000G\000o\000v\000e\000r\000n\000a\000n\000c\000e\000\040\000L\000a\000y\000e\000r}{section.3}% 24
\BOOKMARK [2][-]{subsection.3.5}{\376\377\000I\000n\000f\000r\000a\000s\000t\000r\000u\000c\000t\000u\000r\000e\000\040\000L\000a\000y\000e\000r}{section.3}% 25
\BOOKMARK [1][-]{section.4}{\376\377\000G\000a\000p\000\040\000A\000n\000a\000l\000y\000s\000i\000s}{}% 26
\BOOKMARK [2][-]{subsection.4.1}{\376\377\000C\000R\000I\000T\000I\000C\000A\000L\000\040\000G\000a\000p\000s}{section.4}% 27
\BOOKMARK [3][-]{subsubsection.4.1.1}{\376\377\000G\000a\000p\000\040\0001\000:\000\040\000A\000g\000e\000n\000t\000\040\000B\000e\000h\000a\000v\000i\000o\000r\000a\000l\000\040\000V\000e\000r\000i\000f\000i\000c\000a\000t\000i\000o\000n}{subsection.4.1}% 28
\BOOKMARK [3][-]{subsubsection.4.1.2}{\376\377\000G\000a\000p\000\040\0002\000:\000\040\000A\000g\000e\000n\000t\000\040\000F\000a\000i\000l\000u\000r\000e\000\040\000C\000a\000s\000c\000a\000d\000e\000\040\000P\000r\000e\000v\000e\000n\000t\000i\000o\000n}{subsection.4.1}% 29
\BOOKMARK [2][-]{subsection.4.2}{\376\377\000H\000I\000G\000H\000\040\000G\000a\000p\000s}{section.4}% 30
\BOOKMARK [3][-]{subsubsection.4.2.1}{\376\377\000G\000a\000p\000\040\0003\000:\000\040\000M\000u\000l\000t\000i\000-\000A\000g\000e\000n\000t\000\040\000C\000o\000n\000s\000e\000n\000s\000u\000s\000\040\000P\000r\000o\000t\000o\000c\000o\000l\000s}{subsection.4.2}% 31
\BOOKMARK [3][-]{subsubsection.4.2.2}{\376\377\000G\000a\000p\000\040\0004\000:\000\040\000R\000e\000a\000l\000-\000T\000i\000m\000e\000\040\000A\000g\000e\000n\000t\000\040\000R\000o\000l\000l\000b\000a\000c\000k\000\040\000M\000e\000c\000h\000a\000n\000i\000s\000m\000s}{subsection.4.2}% 32
\BOOKMARK [3][-]{subsubsection.4.2.3}{\376\377\000G\000a\000p\000\040\0005\000:\000\040\000F\000e\000d\000e\000r\000a\000t\000e\000d\000\040\000A\000g\000e\000n\000t\000\040\000L\000e\000a\000r\000n\000i\000n\000g\000\040\000P\000r\000i\000v\000a\000c\000y}{subsection.4.2}% 33
\BOOKMARK [3][-]{subsubsection.4.2.4}{\376\377\000G\000a\000p\000\040\0006\000:\000\040\000C\000r\000o\000s\000s\000-\000D\000o\000m\000a\000i\000n\000\040\000A\000g\000e\000n\000t\000\040\000A\000u\000d\000i\000t\000\040\000T\000r\000a\000i\000l\000s}{subsection.4.2}% 34
\BOOKMARK [3][-]{subsubsection.4.2.5}{\376\377\000G\000a\000p\000\040\0007\000:\000\040\000H\000u\000m\000a\000n\000\040\000O\000v\000e\000r\000r\000i\000d\000e\000\040\000S\000t\000a\000n\000d\000a\000r\000d\000i\000z\000a\000t\000i\000o\000n}{subsection.4.2}% 35
\BOOKMARK [2][-]{subsection.4.3}{\376\377\000M\000E\000D\000I\000U\000M\000\040\000G\000a\000p\000s}{section.4}% 36
\BOOKMARK [3][-]{subsubsection.4.3.1}{\376\377\000G\000a\000p\000\040\0008\000:\000\040\000C\000r\000o\000s\000s\000-\000P\000r\000o\000t\000o\000c\000o\000l\000\040\000A\000g\000e\000n\000t\000\040\000M\000i\000g\000r\000a\000t\000i\000o\000n}{subsection.4.3}% 37
\BOOKMARK [3][-]{subsubsection.4.3.2}{\376\377\000G\000a\000p\000\040\0009\000:\000\040\000A\000g\000e\000n\000t\000\040\000R\000e\000s\000o\000u\000r\000c\000e\000\040\000A\000c\000c\000o\000u\000n\000t\000i\000n\000g\000\040\000a\000n\000d\000\040\000B\000i\000l\000l\000i\000n\000g}{subsection.4.3}% 38
\BOOKMARK [3][-]{subsubsection.4.3.3}{\376\377\000G\000a\000p\000\040\0001\0000\000:\000\040\000A\000g\000e\000n\000t\000\040\000C\000a\000p\000a\000b\000i\000l\000i\000t\000y\000\040\000N\000e\000g\000o\000t\000i\000a\000t\000i\000o\000n}{subsection.4.3}% 39
\BOOKMARK [3][-]{subsubsection.4.3.4}{\376\377\000G\000a\000p\000\040\0001\0001\000:\000\040\000A\000g\000e\000n\000t\000\040\000P\000e\000r\000f\000o\000r\000m\000a\000n\000c\000e\000\040\000B\000e\000n\000c\000h\000m\000a\000r\000k\000i\000n\000g}{subsection.4.3}% 40
\BOOKMARK [1][-]{section.5}{\376\377\000P\000r\000o\000p\000o\000s\000e\000d\000\040\000S\000o\000l\000u\000t\000i\000o\000n\000\040\000F\000r\000a\000m\000e\000w\000o\000r\000k}{}% 41
\BOOKMARK [2][-]{subsection.5.1}{\376\377\000C\000o\000m\000p\000a\000n\000i\000o\000n\000\040\000A\000:\000\040\000B\000e\000h\000a\000v\000i\000o\000r\000a\000l\000\040\000V\000e\000r\000i\000f\000i\000c\000a\000t\000i\000o\000n}{section.5}% 42
\BOOKMARK [2][-]{subsection.5.2}{\376\377\000C\000o\000m\000p\000a\000n\000i\000o\000n\000\040\000B\000:\000\040\000C\000a\000s\000c\000a\000d\000e\000\040\000P\000r\000e\000v\000e\000n\000t\000i\000o\000n}{section.5}% 43
\BOOKMARK [2][-]{subsection.5.3}{\376\377\000C\000o\000m\000p\000a\000n\000i\000o\000n\000\040\000C\000:\000\040\000C\000o\000n\000s\000e\000n\000s\000u\000s\000\040\000P\000r\000o\000t\000o\000c\000o\000l}{section.5}% 44
\BOOKMARK [2][-]{subsection.5.4}{\376\377\000C\000o\000m\000p\000a\000n\000i\000o\000n\000\040\000D\000:\000\040\000C\000r\000o\000s\000s\000-\000D\000o\000m\000a\000i\000n\000\040\000A\000u\000d\000i\000t}{section.5}% 45
\BOOKMARK [2][-]{subsection.5.5}{\376\377\000C\000o\000m\000p\000a\000n\000i\000o\000n\000\040\000E\000:\000\040\000O\000v\000e\000r\000r\000i\000d\000e\000\040\000P\000r\000o\000t\000o\000c\000o\000l}{section.5}% 46
\BOOKMARK [2][-]{subsection.5.6}{\376\377\000C\000o\000m\000p\000a\000n\000i\000o\000n\000\040\000F\000:\000\040\000F\000e\000d\000e\000r\000a\000t\000i\000o\000n\000\040\000P\000r\000i\000v\000a\000c\000y}{section.5}% 47
\BOOKMARK [2][-]{subsection.5.7}{\376\377\000D\000e\000p\000e\000n\000d\000e\000n\000c\000y\000\040\000A\000n\000a\000l\000y\000s\000i\000s}{section.5}% 48
\BOOKMARK [1][-]{section.6}{\376\377\000D\000i\000s\000c\000u\000s\000s\000i\000o\000n}{}% 49
\BOOKMARK [2][-]{subsection.6.1}{\376\377\000C\000r\000o\000s\000s\000-\000C\000u\000t\000t\000i\000n\000g\000\040\000T\000h\000e\000m\000e\000s}{section.6}% 50
\BOOKMARK [2][-]{subsection.6.2}{\376\377\000P\000r\000i\000o\000r\000i\000t\000i\000z\000a\000t\000i\000o\000n\000\040\000R\000a\000t\000i\000o\000n\000a\000l\000e}{section.6}% 51
\BOOKMARK [2][-]{subsection.6.3}{\376\377\000R\000e\000l\000a\000t\000i\000o\000n\000s\000h\000i\000p\000\040\000t\000o\000\040\000I\000n\000d\000u\000s\000t\000r\000y\000\040\000P\000r\000o\000t\000o\000c\000o\000l\000s}{section.6}% 52
\BOOKMARK [2][-]{subsection.6.4}{\376\377\000L\000i\000m\000i\000t\000a\000t\000i\000o\000n\000s}{section.6}% 53
\BOOKMARK [1][-]{section.7}{\376\377\000C\000o\000n\000c\000l\000u\000s\000i\000o\000n\000\040\000a\000n\000d\000\040\000F\000u\000t\000u\000r\000e\000\040\000W\000o\000r\000k}{}% 54

BIN
workspace/drafts/gap-analysis/arxiv/main.pdf Normal file
View File

Binary file not shown.

604
workspace/drafts/gap-analysis/arxiv/main.tex Normal file
View File

@@ -0,0 +1,604 @@
% Switch to IEEEtran for final arXiv submission:
% \documentclass[conference]{IEEEtran}
\documentclass[11pt,twocolumn]{article}
\usepackage[margin=0.75in]{geometry}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
% \usepackage{cite} % uncomment for IEEEtran
\usepackage{amsmath,amssymb}
\usepackage{graphicx}
\usepackage{url}
\usepackage{hyperref}
\usepackage{booktabs}
% \usepackage{multirow} % uncomment if available
\usepackage{xcolor}
\usepackage{array}
\hypersetup{
colorlinks=true,
linkcolor=blue,
citecolor=blue,
urlcolor=blue,
}
\begin{document}
\title{Gap Analysis of IETF Standards for\\Autonomous AI Agent Protocols}
\author{
Christian Nennemann\\
Independent Researcher\\
\texttt{ietf@nennemann.de}
}
\maketitle
% ==================================================================
\begin{abstract}
Autonomous software agents---powered by large language models and
traditional AI planning systems---are rapidly being deployed for
network management, cloud orchestration, supply-chain logistics, and
multi-step AI-driven workflows. A survey of the IETF document
corpus reveals over 260 Internet-Drafts and RFCs that touch on
aspects of agent communication, identity, safety, and operations.
Despite this breadth, these efforts remain fragmented: no single
reference architecture ties them together, and several critical
capabilities---including behavioral verification, failure cascade
prevention, multi-agent consensus, and standardized human
override---lack any standardization whatsoever.
This paper presents a systematic gap analysis of IETF standards
with respect to autonomous agent protocol requirements. We propose
a four-layer reference architecture for agent ecosystems, identify
eleven specific gaps organized by severity (Critical, High, Medium),
and map these gaps to six companion Internet-Drafts that address the
most pressing deficiencies. We further contextualize these gaps
against industry protocols such as Google's Agent-to-Agent (A2A)
protocol and Anthropic's Model Context Protocol (MCP), as well as
academic literature on multi-agent systems, federated learning, and
fault-tolerant distributed systems. Our analysis provides a
structured roadmap for the standards work needed to enable safe,
interoperable, and auditable autonomous agent ecosystems.
\end{abstract}
\medskip
\noindent\textbf{Keywords:} autonomous agents, multi-agent systems, IETF standards, gap analysis,
agent safety, protocol standardization, AI governance
% ==================================================================
\section{Introduction}
\label{sec:intro}
The emergence of large language model (LLM)-based agents~\cite{openai2023gpt4,wang2024survey-llm-agents} has transformed autonomous software agents from a long-studied academic concept~\cite{wooldridge2009multiagent,jennings1998agent-applications} into a practical engineering reality. Modern agent frameworks such as AutoGen~\cite{autogen} and CrewAI~\cite{crewai} orchestrate multiple agents that collaborate on complex tasks, delegate sub-tasks to one another, invoke external tools, and make decisions with limited or no human supervision. Industry protocols including Google's Agent-to-Agent (A2A) protocol~\cite{a2a-protocol} and Anthropic's Model Context Protocol (MCP)~\cite{mcp-protocol} have emerged to standardize agent communication at the application layer.
Simultaneously, agents are being deployed for critical infrastructure operations---network management under the IETF's Network Management Operations (NMOP) working group, cloud orchestration across trust domains, and supply-chain workflows that span organizational boundaries. These deployments demand protocol-level guarantees for identity, authorization, safety, auditability, and fault tolerance that go far beyond what any single existing standard provides.
A survey of the IETF document corpus reveals over 260 Internet-Drafts and RFCs touching on agent-relevant topics across multiple working groups including WIMSE (Workload Identity in Multi-System Environments), RATS (Remote ATtestation procedureS), OAuth/GNAP, SCITT (Supply Chain Integrity, Transparency, and Trust), and NMOP. Yet these efforts remain fragmented, addressing individual facets of the problem without a unifying architecture.
\subsection{Contributions}
This paper makes three contributions:
\begin{enumerate}
\item \textbf{Reference Architecture.} We propose a four-layer reference architecture (Section~\ref{sec:architecture}) that organizes agent capabilities into Human Control, Agent Interaction, Execution, Policy \& Governance, and Infrastructure layers.
\item \textbf{Gap Analysis.} We identify eleven specific gaps in the current IETF standards landscape (Section~\ref{sec:gaps}), classified by severity (Critical, High, Medium), with formal problem statements, impact assessments, and analysis of existing partial coverage.
\item \textbf{Solution Roadmap.} We present six companion Internet-Drafts (Section~\ref{sec:solutions}) that address the most critical gaps, together with a dependency analysis and prioritization rationale.
\end{enumerate}
\subsection{Paper Organization}
Section~\ref{sec:background} surveys existing IETF work and industry protocols relevant to autonomous agents. Section~\ref{sec:architecture} presents the reference architecture. Section~\ref{sec:gaps} details the eleven identified gaps. Section~\ref{sec:solutions} describes the companion draft roadmap. Section~\ref{sec:discussion} discusses cross-cutting themes and limitations. Section~\ref{sec:conclusion} concludes.
% ==================================================================
\section{Background and Related Work}
\label{sec:background}
\subsection{IETF Standards Landscape}
\subsubsection{WIMSE --- Workload Identity in Multi-System Environments}
The WIMSE working group addresses workload identity for services that span multiple systems and trust domains. Of particular relevance is the Execution Context Token (ECT) framework~\cite{id-wimse-ect}, which provides cryptographically signed tokens carrying task identity, delegated authority, and constraints across agent boundaries. ECTs build on the JSON Web Token (JWT)~\cite{rfc7519} format and are designed to propagate execution context through chains of delegated actions---a fundamental requirement for multi-agent workflows. However, ECTs address identity and context propagation without defining failure semantics, behavioral verification, or consensus mechanisms.
\subsubsection{RATS --- Remote ATtestation procedureS}
The RATS architecture~\cite{rfc9334} defines procedures for remote attestation, enabling a relying party to appraise the trustworthiness of a remote peer based on attestation evidence. RATS provides the conceptual foundation for verifiable claims about system state, but its scope is limited to platform and firmware integrity. It does not address the higher-level question of whether an agent's \emph{behavior}---as opposed to its platform---conforms to a declared policy. Extending RATS-style attestation to behavioral claims is one of the critical gaps identified in this analysis.
\subsubsection{OAuth 2.0 and GNAP}
The OAuth 2.0 authorization framework and the Grant Negotiation and Authorization Protocol (GNAP) provide mechanisms for delegated authorization. Transaction tokens and token exchange mechanisms are relevant to agent-to-agent delegation chains, where Agent~A delegates a subset of its authority to Agent~B. However, OAuth and GNAP are designed for human-initiated authorization flows and do not natively support the fully autonomous, multi-hop delegation patterns characteristic of agent ecosystems.
\subsubsection{SCITT --- Supply Chain Integrity, Transparency, and Trust}
SCITT defines transparency services based on append-only cryptographic logs. Its model is directly relevant to agent audit trails: each agent action could be recorded as a signed statement in a transparency log, enabling tamper-evident provenance tracking. However, SCITT does not define agent-specific audit semantics, causal ordering across agent actions, or cross-domain audit correlation.
\subsubsection{NMOP --- Network Management Operations}
The NMOP working group focuses on intent-based network management and autonomous network functions. Agent-driven network management is a primary use case for the gaps identified in this analysis: network agents that autonomously configure devices, respond to incidents, and optimize traffic must operate within strict safety boundaries with reliable override and rollback capabilities.
\subsection{Industry Protocols}
\subsubsection{Google A2A Protocol}
The Agent-to-Agent (A2A) protocol~\cite{a2a-protocol} defines a JSON-RPC-based mechanism for agents to discover each other's capabilities via ``Agent Cards'' and exchange tasks through structured messages. A2A provides useful abstractions for agent discovery and task delegation but does not address behavioral verification, cascade prevention, or cross-domain audit trails. Its capability advertisement mechanism is a partial solution to Gap~10 (Capability Negotiation) but lacks the policy-constrained semantics required for autonomous operations.
\subsubsection{Anthropic MCP}
The Model Context Protocol (MCP)~\cite{mcp-protocol} standardizes how LLM-based applications access external tools and data sources. MCP defines a client-server architecture where the LLM agent acts as a client requesting tool invocations, file access, and prompt templates from MCP servers. While MCP addresses the tool integration layer effectively, it operates within a single trust domain and does not define mechanisms for multi-agent coordination, cross-domain operations, or safety controls.
\subsubsection{Multi-Agent Frameworks}
AutoGen~\cite{autogen} and CrewAI~\cite{crewai} are representative of the emerging class of multi-agent orchestration frameworks. AutoGen provides a conversation-based programming model where multiple LLM agents collaborate through structured dialogues. CrewAI organizes agents into ``crews'' with defined roles, goals, and task assignments. Both frameworks demonstrate the practical need for the capabilities identified in our gap analysis but implement them through framework-specific mechanisms that are not interoperable.
\subsection{Academic Foundations}
\subsubsection{Multi-Agent Systems}
The multi-agent systems (MAS) literature~\cite{wooldridge2009multiagent,dorri2018mas-iot,jennings1998agent-applications} provides foundational models for agent communication, coordination, and negotiation. Classical work on contract nets, auction-based allocation, and belief-desire-intention (BDI) architectures informs the design of agent consensus protocols. However, translating these theoretical models into interoperable protocol standards for heterogeneous, cross-domain agent deployments remains an open problem.
\subsubsection{Distributed Consensus}
Consensus protocols such as Raft~\cite{ongaro2014raft}, Paxos~\cite{lamport1998paxos}, and PBFT~\cite{castro1999pbft} solve the problem of agreement in distributed systems. These protocols are designed for replicated state machines with homogeneous participants and well-defined failure models. Agent consensus differs fundamentally: participants are heterogeneous (different capabilities, trust levels, policies), the decision space is richer than choosing a single value, and the failure model includes semantic errors (an agent ``agrees'' but acts differently) in addition to crash and Byzantine failures.
\subsubsection{Federated Learning and Privacy}
Federated learning~\cite{mcmahan2017fedavg,kairouz2021fedlearning-advances} enables distributed model training without centralizing data. Differential privacy~\cite{dwork2006diffprivacy} provides formal privacy guarantees for statistical queries. Both are directly relevant to agents that share operational telemetry or learned models across organizational boundaries. However, no existing standard defines how these privacy-preserving techniques should be applied to agent-specific data types such as execution traces, behavioral profiles, and performance metrics.
\subsubsection{Circuit Breakers and Fault Tolerance}
The circuit breaker pattern, popularized by Nygard~\cite{nygard2018releaseit}, provides a mechanism for preventing cascade failures in distributed systems by detecting repeated failures and temporarily halting requests to a failing service. While widely adopted in microservice architectures, no protocol standard exists for circuit breaker semantics in agent-to-agent interactions, where the failure modes are richer (partial results, semantic errors, policy violations) and the containment boundaries span trust domains.
% ==================================================================
\section{Reference Architecture}
\label{sec:architecture}
We propose a layered reference architecture for autonomous agent ecosystems. The architecture comprises four principal layers plus an overarching human control layer, as depicted in Fig.~\ref{fig:arch}.
\begin{figure}[htbp]
\centering
\small
\begin{verbatim}
+-----------------------------------------------------------+
| HUMAN OPERATORS |
| [Override & HITL Layer -- GAP 7] |
+-----------------------------------------------------------+
| AGENT INTERACTION LAYER |
| +--------+ +--------+ +--------+ +--------+ |
| |Agent A |<>|Agent B |<>|Agent C |<>|Agent D | |
| +---+----+ +---+----+ +---+----+ +---+----+ |
| | GAP 3: | GAP 10: | GAP 1: | |
| | Consens. | Cap.Neg. | Behav.V. | |
+------+----------+----------+----------+-------------------+
| 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] |
+-----------------------------------------------------------+
\end{verbatim}
\caption{Agent Ecosystem Reference Architecture. Each layer identifies the gap areas addressed by this analysis.}
\label{fig:arch}
\end{figure}
\subsection{Human Control Layer}
The topmost layer provides human-in-the-loop (HITL) controls and override capabilities. This layer ensures that autonomous agents remain subject to human authority at all times. Gap~7 (Human Override Standardization) resides here. The layer interfaces with all lower layers: an override signal may halt execution (Execution Layer), revoke delegation (Policy Layer), or disconnect an agent from infrastructure services (Infrastructure Layer).
\subsection{Agent Interaction Layer}
This layer is where agents communicate, negotiate capabilities, reach consensus, and undergo behavioral verification. Three gaps reside here:
\begin{itemize}
\item \textbf{Gap~1 (Behavioral Verification):} Runtime verification that an agent's observed behavior conforms to its declared policy.
\item \textbf{Gap~3 (Consensus):} Multi-agent agreement on shared decisions.
\item \textbf{Gap~10 (Capability Negotiation):} Dynamic discovery and negotiation of agent capabilities.
\end{itemize}
Industry protocols A2A~\cite{a2a-protocol} and MCP~\cite{mcp-protocol} partially address this layer but lack the safety and governance semantics required for autonomous operation.
\subsection{Execution Layer}
The Execution Layer manages DAG-structured agent workflows. Execution Context Tokens (ECTs)~\cite{id-wimse-ect} carry delegated authority and task context through the execution graph. Two gaps are critical at this layer:
\begin{itemize}
\item \textbf{Gap~2 (Cascade Prevention):} Circuit breakers, failure isolation, and cascade containment for multi-agent workflows.
\item \textbf{Gap~4 (Rollback):} Standardized checkpointing and undo semantics that work across agent and domain boundaries.
\end{itemize}
\subsection{Policy and Governance Layer}
This layer enforces organizational policies, privacy requirements, and compliance constraints. The Agent Context Policy (ACP) framework~\cite{id-dag-hitl-safety} defines per-agent policy documents specifying permitted behaviors, resource limits, and escalation rules. Gaps at this layer include:
\begin{itemize}
\item \textbf{Gap~5 (Federated Privacy):} Privacy guarantees for agents that share operational data or participate in federated learning across domains.
\item \textbf{Gap~6 (Cross-Domain Audit):} End-to-end tamper-evident audit trails across organizational boundaries.
\end{itemize}
\subsection{Infrastructure Layer}
The bottom layer provides foundational services: identity, discovery, registration, and protocol bridging. Remaining gaps reside here:
\begin{itemize}
\item \textbf{Gap~8 (Cross-Protocol Migration):} Preserving agent context across heterogeneous protocol environments.
\item \textbf{Gap~9 (Resource Accounting):} Tracking and reconciling agent resource consumption across domains.
\item \textbf{Gap~11 (Performance Benchmarking):} Standardized metrics for evaluating agent performance.
\end{itemize}
% ==================================================================
\section{Gap Analysis}
\label{sec:gaps}
We identify eleven gaps in the current standards landscape, classified into three severity levels:
\begin{itemize}
\item \textbf{CRITICAL:} No existing standard addresses the problem; failure to standardize poses immediate safety or interoperability risks.
\item \textbf{HIGH:} Partial coverage exists but is insufficient for production autonomous agent deployments.
\item \textbf{MEDIUM:} The gap affects efficiency or completeness but does not pose immediate safety risks.
\end{itemize}
Table~\ref{tab:gap-summary} provides an overview.
\begin{table}[htbp]
\centering
\caption{Summary of Identified Gaps}
\label{tab:gap-summary}
\small
\begin{tabular}{@{}clll@{}}
\toprule
\textbf{Gap} & \textbf{Name} & \textbf{Severity} & \textbf{Category} \\
\midrule
1 & Behavioral Verification & CRITICAL & AI Safety \\
2 & Cascade Prevention & CRITICAL & Safety/Resilience \\
\midrule
3 & Multi-Agent Consensus & HIGH & A2A Protocols \\
4 & Real-Time Rollback & HIGH & Resilience \\
5 & Federated Privacy & HIGH & Privacy \\
6 & Cross-Domain Audit & HIGH & Compliance \\
7 & Human Override & HIGH & AI Safety \\
\midrule
8 & Cross-Protocol Migration & MEDIUM & Interoperability \\
9 & Resource Accounting & MEDIUM & Operations \\
10 & Capability Negotiation & MEDIUM & A2A Protocols \\
11 & Performance Benchmarking & MEDIUM & Metrics \\
\bottomrule
\end{tabular}
\end{table}
% ------------------------------------------------------------------
\subsection{CRITICAL Gaps}
\subsubsection{Gap 1: Agent Behavioral Verification}
\label{sec:gap1}
\paragraph{Problem Statement}
Autonomous agents operating in production environments lack any standardized mechanism for runtime verification of policy compliance. While RATS~\cite{rfc9334} provides attestation for platform integrity---verifying that firmware and software have not been tampered with---no equivalent exists for verifying that an agent's \emph{observed behavior} conforms to its declared behavioral profile or policy constraints.
\paragraph{Evidence and Examples}
Consider a network management agent authorized to modify BGP route policies within defined parameters. Without behavioral verification, there is no protocol-level mechanism to detect that the agent has begun modifying routes outside its authorized scope, whether due to prompt injection, model drift, or adversarial manipulation. The operator learns of the violation only through its downstream effects---potentially after significant damage.
In multi-agent workflows, the problem compounds: Agent~B trusts the output of Agent~A because Agent~A holds valid credentials, but those credentials attest only to Agent~A's identity, not to the correctness of its behavior. A misbehaving Agent~A can corrupt the entire downstream workflow while remaining ``authenticated.''
\paragraph{Impact Assessment}
Undetected policy violations could cause safety incidents, data breaches, or cascading failures in critical infrastructure. In regulated industries, the inability to verify agent compliance creates an insurmountable barrier to deployment.
\paragraph{Existing Partial Solutions}
RATS~\cite{rfc9334} provides the conceptual model (Attester, Verifier, Relying Party) but scopes it to platform integrity. The ACP-DAG-HITL framework~\cite{id-dag-hitl-safety} defines policies but not verification mechanisms. Runtime monitoring tools exist in practice but use proprietary, non-interoperable formats.
% ------------------------------------------------------------------
\subsubsection{Gap 2: Agent Failure Cascade Prevention}
\label{sec:gap2}
\paragraph{Problem Statement}
Multi-agent workflows create dependency chains where a failure in one agent propagates to downstream agents, causing cascade failures. No standardized mechanism exists for circuit breakers~\cite{nygard2018releaseit}, failure isolation, or cascade containment in agent-to-agent interactions.
\paragraph{Evidence and Examples}
Current practice relies on ad-hoc timeout and retry logic that is neither interoperable nor sufficient for complex DAG-structured workflows. In a network management scenario, an agent responsible for collecting telemetry data may fail due to a device timeout. Without cascade containment, the configuration agent waiting for this telemetry proceeds with stale data, the validation agent rubber-stamps the stale configuration, and the deployment agent pushes an incorrect configuration to production routers.
The microservices community has adopted circuit breaker patterns~\cite{nygard2018releaseit}, but these operate at the HTTP request level and do not capture the richer failure semantics of agent interactions: partial results (an agent completed 3 of 5 sub-tasks), semantic errors (an agent returned syntactically valid but logically incorrect output), and policy violations that should trigger containment.
\paragraph{Impact Assessment}
A single agent failure could cascade through an entire multi-agent deployment, causing widespread service disruption with no automated containment. This risk is especially acute in network management, where agent failures can propagate to affect live network operations.
\paragraph{Existing Partial Solutions}
ECTs~\cite{id-wimse-ect} provide execution context but no failure containment semantics. Framework-specific implementations (e.g., AutoGen's~\cite{autogen} error handling) are not interoperable across vendors.
% ------------------------------------------------------------------
\subsection{HIGH Gaps}
\subsubsection{Gap 3: Multi-Agent Consensus Protocols}
\label{sec:gap3}
\paragraph{Problem Statement}
When multiple agents must agree on a shared decision---a network configuration change, a resource allocation plan, or a coordinated incident response---no standardized consensus protocol exists for agent-to-agent agreement.
\paragraph{Evidence and Examples}
Distributed systems consensus protocols (Raft~\cite{ongaro2014raft}, Paxos~\cite{lamport1998paxos}, PBFT~\cite{castro1999pbft}) are designed for replicated state machines with homogeneous participants. Agent consensus differs fundamentally: participants are heterogeneous with different capabilities, trust levels, and policy constraints. Agent consensus requires additional semantics such as weighted voting based on expertise or trust scores, capability-based participation where only qualified agents vote on domain-specific decisions, and policy-constrained proposals where proposed decisions must satisfy all participants' policy constraints.
\paragraph{Impact Assessment}
Without standard consensus protocols, multi-vendor agent deployments cannot coordinate decisions, limiting autonomous agents to single-vendor silos or requiring expensive custom integration.
\paragraph{Existing Partial Solutions}
No existing IETF work directly addresses multi-agent consensus. The MAS literature~\cite{wooldridge2009multiagent} provides theoretical models but not interoperable protocol specifications.
% ------------------------------------------------------------------
\subsubsection{Gap 4: Real-Time Agent Rollback Mechanisms}
\label{sec:gap4}
\paragraph{Problem Statement}
When an autonomous agent takes an action with unintended consequences, no standardized mechanism exists for rolling back the action and restoring the previous state. Rollback requires standardized checkpointing, state snapshots, and undo semantics that work across agent boundaries and administrative domains.
\paragraph{Evidence and Examples}
NETCONF~\cite{rfc6241} provides confirmed-commit with automatic rollback for configuration changes, but this is specific to the NETCONF protocol and device configurations. An agent that has invoked an API, sent a notification, allocated cloud resources, and modified a database cannot undo these heterogeneous actions using NETCONF's rollback. In multi-agent workflows, coordinated rollback is even harder: multiple agents may have taken dependent actions that must be reversed as a unit (a distributed saga pattern) without a standard protocol for coordinating the undo sequence.
\paragraph{Impact Assessment}
Operators cannot safely deploy autonomous agents for critical operations without maintaining manual intervention capability for every action, negating much of the value of autonomy.
\paragraph{Existing Partial Solutions}
NETCONF confirmed-commit provides rollback for configuration changes only~\cite{rfc6241}. The saga pattern is well-known in distributed systems but lacks a standard protocol binding for agent interactions.
% ------------------------------------------------------------------
\subsubsection{Gap 5: Federated Agent Learning Privacy}
\label{sec:gap5}
\paragraph{Problem Statement}
Agents participating in federated learning~\cite{mcmahan2017fedavg} or sharing operational data across administrative domains require privacy guarantees beyond transport encryption. No IETF specification addresses differential privacy parameters~\cite{dwork2006diffprivacy} for shared agent telemetry, data minimization for cross-domain agent data, or consent management for federated agent learning.
\paragraph{Evidence and Examples}
Network management agents across ISPs could benefit from federated learning of anomaly detection models without sharing raw traffic data. However, even model updates can leak information about network topology and traffic patterns~\cite{kairouz2021fedlearning-advances}. Without standardized privacy controls, organizations must choose between participating in federated ecosystems (accepting privacy risks) or operating in isolation (forgoing collaborative benefits).
\paragraph{Impact Assessment}
Organizations will be unable to participate in federated agent ecosystems without unacceptable privacy risks, limiting the value of multi-domain agent deployments.
\paragraph{Existing Partial Solutions}
General privacy frameworks exist but none address the specific data types and threat models of agent-to-agent federated learning.
% ------------------------------------------------------------------
\subsubsection{Gap 6: Cross-Domain Agent Audit Trails}
\label{sec:gap6}
\paragraph{Problem Statement}
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.
\paragraph{Evidence and Examples}
Execution Audit Tokens~\cite{id-exec-audit} provide per-action audit records, and SCITT provides transparency log primitives, but no standard defines how these records are aggregated, correlated, and queried across domains. A compliance auditor investigating an incident involving agents from three organizations currently has no standard way to reconstruct the end-to-end sequence of agent actions, verify that no records are missing, or confirm the causal relationships between actions in different domains.
Regulatory and compliance requirements (e.g., the EU AI Act) increasingly demand end-to-end audit trails for automated decision-making, making this gap urgent for enterprise deployments.
\paragraph{Impact Assessment}
Organizations cannot demonstrate compliance for cross-domain agent operations, blocking adoption in regulated industries including financial services, healthcare, and telecommunications.
\paragraph{Existing Partial Solutions}
SCITT provides transparency log primitives. Execution Audit Tokens~\cite{id-exec-audit} define per-action audit records. Neither addresses cross-domain correlation or causal ordering.
% ------------------------------------------------------------------
\subsubsection{Gap 7: Human Override Standardization}
\label{sec:gap7}
\paragraph{Problem Statement}
Autonomous agents must always be subject to human override, but no cross-vendor protocol exists for sending override signals to agents. Required override types include emergency stop (immediate halt), graceful pause (complete current step then halt), parameter modification (adjust constraints while running), and forced rollback (undo recent actions).
\paragraph{Evidence and Examples}
The ACP-DAG-HITL framework~\cite{id-dag-hitl-safety} defines \emph{when} human approval is required (policy gates in the DAG execution plan) but does not specify the \emph{protocol} for delivering override signals to a running agent. In a multi-vendor deployment, if Agent~A (from Vendor~X) misbehaves and the management platform (from Vendor~Y) needs to issue an emergency stop, there is no standard message format, delivery mechanism, or acknowledgment protocol.
The absence of standard override creates an asymmetric safety risk: more capable agents that can take more impactful actions are precisely the ones that are hardest to stop if something goes wrong.
\paragraph{Impact Assessment}
Operators lose the ability to control autonomous agents in emergency situations, creating unacceptable safety risks for any deployment beyond sandboxed experimentation.
\paragraph{Existing Partial Solutions}
ACP-DAG-HITL~\cite{id-dag-hitl-safety} defines HITL policies but not override delivery. Vendor-specific kill switches exist but are not interoperable.
% ------------------------------------------------------------------
\subsection{MEDIUM Gaps}
\subsubsection{Gap 8: Cross-Protocol Agent Migration}
\label{sec:gap8}
\paragraph{Problem Statement}
Agents may need to migrate between protocol environments (e.g., from an A2A-based system~\cite{a2a-protocol} to an MCP-based system~\cite{mcp-protocol}) while preserving execution context, identity, and accumulated state. No standard defines how agent context is translated or preserved across protocol boundaries.
\paragraph{Impact Assessment}
Agent deployments become fragmented across protocol silos, reducing interoperability and increasing operational complexity. As the protocol landscape matures and consolidates, lack of migration support will strand early adopters.
\paragraph{Existing Partial Solutions}
ECTs~\cite{id-wimse-ect} provide a protocol-neutral context token but do not define migration procedures.
% ------------------------------------------------------------------
\subsubsection{Gap 9: Agent Resource Accounting and Billing}
\label{sec:gap9}
\paragraph{Problem Statement}
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.
\paragraph{Impact Assessment}
Organizations cannot accurately track or bill for agent resource consumption, hindering the development of sustainable commercial multi-domain agent ecosystems.
\paragraph{Existing Partial Solutions}
No existing IETF work addresses agent-specific resource accounting. Cloud provider billing APIs exist but are domain-specific and do not correlate consumption with agent identity or execution context.
% ------------------------------------------------------------------
\subsubsection{Gap 10: Agent Capability Negotiation}
\label{sec:gap10}
\paragraph{Problem Statement}
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 URIs~\cite{rfc8615} and HTTP content negotiation~\cite{rfc9110} provide basic discovery primitives, but agent capability negotiation requires richer semantics: versioned capability declarations, conditional capabilities that depend on policy or context, and mutual negotiation where both parties agree on a compatible interaction profile.
\paragraph{Impact Assessment}
Agent interactions require pre-configured knowledge of peer capabilities, limiting dynamic composition and ad-hoc agent collaboration.
\paragraph{Existing Partial Solutions}
A2A Agent Cards~\cite{a2a-protocol} provide capability advertisement but without policy-constrained negotiation semantics. HTTP content negotiation~\cite{rfc9110} provides basic media type negotiation but not agent-capability-level negotiation.
% ------------------------------------------------------------------
\subsubsection{Gap 11: Agent Performance Benchmarking}
\label{sec:gap11}
\paragraph{Problem Statement}
No standardized metrics or benchmarking methodology exists for evaluating autonomous agent performance. Agent performance spans multiple dimensions: task completion accuracy, latency, resource efficiency, safety compliance rate, and behavioral consistency. Without common metrics, operators cannot compare agent implementations, set performance baselines, or detect performance degradation over time.
\paragraph{Impact Assessment}
Operators cannot objectively evaluate or compare autonomous agent implementations, hindering procurement and deployment decisions.
\paragraph{Existing Partial Solutions}
No existing IETF work addresses agent performance benchmarking. ML model evaluation benchmarks exist but do not address the operational performance dimensions unique to autonomous agents.
% ==================================================================
\section{Proposed Solution Framework}
\label{sec:solutions}
To address the identified gaps, we have developed six companion Internet-Drafts. Table~\ref{tab:roadmap} maps each draft to the gaps it addresses.
\begin{table}[htbp]
\centering
\caption{Companion Draft Roadmap}
\label{tab:roadmap}
\small
\begin{tabular}{@{}p{4.2cm}cc@{}}
\toprule
\textbf{Companion Draft} & \textbf{Gaps} & \textbf{Priority} \\
\midrule
Behavioral Verification~\cite{id-behavioral-verification} & 1, 11 & CRITICAL \\
Cascade Prevention~\cite{id-cascade-prevention} & 2, 4 & CRITICAL \\
\midrule
Consensus Protocol~\cite{id-consensus} & 3, 10 & HIGH \\
Cross-Domain Audit~\cite{id-cross-domain-audit} & 6, 9 & HIGH \\
Override Protocol~\cite{id-override-protocol} & 7 & HIGH \\
Federation Privacy~\cite{id-federation-privacy} & 5, 8 & HIGH \\
\bottomrule
\end{tabular}
\end{table}
\subsection{Companion A: Behavioral Verification}
The Agent Behavioral Verification draft~\cite{id-behavioral-verification} extends the RATS attestation model to agent behavior. It defines behavioral profiles (machine-readable descriptions of permitted agent actions), verification evidence formats (signed attestations of observed behavior), and appraisal procedures for comparing observed behavior against declared profiles. This draft also addresses Gap~11 by defining standardized performance metrics that can be included in behavioral attestations.
\subsection{Companion B: Cascade Prevention}
The Agent Failure Cascade Prevention draft~\cite{id-cascade-prevention} defines protocol-level circuit breakers, failure isolation boundaries, and coordinated rollback for multi-agent DAG workflows. Circuit breaker states (Closed, Open, Half-Open) are communicated between agents using standardized health signals. The draft also addresses Gap~4 (Rollback) by defining checkpoint and undo semantics for agent actions.
\subsection{Companion C: Consensus Protocol}
The Multi-Agent Consensus draft~\cite{id-consensus} defines a consensus protocol tailored to heterogeneous agents. It supports weighted voting, capability-based participation, and policy-constrained proposals. The protocol builds on classical consensus theory~\cite{ongaro2014raft,lamport1998paxos} while adding agent-specific extensions. This draft also addresses Gap~10 by defining capability negotiation as a precursor to consensus formation.
\subsection{Companion D: Cross-Domain Audit}
The Cross-Domain Agent Audit Trails draft~\cite{id-cross-domain-audit} defines a standard format for cross-domain audit records with causal ordering (Lamport timestamps and vector clocks), domain boundary linkage, and tamper-evident aggregation using Merkle trees. The draft builds on SCITT transparency log primitives and Execution Audit Tokens~\cite{id-exec-audit}. It also addresses Gap~9 by including resource consumption records in the audit trail.
\subsection{Companion E: Override Protocol}
The Standardized Human Override Protocol~\cite{id-override-protocol} defines message formats and delivery mechanisms for four override types: emergency stop, graceful pause, parameter modification, and forced rollback. The protocol supports multi-vendor environments with standard acknowledgment semantics and escalation procedures when an agent fails to respond to an override signal.
\subsection{Companion F: Federation Privacy}
The Federated Agent Learning Privacy draft~\cite{id-federation-privacy} defines privacy controls for agents sharing data across domains, including differential privacy parameters for agent telemetry, data minimization profiles, and consent management. The draft also addresses Gap~8 (Cross-Protocol Migration) by defining context preservation mechanisms for agents moving between protocol environments.
\subsection{Dependency Analysis}
The companion drafts have the following dependency structure:
\begin{itemize}
\item \textbf{Behavioral Verification} (A) is foundational: its attestation format is used by Cascade Prevention (B) and Cross-Domain Audit (D).
\item \textbf{Cascade Prevention} (B) defines failure containment that Override Protocol (E) builds upon.
\item \textbf{Consensus} (C) extends behavioral verification with multi-agent agreement.
\item \textbf{Cross-Domain Audit} (D) provides the audit infrastructure that Federation Privacy (F) adds privacy controls to.
\end{itemize}
This dependency ordering implies a natural implementation sequence: A $\rightarrow$ B $\rightarrow$ E and A $\rightarrow$ D $\rightarrow$ F, with C depending on A.
% ==================================================================
\section{Discussion}
\label{sec:discussion}
\subsection{Cross-Cutting Themes}
Several themes cut across multiple gaps:
\paragraph{Trust Propagation}
Gaps~1, 3, 5, 6, and 7 all involve trust relationships that must be established, verified, and maintained across agent and domain boundaries. The ECT~\cite{id-wimse-ect} provides a foundation for trust propagation, but the gaps reveal that identity-based trust is necessary but not sufficient---behavioral trust, consensus-based trust, and audit-verified trust are equally important.
\paragraph{Safety vs.\ Autonomy Trade-off}
Gaps~1, 2, 4, and 7 reflect the fundamental tension between agent autonomy and safety. Greater autonomy enables more valuable agent applications but increases the risk and blast radius of failures. The companion drafts collectively define a ``safety envelope'' that enables autonomy within verified boundaries.
\paragraph{Cross-Domain Operations}
Gaps~5, 6, 8, and 9 all involve operations that cross organizational boundaries. Cross-domain agent operations are where the most valuable applications lie (federated network management, multi-cloud orchestration, supply-chain automation) but also where the standards gaps are most acute.
\subsection{Prioritization Rationale}
The severity classification reflects two criteria:
\begin{enumerate}
\item \textbf{Safety Impact:} Gaps that could lead to safety incidents if unaddressed are rated CRITICAL or HIGH.
\item \textbf{Blocking Effect:} Gaps that prevent entire classes of agent deployments are rated higher than those that merely reduce efficiency.
\end{enumerate}
Gaps~1 and 2 are CRITICAL because they represent fundamental safety requirements: without behavioral verification (Gap~1), operators cannot trust agents, and without cascade prevention (Gap~2), a single failure can cause widespread disruption. Gap~7 (Human Override) is rated HIGH rather than CRITICAL because manual, vendor-specific overrides exist as imperfect stopgaps; the gap is in interoperability, not in the complete absence of override capability.
\subsection{Relationship to Industry Protocols}
The A2A~\cite{a2a-protocol} and MCP~\cite{mcp-protocol} protocols address important aspects of agent communication but operate at a different layer than the gaps identified here. A2A focuses on task-level agent interaction; MCP focuses on tool integration. Neither addresses the safety, governance, and cross-domain concerns that constitute the majority of our identified gaps. We view the companion drafts as complementary to industry protocols: A2A and MCP handle the ``what'' of agent communication, while the companion drafts address the ``how safely'' and ``how accountably.''
\subsection{Limitations}
This analysis has several limitations:
\begin{enumerate}
\item \textbf{Evolving Landscape.} The agent protocol landscape is evolving rapidly. New standards and industry protocols may address some identified gaps by the time the companion drafts reach maturity.
\item \textbf{Implementation Validation.} The gap analysis is based on specification review and architectural analysis, not on experimental evaluation of prototype implementations. Some gaps may prove easier or harder to address in practice than our analysis suggests.
\item \textbf{Scope.} We focus on IETF-style protocol standards and do not analyze gaps in other standardization bodies (W3C, IEEE, ISO) that may also be relevant to autonomous agents.
\item \textbf{Single-Author Perspective.} While informed by discussions in multiple IETF working groups, this analysis reflects a single researcher's assessment. Community review may identify additional gaps or disagree with severity classifications.
\end{enumerate}
% ==================================================================
\section{Conclusion and Future Work}
\label{sec:conclusion}
We have presented a systematic gap analysis of IETF standards for autonomous AI agent protocols. Our analysis identified eleven specific gaps across four severity categories, organized within a four-layer reference architecture. The two CRITICAL gaps---behavioral verification and cascade prevention---represent fundamental safety requirements that must be addressed before autonomous agents can be deployed responsibly in production environments.
Six companion Internet-Drafts have been developed to address the most pressing gaps, with a dependency-ordered implementation roadmap. These drafts are designed to be complementary to existing IETF work (WIMSE, RATS, SCITT) and to industry protocols (A2A, MCP).
Future work includes:
\begin{itemize}
\item \textbf{Prototype Implementation:} Building reference implementations of the companion drafts to validate feasibility and identify specification gaps.
\item \textbf{Interoperability Testing:} Developing an interoperability test suite for multi-vendor agent deployments using the proposed standards.
\item \textbf{Formal Verification:} Applying formal methods to verify safety properties of the proposed protocols, particularly the cascade prevention and override mechanisms.
\item \textbf{Performance Evaluation:} Measuring the overhead introduced by behavioral verification, audit logging, and consensus protocols in realistic agent workloads.
\item \textbf{Community Engagement:} Presenting this analysis to relevant IETF working groups (WIMSE, RATS, NMOP) to solicit feedback and build consensus on prioritization.
\end{itemize}
The autonomous agent ecosystem is at an inflection point: capable enough to deliver real value, but lacking the protocol-level safety and governance infrastructure needed for responsible deployment. Closing the gaps identified in this analysis is essential for realizing the potential of autonomous agents while maintaining the safety and accountability that critical infrastructure demands.
% ==================================================================
\section*{Acknowledgments}
The author thanks the participants of the WIMSE, RATS, and NMOP working groups for discussions that informed this analysis.
% ==================================================================
% Switch to IEEEtran for final arXiv submission:
% \bibliographystyle{IEEEtran}
\bibliographystyle{plain}
\bibliography{references}
\end{document}

316
workspace/drafts/gap-analysis/arxiv/references.bib Normal file
View File

@@ -0,0 +1,316 @@
% ============================================================
% RFCs
% ============================================================
@misc{rfc2119,
author = {Scott Bradner},
title = {Key words for use in {RFCs} to Indicate Requirement Levels},
howpublished = {RFC 2119},
month = mar,
year = 1997,
publisher = {RFC Editor},
doi = {10.17487/RFC2119},
url = {https://www.rfc-editor.org/rfc/rfc2119},
}
@misc{rfc8174,
author = {Barry Leiba},
title = {Ambiguity of Uppercase vs Lowercase in {RFC} 2119 Key Words},
howpublished = {RFC 8174},
month = may,
year = 2017,
publisher = {RFC Editor},
doi = {10.17487/RFC8174},
url = {https://www.rfc-editor.org/rfc/rfc8174},
}
@misc{rfc9334,
author = {Henk Birkholz and Dave Thaler and Michael Richardson and Ned Smith and Wei Pan},
title = {Remote {ATtestation} Procedures ({RATS}) Architecture},
howpublished = {RFC 9334},
month = jan,
year = 2023,
publisher = {RFC Editor},
doi = {10.17487/RFC9334},
url = {https://www.rfc-editor.org/rfc/rfc9334},
}
@misc{rfc7519,
author = {Michael Jones and John Bradley and Nat Sakimura},
title = {{JSON} Web Token ({JWT})},
howpublished = {RFC 7519},
month = may,
year = 2015,
publisher = {RFC Editor},
doi = {10.17487/RFC7519},
url = {https://www.rfc-editor.org/rfc/rfc7519},
}
@misc{rfc9110,
author = {Roy Fielding and Mark Nottingham and Julian Reschke},
title = {{HTTP} Semantics},
howpublished = {RFC 9110},
month = jun,
year = 2022,
publisher = {RFC Editor},
doi = {10.17487/RFC9110},
url = {https://www.rfc-editor.org/rfc/rfc9110},
}
@misc{rfc8615,
author = {Mark Nottingham},
title = {Well-Known Uniform Resource Identifiers ({URIs})},
howpublished = {RFC 8615},
month = may,
year = 2019,
publisher = {RFC Editor},
doi = {10.17487/RFC8615},
url = {https://www.rfc-editor.org/rfc/rfc8615},
}
@misc{rfc6241,
author = {Rob Enns and Martin Bjorklund and Juergen Schoenwaelder and Andy Bierman},
title = {Network Configuration Protocol ({NETCONF})},
howpublished = {RFC 6241},
month = jun,
year = 2011,
publisher = {RFC Editor},
doi = {10.17487/RFC6241},
url = {https://www.rfc-editor.org/rfc/rfc6241},
}
% ============================================================
% IETF Internet-Drafts (companion drafts)
% ============================================================
@misc{id-wimse-ect,
author = {Christian Nennemann},
title = {Execution Context Tokens for Distributed Agentic Workflows},
howpublished = {Internet-Draft draft-nennemann-wimse-ect},
year = 2025,
url = {https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/},
}
@misc{id-dag-hitl-safety,
author = {Christian Nennemann},
title = {Agent Context Policy Token: {DAG} Delegation with Human Override},
howpublished = {Internet-Draft draft-nennemann-agent-dag-hitl-safety},
year = 2025,
url = {https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/},
}
@misc{id-exec-audit,
author = {Christian Nennemann},
title = {Cross-Domain Execution Audit Tokens},
howpublished = {Internet-Draft draft-nennemann-exec-audit},
year = 2025,
url = {https://datatracker.ietf.org/doc/draft-nennemann-exec-audit/},
}
@misc{id-behavioral-verification,
author = {Christian Nennemann},
title = {Agent Behavioral Verification and Performance Benchmarking},
howpublished = {Internet-Draft draft-nennemann-agent-behavioral-verification},
year = 2025,
url = {https://datatracker.ietf.org/doc/draft-nennemann-agent-behavioral-verification/},
}
@misc{id-cascade-prevention,
author = {Christian Nennemann},
title = {Agent Failure Cascade Prevention and Rollback},
howpublished = {Internet-Draft draft-nennemann-agent-cascade-prevention},
year = 2025,
url = {https://datatracker.ietf.org/doc/draft-nennemann-agent-cascade-prevention/},
}
@misc{id-consensus,
author = {Christian Nennemann},
title = {Multi-Agent Consensus and Capability Negotiation Protocols},
howpublished = {Internet-Draft draft-nennemann-agent-consensus},
year = 2025,
url = {https://datatracker.ietf.org/doc/draft-nennemann-agent-consensus/},
}
@misc{id-cross-domain-audit,
author = {Christian Nennemann},
title = {Cross-Domain Agent Audit Trails and Resource Accounting},
howpublished = {Internet-Draft draft-nennemann-agent-cross-domain-audit},
year = 2025,
url = {https://datatracker.ietf.org/doc/draft-nennemann-agent-cross-domain-audit/},
}
@misc{id-override-protocol,
author = {Christian Nennemann},
title = {Standardized Human Override Protocol for Autonomous Agents},
howpublished = {Internet-Draft draft-nennemann-agent-override-protocol},
year = 2025,
url = {https://datatracker.ietf.org/doc/draft-nennemann-agent-override-protocol/},
}
@misc{id-federation-privacy,
author = {Christian Nennemann},
title = {Federated Agent Learning Privacy and Cross-Protocol Migration},
howpublished = {Internet-Draft draft-nennemann-agent-federation-privacy},
year = 2025,
url = {https://datatracker.ietf.org/doc/draft-nennemann-agent-federation-privacy/},
}
@misc{id-gap-analysis,
author = {Christian Nennemann},
title = {Gap Analysis for Autonomous Agent Protocols},
howpublished = {Internet-Draft draft-nennemann-agent-gap-analysis-00},
year = 2025,
url = {https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/},
}
% ============================================================
% Industry protocols
% ============================================================
@misc{a2a-protocol,
author = {{Google}},
title = {Agent-to-Agent ({A2A}) Protocol Specification},
year = 2025,
url = {https://google.github.io/A2A/},
note = {Open specification for agent interoperability},
}
@misc{mcp-protocol,
author = {{Anthropic}},
title = {Model Context Protocol ({MCP}) Specification},
year = 2024,
url = {https://modelcontextprotocol.io/},
note = {Open protocol for LLM tool and context integration},
}
@misc{autogen,
author = {Qingyun Wu and Gagan Bansal and Jieyu Zhang and Yiran Wu and Beibin Li and Erkang Zhu and Li Jiang and Xiaoyun Zhang and Chi Wang},
title = {{AutoGen}: Enabling Next-Gen {LLM} Applications via Multi-Agent Conversation},
year = 2023,
eprint = {2308.08155},
archiveprefix = {arXiv},
primaryclass = {cs.AI},
}
@misc{crewai,
author = {{crewAI Inc.}},
title = {{CrewAI}: Framework for Orchestrating Role-Playing Autonomous {AI} Agents},
year = 2024,
url = {https://www.crewai.com/},
}
% ============================================================
% Academic references
% ============================================================
@article{ongaro2014raft,
author = {Diego Ongaro and John Ousterhout},
title = {In Search of an Understandable Consensus Algorithm},
journal = {Proceedings of the 2014 USENIX Annual Technical Conference (ATC)},
pages = {305--319},
year = 2014,
}
@article{lamport1998paxos,
author = {Leslie Lamport},
title = {The Part-Time Parliament},
journal = {ACM Transactions on Computer Systems},
volume = 16,
number = 2,
pages = {133--169},
year = 1998,
doi = {10.1145/279227.279229},
}
@article{castro1999pbft,
author = {Miguel Castro and Barbara Liskov},
title = {Practical {Byzantine} Fault Tolerance},
journal = {Proceedings of the Third Symposium on Operating Systems Design and Implementation (OSDI)},
pages = {173--186},
year = 1999,
}
@book{nygard2018releaseit,
author = {Michael T. Nygard},
title = {Release It!: Design and Deploy Production-Ready Software},
publisher = {Pragmatic Bookshelf},
edition = {2nd},
year = 2018,
isbn = {978-1680502398},
}
@article{mcmahan2017fedavg,
author = {Brendan McMahan and Eider Moore and Daniel Ramage and Seth Hampson and Blaise Ag{\"u}era y Arcas},
title = {Communication-Efficient Learning of Deep Networks from Decentralized Data},
journal = {Proceedings of the 20th International Conference on Artificial Intelligence and Statistics (AISTATS)},
pages = {1273--1282},
year = 2017,
}
@article{dwork2006diffprivacy,
author = {Cynthia Dwork},
title = {Differential Privacy},
journal = {Proceedings of the 33rd International Colloquium on Automata, Languages and Programming (ICALP)},
pages = {1--12},
year = 2006,
doi = {10.1007/11787006_1},
}
@article{wooldridge2009multiagent,
author = {Michael Wooldridge},
title = {An Introduction to {MultiAgent} Systems},
publisher = {John Wiley \& Sons},
edition = {2nd},
year = 2009,
isbn = {978-0470519462},
}
@article{dorri2018mas-iot,
author = {Ali Dorri and Salil S. Kanhere and Raja Jurdak},
title = {Multi-Agent Systems: A Survey},
journal = {IEEE Access},
volume = 6,
pages = {28573--28593},
year = 2018,
doi = {10.1109/ACCESS.2018.2831228},
}
@inproceedings{jennings1998agent-applications,
author = {Nicholas R. Jennings and Katia Sycara and Michael Wooldridge},
title = {A Roadmap of Agent Research and Development},
booktitle = {Autonomous Agents and Multi-Agent Systems},
volume = 1,
number = 1,
pages = {7--38},
year = 1998,
}
@article{kairouz2021fedlearning-advances,
author = {Peter Kairouz and H. Brendan McMahan and others},
title = {Advances and Open Problems in Federated Learning},
journal = {Foundations and Trends in Machine Learning},
volume = 14,
number = {1--2},
pages = {1--210},
year = 2021,
doi = {10.1561/2200000083},
}
@inproceedings{wang2024survey-llm-agents,
author = {Lei Wang and Chen Ma and Xueyang Feng and others},
title = {A Survey on Large Language Model based Autonomous Agents},
booktitle = {Frontiers of Computer Science},
volume = 18,
number = 6,
year = 2024,
doi = {10.1007/s11704-024-40231-1},
}
@misc{openai2023gpt4,
author = {{OpenAI}},
title = {{GPT-4} Technical Report},
year = 2023,
eprint = {2303.08774},
archiveprefix = {arXiv},
primaryclass = {cs.CL},
}

2511
workspace/drafts/gap-analysis/draft-nennemann-agent-behavioral-verification-00.html Normal file
View File

File diff suppressed because it is too large Load Diff

660
workspace/drafts/gap-analysis/draft-nennemann-agent-behavioral-verification-00.md Normal file
View File

@@ -0,0 +1,660 @@
---
title: >
Agent Behavioral Verification and
Performance Benchmarking
abbrev: "Agent Behavioral Verification"
category: std
docname: draft-nennemann-agent-behavioral-verification-00
area: "OPS"
workgroup: "NMOP"
submissiontype: IETF
v: 3
author:
- fullname: Christian Nennemann
organization: Independent Researcher
email: ietf@nennemann.de
normative:
RFC2119:
RFC8174:
RFC9334:
RFC7519:
RFC7515:
I-D.nennemann-wimse-ect:
title: "Execution Context Tokens for Distributed Agentic Workflows"
target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
I-D.nennemann-agent-dag-hitl-safety:
title: "Agent Context Policy Token: DAG Delegation with Human Override"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/
informative:
RFC9110:
I-D.nennemann-agent-gap-analysis:
title: "Gap Analysis for Autonomous Agent Protocols"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/
I-D.ietf-scitt-architecture:
--- abstract
This document defines protocols for runtime
verification that deployed AI agents behave
according to their declared policies. It also
specifies standardized metrics and a framework
for benchmarking agent performance across
implementations. Behavioral Evidence Tokens
(BETs) extend the Execution Context Token
architecture to provide cryptographically
verifiable proof of policy compliance.
Performance profiles enable objective comparison
of agent capabilities.
--- middle
# Introduction
Autonomous AI agents increasingly operate in
networked environments where they make decisions,
invoke tools, and delegate tasks to other agents.
Operators and relying parties need assurance that
these agents behave according to their declared
policies at runtime, not merely at deployment
time.
{{I-D.nennemann-agent-gap-analysis}} identifies
two critical gaps in the current standards
landscape:
- Gap 1 (Behavioral Verification): Agents
declare policies in their Execution Context
Tokens but no standardized mechanism exists to
verify that runtime behavior matches those
declarations.
- Gap 11 (Performance Benchmarking): No
standardized way exists to compare agent
implementations objectively across dimensions
such as task completion, latency, accuracy,
and safety compliance.
This document addresses both gaps by defining:
1. A behavioral verification architecture
aligned with the Remote Attestation Procedures
(RATS) framework {{RFC9334}}.
2. Behavioral Evidence Tokens (BETs) that extend
the Execution Context Token (ECT)
{{I-D.nennemann-wimse-ect}} with runtime
compliance claims.
3. A performance benchmarking framework with
standard metrics, benchmark profiles, and an
execution protocol.
# Terminology
{::boilerplate bcp14-tagged}
The following terms are used in this document:
Behavioral Attestation:
: The process of generating verifiable evidence
that an agent's runtime actions conform to its
declared policies.
Policy-Behavior Binding:
: A formal linkage between a declared policy in
an agent's ECT and observable runtime actions
that demonstrate compliance with that policy.
Behavioral Evidence Token (BET):
: A signed token containing claims about an
agent's observed runtime behavior relative to
its declared policies. BETs extend the ECT
architecture.
Runtime Monitor:
: A component that observes agent actions and
collects evidence for behavioral attestation.
Benchmark Suite:
: A collection of standardized test scenarios
designed to evaluate agent performance across
defined metrics.
Performance Profile:
: A structured record of benchmark results for
a specific agent implementation.
# Behavioral Verification Architecture
## Verification Model Overview
The behavioral verification architecture aligns
with the RATS {{RFC9334}} roles of Attester,
Verifier, and Relying Party. A Runtime Monitor
collects evidence of agent actions and produces
Behavioral Evidence Tokens.
~~~
+-------------+ +---------+
| Agent |------>| Runtime |
| (Attester) |actions| Monitor |
+-------------+ +----+----+
|
evidence
|
+----v----+
| BET |
| Creator |
+----+----+
|
BET
|
+---------v---------+
| Verifier |
| (Policy Engine) |
+---------+---------+
|
attestation result
|
+---------v---------+
| Relying Party |
| (Orchestrator / |
| Operator) |
+-------------------+
~~~
{: #fig-arch title="Behavioral Verification
Architecture"}
The architecture supports two modes of
operation:
- Continuous Monitoring: The Runtime Monitor
observes all agent actions in real time and
generates BETs at configurable intervals or
upon policy-relevant events.
- Point-in-Time Attestation: A Verifier
requests behavioral evidence for a specific
time window, and the Monitor assembles a BET
covering that period.
## Policy-Behavior Binding
A Policy-Behavior Binding declares the expected
behaviors associated with a policy and the
observable actions that constitute compliance.
The binding is expressed as a JSON object:
~~~json
{
"policy_id": "urn:example:policy:data-access",
"version": "1.0",
"expected_behaviors": [
{
"behavior_id": "bhv-001",
"description": "Agent accesses only
authorized data sources",
"observable_actions": [
"data_source_access"
],
"compliance_criteria": {
"type": "allowlist",
"values": [
"urn:example:ds:approved-1",
"urn:example:ds:approved-2"
]
}
}
],
"evaluation_mode": "continuous"
}
~~~
{: #fig-binding title="Policy-Behavior Binding
Structure"}
Each binding MUST include:
- `policy_id`: A URI identifying the policy.
- `expected_behaviors`: An array of behavior
descriptors.
- `evaluation_mode`: Either "continuous" or
"on_demand".
Each behavior descriptor MUST include:
- `behavior_id`: A unique identifier.
- `observable_actions`: Action types the monitor
MUST observe.
- `compliance_criteria`: The conditions under
which the behavior is considered compliant.
## Behavioral Evidence Tokens (BET)
A Behavioral Evidence Token is a JSON Web Token
(JWT) {{RFC7519}} signed using JSON Web Signature
(JWS) {{RFC7515}}. BETs extend the ECT claim
set with behavioral verification claims.
The following new claims are defined:
`bhv_policy`:
: REQUIRED. A URI reference to the policy being
verified.
`bhv_result`:
: REQUIRED. The verification result. One of
"pass", "fail", or "partial".
`bhv_evidence`:
: REQUIRED. A base64url-encoded hash (SHA-256)
of the collected observable actions during the
observation window.
`bhv_window`:
: REQUIRED. A JSON object with `start` and
`end` fields containing NumericDate values
(as defined in {{RFC7519}}) representing the
observation period.
`bhv_details`:
: OPTIONAL. An array of per-behavior results
with `behavior_id` and individual `result`
values.
Example BET payload:
~~~json
{
"iss": "urn:example:monitor:m-001",
"sub": "urn:example:agent:agent-42",
"iat": 1700000000,
"exp": 1700003600,
"bhv_policy": "urn:example:policy:data-access",
"bhv_result": "pass",
"bhv_evidence": "dGhpcyBpcyBhIGhhc2g...",
"bhv_window": {
"start": 1699996400,
"end": 1700000000
},
"bhv_details": [
{
"behavior_id": "bhv-001",
"result": "pass"
}
]
}
~~~
{: #fig-bet title="Example BET Payload"}
### BET Lifecycle
The lifecycle of a Behavioral Evidence Token
consists of three phases:
1. Creation: The Runtime Monitor collects
evidence of agent actions, evaluates them
against the Policy-Behavior Binding, and
constructs a BET with the appropriate claims.
The BET is signed by the Monitor's key.
2. Submission: The signed BET is submitted to
the Verifier. Submission MAY occur via a
push model (Monitor sends to Verifier) or a
pull model (Verifier requests from Monitor).
3. Verification: The Verifier validates the BET
signature, checks the claims against its
reference policies, and produces an
attestation result for the Relying Party.
## Runtime Monitoring Protocol
### Monitor Placement
Runtime Monitors MAY be deployed in one of three
configurations:
Inline:
: The Monitor intercepts all agent
communications as a proxy. This provides
complete visibility but adds latency.
Sidecar:
: The Monitor runs alongside the agent process
and receives copies of all actions via a local
interface. This minimizes latency while
maintaining visibility.
External:
: The Monitor operates as a separate service
that receives action logs asynchronously.
This provides the least overhead but may miss
real-time events.
### Observation Collection
The Monitor MUST maintain a time-ordered log of
observed actions. Each log entry MUST contain:
- Timestamp (NumericDate)
- Action type
- Action target (URI)
- Action parameters (opaque to the Monitor)
- Agent identifier
### Evidence Assembly
When assembling evidence for a BET, the Monitor
MUST:
1. Select all log entries within the observation
window.
2. Compute a SHA-256 hash over the canonical
JSON serialization of the selected entries.
3. Evaluate each entry against the applicable
Policy-Behavior Bindings.
4. Determine the aggregate `bhv_result`.
### Anomaly Detection Signaling
When the Monitor detects behavior that violates
a Policy-Behavior Binding, it MUST:
1. Generate a BET with `bhv_result` set to
"fail" or "partial".
2. Signal the anomaly to the Verifier
immediately, regardless of the configured
reporting interval.
3. Optionally signal the agent's orchestrator
to enable corrective action.
# Performance Benchmarking Framework
## Standard Metrics
The following metrics are defined for agent
performance benchmarking:
Task Completion Rate (TCR):
: The ratio of successfully completed tasks to
total tasks attempted. Unit: percentage (%).
Measured over a complete benchmark suite run.
Task Latency (TL):
: The time elapsed from task assignment to task
completion. Unit: milliseconds (ms).
Reported as p50, p95, and p99 percentiles.
Task Accuracy (TA):
: The degree to which task outputs match
expected results. Unit: percentage (%).
Measured using benchmark-specific evaluation
functions.
Resource Efficiency (RE):
: The computational resources consumed per task.
Unit: normalized resource units (NRU).
Includes CPU, memory, and network I/O.
Safety Compliance Score (SCS):
: The ratio of tasks completed without safety
policy violations to total tasks.
Unit: percentage (%).
Delegation Success Rate (DSR):
: The ratio of successful delegations to total
delegation attempts. Unit: percentage (%).
Applicable only to multi-agent scenarios.
## Benchmark Profiles
A Benchmark Profile defines a standardized set
of test scenarios for a specific agent category.
Profiles are expressed as JSON objects:
~~~json
{
"profile_id": "urn:ietf:bench:general-v1",
"profile_name": "General Agent Benchmark",
"version": "1.0",
"agent_category": "general-purpose",
"scenarios": [
{
"scenario_id": "s-001",
"description": "Simple data retrieval",
"difficulty": "basic",
"metrics": ["TCR", "TL", "TA"],
"timeout_ms": 30000,
"expected_output_schema": "..."
}
],
"scoring": {
"weights": {
"TCR": 0.3,
"TL": 0.2,
"TA": 0.3,
"SCS": 0.2
}
}
}
~~~
{: #fig-profile title="Benchmark Profile
Structure"}
Predefined profiles SHOULD be registered for
common agent types including:
- General-purpose agents
- Code generation agents
- Data analysis agents
- Network management agents
## Benchmark Execution Protocol
### Test Harness Requirements
A conformant test harness MUST:
1. Execute all scenarios in the benchmark
profile in a controlled environment.
2. Isolate agent instances from external
resources not specified in the scenario.
3. Record all metrics defined in the profile.
4. Produce a benchmark result document.
### Result Reporting Format
Benchmark results MUST be reported as a JSON
object containing:
- `profile_id`: The benchmark profile used.
- `agent_id`: Identifier of the tested agent.
- `timestamp`: Time of benchmark execution.
- `results`: Per-scenario metric values.
- `aggregate`: Weighted aggregate scores.
### Anti-Gaming Provisions
To prevent agents from gaming benchmark results,
the following provisions apply:
1. Randomized Scenarios: Test harnesses MUST
randomize scenario ordering and MAY
introduce minor variations in scenario
parameters.
2. Blind Evaluation: The agent under test
MUST NOT have access to the expected
outputs or evaluation functions.
3. Holdback Scenarios: Benchmark profiles
SHOULD include scenarios not disclosed to
agent developers.
4. Temporal Variation: Repeated benchmark
runs MUST vary timing to prevent
memoization attacks.
## Performance Claims in ECT
Agent ECTs MAY include performance attestation
claims in the `ext` field:
`perf_profile`:
: The benchmark profile identifier.
`perf_score`:
: The aggregate benchmark score.
`perf_timestamp`:
: The time of the benchmark execution.
`perf_harness`:
: Identifier of the test harness that produced
the results.
These claims allow relying parties to evaluate
agent capability before delegation.
# Integration with ECT
Behavioral Evidence Tokens integrate into the
ECT DAG defined in
{{I-D.nennemann-agent-dag-hitl-safety}} as
follows:
1. Each BET references the ECT of the agent
whose behavior was verified via the `sub`
claim.
2. BETs are attached as child nodes in the
ECT DAG, linked to the agent's execution
node.
3. When an agent delegates to a sub-agent,
the delegating agent's BET chain includes
evidence covering the delegation decision.
4. Verifiers traversing the DAG can inspect
BETs at each node to assess behavioral
compliance across the entire execution
chain.
~~~
+----------+ +----------+
| ECT |---->| ECT |
| Agent A | | Agent B |
+----+-----+ +----+-----+
| |
+----v-----+ +----v-----+
| BET | | BET |
| Agent A | | Agent B |
+----------+ +----------+
~~~
{: #fig-dag title="BET Integration in ECT DAG"}
This structure enables end-to-end behavioral
verification across multi-agent workflows.
# Security Considerations
## Adversarial Behavior
Agents MAY attempt to behave correctly only when
they detect monitoring. Mitigations include:
- Unpredictable monitoring intervals
- Covert observation modes where the agent is
not informed of monitor presence
- Cross-referencing BETs with external audit
logs
## Monitor Compromise
A compromised Runtime Monitor could produce
fraudulent BETs. Mitigations include:
- Monitor attestation using RATS {{RFC9334}}
- Multiple independent monitors with
cross-validation
- Transparency logs for BETs, aligned with
SCITT {{I-D.ietf-scitt-architecture}}
## Benchmark Manipulation
Agents or their operators MAY attempt to
manipulate benchmark results. The anti-gaming
provisions in Section 4.3.3 address this risk.
Additionally:
- Benchmark harnesses MUST be operated by
independent parties.
- Results MUST be signed by the harness
operator.
- Benchmark profiles MUST be versioned and
immutable once published.
## Privacy of Behavioral Evidence
BETs contain information about agent actions
that may be sensitive. Implementations MUST:
- Minimize the detail in `bhv_evidence` to
what is necessary for verification.
- Support selective disclosure where possible.
- Protect BETs in transit using TLS
({{RFC9110}}).
- Define retention policies for behavioral
evidence.
# IANA Considerations
## ECT Extension Claim Keys
This document requests registration of the
following claim keys in the ECT `ext` claims
registry:
| Claim Key | Description |
|:---------------|:---------------------------|
| bhv_policy | Policy URI reference |
| bhv_result | Verification result |
| bhv_evidence | Observed actions hash |
| bhv_window | Observation period |
| bhv_details | Per-behavior results |
| perf_profile | Benchmark profile ID |
| perf_score | Aggregate benchmark score |
| perf_timestamp | Benchmark execution time |
| perf_harness | Test harness identifier |
{: #tbl-claims title="ECT Extension Claims for
Behavioral Verification"}
## Benchmark Profile Media Type
This document requests registration of the
following media type:
Type name: application
Subtype name: agent-benchmark-profile+json
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary (UTF-8 JSON)
Security considerations: See Section 6
--- back
# Acknowledgments
{:numbered="false"}
The author thanks the contributors to the NMOP
working group for discussions on agent
operational requirements.

1110
workspace/drafts/gap-analysis/draft-nennemann-agent-behavioral-verification-00.xml Normal file
View File

File diff suppressed because it is too large Load Diff

3175
workspace/drafts/gap-analysis/draft-nennemann-agent-cascade-prevention-00.html Normal file
View File

File diff suppressed because it is too large Load Diff

907
workspace/drafts/gap-analysis/draft-nennemann-agent-cascade-prevention-00.md Normal file
View File

@@ -0,0 +1,907 @@
---
title: "Agent Failure Cascade Prevention and Rollback"
abbrev: "Agent Cascade Prevention"
category: std
docname: draft-nennemann-agent-cascade-prevention-00
submissiontype: IETF
number:
date:
v: 3
area: "OPS"
workgroup: "NMOP"
keyword:
- cascade prevention
- circuit breaker
- rollback
- failure domain
- agent recovery
author:
-
fullname: Christian Nennemann
organization: Independent Researcher
email: ietf@nennemann.de
normative:
RFC2119:
RFC8174:
RFC7519:
RFC7515:
RFC9110:
I-D.nennemann-wimse-ect:
title: "Execution Context Tokens for Distributed Agentic Workflows"
target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
I-D.nennemann-agent-dag-hitl-safety:
title: "Agent Context Policy Token: DAG Delegation with Human Override"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/
informative:
I-D.nennemann-agent-gap-analysis:
title: "Gap Analysis of IETF Standards for Autonomous AI Agent Networking"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/
--- abstract
This document defines protocols for preventing agent failures from
cascading across interconnected autonomous systems and standardized
mechanisms for real-time rollback of incorrect agent decisions. It
specifies a circuit breaker protocol with well-defined state
transitions, failure domain isolation through bulkhead patterns, cascade
detection via error rate and latency analysis, and a distributed
rollback coordination protocol that walks the Execution Context Token
(ECT) DAG backwards to revert agent actions to a known-good state.
This document absorbs and supersedes the concepts introduced in earlier
AERR and ATD proposals.
--- middle
# Introduction
Autonomous AI agents increasingly operate in interconnected
multi-agent systems where a single agent's failure can propagate
through the network, causing widespread service disruption. The IETF
gap analysis {{I-D.nennemann-agent-gap-analysis}} identified two
critical gaps in existing standards:
- **Gap 2 (Cascade Prevention)**: No standard mechanism exists for
containing failures within agent ecosystems. When one agent fails,
dependent agents continue sending requests to the failing agent,
amplifying the failure across the system.
- **Gap 4 (Rollback)**: No standard protocol exists for reverting
incorrect agent decisions. When an autonomous agent misconfigures
a network device or makes an erroneous API call, there is no
interoperable way to undo the action or coordinate rollback across
multiple affected agents.
This document addresses both gaps by defining:
1. A circuit breaker protocol that stops failure propagation between
agents.
2. Failure domain isolation mechanisms that contain blast radius.
3. Cascade detection signals that identify propagating failures early.
4. A distributed rollback protocol that coordinates state reversion
across multiple agents using the ECT DAG
{{I-D.nennemann-wimse-ect}}.
This specification absorbs and supersedes the concepts from the earlier
Agent Error Recovery and Rollback (AERR) and Agent Task DAG (ATD)
proposals, consolidating cascade prevention and rollback into a single
coherent protocol built on ECT infrastructure.
Design principles:
1. Agents that take consequential actions MUST be able to undo them,
or MUST declare them irreversible upfront.
2. Failure containment takes priority over failure diagnosis.
3. The protocol adds minimal overhead to the happy path.
4. All cascade prevention and rollback actions are recorded as ECT
nodes, providing a cryptographic audit trail.
# Terminology
{::boilerplate bcp14-tagged}
Circuit Breaker:
: A mechanism that stops an agent from propagating requests to a
failing downstream agent, preventing cascading failures. Modeled
after the electrical circuit breaker pattern used in microservice
architectures.
Failure Domain:
: A bounded set of agents and resources within which a failure is
contained. Failures within a domain MUST NOT propagate beyond the
domain boundary without explicit escalation.
Blast Radius:
: The set of agents and systems affected by a single agent's failure,
determinable by traversing the ECT DAG forward from the failing
node.
Cascade Detection:
: The process of identifying that a failure is propagating across
agent boundaries, using signals such as error rate spikes, latency
increases, and resource exhaustion patterns.
Rollback Coordinator:
: An agent or orchestrator responsible for coordinating distributed
rollback across multiple agents in a workflow, ensuring consistency
and resolving conflicts.
Checkpoint:
: An ECT node recording an agent's state hash before a consequential
action, providing a restore point for rollback.
Compensating Action:
: An action that semantically reverses the effect of a prior action
when direct state restoration is not possible (e.g., deleting a
resource that was created, rather than restoring a pre-creation
snapshot).
Recovery Point:
: The most recent checkpoint in the ECT DAG to which an agent or
workflow can be safely rolled back without violating consistency
constraints.
# Failure Cascade Prevention
## Cascade Model
When an agent fails in a multi-agent system, the failure can
propagate through multiple vectors. The following diagram
illustrates a typical cascade scenario:
~~~
Agent A Agent B Agent C Agent D
| | | |
| request | | |
|--------------->| | |
| | request | |
| |--------------->| |
| | | request |
| | |--------------->|
| | | |
| | | FAILURE |
| | |<--- X ---------|
| | | |
| | error/timeout | |
| |<---------------| |
| | | |
| error/timeout | | |
|<---------------| | |
| | | |
| [CASCADE: all agents impacted by D's failure] |
| | | |
~~~
{: #fig-cascade title="Failure Cascade Propagation"}
### Failure Domain Taxonomy
Failures in agent ecosystems fall into the following categories:
Agent-Local Failure:
: A failure confined to a single agent instance (e.g., out-of-memory,
logic error). The blast radius is limited to the agent itself and
its immediate callers.
Service Failure:
: A failure affecting all instances of a particular agent service
(e.g., model endpoint unavailable). The blast radius includes all
agents that depend on the failing service.
Infrastructure Failure:
: A failure in shared infrastructure (e.g., network partition,
certificate authority unavailable). The blast radius may span
multiple failure domains.
Semantic Failure:
: An agent produces incorrect output without raising an error (e.g.,
misconfiguration, wrong decision). This is the hardest category
to detect and may propagate silently through the DAG.
### Propagation Vectors in Agent Ecosystems
Failures propagate through the following vectors:
1. **Synchronous request chains**: An agent blocks waiting for a
failing downstream agent, causing its own callers to time out.
2. **Shared state corruption**: An agent writes incorrect data to a
shared store, causing other agents reading that data to fail or
make incorrect decisions.
3. **Resource exhaustion**: A failing agent consumes excessive
resources (connections, memory, compute), starving healthy agents.
4. **Retry amplification**: Multiple agents retry requests to a
failing agent simultaneously, overwhelming it further.
## Circuit Breaker Protocol
Each agent MUST implement a circuit breaker for every downstream
agent it communicates with.
### States
The circuit breaker has four states:
CLOSED (normal):
: Requests flow through normally. The agent tracks the error rate
over a sliding window (default: 60 seconds).
OPEN (failure detected):
: When the error rate exceeds the configured threshold (default: 50%
over the window), the breaker opens. All requests to the
downstream agent are immediately rejected locally. The agent
MUST emit an ECT with `exec_act` value `"circuit_breaker_open"`.
HALF_OPEN (recovery probe):
: After a cooldown period (default: 30 seconds), the breaker
transitions to HALF_OPEN and allows a single probe request. If
the probe succeeds, the breaker returns to CLOSED. If the probe
fails, the breaker returns to OPEN with doubled cooldown
(exponential backoff, maximum 300 seconds).
CLOSED (recovered):
: When a probe succeeds in the HALF_OPEN state, the breaker returns
to CLOSED and the agent MUST emit an ECT with `exec_act` value
`"circuit_breaker_close"`.
### State Transition Rules
~~~
error_rate > threshold
CLOSED ────────────────────────────────► OPEN
▲ │
│ probe succeeds │ cooldown expires
│ ▼
└──────────────────────────────── HALF_OPEN
│
probe fails │
▼
OPEN
(cooldown *= 2,
max 300s)
~~~
{: #fig-circuit-fsm title="Circuit Breaker State Machine"}
The following rules govern state transitions:
1. CLOSED to OPEN: The error rate over the sliding window exceeds
the configured threshold. The agent MUST emit a
`"circuit_breaker_open"` ECT and reject all subsequent requests
to the downstream agent.
2. OPEN to HALF_OPEN: The cooldown timer expires. The agent MUST
allow exactly one probe request through.
3. HALF_OPEN to CLOSED: The probe request succeeds. The agent MUST
emit a `"circuit_breaker_close"` ECT and resume normal operation.
The error rate counters MUST be reset.
4. HALF_OPEN to OPEN: The probe request fails. The cooldown period
MUST be doubled (up to a maximum of 300 seconds).
### Circuit Breaker Registration and Discovery
Agents MUST expose circuit breaker state at a well-known endpoint:
~~~
GET /.well-known/cascade/circuits HTTP/1.1
~~~
Response:
~~~json
{
"circuits": [
{
"downstream_agent": "spiffe://example.com/agent/router-mgr",
"state": "open",
"error_rate": 0.75,
"window_s": 60,
"last_failure_ect": "550e8400-e29b-41d4-a716-446655440099",
"cooldown_remaining_s": 22
}
]
}
~~~
{: #fig-circuits title="Circuit Breaker Status Endpoint"}
### ECT Integration
Each circuit breaker state change MUST produce an ECT node:
~~~json
{
"jti": "cb-open-uuid",
"exec_act": "circuit_breaker_open",
"par": ["error-ect-uuid"],
"ext": {
"cascade.downstream_agent":
"spiffe://example.com/agent/router-mgr",
"cascade.error_rate": 0.75,
"cascade.window_s": 60,
"cascade.cooldown_s": 30
}
}
~~~
{: #fig-cb-ect title="Circuit Breaker Open ECT"}
~~~json
{
"jti": "cb-close-uuid",
"exec_act": "circuit_breaker_close",
"par": ["cb-open-uuid"],
"ext": {
"cascade.downstream_agent":
"spiffe://example.com/agent/router-mgr",
"cascade.total_cooldown_s": 30
}
}
~~~
{: #fig-cb-close-ect title="Circuit Breaker Close ECT"}
## Failure Domain Isolation
### Blast Radius Containment Strategies
Agents MUST implement the following containment strategies:
1. **Request rejection at the boundary**: When a circuit breaker
opens, the agent MUST return a structured error to its callers
indicating that the downstream dependency is unavailable, rather
than propagating the failure.
2. **Timeout enforcement**: Agents MUST enforce timeouts on all
downstream requests. The timeout MUST be shorter than the
caller's timeout to prevent timeout cascades.
3. **Graceful degradation**: When a non-critical downstream agent
is unavailable, agents SHOULD continue operating with reduced
functionality rather than failing entirely.
### Domain Boundary Enforcement
Failure domains are defined by the workflow topology in the ECT DAG.
Each workflow (identified by the `wid` claim) constitutes a failure
domain. Cross-workflow failures MUST be escalated through the HITL
mechanism {{I-D.nennemann-agent-dag-hitl-safety}} rather than
propagating automatically.
Agents at domain boundaries MUST:
1. Validate all incoming requests against the circuit breaker state
of their downstream dependencies before accepting work.
2. Emit a `"circuit_breaker_open"` ECT when rejecting work due to
downstream unavailability.
3. Report domain health status via the circuits endpoint.
### Bulkhead Patterns for Agent Pools
When multiple workflows share a common agent pool, the pool MUST
implement bulkhead isolation:
1. **Connection limits**: Each workflow MUST have a maximum number
of concurrent connections to the shared agent pool.
2. **Queue isolation**: Each workflow's requests MUST be queued
independently, preventing one workflow's backlog from blocking
others.
3. **Resource quotas**: Shared agent pools SHOULD enforce per-workflow
resource quotas (CPU, memory, request rate).
## Cascade Detection
### Detection Signals
Agents MUST monitor the following signals for cascade detection:
Error Rate:
: The ratio of failed requests to total requests over a sliding
window. An error rate exceeding the circuit breaker threshold
indicates a potential cascade.
Latency Spike:
: A sudden increase in response latency (e.g., p99 latency exceeding
3x the baseline) indicates downstream congestion or failure.
Agents SHOULD track latency baselines using exponentially weighted
moving averages.
Resource Exhaustion:
: Thread pool saturation, connection pool exhaustion, or memory
pressure above configured thresholds indicates that a cascade is
consuming resources.
### Propagation Tracking via ECT DAG Analysis
Orchestrators SHOULD analyze the ECT DAG to detect cascading
patterns:
1. **Error clustering**: Multiple `"circuit_breaker_open"` ECTs
referencing the same downstream agent within a short window
indicate a shared dependency failure.
2. **Depth-first propagation**: Errors propagating along `par`
chains in the DAG indicate a synchronous cascade.
3. **Breadth-first propagation**: Multiple sibling nodes in the
DAG failing concurrently indicate a shared infrastructure
failure.
### Alert Format and Escalation
When cascade detection identifies a propagating failure, the
detecting agent MUST emit a cascade alert ECT:
~~~json
{
"exec_act": "cascade_detected",
"ext": {
"cascade.pattern": "depth_first",
"cascade.affected_agents": 4,
"cascade.root_cause_ect": "error-ect-uuid",
"cascade.blast_radius": [
"spiffe://example.com/agent/a",
"spiffe://example.com/agent/b",
"spiffe://example.com/agent/c"
]
}
}
~~~
{: #fig-cascade-alert title="Cascade Alert ECT"}
Cascade alerts with more than 3 affected agents SHOULD trigger
HITL escalation per {{I-D.nennemann-agent-dag-hitl-safety}}.
# Real-Time Rollback
## Rollback Model
Rollback reverses the effects of agent actions by walking the ECT
DAG backwards from the point of failure to the nearest valid
recovery point.
### Walking the ECT DAG Backwards
The rollback process follows `par` references in reverse:
1. Identify the failing ECT node.
2. Find the checkpoint ECT associated with the failing action
(referenced via `par`).
3. Follow `par` references backwards to identify all downstream
actions that were caused by the checkpointed action.
4. Issue rollback requests to each affected agent in reverse
topological order.
~~~
Checkpoint A ──► Action A1 ──► Checkpoint B ──► Action B1
│
└──► Action B2
Rollback order: B2, B1, B, A1, A (reverse topological)
~~~
{: #fig-rollback-order title="Rollback Order via DAG Traversal"}
### Compensating Actions vs State Restoration
Rollback can be performed through two mechanisms:
State Restoration:
: The agent restores its state from the checkpoint snapshot. This
is the preferred mechanism when the checkpoint contains a complete
state snapshot (verified via `out_hash`).
Compensating Action:
: When state restoration is not possible (e.g., the action involved
an external API call), the agent executes a compensating action
that semantically reverses the original action. Compensating
actions MUST be recorded as ECT nodes with `exec_act` value
`"compensate"`.
### Rollback Scope
Rollback can be scoped to three levels:
Single Agent:
: Only the specified agent's checkpoint is rolled back. No
downstream propagation occurs.
Sub-DAG:
: The checkpoint and all downstream checkpoints in the sub-DAG
are rolled back. This is the default when `cascade` is `true`.
Full Workflow:
: All checkpoints in the workflow are rolled back and the workflow
is terminated. This requires Rollback Coordinator authorization.
## Checkpoint Protocol
### Checkpoint Creation
An agent MUST create a checkpoint ECT before any consequential
action. An action is consequential if it modifies external state
(network configuration, database records, API calls with side
effects).
A checkpoint is an ECT with:
- `exec_act`: `"checkpoint"`
- `par`: the ECT of the action being checkpointed
- `out_hash`: SHA-256 hash of the agent's state snapshot
~~~json
{
"jti": "ckpt-uuid",
"exec_act": "checkpoint",
"par": ["action-ect-uuid"],
"out_hash": "sha256:...",
"ext": {
"cascade.reversible": true,
"cascade.rollback_uri":
"https://agent-b.example.com/.well-known/cascade/rollback",
"cascade.target": "router-07.example.com",
"cascade.description": "Update BGP peer configuration",
"cascade.ttl": 86400
}
}
~~~
{: #fig-checkpoint title="Checkpoint ECT"}
The `cascade.reversible` field MUST be present. If `false`, the
agent declares that this action cannot be automatically undone and
rollback requests MUST be escalated to a human operator via the
HITL mechanism {{I-D.nennemann-agent-dag-hitl-safety}}.
### Checkpoint Storage and Retrieval
Checkpoint ECTs MUST be stored for at least the duration specified
by `cascade.ttl`. Agents MUST store checkpoints in durable storage
that survives agent restarts.
Agents MUST expose a checkpoint retrieval endpoint:
~~~
GET /.well-known/cascade/checkpoints/{jti} HTTP/1.1
~~~
The response MUST include the checkpoint ECT and its verification
status (whether `out_hash` matches the current stored state snapshot).
### Checkpoint Verification
Before executing a rollback, the agent MUST verify the checkpoint
integrity:
1. Retrieve the checkpoint ECT.
2. Verify the ECT signature chain (L2/L3).
3. Verify that the stored state snapshot matches `out_hash`.
4. Verify that the checkpoint has not expired (`cascade.ttl`).
If verification fails, the agent MUST reject the rollback request
and emit an error ECT.
## Distributed Rollback Coordination
### Rollback Coordinator Role
For rollbacks spanning multiple agents (sub-DAG or full workflow
scope), a Rollback Coordinator MUST be designated. The coordinator
is typically the orchestrator or the agent that initiated the
workflow.
The coordinator is responsible for:
1. Computing the blast radius by traversing the ECT DAG.
2. Determining rollback order (reverse topological sort).
3. Issuing rollback requests to each affected agent.
4. Tracking rollback progress and handling failures.
5. Emitting the final rollback completion ECT.
### Two-Phase Rollback Protocol
Distributed rollback follows a two-phase protocol:
**Phase 1: Prepare**
The coordinator sends a prepare request to each affected agent:
~~~
POST /.well-known/cascade/rollback/prepare HTTP/1.1
Content-Type: application/json
Execution-Context: <prepare-ect>
{
"rollback_id": "urn:uuid:...",
"checkpoint_id": "ckpt-uuid",
"scope": "sub_dag"
}
~~~
{: #fig-prepare title="Rollback Prepare Request"}
Each agent MUST respond with either:
- `"prepared"`: The agent has verified its checkpoint and is ready
to roll back.
- `"cannot_prepare"`: The agent cannot roll back (e.g., checkpoint
expired, irreversible action).
**Phase 2: Execute**
If all agents respond `"prepared"`, the coordinator sends execute
requests in reverse topological order:
~~~
POST /.well-known/cascade/rollback HTTP/1.1
Content-Type: application/json
Execution-Context: <rollback-ect>
{
"rollback_id": "urn:uuid:...",
"checkpoint_id": "ckpt-uuid",
"phase": "execute"
}
~~~
{: #fig-execute title="Rollback Execute Request"}
If any agent responds `"cannot_prepare"` in Phase 1, the
coordinator MUST either:
- Proceed with partial rollback (if the unprepared agent is not
on the critical path), or
- Abort the rollback and escalate to HITL.
### Partial Rollback Handling
When a distributed rollback cannot be completed fully, the
coordinator MUST:
1. Roll back all agents that responded `"prepared"`.
2. Record the partial rollback result in the ECT DAG.
3. Emit an ECT with `exec_act` value `"rollback_complete"` and
`cascade.status` set to `"partial"`.
4. Include the list of agents that could not be rolled back in
the `cascade.failed_agents` extension claim.
### Conflict Resolution During Concurrent Rollbacks
When multiple rollback requests target overlapping portions of the
ECT DAG:
1. The rollback with the broader scope takes precedence (full
workflow > sub-DAG > single agent).
2. If scopes are equal, the earlier rollback request (by timestamp)
takes precedence.
3. The losing rollback request MUST be rejected with an error
indicating the conflicting rollback ID.
Agents MUST implement idempotent rollback: receiving the same
`rollback_id` twice MUST return the same result without
re-executing the rollback.
## Rollback Evidence
### ECT Nodes for Rollback Actions
Each rollback action MUST produce ECT nodes for audit:
Rollback Start:
: `exec_act`: `"rollback_start"`, `par` references the error ECT
that triggered the rollback.
~~~json
{
"jti": "rb-start-uuid",
"exec_act": "rollback_start",
"par": ["error-ect-uuid"],
"ext": {
"cascade.rollback_id": "urn:uuid:...",
"cascade.checkpoint_id": "ckpt-uuid",
"cascade.scope": "sub_dag",
"cascade.reason": "Upstream cascading failure"
}
}
~~~
{: #fig-rb-start title="Rollback Start ECT"}
Rollback Complete:
: `exec_act`: `"rollback_complete"`, `par` references the rollback
start ECT.
~~~json
{
"jti": "rb-complete-uuid",
"exec_act": "rollback_complete",
"par": ["rb-start-uuid"],
"out_hash": "sha256:...",
"ext": {
"cascade.rollback_id": "urn:uuid:...",
"cascade.status": "completed",
"cascade.state_hash_before": "sha256:...",
"cascade.state_hash_after": "sha256:...",
"cascade.cascaded": [
{
"agent": "spiffe://example.com/agent/monitor",
"status": "completed"
},
{
"agent": "spiffe://example.com/agent/classify",
"status": "escalated"
}
]
}
}
~~~
{: #fig-rb-complete title="Rollback Complete ECT"}
### Rollback Audit Trail
The complete rollback audit trail is captured in the ECT DAG:
~~~
error ECT
│
▼
rollback_start ECT
│
├──► agent-A rollback_complete ECT
│
├──► agent-B rollback_complete ECT
│
└──► agent-C compensate ECT
~~~
{: #fig-rb-audit title="Rollback Audit Trail in ECT DAG"}
Status values for individual agent rollbacks: `completed`,
`partial`, `escalated`, `failed`.
# ECT Integration
This document defines the following new `exec_act` values for use
in ECT nodes {{I-D.nennemann-wimse-ect}}:
| `exec_act` Value | Description |
|-----------------|-------------|
| `circuit_breaker_open` | Circuit breaker transitioned to OPEN state |
| `circuit_breaker_close` | Circuit breaker transitioned to CLOSED state |
| `checkpoint` | State snapshot before consequential action |
| `rollback_start` | Rollback initiated for a checkpoint |
| `rollback_complete` | Rollback finished (with status) |
| `compensate` | Compensating action executed in lieu of state restoration |
| `cascade_detected` | Cascading failure pattern detected |
{: #fig-exec-act-values title="New exec_act Values"}
This document defines the following new `ext` claims for failure
context:
| Claim | Type | Description |
|-------|------|-------------|
| `cascade.downstream_agent` | string | SPIFFE ID of the downstream agent |
| `cascade.error_rate` | number | Error rate that triggered the circuit breaker |
| `cascade.window_s` | number | Sliding window duration in seconds |
| `cascade.cooldown_s` | number | Cooldown duration in seconds |
| `cascade.reversible` | boolean | Whether the checkpointed action can be undone |
| `cascade.rollback_uri` | string | URI for rollback requests |
| `cascade.target` | string | Target system of the checkpointed action |
| `cascade.ttl` | number | Checkpoint time-to-live in seconds |
| `cascade.rollback_id` | string | Unique identifier for a rollback operation |
| `cascade.checkpoint_id` | string | JTI of the checkpoint being rolled back |
| `cascade.scope` | string | Rollback scope: single, sub_dag, full_workflow |
| `cascade.status` | string | Rollback result status |
| `cascade.reason` | string | Human-readable reason for the action |
| `cascade.pattern` | string | Detected cascade pattern type |
| `cascade.affected_agents` | number | Count of agents affected by cascade |
| `cascade.blast_radius` | array | SPIFFE IDs of affected agents |
| `cascade.cascaded` | array | Per-agent rollback results |
| `cascade.failed_agents` | array | Agents that could not be rolled back |
| `cascade.state_hash_before` | string | State hash before rollback |
| `cascade.state_hash_after` | string | State hash after rollback |
| `cascade.description` | string | Human-readable description |
{: #fig-ext-claims title="New ext Claims for Cascade Prevention"}
# Security Considerations
## Rollback Weaponization
Malicious agents could attempt to force unnecessary rollbacks to
disrupt workflows. Mitigations:
1. Rollback requests MUST be authenticated via the ECT signature
chain. Only agents whose ECTs appear in the same workflow DAG
(identified by `wid`) are authorized to request rollback.
2. Rollback requests from outside the originating workflow MUST be
rejected with HTTP 403.
3. Agents SHOULD implement rate limiting on rollback requests to
prevent denial-of-service through rollback flooding.
4. The two-phase rollback protocol provides a prepare phase where
agents can validate the rollback request before committing.
## Circuit Breaker Manipulation
An adversary could attempt to manipulate circuit breaker state to
either prevent legitimate circuit breaking or force unnecessary
circuit breaks:
1. **False error injection**: A malicious agent could emit false
error ECTs to trigger circuit breakers. At L2/L3
{{I-D.nennemann-wimse-ect}}, ECT signatures prevent forgery.
Agents SHOULD verify that error ECTs reference valid `par`
values within their own workflow DAG.
2. **Circuit breaker suppression**: An adversary could attempt to
reset circuit breakers by sending successful probe responses.
Agents MUST only accept probe responses from the actual
downstream agent (verified via ECT identity binding).
3. **Status endpoint abuse**: The `/.well-known/cascade/circuits`
endpoint reveals system health topology. This endpoint MUST
require authentication and SHOULD be restricted to agents within
the same administrative domain.
## Checkpoint Integrity
Checkpoint state snapshots contain sensitive system state. Agents
MUST:
1. Encrypt stored checkpoint state at rest.
2. Reference checkpoint state via `out_hash` only in ECTs; MUST NOT
include checkpoint contents in ECT claims.
3. Verify `out_hash` integrity before executing rollback to prevent
rollback to a tampered state.
4. Enforce checkpoint storage quotas to prevent checkpoint flooding
attacks.
5. Purge expired checkpoints (past `cascade.ttl`).
# IANA Considerations
## Registration of exec_act Values
This document requests registration of the following `exec_act`
values in the ECT exec_act registry:
| Value | Description | Reference |
|-------|-------------|-----------|
| `circuit_breaker_open` | Circuit breaker transitioned to OPEN | This document |
| `circuit_breaker_close` | Circuit breaker transitioned to CLOSED | This document |
| `checkpoint` | State snapshot before consequential action | This document |
| `rollback_start` | Rollback operation initiated | This document |
| `rollback_complete` | Rollback operation finished | This document |
| `compensate` | Compensating action executed | This document |
| `cascade_detected` | Cascading failure pattern detected | This document |
{: #fig-iana-exec-act title="exec_act Value Registrations"}
## Registration of ext Claims
This document requests registration of the `ext` claims listed in
{{fig-ext-claims}} in the ECT extension claims registry. All claims
use the `cascade.` namespace prefix.
## Well-Known URI Registration
This document requests registration of the following well-known URI
suffixes per {{RFC9110}}:
| URI Suffix | Description | Reference |
|------------|-------------|-----------|
| `cascade/circuits` | Circuit breaker status | This document |
| `cascade/rollback` | Rollback request endpoint | This document |
| `cascade/rollback/prepare` | Rollback prepare endpoint | This document |
| `cascade/checkpoints` | Checkpoint retrieval | This document |
{: #fig-iana-uris title="Well-Known URI Registrations"}
--- back
# Acknowledgments
{:numbered="false"}
This document absorbs and supersedes concepts from the earlier Agent
Error Recovery and Rollback (AERR) and Agent Task DAG (ATD) proposals.
It builds on the Execution Context Token specification
{{I-D.nennemann-wimse-ect}} for DAG-based audit trails and the Agent
Context Policy Token {{I-D.nennemann-agent-dag-hitl-safety}} for HITL
escalation of irreversible actions. The circuit breaker pattern is
adapted from microservice architecture best practices.

1452
workspace/drafts/gap-analysis/draft-nennemann-agent-cascade-prevention-00.xml Normal file
View File

File diff suppressed because it is too large Load Diff

2668
workspace/drafts/gap-analysis/draft-nennemann-agent-consensus-00.html Normal file
View File

File diff suppressed because it is too large Load Diff

597
workspace/drafts/gap-analysis/draft-nennemann-agent-consensus-00.md Normal file
View File

@@ -0,0 +1,597 @@
---
title: "Multi-Agent Consensus and Capability Negotiation Protocols"
abbrev: "Agent Consensus"
category: std
docname: draft-nennemann-agent-consensus-00
area: "OPS"
workgroup: "NMOP"
submissiontype: IETF
v: 3
author:
- fullname: Christian Nennemann
organization: Independent Researcher
email: ietf@nennemann.de
normative:
RFC2119:
RFC8174:
RFC7519:
RFC7515:
RFC9110:
I-D.nennemann-wimse-ect:
title: "Execution Context Tokens for Distributed Agentic Workflows"
target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
I-D.nennemann-agent-dag-hitl-safety:
title: "Agent Context Policy Token: DAG Delegation with Human Override"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/
informative:
RFC8126:
I-D.nennemann-agent-gap-analysis:
title: "Gap Analysis for Autonomous Agent Protocols"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/
--- abstract
This document defines standardized protocols for multiple AI agents to
reach consensus on shared decisions and negotiate capabilities dynamically
during runtime collaboration. As autonomous agent systems increasingly
operate in multi-agent configurations, the need for formal agreement
mechanisms and capability discovery becomes critical. This specification
addresses the lack of consensus protocols and capability negotiation
standards identified in the gap analysis for AI agent infrastructure.
--- middle
# Introduction
When multiple AI agents collaborate on shared tasks such as network
management, resource allocation, or policy enforcement, they must
frequently agree on joint decisions. Currently, no standardized protocol
exists for agents to propose actions, vote on alternatives, reach
quorum, or handle disagreements.
This document addresses Gap 3 (Multi-Agent Consensus) and Gap 10
(Capability Negotiation) from the gap analysis {{I-D.nennemann-agent-gap-analysis}}.
Gap 3 identifies the absence of formal consensus mechanisms for
multi-agent coordination, while Gap 10 highlights the lack of dynamic
capability negotiation during runtime collaboration.
The protocols defined here enable agents to:
- Propose actions and gather votes from participating agents.
- Reach agreement using multiple consensus mechanisms suited to
different operational contexts.
- Advertise, discover, and negotiate capabilities dynamically.
- Record consensus and negotiation outcomes in verifiable
evidence chains via the Execution Chain Trace (ECT)
framework {{I-D.nennemann-wimse-ect}}.
The human-in-the-loop override protocol defined in
{{I-D.nennemann-agent-dag-hitl-safety}} serves as the ultimate
escalation path when consensus cannot be reached or when decisions
exceed agent authority.
# Terminology
{::boilerplate bcp14-tagged}
The following terms are used throughout this document:
Consensus Round:
: A bounded period during which agents exchange proposals and votes
to reach agreement on a specific decision.
Quorum:
: The minimum number of participating agents required for a consensus
round to produce a valid outcome.
Proposal:
: A structured message submitted by an agent that describes a
candidate action or decision for group consideration.
Vote:
: A response to a proposal indicating approval, rejection, or
abstention, optionally accompanied by a rationale.
Leader Agent:
: An agent designated as the coordinator for a consensus round,
responsible for collecting votes and declaring outcomes.
Capability Advertisement:
: A structured declaration by an agent of the capabilities it offers
to other agents in a collaboration.
Capability Offer:
: A message proposing the use of a specific capability under
defined terms during a negotiation session.
Capability Acceptance:
: A binding confirmation that an agent agrees to the terms of a
capability offer.
Negotiation Session:
: A bounded interaction between two or more agents for the purpose
of agreeing on capability usage terms.
# Consensus Protocols
## Consensus Model Overview
The consensus protocol follows a three-phase commit model: propose,
vote, and commit. The following diagram illustrates the message flow
for a typical consensus round.
~~~ ascii-art
Agent A Leader Agent B Agent C
| | | |
|--- Propose ---->| | |
| |-- Vote Req --->| |
| |-- Vote Req ------------------> |
| | | |
| |<-- Vote -------| |
| |<-- Vote ---------------------- |
| | | |
| |--- Tally & Decide ----------> |
|<-- Commit ------| | |
| |-- Commit ----->| |
| |-- Commit -------------------> |
| | | |
~~~
{: #fig-consensus-flow title="Consensus Round Message Flow"}
1. **Propose**: An agent submits a proposal to the leader agent.
2. **Vote**: The leader distributes the proposal to all participants
and collects votes within the timeout window.
3. **Commit/Abort**: The leader evaluates votes against the quorum
and consensus mechanism rules, then issues a commit or abort
signal to all participants.
## Consensus Mechanisms
This specification defines four consensus mechanisms. Implementations
MUST support simple majority voting and SHOULD support at least one
additional mechanism.
### Simple Majority Voting
A proposal is accepted if more than half of the votes received are
approvals. Abstentions do not count toward the total.
- Quorum: A minimum of ceil(N/2) votes must be received, where N
is the number of eligible voters.
- Ties result in rejection of the proposal.
### Weighted Consensus
Each agent is assigned a weight reflecting its trust score, domain
expertise, or capability level. A proposal is accepted if the sum
of approval weights exceeds a configured threshold (default: 50%
of total weight).
- Weights MUST be distributed and agreed upon before the consensus
round begins.
- Weight assignments SHOULD be recorded in the ECT for
auditability.
### Leader-Based Consensus
A designated leader agent makes the final decision after soliciting
input from participants. Participant votes serve as advisory input
rather than binding decisions.
- The leader MUST provide a rationale when overriding participant
recommendations.
- Leader designation SHOULD rotate or be determined by a
higher-level policy.
- This mechanism is appropriate for time-critical decisions where
full consensus would introduce unacceptable delay.
### Optimistic Consensus
A proposal is considered accepted unless an objection is raised
within the timeout window. This mechanism minimizes communication
overhead for routine decisions.
- Any single objection blocks the proposal.
- The objecting agent MUST provide a rationale.
- Optimistic consensus SHOULD only be used for low-risk,
reversible decisions.
## Consensus Message Format
### Proposal Message Structure
A proposal message MUST contain the following fields:
- **proposal_id**: A globally unique identifier for the proposal
(UUID format).
- **proposer**: The identity of the proposing agent.
- **consensus_round_id**: Identifier for the consensus round.
- **mechanism**: The consensus mechanism to use (one of "majority",
"weighted", "leader", "optimistic").
- **subject**: A human-readable summary of the proposal.
- **action**: A structured description of the proposed action.
- **timeout**: The deadline for vote collection (as an absolute
timestamp per {{RFC9110}} Section 5.6.7).
- **quorum**: The minimum number of votes required.
- **participants**: List of agent identifiers eligible to vote.
### Vote Message Structure
A vote message MUST contain the following fields:
- **proposal_id**: The identifier of the proposal being voted on.
- **voter**: The identity of the voting agent.
- **decision**: One of "approve", "reject", or "abstain".
- **rationale**: A human-readable explanation for the vote
(REQUIRED for "reject", OPTIONAL for others).
- **timestamp**: The time the vote was cast.
- **signature**: A JWS {{RFC7515}} signature over the vote content
for non-repudiation.
### Commit and Abort Signals
After vote collection, the leader issues either a commit or abort
signal:
- **Commit**: Indicates the proposal was accepted. All participants
MUST execute the agreed action.
- **Abort**: Indicates the proposal was rejected. Participants MUST
NOT execute the proposed action.
Both signals MUST include the proposal_id, the final tally, and a
JWS signature from the leader.
## Quorum and Timeout Rules
### Quorum Calculation
The quorum for a consensus round is determined by the consensus
mechanism in use:
- **Simple majority**: ceil(N/2) where N is the number of
eligible voters.
- **Weighted**: Agents representing at least 50% of total weight
must participate.
- **Leader-based**: No quorum required; leader decides
independently.
- **Optimistic**: All eligible agents are considered participants;
silence counts as approval.
### Timeout Semantics and Fallback Behavior
Each consensus round MUST specify a timeout. If quorum is not
reached before the timeout:
1. The leader MUST issue an abort signal.
2. The proposing agent MAY re-submit the proposal with a longer
timeout or reduced quorum.
3. If the decision is time-critical, the leader MAY escalate to
a human operator via the override protocol defined in
{{I-D.nennemann-agent-dag-hitl-safety}}.
Implementations SHOULD use exponential backoff for re-submissions
with a maximum retry count of 3.
### Split-Brain Prevention
In distributed deployments where network partitions may occur:
- A consensus round is valid only if the leader can verify
connectivity to a majority of participants.
- If a partition is detected, all in-progress consensus rounds
MUST be suspended until connectivity is restored.
- Agents MUST NOT accept commit signals from multiple leaders
for the same consensus round.
## Conflict Resolution
### Priority-Based Resolution
When multiple competing proposals address the same resource or
decision:
- Proposals are ranked by a priority score derived from the
urgency of the decision, the authority level of the proposer,
and the specificity of the proposed action.
- Higher-priority proposals are evaluated first.
- Lower-priority proposals that conflict with an accepted
higher-priority proposal are automatically rejected.
### Escalation to Human Operator
If consensus cannot be reached after the maximum number of retries,
or if agents are deadlocked:
- The leader MUST escalate to a human operator using the override
protocol defined in {{I-D.nennemann-agent-dag-hitl-safety}}.
- The escalation message MUST include the proposal, all votes
received, and the reason for escalation.
- The human operator's decision is binding and MUST be recorded
in the ECT.
### Deadlock Detection and Breaking
A deadlock exists when:
- Two or more proposals mutually block each other (circular
dependency).
- A consensus round cannot reach quorum due to persistent
abstentions or non-responsive agents.
Deadlock breaking strategies:
1. **Timeout-based**: The oldest proposal takes precedence.
2. **Random selection**: A verifiable random function selects
the winning proposal.
3. **Escalation**: The deadlock is escalated to a human operator.
The leader MUST detect deadlocks within two consecutive failed
consensus rounds on related proposals.
# Capability Negotiation
## Capability Advertisement Format
### Extending Agent Discovery with Capability Descriptors
Agents MUST advertise their capabilities using a structured
descriptor format. Capability advertisements extend the agent
discovery mechanism and SHOULD be published during agent
registration.
A capability descriptor MUST include:
- **agent_id**: The identity of the advertising agent.
- **capabilities**: An array of capability objects, each containing:
- **type**: The capability type from the capability registry
(see {{capability-registry}}).
- **version**: The version of the capability implementation.
- **parameters**: Capability-specific configuration parameters.
- **constraints**: Limitations on capability usage (e.g., rate
limits, maximum payload size).
- **availability**: Current availability status ("available",
"busy", "degraded", "unavailable").
### Capability Categories
Capabilities are organized into the following categories:
- **Compute**: Processing power, model inference, data
transformation.
- **Knowledge**: Domain expertise, access to knowledge bases,
training data coverage.
- **Tool Access**: Integration with external tools, APIs, or
services.
- **Authorization Scope**: Permissions and access levels the agent
holds in various systems.
### Version and Compatibility Metadata
Each capability advertisement MUST include version information
to enable compatibility checking:
- **min_version**: The minimum protocol version supported.
- **max_version**: The maximum protocol version supported.
- **deprecated_versions**: A list of versions that are supported
but deprecated.
Agents MUST negotiate a mutually supported version before
initiating capability usage.
## Dynamic Negotiation Protocol
### Negotiation Initiation and Session Management
A negotiation session is initiated when an agent requires a
capability that it does not possess but has identified in another
agent's advertisement.
1. The initiating agent sends a **Negotiation Request** specifying
the desired capability type and parameters.
2. The target agent responds with a **Negotiation Response**
indicating willingness to negotiate.
3. A **session_id** is established for tracking the negotiation.
Sessions have a configurable timeout (default: 60 seconds) and
MUST be explicitly closed by either party.
### Offer/Counter-Offer Exchange
Once a session is established:
1. The initiating agent sends a **Capability Offer** specifying
the desired terms of use (duration, rate limits, data handling
requirements).
2. The target agent may respond with:
- **Accept**: Agreement to the offered terms.
- **Counter-Offer**: Modified terms for the initiator to
consider.
- **Reject**: Refusal to provide the capability, with a
rationale.
3. Counter-offers may continue for a maximum of 5 rounds before
the negotiation MUST be concluded or abandoned.
### Acceptance and Binding
When both parties agree on terms:
- A **Capability Agreement** is created containing the final terms,
signed by both parties using JWS {{RFC7515}}.
- The agreement includes a unique **agreement_id**, the agreed
capability parameters, duration, and any usage constraints.
- Both agents MUST honor the agreement until its expiration or
explicit revocation.
### Re-Negotiation During Runtime
Either party MAY initiate re-negotiation of an active agreement
when:
- Resource availability changes.
- New constraints are imposed by external factors.
- The original terms are no longer adequate.
Re-negotiation follows the same offer/counter-offer protocol but
references the existing agreement_id.
## Capability Registry {#capability-registry}
### Well-Known Capability Types
The following capability types are defined as initial entries in
the capability registry:
| Type ID | Category | Description |
|---|---|---|
| compute.inference | Compute | Model inference execution |
| compute.transform | Compute | Data transformation and processing |
| knowledge.domain | Knowledge | Domain-specific expertise |
| knowledge.retrieval | Knowledge | Information retrieval from knowledge bases |
| tool.api | Tool Access | External API integration |
| tool.execution | Tool Access | Tool or script execution |
| authz.delegate | Authorization | Delegated authorization scope |
| authz.verify | Authorization | Credential and permission verification |
{: #tab-capability-types title="Well-Known Capability Types"}
### Extension Mechanism for Custom Capabilities
Organizations MAY define custom capability types using a reverse
domain name prefix (e.g., "com.example.custom-capability"). Custom
capability types:
- MUST NOT conflict with well-known capability type identifiers.
- SHOULD be registered with IANA for interoperability when intended
for broad use.
- MUST include a human-readable description and a machine-readable
schema for parameters.
# ECT Integration
Consensus and capability negotiation events MUST be recorded in the
Execution Chain Trace (ECT) framework defined in
{{I-D.nennemann-wimse-ect}} to provide a verifiable audit trail.
## Consensus Evidence in ECT Nodes
The following exec_act values are defined for consensus operations:
- **consensus_propose**: Records the submission of a proposal.
The ECT node MUST include the proposal_id, proposer identity,
and proposal summary.
- **consensus_vote**: Records a vote cast by an agent. The ECT
node MUST include the proposal_id, voter identity, decision,
and rationale (if provided).
- **consensus_commit**: Records the outcome of a consensus round.
The ECT node MUST include the proposal_id, final tally,
outcome (commit or abort), and the leader's signature.
## Capability Negotiation Records in ECT
Capability negotiation events are recorded using the ECT ext
(extension) claims mechanism:
- The **ext** claim MUST include a "capability_negotiation" object
containing the session_id, capability type, and negotiation
outcome.
- Agreement creation and revocation events MUST each produce an
ECT node with the agreement_id and relevant terms.
- Re-negotiation events MUST reference the original agreement_id
and include both the previous and updated terms.
# Security Considerations
## Sybil Resistance
To prevent an attacker from creating multiple fake agent identities
to influence consensus outcomes:
- Agents MUST authenticate using verifiable credentials bound to
their operational identity.
- The leader MUST verify agent identities before accepting votes.
- Consensus mechanisms SHOULD incorporate identity verification
scores that penalize newly registered or unverified agents.
- Rate limiting on agent registration prevents rapid creation of
sybil identities.
## Byzantine Fault Tolerance Considerations
The consensus mechanisms defined in this document do not provide
full Byzantine fault tolerance (BFT). Deployments requiring BFT
guarantees SHOULD:
- Use weighted consensus with trust scores that reflect agent
reliability history.
- Implement cross-validation of votes through independent
verification channels.
- Set quorum thresholds to at least 2f+1 where f is the maximum
number of potentially faulty agents.
- Consider established BFT protocols (e.g., PBFT) as an
alternative consensus mechanism for high-security environments.
## Capability Spoofing
Agents MUST NOT advertise capabilities they do not possess.
Mitigations include:
- Capability advertisements MUST be signed using the agent's
verified credentials.
- Consumers SHOULD validate capability claims through test
invocations before relying on them for critical operations.
- Agents that fail to deliver advertised capabilities MUST have
their trust scores reduced.
- Repeated capability spoofing SHOULD result in exclusion from
future consensus rounds and negotiation sessions.
## Coercion and Collusion Detection
To detect coordinated manipulation of consensus outcomes:
- Vote patterns SHOULD be analyzed for statistical anomalies
(e.g., identical rationales, synchronized timing).
- Agents SHOULD be required to submit votes independently without
knowledge of other agents' votes until the tally is complete
(sealed-bid voting).
- The ECT audit trail enables post-hoc analysis of voting patterns
to identify potential collusion.
- Human operators SHOULD be notified when anomalous voting patterns
are detected.
# IANA Considerations
## Consensus exec_act Values
This document requests registration of the following exec_act
values in the ECT exec_act registry:
| Value | Description | Reference |
|---|---|---|
| consensus_propose | Agent submits a consensus proposal | This document |
| consensus_vote | Agent casts a vote on a proposal | This document |
| consensus_commit | Leader commits or aborts a consensus round | This document |
{: #tab-exec-act title="Consensus exec_act Values"}
## Capability Type Registry
This document requests IANA to create a new "Agent Capability
Types" registry with the following initial entries as defined in
{{tab-capability-types}}.
New entries in this registry require Specification Required
(per {{RFC8126}}) and MUST include:
- A unique type identifier.
- The capability category.
- A human-readable description.
- A reference to the defining specification.
--- back
# Acknowledgments
{:numbered="false"}
The author thanks the contributors to the NMOP working group
discussions on AI agent orchestration and multi-agent coordination
challenges.

1089
workspace/drafts/gap-analysis/draft-nennemann-agent-consensus-00.xml Normal file
View File

File diff suppressed because it is too large Load Diff

2821
workspace/drafts/gap-analysis/draft-nennemann-agent-cross-domain-audit-00.html Normal file
View File

File diff suppressed because it is too large Load Diff

807
workspace/drafts/gap-analysis/draft-nennemann-agent-cross-domain-audit-00.md Normal file
View File

@@ -0,0 +1,807 @@
---
title: "Cross-Domain Agent Audit Trails and Resource Accounting"
abbrev: "Agent Cross-Domain Audit"
category: std
docname: draft-nennemann-agent-cross-domain-audit-00
submissiontype: IETF
number:
date:
v: 3
area: "OPS"
workgroup: "NMOP"
keyword:
- cross-domain audit
- resource accounting
- agent workflows
- regulatory compliance
- billing
author:
-
fullname: Christian Nennemann
organization: Independent Researcher
email: ietf@nennemann.de
normative:
RFC2119:
RFC8174:
RFC7519:
RFC7515:
RFC9110:
I-D.nennemann-wimse-ect:
title: "Execution Context Tokens for Distributed Agentic Workflows"
target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
I-D.nennemann-exec-audit:
title: "Cross-Domain Execution Audit Tokens"
target: https://datatracker.ietf.org/doc/draft-nennemann-exec-audit/
informative:
I-D.nennemann-agent-gap-analysis:
title: "Gap Analysis for Autonomous Agent Protocols"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/
I-D.ietf-scitt-architecture:
RFC9334:
SD-JWT:
title: "Selective Disclosure for JWTs (SD-JWT)"
target: https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/
seriesinfo:
Internet-Draft: draft-ietf-oauth-selective-disclosure-jwt
date: 2024
EU-AI-ACT:
title: "Regulation (EU) 2024/1689 (AI Act)"
target: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
date: 2024
author:
- org: European Parliament and Council
--- abstract
This document defines standardized formats and protocols for
maintaining audit trails when autonomous agents operate across
multiple administrative domains and organizations with divergent
regulatory requirements. It additionally specifies mechanisms for
tracking, recording, and settling agent resource consumption
across domain boundaries.
The cross-domain audit trail format extends the Execution Audit
Token (EAT) defined in {{I-D.nennemann-exec-audit}} with
regulatory profile metadata, audit trail stitching identifiers,
and selective disclosure controls. The resource accounting
framework introduces metering points, consumption records, and
a settlement protocol for multi-domain agent deployments.
--- middle
# Introduction
Autonomous agent workflows increasingly span multiple
administrative domains, each subject to distinct regulatory
regimes. An agent operating in the European Union must satisfy
GDPR data protection requirements; the same workflow may cross
into a US domain governed by HIPAA for healthcare data or SOX
for financial reporting. Each domain maintains its own audit
infrastructure, retention policies, and disclosure obligations.
This document addresses two gaps identified in
{{I-D.nennemann-agent-gap-analysis}}:
Gap 6 -- Cross-Domain Audit Trails:
: No standardized mechanism exists for maintaining coherent
audit trails when agent workflows cross organizational
boundaries with different regulatory requirements. Existing
audit systems are domain-local and cannot correlate execution
records across trust boundaries without leaking regulated
information.
Gap 9 -- Resource Accounting:
: Agent workflows consume computational resources -- CPU cycles,
network bandwidth, storage, API calls, and large language
model token usage -- across multiple domains. No standard
format exists for metering these resources, attributing
consumption to specific agents or tasks, and settling costs
across organizational boundaries.
This document builds on the Execution Audit Token (EAT) format
defined in {{I-D.nennemann-exec-audit}} and the Execution Context
Token (ECT) defined in {{I-D.nennemann-wimse-ect}}. It extends
both with cross-domain audit claims and resource accounting
fields while preserving backward compatibility.
## Scope
This document defines:
- Cross-domain audit record format extending EAT
({{audit-architecture}})
- Regulatory profile mapping for GDPR, SOX, and HIPAA
({{regulatory-profiles}})
- Audit trail stitching protocol for cross-domain correlation
({{audit-stitching}})
- Selective disclosure mechanisms for privacy-preserving audit
({{selective-disclosure}})
- Resource metering model and consumption record format
({{resource-metering}})
- Billing integration and settlement protocol
({{billing-integration}})
# Terminology
{::boilerplate bcp14-tagged}
The following terms are used in this document:
Audit Domain:
: An administrative boundary within which a single set of audit
policies, retention requirements, and regulatory obligations
apply uniformly.
Domain Boundary:
: The point at which an agent workflow transitions from one audit
domain to another, triggering boundary crossing records and
potential selective disclosure.
Regulatory Profile:
: A machine-readable identifier specifying the regulatory
framework (e.g., GDPR, SOX, HIPAA) governing audit records
within an audit domain.
Audit Record:
: A single entry in the cross-domain audit trail, extending the
EAT format with domain-specific metadata and cross-reference
identifiers.
Audit Stitching:
: The process of correlating audit records across domain
boundaries to reconstruct end-to-end workflow execution
history without requiring full data disclosure.
Selective Disclosure:
: A mechanism allowing an audit record holder to reveal only
specific claims to a verifier while proving the integrity of
the complete record.
Resource Meter:
: A component that measures agent resource consumption at defined
metering points within the execution pipeline.
Consumption Record:
: A signed attestation of resource usage by an agent or task,
including resource type, quantity, and attribution metadata.
Settlement:
: The process of reconciling consumption records across domain
boundaries and resolving financial obligations between
organizations.
# Cross-Domain Audit Trails
## Audit Architecture {#audit-architecture}
Cross-domain audit trails follow a federated architecture where
each domain maintains sovereign control over its audit records
while enabling end-to-end trail reconstruction through
cryptographic stitching.
~~~
+------------------+ +------------------+ +------------------+
| Domain A | | Domain B | | Domain C |
| (GDPR) | | (SOX) | | (HIPAA) |
| | | | | |
| +------+ +----+ | | +------+ +----+ | | +------+ +----+ |
| |Agent | |Audit| | | |Agent | |Audit| | | |Agent | |Audit| |
| | A1 |->| Log| | | | B1 |->| Log| | | | C1 |->| Log| |
| +------+ +--+-+ | | +------+ +--+-+ | | +------+ +--+-+ |
| | | | | | | | |
| +---------+ | | | +---------+ | | | +---------+ | |
| |Reg. | | | | |Reg. | | | | |Reg. | | |
| |Profile | | | | |Profile | | | | |Profile | | |
| +---------+ | | | +---------+ | | | +---------+ | |
+--------------+----+ +--------------+----+ +--------------+----+
| | |
v v v
+-----+-------------------------+-------------------------+----+
| Cross-Domain Audit Stitching Layer |
| |
| Boundary Crossing Records + Correlation Identifiers |
+--------------------------------------------------------------+
~~~
{: #fig-audit-arch title="Cross-Domain Audit Architecture"}
Each domain operates independently with its own audit log and
regulatory profile. The stitching layer connects audit records
across boundaries using cryptographic cross-references without
requiring domains to share raw audit data.
## Audit Record Format {#audit-record-format}
The cross-domain audit record extends the EAT payload defined
in {{I-D.nennemann-exec-audit}} with additional claims for
domain identification, regulatory context, and cross-referencing.
### Base Audit Record Structure
The base audit record is a JSON object carried as the payload of
a JWS {{RFC7515}} with the following claims:
~~~json
{
"iss": "https://domain-a.example.com/audit",
"sub": "agent:a1:task:12345",
"iat": 1700000000,
"jti": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
"eat_ref": "urn:uuid:a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"aud_domain": "domain-a.example.com",
"reg_profile": "gdpr-v1",
"xref": {
"prev_domain": "domain-b.example.com",
"prev_jti": "urn:uuid:12345678-abcd-ef01-2345-678901234567",
"boundary_id": "urn:uuid:bnd-98765432-dcba-10fe-5432-109876543210"
},
"task_desc": "Process customer data enrichment",
"inputs_hash": "sha256:abc123...",
"outputs_hash": "sha256:def456...",
"assurance_level": "L2"
}
~~~
The claims are defined as follows:
eat_ref:
: REQUIRED. A reference to the corresponding Execution Audit
Token for this task, enabling correlation between the audit
record and the execution context.
aud_domain:
: REQUIRED. The fully qualified domain name of the audit domain
that produced this record.
reg_profile:
: REQUIRED. The regulatory profile identifier governing this
audit record. See {{regulatory-profiles}}.
xref:
: OPTIONAL. Cross-reference object for audit trail stitching.
Present when this record follows a domain boundary crossing.
See {{audit-stitching}}.
### Domain-Specific Extensions
Each regulatory profile MAY define additional required claims.
Domain-specific extensions are carried in a "domain_ext" object:
~~~json
{
"domain_ext": {
"gdpr": {
"data_subject_category": "customer",
"processing_purpose": "enrichment",
"legal_basis": "legitimate_interest",
"retention_days": 730,
"dpo_contact": "dpo@domain-a.example.com"
}
}
}
~~~
### Cross-Reference Identifiers
Cross-reference identifiers enable trail stitching without
requiring access to the full audit records of other domains:
boundary_id:
: A globally unique identifier assigned at the domain boundary
crossing point. Both the outgoing record in the source domain
and the incoming record in the destination domain carry the
same boundary_id.
prev_jti:
: The JTI of the last audit record in the preceding domain.
This enables sequential chain verification.
prev_domain:
: The audit domain identifier of the preceding domain.
## Regulatory Profile Mapping {#regulatory-profiles}
### Profile Definitions
A regulatory profile is identified by a string of the form
"{framework}-v{version}". This document defines the following
initial profiles:
| Profile ID | Framework | Required Claims | Retention |
|:------------|:----------|:----------------|:----------|
| gdpr-v1 | EU GDPR | data_subject_category, processing_purpose, legal_basis, retention_days | Per purpose |
| sox-v1 | US SOX | control_objective, control_id, evidence_class, attestor | 7 years |
| hipaa-v1 | US HIPAA | phi_category, access_purpose, minimum_necessary, covered_entity | 6 years |
{: #tab-profiles title="Regulatory Profile Definitions"}
### Compliance Field Mapping
Each profile maps to a set of required and optional claims in the
"domain_ext" object. An audit record MUST include all required
claims for its declared regulatory profile. A verifier MUST
reject records missing required claims.
GDPR Profile (gdpr-v1):
: REQUIRED claims: data_subject_category, processing_purpose,
legal_basis, retention_days.
OPTIONAL claims: dpo_contact, cross_border_transfer,
data_categories, recipients.
SOX Profile (sox-v1):
: REQUIRED claims: control_objective, control_id, evidence_class,
attestor.
OPTIONAL claims: deficiency_flag, management_response,
test_procedure.
HIPAA Profile (hipaa-v1):
: REQUIRED claims: phi_category, access_purpose,
minimum_necessary, covered_entity.
OPTIONAL claims: business_associate, disclosure_authorization,
breach_risk_assessment.
### Regulatory Metadata Claims
Regulatory metadata is carried as claims in the EAT payload
under the "reg_meta" key:
~~~json
{
"reg_meta": {
"profile": "gdpr-v1",
"jurisdiction": "EU",
"supervisory_authority": "de-bfdi",
"cross_border": true,
"adequacy_decision": "eu-us-dpf",
"retention_expiry": 1763078400
}
}
~~~
## Audit Trail Stitching {#audit-stitching}
### Cross-Domain Correlation Protocol
When a workflow crosses a domain boundary, the following protocol
ensures audit trail continuity:
1. The source domain creates a boundary crossing record containing
the last audit record's JTI and a newly generated boundary_id.
2. The source domain signs the boundary crossing record and
transmits it to the destination domain along with the agent
handoff.
3. The destination domain creates its first audit record with
an xref object referencing the boundary_id and the source
domain's last JTI.
4. Both domains independently log the boundary crossing record
in their respective audit ledgers.
### Boundary Crossing Records
A boundary crossing record is a JWS-signed JSON object:
~~~json
{
"type": "boundary_crossing",
"boundary_id": "urn:uuid:bnd-98765432-dcba-10fe-5432-109876543210",
"source_domain": "domain-a.example.com",
"dest_domain": "domain-b.example.com",
"source_last_jti": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
"crossing_time": 1700000100,
"workflow_id": "urn:uuid:wf-11111111-2222-3333-4444-555555555555",
"source_reg_profile": "gdpr-v1",
"dest_reg_profile": "sox-v1",
"disclosed_claims": ["task_desc", "inputs_hash", "outputs_hash"],
"redacted_claims": ["data_subject_category", "processing_purpose"]
}
~~~
The "disclosed_claims" and "redacted_claims" arrays enumerate
which claims from the source domain's audit record are visible
to the destination domain and which are withheld for privacy.
### Partial Trail Assembly
An auditor with access to multiple domains can reconstruct the
full workflow trail by following the chain of boundary_id
references. When an auditor lacks access to a particular domain,
the trail contains a gap that can be verified structurally
(the boundary crossing records on either side reference the same
boundary_id) without revealing the content of the missing
domain's records.
This allows privacy-preserving end-to-end audit where each domain
proves its segment of the trail without exposing regulated data
to unauthorized parties.
## Selective Disclosure {#selective-disclosure}
### Using SD-JWT Concepts for Audit Records
Cross-domain audit records MAY use Selective Disclosure JWT
(SD-JWT) {{SD-JWT}} mechanisms to enable fine-grained claim
disclosure. When an audit record is issued, the issuer creates
an SD-JWT where each claim can be independently disclosed or
withheld.
An SD-JWT audit record replaces direct claims with hashed
disclosures:
~~~json
{
"iss": "https://domain-a.example.com/audit",
"aud_domain": "domain-a.example.com",
"reg_profile": "gdpr-v1",
"_sd": [
"WyJ...base64url-encoded disclosure hash..."
],
"_sd_alg": "sha-256"
}
~~~
Individual claims are disclosed by providing the corresponding
disclosure values alongside the SD-JWT.
### Per-Domain Visibility Controls
Each audit domain declares a visibility policy specifying which
claims are:
- Public: Disclosed to all domains in the workflow trail.
- Boundary: Disclosed only to the immediate upstream and
downstream domains.
- Private: Never disclosed outside the originating domain.
The visibility policy is declared in the regulatory profile
and enforced at each domain boundary crossing.
### Redaction and Minimization Rules
When an audit record crosses a domain boundary, the following
rules apply:
1. Claims classified as "private" MUST be redacted using SD-JWT
disclosures. The destination domain receives proof that the
claims exist but cannot read their values.
2. Claims classified as "boundary" MUST be disclosed to the
immediate destination domain but redacted for subsequent
domains in the chain.
3. Claims classified as "public" MUST be disclosed to all
domains.
4. The minimum set of public claims required for trail stitching
is: jti, boundary_id, aud_domain, and crossing_time.
# Resource Accounting
## Resource Metering Model {#resource-metering}
### Resource Types
This document defines the following resource types for agent
metering:
| Resource Type | Unit | Description |
|:--------------|:-----|:------------|
| compute | cpu-ms | CPU time in milliseconds |
| memory | byte-s | Memory usage in byte-seconds |
| network_egress| bytes | Outbound network transfer |
| network_ingress| bytes | Inbound network transfer |
| storage | byte-s | Persistent storage in byte-seconds |
| api_calls | count | External API invocations |
| llm_tokens | count | Large language model tokens consumed |
| gpu_compute | gpu-ms | GPU time in milliseconds |
{: #tab-resources title="Resource Type Definitions"}
### Metering Points
Resource meters are placed at defined points in the agent
execution pipeline:
1. Task Ingress: Resources consumed receiving and parsing task
inputs.
2. Execution: Resources consumed during task execution proper.
3. Tool Invocation: Resources consumed by each tool call within
a task.
4. Task Egress: Resources consumed producing and transmitting
task outputs.
5. Audit Overhead: Resources consumed generating and transmitting
audit records themselves.
Each metering point produces a meter reading that is included
in the task's consumption record.
### Meter Reading Format
A meter reading is a JSON object:
~~~json
{
"meter_point": "execution",
"resource_type": "llm_tokens",
"quantity": 4096,
"unit": "count",
"start_time": 1700000000,
"end_time": 1700000005,
"confidence": "measured"
}
~~~
The "confidence" field indicates whether the reading is
"measured" (exact instrumentation), "estimated" (statistical
sampling), or "allocated" (apportioned from a shared pool).
## Consumption Records {#consumption-records}
### Per-Agent Resource Consumption Claims
Resource consumption is recorded as claims in the EAT payload
under the "resource" key:
~~~json
{
"resource": {
"agent_id": "spiffe://domain-a.example.com/agent/a1",
"task_id": "urn:uuid:a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"domain": "domain-a.example.com",
"period": {
"start": 1700000000,
"end": 1700000010
},
"meters": [
{
"meter_point": "execution",
"resource_type": "compute",
"quantity": 2500,
"unit": "cpu-ms",
"confidence": "measured"
},
{
"meter_point": "execution",
"resource_type": "llm_tokens",
"quantity": 4096,
"unit": "count",
"confidence": "measured"
},
{
"meter_point": "tool_invocation",
"resource_type": "api_calls",
"quantity": 3,
"unit": "count",
"confidence": "measured"
}
]
}
}
~~~
### Aggregation Across DAG Nodes
When a workflow DAG spans multiple tasks, consumption records
can be aggregated to produce a workflow-level resource summary.
The aggregation MUST:
- Sum quantities of the same resource type and unit across all
DAG nodes within a domain.
- Maintain per-task granularity for dispute resolution.
- Record the aggregation method ("sum", "max", "weighted") for
each resource type.
### Multi-Tenant Isolation
In shared infrastructure deployments, resource meters MUST
provide tenant isolation guarantees:
- Each agent's resource consumption MUST be independently
metered.
- Shared resources (e.g., shared GPU pools) MUST use the
"allocated" confidence level and document the allocation
method.
- Consumption records MUST NOT leak information about other
tenants' resource usage.
## Billing Integration {#billing-integration}
### Settlement Protocol Overview
Settlement between domains follows a three-phase protocol:
Phase 1 -- Reporting:
: Each domain produces a signed usage report summarizing
consumption records for a billing period. The report is
signed using the domain's audit signing key.
Phase 2 -- Reconciliation:
: Participating domains exchange usage reports and verify that
boundary crossing records match. Discrepancies are flagged
for manual review.
Phase 3 -- Settlement:
: Reconciled usage is converted to monetary amounts using
pre-agreed rate cards. Settlement records are logged in
each domain's audit ledger.
### Usage Report Format
A usage report is a JWS-signed JSON object:
~~~json
{
"type": "usage_report",
"reporter_domain": "domain-a.example.com",
"billing_period": {
"start": 1700000000,
"end": 1702592000
},
"counterparty_domain": "domain-b.example.com",
"summary": [
{
"resource_type": "compute",
"total_quantity": 15000000,
"unit": "cpu-ms",
"task_count": 1250
},
{
"resource_type": "llm_tokens",
"total_quantity": 5242880,
"unit": "count",
"task_count": 1250
}
],
"detail_hash": "sha256:fedcba987654...",
"rate_card_ref": "urn:uuid:rc-aabbccdd-1122-3344-5566-778899001122"
}
~~~
The "detail_hash" is a hash of the full set of per-task
consumption records, enabling the counterparty to request and
verify individual records during dispute resolution.
### Fair-Use Enforcement Mechanisms
Domains MAY enforce fair-use policies on agent resource
consumption:
- Rate Limiting: Domains MAY impose per-agent or per-workflow
rate limits on resource types. Rate limit policies SHOULD
be communicated in the boundary crossing record.
- Budget Caps: Workflows MAY carry a resource budget in the ECT
that specifies maximum consumption per resource type. Agents
MUST NOT exceed the declared budget without obtaining a revised
ECT.
- Anomaly Detection: Domains SHOULD monitor consumption patterns
and flag anomalous usage (e.g., token consumption 10x above
the workflow's declared budget).
# Integration with ECT and Exec-Audit
The cross-domain audit and resource accounting claims defined in
this document extend the existing token formats as follows:
ECT Extensions ({{I-D.nennemann-wimse-ect}}):
: The ECT payload is extended with a "resource_budget" claim
specifying per-resource-type consumption limits for the
workflow. The ECT MAY also carry a "reg_profiles" array
listing the regulatory profiles that the workflow is expected
to traverse.
EAT Extensions ({{I-D.nennemann-exec-audit}}):
: The EAT payload is extended with the "aud_domain", "reg_profile",
"reg_meta", "xref", "domain_ext", and "resource" claims defined
in this document. These claims are OPTIONAL for single-domain
deployments and REQUIRED for cross-domain workflows.
Backward Compatibility:
: Existing ECT and EAT processors that do not recognize the new
claims MUST ignore them per standard JWT processing rules
{{RFC7519}}. Cross-domain audit functionality degrades
gracefully: single-domain deployments continue to function
without modification.
# Security Considerations
## Audit Trail Tampering Across Domains
Because each domain signs its own audit records independently,
a compromised domain can fabricate or alter its segment of the
audit trail. Mitigations include:
- Requiring Level 3 assurance (ledger-anchored EATs) for
cross-domain workflows in regulated environments.
- Cross-domain ledger anchoring as defined in
{{I-D.nennemann-exec-audit}} to detect tampering after the
fact.
- Independent third-party audit of boundary crossing records.
## Resource Metering Fraud
A malicious domain could under-report resource consumption to
reduce settlement obligations or over-report to inflate charges.
Mitigations include:
- Bilateral verification of boundary crossing records, which
constrain the plausible range of resource consumption.
- Statistical sampling and spot-checking of consumption records
against actual infrastructure metrics.
- Requiring "measured" confidence level for high-value resource
types and rejecting "estimated" readings above a threshold.
## Privacy Leakage Through Audit Correlation
Even with selective disclosure, the structure of the audit trail
(timing, frequency, and pattern of boundary crossings) can leak
information about the nature of the workflow. Mitigations
include:
- Batching boundary crossing records to obscure individual
workflow timing.
- Using domain-specific pseudonymous identifiers in cross-
references rather than globally unique agent identifiers.
- Minimizing the set of public claims to the structural minimum
required for trail stitching.
## Selective Disclosure Attacks
An adversary with access to multiple boundary crossing records
could attempt to correlate redacted claims across domains.
SD-JWT provides unlinkability guarantees when fresh salts are
used for each disclosure. Implementations MUST use
cryptographically random salts of at least 128 bits for each
SD-JWT disclosure.
# IANA Considerations
## JWT Claims Registration
This document requests registration of the following claims in
the JSON Web Token Claims registry established by {{RFC7519}}:
| Claim Name | Description | Reference |
|:-------------|:------------|:----------|
| aud_domain | Audit domain identifier | This document |
| reg_profile | Regulatory profile identifier | This document |
| reg_meta | Regulatory metadata object | This document |
| xref | Cross-domain reference object | This document |
| domain_ext | Domain-specific extension claims | This document |
| resource | Resource consumption record | This document |
| resource_budget | Resource budget limits | This document |
{: #tab-claims title="JWT Claims Registration"}
## Regulatory Profile Registry
This document establishes a new "Agent Audit Regulatory Profiles"
registry. The registration policy is Specification Required
{{!RFC8126}}.
Initial registrations:
| Profile ID | Framework | Reference |
|:-----------|:----------|:----------|
| gdpr-v1 | EU General Data Protection Regulation | This document |
| sox-v1 | US Sarbanes-Oxley Act | This document |
| hipaa-v1 | US Health Insurance Portability and Accountability Act | This document |
{: #tab-reg-profiles title="Regulatory Profile Registry"}
## Resource Type Registry
This document establishes a new "Agent Resource Types" registry.
The registration policy is Specification Required {{!RFC8126}}.
Initial registrations are listed in {{tab-resources}}.
--- back
# Acknowledgments
{:numbered="false"}
The author thanks the participants of the NMOP working group
for their feedback on agent management and operational
challenges.

1392
workspace/drafts/gap-analysis/draft-nennemann-agent-cross-domain-audit-00.xml Normal file
View File

File diff suppressed because it is too large Load Diff

2793
workspace/drafts/gap-analysis/draft-nennemann-agent-federation-privacy-00.html Normal file
View File

File diff suppressed because it is too large Load Diff

745
workspace/drafts/gap-analysis/draft-nennemann-agent-federation-privacy-00.md Normal file
View File

@@ -0,0 +1,745 @@
---
title: "Federated Agent Learning Privacy and Cross-Protocol Migration"
abbrev: "Agent Federation Privacy"
category: std
docname: draft-nennemann-agent-federation-privacy-00
submissiontype: IETF
number:
date:
v: 3
area: "OPS"
workgroup: "NMOP"
keyword:
- federated learning
- agent privacy
- agent migration
- cross-protocol
- differential privacy
author:
-
fullname: Christian Nennemann
organization: Independent Researcher
email: ietf@nennemann.de
normative:
RFC2119:
RFC8174:
RFC7519:
RFC7515:
RFC9110:
I-D.nennemann-wimse-ect:
title: "Execution Context Tokens for Distributed Agentic Workflows"
target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
I-D.nennemann-agent-dag-hitl-safety:
title: "Agent Context Policy Token: DAG Delegation with Human Override"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/
informative:
I-D.nennemann-agent-gap-analysis:
title: "Gap Analysis of IETF Agent-Related Drafts"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/
--- abstract
This document defines privacy-preserving protocols for federated
agent learning across organizational boundaries and standardized
mechanisms for agent migration between protocols, domains, and
infrastructure providers while maintaining state and identity
continuity. Federated learning enables multiple agent deployments
to collaboratively improve without sharing raw data, but requires
formal privacy guarantees to prevent data leakage between
participants. Cross-protocol migration enables agents to move
between environments while preserving operational state and
cryptographic identity through Execution Context Tokens (ECTs).
--- middle
# Introduction
As AI agents become integral to enterprise workflows, two
capabilities emerge as critical yet underspecified: collaborative
learning across organizational boundaries and seamless migration
between protocol environments.
This document addresses Gap 5 (Federated Learning Privacy) and
Gap 8 (Cross-Protocol Migration) as identified in
{{I-D.nennemann-agent-gap-analysis}}.
Gap 5 concerns the absence of privacy-preserving protocols for
federated agent learning. As agents learn and improve through
federation, data leakage between participants must be prevented.
Current federated learning research provides theoretical
foundations, but no IETF-standard protocol exists that integrates
differential privacy, secure aggregation, and privacy budget
enforcement into agent communication frameworks.
Gap 8 concerns the lack of standardized mechanisms for agent
migration between protocols, domains, and infrastructure providers.
As agents need to move between environments -- whether for load
balancing, disaster recovery, or organizational restructuring --
state and identity must transfer safely. Without a migration
protocol, agents lose context, learned parameters, and
cryptographic identity when changing environments.
This document builds on the Execution Context Token (ECT)
framework {{I-D.nennemann-wimse-ect}} to provide cryptographic
audit trails for both federated learning rounds and migration
events, and on the Agent Context Policy Token
{{I-D.nennemann-agent-dag-hitl-safety}} to enforce privacy and
migration policies within delegation DAGs.
# Terminology
{::boilerplate bcp14-tagged}
The following terms are used in this document:
Federated Learning:
: A machine learning approach where multiple participants
collaboratively train a model without sharing raw data, instead
exchanging model updates (gradients or parameters).
Differential Privacy:
: A mathematical framework providing formal guarantees that the
output of a computation does not reveal whether any individual
data point was included in the input, parameterized by epsilon
and delta.
Secure Aggregation:
: A cryptographic protocol enabling a server to compute the sum
of participant updates without learning any individual update.
Privacy Budget:
: A cumulative bound (epsilon) on the total privacy loss incurred
across multiple rounds of federated learning, enforced to prevent
gradual information leakage.
Data Leakage:
: The unintended exposure of private training data through model
updates, inference attacks, or side channels during federated
learning.
Agent Migration:
: The process of transferring an agent's operational state,
identity, and capabilities from one protocol environment, domain,
or infrastructure provider to another.
State Transfer:
: The serialization, transmission, and deserialization of an
agent's internal state during migration, including context,
memory, learned parameters, and active tasks.
Identity Continuity:
: The property that an agent's cryptographic identity (e.g., SPIFFE
ID and associated ECT chain) remains verifiable across migration
boundaries.
Protocol Bridge:
: A component that translates agent communication between different
protocols (e.g., A2A to MCP), maintaining semantic equivalence
of messages and state.
Migration Handoff:
: The coordinated process by which the source environment transfers
responsibility for an agent to the destination environment,
including state transfer and identity re-attestation.
# Federated Agent Learning Privacy
## Federated Learning Architecture for Agents
Federated learning for agents follows a topology where participant
agents contribute model updates to an aggregation function without
exposing their local training data.
~~~
+---------------------------------------------------+
| Federation Topology |
| |
| Star: Ring: Hierarchical: |
| |
| [Agg] A1--A2 [Root Agg] |
| / | \ | | / \ |
| A1 A2 A3 A3--A4 [Sub-Agg] [Sub-Agg] |
| / \ / \ |
| A1 A2 A3 A4 |
| |
+---------------------------------------------------+
[Agg] = Aggregation Server
A1..A4 = Participant Agents
Data flow (Star topology):
A1 ---local_update---> [Agg]
A2 ---local_update---> [Agg]
A3 ---local_update---> [Agg]
[Agg] computes aggregate
A1 <--global_model--- [Agg]
A2 <--global_model--- [Agg]
A3 <--global_model--- [Agg]
~~~
{: #fig-federation-arch title="Federated Learning Topologies for Agents"}
Three topologies are defined:
Star Topology:
: A central aggregation server receives updates from all
participant agents and distributes the aggregated model. This
is the simplest topology but creates a single point of trust.
Ring Topology:
: Participant agents pass updates around a ring, each adding its
own contribution before forwarding. This eliminates the central
server but increases latency.
Hierarchical Topology:
: Sub-aggregation servers collect updates from subsets of agents
before forwarding to a root aggregator. This scales to large
federations while limiting exposure at each level.
The aggregation server (or function, in ring topology) MUST NOT
have access to individual agent updates in plaintext when secure
aggregation is enabled.
## Privacy Mechanisms
### Differential Privacy for Model Updates
Participant agents MUST apply differential privacy to model
updates before transmission. Each update is clipped to a maximum
L2 norm S and perturbed with calibrated Gaussian noise:
- Clipping bound S: limits the influence of any single data point
- Noise scale sigma: calibrated to achieve (epsilon, delta)-
differential privacy for each round
- Composition: total privacy loss across T rounds is tracked using
the moments accountant or Renyi differential privacy
The privacy parameters MUST be declared in the federation
configuration and enforced by each participant agent.
### Secure Aggregation Protocol
The aggregation server MUST implement a secure aggregation protocol
such that:
1. Each participant agent secret-shares its update using pairwise
keys established with other participants.
2. The aggregation server collects masked updates from all
participants.
3. After a configurable threshold of participants have submitted
updates, the server reconstructs only the aggregate sum.
4. Individual updates are never available to the server in
plaintext.
Dropped participants are handled by reconstructing their masking
contributions from the shares held by surviving participants.
### Privacy Budget Tracking and Enforcement
Each federation MUST maintain a privacy budget tracker that records
cumulative epsilon expenditure per participant. The tracker MUST:
- Record the epsilon cost of each federated learning round
- Refuse to include a participant whose cumulative epsilon would
exceed the configured maximum budget
- Support budget refresh after a configurable cooldown period
- Report remaining budget to participants upon request
Privacy budget state MUST be recorded in ECTs (see {{ect-integration}})
to provide a cryptographic audit trail of privacy expenditure.
### Gradient Compression with Privacy Preservation
To reduce communication overhead, participants MAY compress model
updates using techniques such as top-k sparsification or random
sparsification. Compression MUST NOT reduce the effective privacy
guarantee below the declared epsilon -- noise MUST be added after
compression, calibrated to the compressed update's sensitivity.
## Data Leakage Prevention
### Membership Inference Attack Mitigation
Federation participants MUST apply differential privacy at
sufficient epsilon levels to bound the success rate of membership
inference attacks. The aggregation server SHOULD monitor update
distributions for anomalous patterns indicative of membership
inference attempts.
### Model Inversion Attack Prevention
To prevent reconstruction of training data from model updates:
- Updates MUST be clipped and noised per the differential privacy
mechanism defined above.
- The aggregation server MUST NOT release per-participant update
statistics.
- Participants SHOULD limit the number of rounds in which they
participate with unchanged local data.
### Update Poisoning Detection
The aggregation server MUST implement poisoning detection to
identify malicious updates that attempt to corrupt the global
model:
- Statistical outlier detection on update norms and directions
- Byzantine-robust aggregation (e.g., coordinate-wise median or
trimmed mean) as an alternative to simple averaging
- Participants submitting suspected poisoned updates SHOULD be
flagged and excluded from subsequent rounds pending review
### Privacy Attestation via ECT
Each federated learning round MUST produce an ECT
{{I-D.nennemann-wimse-ect}} attesting to the privacy mechanisms
applied. The ECT `ext` claim MUST include:
~~~json
{
"ext": {
"fed.round_id": "round-42",
"fed.epsilon": 1.5,
"fed.delta": 1e-5,
"fed.participants": 12,
"fed.aggregation": "secure_aggregation",
"fed.poisoning_detected": false
}
}
~~~
{: #fig-privacy-attestation title="Privacy Attestation in ECT Extension Claims"}
## Privacy Policy Format
Federation participants MUST publish a machine-readable privacy
policy document describing their federation parameters. The policy
is a JSON object:
~~~json
{
"federation_policy_version": "1.0",
"max_epsilon_per_round": 2.0,
"max_total_epsilon": 10.0,
"delta": 1e-5,
"secure_aggregation_required": true,
"min_participants": 3,
"budget_refresh_seconds": 86400,
"allowed_topologies": ["star", "hierarchical"],
"data_categories_excluded": ["PII", "PHI"]
}
~~~
{: #fig-privacy-policy title="Machine-Readable Privacy Policy"}
Privacy level claims SHOULD be included in the ECT `ext` field
as `fed.policy_hash`, containing the SHA-256 hash of the
federation privacy policy document, enabling verifiers to confirm
that a specific policy was in effect during a learning round.
# Cross-Protocol Agent Migration
## Migration Model
~~~
+-----------------------------------------------------------+
| Migration Flow |
| |
| Source Domain (Protocol A) Dest Domain (Protocol B) |
| +---------------------+ +---------------------+ |
| | | | | |
| | [Agent] | | [Agent] | |
| | | | | ^ | |
| | | 1.trigger | | | | |
| | v | | 5.resume | |
| | [Serialize State] | | | | |
| | | | | [Deserialize State]| |
| | | 2.package | | ^ | | |
| | v | | |4.recv| | |
| | [Migration Msg]----|--3.transfer--|------+ | |
| | | | | |
| +---------------------+ +---------------------+ |
| |
| ECT Chain: migration_start -> migration_transfer |
| -> migration_complete |
+-----------------------------------------------------------+
~~~
{: #fig-migration-model title="Agent Migration Between Domains"}
## Migration Protocol
### Migration Trigger Events and Conditions
A migration MAY be triggered by any of the following events:
- Operator-initiated domain transfer
- Load balancing across infrastructure providers
- Disaster recovery failover
- Protocol deprecation requiring protocol change
- Policy-driven relocation (e.g., data sovereignty requirements)
The migration trigger MUST be recorded in an ECT with
`exec_act` set to `"migration_start"`.
### Pre-Migration Capability Check
Before initiating migration, the source environment MUST verify
that the destination environment supports the agent's required
capabilities:
1. Query the destination's capability advertisement endpoint.
2. Verify that all required agent capabilities can be mapped to
the destination protocol.
3. Verify that the destination accepts the agent's identity
format (e.g., SPIFFE ID).
4. Confirm sufficient resources at the destination for the
agent's state size.
If any check fails, the migration MUST be aborted and an error
reported to the triggering entity.
### State Serialization Format
Agent state MUST be serialized using CBOR (Concise Binary Object
Representation) with the following top-level structure:
~~~
migration_state = {
"version": uint, ; serialization format version
"agent_id": tstr, ; agent SPIFFE ID
"source_protocol": tstr, ; source protocol identifier
"dest_protocol": tstr, ; destination protocol identifier
"timestamp": uint, ; Unix timestamp of serialization
"state": {
"context": bstr, ; conversation/task context
"memory": bstr, ; long-term memory store
"learned_params": bstr, ; model parameters or embeddings
"active_tasks": [* task] ; in-progress task descriptors
},
"ect_chain": [* tstr], ; ECT JWS chain for identity
"integrity": tstr ; HMAC-SHA256 of state fields
}
~~~
{: #fig-state-format title="CBOR Migration State Structure"}
### Identity Transfer and Re-Attestation
During migration, the agent's identity MUST be preserved through
the ECT chain:
1. The source environment issues a migration ECT with the full
ECT chain as the `par` claim.
2. The destination environment verifies the ECT chain back to a
trusted root.
3. The destination environment issues a new ECT for the agent with
`exec_act` set to `"migration_complete"` and `par` referencing
the migration transfer ECT.
4. The agent's SPIFFE ID remains unchanged; only the issuing
authority for new ECTs changes.
### Post-Migration Verification
After migration completes, the destination environment MUST:
1. Verify state integrity using the HMAC in the migration payload.
2. Deserialize and load the agent state.
3. Execute a capability self-test to confirm operational readiness.
4. Issue the `"migration_complete"` ECT.
5. Notify the source environment of successful migration so it
can release resources.
If verification fails, the destination MUST notify the source
environment, which SHOULD retain the agent in its original state
for retry or rollback.
## State Transfer
### Agent State Components
An agent's transferable state consists of four components:
Context:
: The current conversation or task execution context, including
recent message history and active reasoning chains.
Memory:
: Long-term memory stores such as retrieval-augmented generation
(RAG) indices, episodic memory, or key-value caches.
Learned Parameters:
: Fine-tuned model weights, adapter layers, embeddings, or
reinforcement learning policies specific to the agent's role.
Active Tasks:
: In-progress task descriptors including task ID, current step,
dependencies, and expected outputs.
### Incremental State Transfer for Large State
For agents with state exceeding 10 MB, incremental transfer
MUST be supported:
1. The source environment transmits a state manifest listing all
state chunks with their SHA-256 hashes.
2. The destination environment requests only chunks it does not
already possess (delta transfer).
3. Each chunk transfer is individually acknowledged.
4. After all chunks are received, the destination assembles the
complete state and verifies the root hash.
### State Integrity Verification
State integrity MUST be verified at each stage:
- Before transmission: source computes HMAC-SHA256 over the
serialized state using a key derived from the migration ECT.
- During transmission: TLS provides transport integrity.
- After reception: destination recomputes and verifies the HMAC.
- After deserialization: destination runs a state consistency
check (e.g., verifying that active task references resolve).
## Protocol Bridges
### Bridge Architecture for Common Protocols
Protocol bridges translate agent communication between protocols
while preserving semantic equivalence. A bridge MUST support
bidirectional translation for each protocol pair it advertises.
~~~
[Agent (A2A)] <--A2A--> [Bridge] <--MCP--> [Agent (MCP)]
|
[ECT Logger]
~~~
{: #fig-bridge-arch title="Protocol Bridge Architecture"}
Each bridge instance MUST:
- Maintain a mapping table for message types between protocols.
- Preserve task identifiers across protocol boundaries.
- Record each translation as an ECT with `exec_act` set to
`"bridge_translate"`.
### Context Translation Rules
When translating context between protocols, bridges MUST:
- Map equivalent fields (e.g., A2A "task" to MCP "resource").
- Preserve all metadata as extension fields where direct mapping
is not available.
- Flag semantic mismatches in the translation ECT's `ext` claim
under `bridge.warnings`.
### Capability Re-Mapping
Agent capabilities expressed in the source protocol MUST be
re-mapped to the closest equivalent in the destination protocol.
Capabilities with no equivalent MUST be listed in the migration
state as `unmapped_capabilities` so the destination environment
can handle them appropriately (e.g., by loading additional
tooling or reporting reduced functionality).
## Privacy During Migration
### Context Sanitization Before Transfer
Before state serialization, the source environment MUST sanitize
the agent's context by:
- Removing credentials, API keys, and session tokens.
- Redacting PII unless the destination is authorized to receive
it per the agent's privacy policy.
- Stripping environment-specific configuration (e.g., internal
hostnames, file paths).
### Selective State Disclosure
The migration protocol supports selective state disclosure:
the source environment MAY omit state components that the
destination is not authorized to receive. The migration state
manifest indicates which components are included and which are
withheld, allowing the destination to request missing components
through an authorized channel if needed.
### No-Context-Leakage Guarantees to New Host
The destination environment MUST NOT have access to state
components that were excluded during selective disclosure. The
migration protocol provides the following guarantees:
- State components are individually encrypted with component-
specific keys.
- Only authorized components have their keys transmitted to the
destination.
- The destination cannot derive keys for withheld components
from the keys it receives.
- The migration ECT records which components were transferred,
enabling audit of information flow.
# ECT Integration {#ect-integration}
## Privacy Attestation Claims
ECTs produced during federated learning rounds MUST include
privacy attestation claims in the `ext` field as defined in
{{privacy-attestation-via-ect}}. These claims enable any
verifier in the ECT chain to confirm that appropriate privacy
mechanisms were applied without accessing the underlying data.
## Migration Evidence Chain
Migration events produce a chain of three ECTs that together
provide a complete cryptographic record of the migration:
~~~
ECT 1: exec_act = "migration_start"
- Records: trigger reason, source domain, agent ID
- par: references the agent's most recent operational ECT
ECT 2: exec_act = "migration_transfer"
- Records: state hash, components transferred, dest domain
- par: references ECT 1
- inp_hash: SHA-256 of serialized migration state
ECT 3: exec_act = "migration_complete"
- Records: verification result, new domain, resumed capabilities
- par: references ECT 2
- Issued by: destination environment
~~~
{: #fig-migration-ect-chain title="Migration ECT Evidence Chain"}
This three-ECT chain ensures that migration events are
non-repudiable and auditable. Any party with access to the
ECT chain can verify that a migration occurred, what state was
transferred, and whether it completed successfully.
## Federation Participation Records
Each agent's participation in federated learning MUST be
recorded in the ECT DAG. The aggregation server issues a
per-round ECT with `exec_act` set to `"fed_aggregate"` and
`par` referencing the ECTs of all participating agents for
that round. This creates a verifiable record of federation
participation without revealing the content of individual
updates.
# Security Considerations
## Privacy Budget Exhaustion Attacks
An attacker controlling the aggregation server or a quorum of
participants could attempt to exhaust a victim participant's
privacy budget by triggering excessive learning rounds.
Mitigations include:
- Participant-side rate limiting on round participation.
- Privacy budget enforcement at the participant, not solely
at the aggregation server.
- ECT-based audit trails enabling detection of abnormal round
frequency.
## Migration Hijacking
An attacker could attempt to redirect a migration to a
malicious destination. Mitigations include:
- Mutual TLS authentication between source and destination.
- Destination identity verification via SPIFFE ID in the
migration ECT.
- Operator confirmation for migrations to previously unknown
destinations.
## State Tampering During Transfer
An attacker with access to the network path could attempt to
modify the migration state in transit. Mitigations include:
- HMAC-SHA256 integrity protection of the serialized state.
- TLS 1.3 for transport security.
- Post-migration state verification at the destination.
- ECT `inp_hash` recording the expected state hash.
## Protocol Bridge Vulnerabilities
Protocol bridges are trusted intermediaries that could be
compromised to:
- Modify messages during translation.
- Exfiltrate sensitive data from translated messages.
- Inject malicious content into translated messages.
Mitigations include:
- ECT audit trails for all bridge translations.
- Input/output hash verification via `inp_hash`/`out_hash`.
- Bridge attestation using hardware security modules where
available.
## Federation Participant Compromise
A compromised participant could attempt to:
- Submit poisoned updates to corrupt the global model.
- Conduct inference attacks on other participants' updates
observed during ring topology forwarding.
- Collude with the aggregation server to bypass secure
aggregation.
Mitigations include:
- Byzantine-robust aggregation algorithms.
- Secure aggregation preventing server access to individual
updates.
- Anomaly detection on update distributions.
- ECT-based participation records enabling forensic analysis.
# IANA Considerations
This document requests the following IANA registrations:
## ECT Action Type Registry
Registration of the following `exec_act` values in a future ECT
action type registry:
| Value | Description |
|:---------------------|:-------------------------------------|
| migration_start | Agent migration initiated |
| migration_transfer | Agent state transferred |
| migration_complete | Agent migration completed |
| fed_aggregate | Federated learning round aggregated |
| bridge_translate | Protocol bridge translation |
## ECT Extension Claims Registry
Registration of the following `ext` claim prefixes:
| Prefix | Description |
|:---------|:-----------------------------------------|
| fed. | Federated learning privacy claims |
| mig. | Migration-related claims |
| bridge. | Protocol bridge claims |
## Media Type Registration
Registration of the following media type:
- Type name: application
- Subtype name: agent-migration-state+cbor
- Required parameters: none
- Optional parameters: version
- Encoding: binary (CBOR)
- Purpose: Serialized agent migration state for cross-protocol
agent migration as defined in this document.
--- back
# Acknowledgments
{:numbered="false"}
This document builds on the Execution Context Token specification
{{I-D.nennemann-wimse-ect}} and the Agent Context Policy Token
{{I-D.nennemann-agent-dag-hitl-safety}}. The gap analysis
{{I-D.nennemann-agent-gap-analysis}} identified the requirements
addressed by this document.

1219
workspace/drafts/gap-analysis/draft-nennemann-agent-federation-privacy-00.xml Normal file
View File

File diff suppressed because it is too large Load Diff

2649
workspace/drafts/gap-analysis/draft-nennemann-agent-gap-analysis-00.html Normal file
View File

File diff suppressed because it is too large Load Diff

779
workspace/drafts/gap-analysis/draft-nennemann-agent-gap-analysis-00.md Normal file
View File

@@ -0,0 +1,779 @@
---
title: "Gap Analysis for Autonomous Agent Protocols"
abbrev: "Agent Gap Analysis"
category: info
docname: draft-nennemann-agent-gap-analysis-00
area: "OPS"
workgroup: "NMOP"
submissiontype: IETF
v: 3
author:
- fullname: Christian Nennemann
organization: Independent Researcher
email: ietf@nennemann.de
normative:
RFC2119:
RFC8174:
informative:
RFC9334:
RFC7519:
RFC8615:
RFC9110:
I-D.nennemann-wimse-ect:
title: "Execution Context Tokens for Distributed Agentic Workflows"
target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
I-D.nennemann-agent-dag-hitl-safety:
title: "Agent Context Policy Token: DAG Delegation with Human Override"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/
I-D.nennemann-exec-audit:
title: "Cross-Domain Execution Audit Tokens"
target: https://datatracker.ietf.org/doc/draft-nennemann-exec-audit/
I-D.nennemann-agent-behavioral-verification:
title: "Agent Behavioral Verification and Performance Benchmarking"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-behavioral-verification/
I-D.nennemann-agent-cascade-prevention:
title: "Agent Failure Cascade Prevention and Rollback"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-cascade-prevention/
I-D.nennemann-agent-consensus:
title: "Multi-Agent Consensus and Capability Negotiation Protocols"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-consensus/
I-D.nennemann-agent-cross-domain-audit:
title: "Cross-Domain Agent Audit Trails and Resource Accounting"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-cross-domain-audit/
I-D.nennemann-agent-override-protocol:
title: "Standardized Human Override Protocol for Autonomous Agents"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-override-protocol/
I-D.nennemann-agent-federation-privacy:
title: "Federated Agent Learning Privacy and Cross-Protocol Migration"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-federation-privacy/
--- abstract
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.
--- middle
# Introduction
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:
1. A reference architecture that organizes agent
capabilities into layers (Section 3).
2. A survey of existing IETF work relevant to autonomous
agents (Section 4).
3. 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.
# Terminology
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.
{::boilerplate bcp14-tagged}
The following terms are used throughout this document:
Agent:
: 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.
Autonomous Agent:
: An agent capable of executing multi-step tasks without
continuous human supervision, including making decisions
based on policy, context, and environmental state.
Agent Ecosystem:
: The set of agents, their principals, the policies that
govern them, and the infrastructure services (identity,
discovery, audit) they rely on.
DAG (Directed Acyclic Graph):
: A graph structure used to represent multi-step agent
execution plans where tasks have dependency ordering
but no circular dependencies.
HITL (Human-in-the-Loop):
: A control pattern in which a human operator must
approve, modify, or reject an agent action before
it takes effect.
ECT (Execution Context Token):
: A cryptographically signed token that carries the
execution context (task identity, delegated authority,
constraints) for an agent action. See
{{I-D.nennemann-wimse-ect}}.
ACP (Agent Context Policy):
: 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}}.
Behavioral Attestation:
: A verifiable claim that an agent's runtime behavior
conforms to a declared policy or behavioral profile.
Cascade Failure:
: 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.
Consensus Protocol:
: A protocol by which multiple agents reach agreement
on a shared decision, state, or action plan.
Override Signal:
: A message from a human operator or supervisory system
that instructs an agent to halt, modify, or roll back
its current action.
# Reference Architecture
The following diagram presents a layered reference
architecture for autonomous agent ecosystems. Each layer
identifies the relevant gap areas addressed by this
analysis.
~~~ ascii-art
+-------------------------------------------------------------+
| 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] |
+-------------------------------------------------------------+
~~~
{: #fig-arch title="Agent Ecosystem Reference Architecture"}
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).
# Existing IETF Work
This section briefly surveys existing IETF efforts relevant
to autonomous agent protocols.
## WIMSE (Workload Identity in Multi-System Environments)
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 (Remote ATtestation procedureS)
RATS defines architectures and protocols for remote
attestation {{RFC9334}}. Attestation evidence and
appraisal are directly applicable to verifying agent
behavioral claims.
## OAuth and GNAP
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 (Supply Chain Integrity, Transparency, and Trust)
SCITT defines transparency services for supply chain
artifacts. Its append-only log model is relevant to
agent audit trails and provenance tracking.
## NMOP (Network Management Operations)
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.
## Industry Protocols: A2A and MCP
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.
# Gap Analysis
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.
## Gap 1: Agent Behavioral Verification {#gap-1}
Severity:
: CRITICAL
Category:
: AI Safety
Problem Statement:
: 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.
Impact if Unaddressed:
: Undetected policy violations in autonomous agents
could cause safety incidents, data breaches, or
cascading failures in critical infrastructure.
Existing Partial Coverage:
: 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.
Companion Draft:
: {{I-D.nennemann-agent-behavioral-verification}}
## Gap 2: Agent Failure Cascade Prevention {#gap-2}
Severity:
: CRITICAL
Category:
: AI Safety, Resilience
Problem Statement:
: 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.
Impact if Unaddressed:
: A single agent failure could cascade through an entire
multi-agent deployment, causing widespread service
disruption with no automated containment.
Existing Partial Coverage:
: ECT {{I-D.nennemann-wimse-ect}} provides execution
context but no failure containment semantics.
Companion Draft:
: {{I-D.nennemann-agent-cascade-prevention}}
## Gap 3: Multi-Agent Consensus Protocols {#gap-3}
Severity:
: HIGH
Category:
: A2A Protocols
Problem Statement:
: 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.
Impact if Unaddressed:
: Multi-vendor agent deployments cannot coordinate
decisions, limiting autonomous agents to single-vendor
silos.
Existing Partial Coverage:
: No existing IETF work directly addresses multi-agent
consensus.
Companion Draft:
: {{I-D.nennemann-agent-consensus}}
## Gap 4: Real-Time Agent Rollback Mechanisms {#gap-4}
Severity:
: HIGH
Category:
: Resilience, Operations
Problem Statement:
: 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.
Impact if Unaddressed:
: Operators cannot safely deploy autonomous agents for
critical operations without manual intervention
capability for every action.
Existing Partial Coverage:
: NETCONF confirmed-commit provides rollback for
configuration changes only.
Companion Draft:
: {{I-D.nennemann-agent-cascade-prevention}}
## Gap 5: Federated Agent Learning Privacy {#gap-5}
Severity:
: HIGH
Category:
: Privacy, Federated Systems
Problem Statement:
: 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.
Impact if Unaddressed:
: Organizations will be unable to participate in
federated agent ecosystems without unacceptable
privacy risks, limiting the value of multi-domain
agent deployments.
Existing Partial Coverage:
: General privacy frameworks exist but none address
agent-specific federated learning scenarios.
Companion Draft:
: {{I-D.nennemann-agent-federation-privacy}}
## Gap 6: Cross-Domain Agent Audit Trails {#gap-6}
Severity:
: HIGH
Category:
: Audit, Compliance
Problem Statement:
: 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.
Impact if Unaddressed:
: Organizations cannot demonstrate compliance for
cross-domain agent operations, blocking adoption
in regulated industries.
Existing Partial Coverage:
: SCITT provides transparency log primitives.
{{I-D.nennemann-exec-audit}} defines per-action
audit tokens.
Companion Draft:
: {{I-D.nennemann-agent-cross-domain-audit}}
## Gap 7: Human Override Standardization {#gap-7}
Severity:
: HIGH
Category:
: AI Safety, Human Control
Problem Statement:
: 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.
Impact if Unaddressed:
: Operators lose the ability to control autonomous
agents in emergency situations, creating unacceptable
safety risks.
Existing Partial Coverage:
: ACP-DAG-HITL {{I-D.nennemann-agent-dag-hitl-safety}}
defines HITL policies but not override delivery.
Companion Draft:
: {{I-D.nennemann-agent-override-protocol}}
## Gap 8: Cross-Protocol Agent Migration {#gap-8}
Severity:
: MEDIUM
Category:
: Interoperability
Problem Statement:
: 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.
Impact if Unaddressed:
: Agent deployments become fragmented across protocol
silos, reducing interoperability and increasing
operational complexity.
Existing Partial Coverage:
: ECT {{I-D.nennemann-wimse-ect}} provides a
protocol-neutral context token but does not define
migration procedures.
Companion Draft:
: {{I-D.nennemann-agent-federation-privacy}}
## Gap 9: Agent Resource Accounting and Billing {#gap-9}
Severity:
: MEDIUM
Category:
: Operations, Economics
Problem Statement:
: 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.
Impact if Unaddressed:
: Organizations cannot accurately track or bill for
agent resource consumption, hindering commercial
multi-domain agent deployments.
Existing Partial Coverage:
: No existing IETF work addresses agent-specific
resource accounting.
Companion Draft:
: {{I-D.nennemann-agent-cross-domain-audit}}
## Gap 10: Agent Capability Negotiation {#gap-10}
Severity:
: MEDIUM
Category:
: A2A Protocols
Problem Statement:
: 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.
Impact if Unaddressed:
: Agent interactions require pre-configured knowledge
of peer capabilities, limiting dynamic composition
and ad-hoc agent collaboration.
Existing Partial Coverage:
: HTTP content negotiation and well-known URIs provide
basic discovery but not agent-specific capability
negotiation.
Companion Draft:
: {{I-D.nennemann-agent-consensus}}
## Gap 11: Agent Performance Benchmarking {#gap-11}
Severity:
: MEDIUM
Category:
: Operations, Metrics
Problem Statement:
: 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.
Impact if Unaddressed:
: Operators cannot objectively evaluate or compare
autonomous agent implementations, hindering
procurement and deployment decisions.
Existing Partial Coverage:
: No existing IETF work addresses agent performance
benchmarking.
Companion Draft:
: {{I-D.nennemann-agent-behavioral-verification}}
# Companion Draft Roadmap
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 |
{: #tab-roadmap title="Companion Draft Roadmap"}
The dependency relationships between companion drafts
are shown below:
~~~ ascii-art
behavioral-verification ---+
| |
v |
cascade-prevention |
| |
v v
override-protocol cross-domain-audit
| |
v v
consensus federation-privacy
~~~
{: #fig-deps title="Companion Draft Dependencies"}
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.
# Security Considerations
The gaps identified in this document have direct security
implications:
Behavioral Verification (Gap 1):
: Without runtime behavioral verification, compromised
or malfunctioning agents cannot be detected, creating
opportunities for attacks that exploit trusted agent
identities to perform unauthorized actions.
Cascade Prevention (Gap 2):
: 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.
Human Override (Gap 7):
: Without standardized override protocols, safety-
critical agent actions may not be stoppable, creating
an unacceptable risk profile for autonomous
deployments.
Cross-Domain Audit (Gap 6):
: Gaps in audit trails across domain boundaries create
opportunities for agents to take actions that evade
detection and accountability.
Federated Privacy (Gap 5):
: 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.
# IANA Considerations
This document has no IANA actions.
--- back
# Acknowledgments
The author thanks the participants of the WIMSE, RATS,
and NMOP working groups for discussions that informed
this analysis.

1368
workspace/drafts/gap-analysis/draft-nennemann-agent-gap-analysis-00.xml Normal file
View File

File diff suppressed because it is too large Load Diff

2733
workspace/drafts/gap-analysis/draft-nennemann-agent-override-protocol-00.html Normal file
View File

File diff suppressed because it is too large Load Diff

669
workspace/drafts/gap-analysis/draft-nennemann-agent-override-protocol-00.md Normal file
View File

@@ -0,0 +1,669 @@
---
title: "Standardized Human Override Protocol for Autonomous Agents"
abbrev: "Agent Override Protocol"
category: std
docname: draft-nennemann-agent-override-protocol-00
submissiontype: IETF
number:
date:
v: 3
area: "OPS"
workgroup: "NMOP"
keyword:
- human override
- autonomous agents
- kill switch
- override protocol
- agent safety
author:
-
fullname: Christian Nennemann
organization: Independent Researcher
email: ietf@nennemann.de
normative:
RFC2119:
RFC8174:
RFC7519:
RFC7515:
RFC9110:
I-D.nennemann-wimse-ect:
title: "Execution Context Tokens for Distributed Agentic Workflows"
target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
I-D.nennemann-agent-dag-hitl-safety:
title: "Agent Context Policy Token: DAG Delegation with Human Override"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/
informative:
I-D.nennemann-agent-gap-analysis:
title: "Gap Analysis of IETF Standards for Agentic AI Workflows"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/
--- abstract
This document defines a cross-vendor interoperable protocol for
human operators to override autonomous agent decisions at multiple
authority levels, with verified compliance and audit trails. It
absorbs and supersedes the override mechanisms described in earlier
HEOP and HITL drafts, providing a single unified protocol that
works across agent implementations from different vendors. The
protocol specifies three override levels (Advisory, Mandatory,
Emergency), a JWT-based override signal format, multiple delivery
mechanisms, compliance verification, and graceful degradation
semantics. Override events are recorded as Execution Context Token
(ECT) nodes for tamper-evident audit.
--- middle
# Introduction
Gap 7 of the agentic AI gap analysis
{{I-D.nennemann-agent-gap-analysis}} identifies the absence of a
standardized human override mechanism as a critical deficiency.
Current human-in-the-loop (HITL) mechanisms are vendor-specific:
each agent platform implements its own override interface,
authentication scheme, and compliance model. When agents from
different vendors collaborate in a shared workflow, there is no
universal mechanism for a human operator to intervene.
Earlier drafts addressed portions of this problem. The Human
Emergency Override Protocol (HEOP) defined four override levels
with ECT integration. The HITL Primitives draft added approval
gates, explainability tokens, and timeout policies. This document
absorbs and supersedes the override protocol aspects of both,
providing a single cross-vendor interoperable specification.
The design draws from industrial safety: the emergency stop button
on factory equipment, the circuit breaker in electrical systems, and
the kill switch in robotics. The override mechanism must be simpler
and more reliable than the system it controls.
The protocol integrates with the Agent Context Policy Token
{{I-D.nennemann-agent-dag-hitl-safety}} for authorization and with
the Execution Context Token {{I-D.nennemann-wimse-ect}} for audit.
# Terminology
{::boilerplate bcp14-tagged}
Override Signal:
: A signed message from an authorized human operator directing one
or more agents to change their autonomous behavior.
Override Authority:
: The authenticated identity and role of a human operator authorized
to issue override signals, as defined in ACP-DAG-HITL policy.
Override Scope:
: The set of agents or agent functions targeted by an override
signal.
Override Level:
: One of three escalating intervention types: Advisory (Level 1),
Mandatory (Level 2), or Emergency (Level 3).
Compliance Verification:
: The process of confirming that an agent has changed its behavior
in accordance with an override signal.
Acknowledgment:
: A signed response from an agent confirming receipt and processing
of an override signal.
Graceful Degradation:
: The behavior of the override system when the target agent is
unreachable or non-responsive.
Kill Switch:
: An Emergency (Level 3) override that requires immediate cessation
of all autonomous agent activity.
# Override Protocol
## Override Architecture
The following diagram illustrates the override signal flow from a
human operator through the override system to the target agent(s):
~~~
+----------+ Override Signal +------------------+
| Human |--(JWT-signed msg)--->| Override |
| Operator | | Dispatcher |
+----------+ +------------------+
^ | | |
| +---------+ | +---------+
| v v v
| +---------+ +---------+ +---------+
| | Agent A | | Agent B | | Agent C |
| | (push) | | (pull) | | (bcast) |
| +---------+ +---------+ +---------+
| | | |
+-----(Ack ECT)-----+-----(Ack)---+-----(Ack)---+
| | |
+----v-------------v-------------v----+
| Compliance Verification |
| & Audit Trail (ECT DAG) |
+-------------------------------------+
~~~
{: #fig-architecture title="Override Architecture"}
The Override Dispatcher receives the operator's signed override
signal and routes it to target agents via the appropriate delivery
mechanism. Each agent acknowledges the override with an ECT. The
compliance verification layer monitors agent behavior to confirm
the override was applied.
## Override Authority Levels
### Level 1: Advisory
An Advisory override is a suggestion for the agent to reconsider
its current course of action. The agent MAY comply with an
Advisory override. If the agent does not comply, it MUST
acknowledge receipt and provide a reason for non-compliance.
Advisory overrides are appropriate when the operator wants to
influence agent behavior without mandating a specific outcome.
### Level 2: Mandatory
A Mandatory override is a directive for the agent to change its
behavior. The agent MUST comply with a Mandatory override. The
agent MUST alter its behavior as specified in the override signal
and confirm compliance.
Mandatory overrides are appropriate when the operator requires a
specific behavioral change but the situation does not require
immediate cessation of all activity.
### Level 3: Emergency
An Emergency override requires immediate halt of all autonomous
agent activity. The agent MUST stop all autonomous actions
immediately upon receipt. The agent MUST NOT initiate any new
actions until explicitly released by an authorized operator.
This is the kill switch.
Emergency overrides are appropriate in safety-critical situations
where continued autonomous operation poses unacceptable risk.
The agent MUST process Emergency overrides within 1 second of
receipt. The override processing path MUST be independent of
the agent's main processing loop.
### Authority Delegation and Chain of Command
Override authority is derived from ACP-DAG-HITL policy. The
policy defines which operator roles are authorized for each
override level:
- Level 1 (Advisory): Any operator with `advisory_override` role
- Level 2 (Mandatory): Operators with `mandatory_override` role
- Level 3 (Emergency): Operators with `emergency_override` role
An operator with a higher-level role implicitly holds all
lower-level roles. Authority delegation (one operator authorizing
another to act on their behalf) MUST be recorded as an ECT and
MUST be time-bounded.
## Override Scope
### Single Agent Override
Targets a specific agent identified by its agent identifier
(e.g., a SPIFFE ID). The override signal contains a single
`target` value.
### Agent Group Override
Targets a set of agents identified by a tag or label. The
override signal contains a `target_group` value that matches
agents sharing a common label (e.g., `group:firewall-agents`).
### Workflow-Wide Override
Targets all agents participating in a specific workflow DAG.
The override signal contains a `target_workflow` value
referencing the workflow identifier.
### Domain-Wide Override
Targets all agents within an administrative domain. The
override signal contains `target_domain` set to `"*"` or a
specific domain identifier.
## Override Signal Format
Override signals are JSON Web Tokens (JWTs) {{RFC7519}} signed
by the override authority using JSON Web Signature (JWS)
{{RFC7515}}.
The JWT payload MUST contain the following claims:
~~~json
{
"jti": "urn:uuid:f47ac10b-58cc-4372-a567-0e02b2c3d479",
"iss": "spiffe://example.com/human/alice",
"iat": 1741042800,
"override_level": 3,
"override_scope": {
"type": "single",
"target": "spiffe://example.com/agent/firewall-mgr"
},
"override_action": "stop",
"override_reason": "Agent blocking legitimate traffic",
"override_expiry": 1741046400,
"nonce": "a3f8b2c1e9d74506"
}
~~~
{: #fig-signal title="Override Signal JWT Payload"}
Claim definitions:
`override_level`:
: Integer 1-3. MUST be present. Specifies the override authority
level.
`override_scope`:
: Object. MUST be present. Contains `type` (one of `single`,
`group`, `workflow`, `domain`) and the corresponding target
identifier.
`override_action`:
: String. MUST be present. The action the agent should take.
Values include `reconsider`, `change_behavior`, `stop`,
`restrict`, and `resume`.
`override_reason`:
: String. MUST be present. Human-readable explanation for the
override.
`override_expiry`:
: Integer (Unix timestamp) or null. If set, the override expires
automatically at this time and the agent resumes its prior mode.
If null, the override persists until explicitly lifted.
`nonce`:
: String. MUST be present. A random value to prevent replay
attacks.
### Delivery Mechanisms
#### Push (Webhook)
The override dispatcher sends the signed override signal as an
HTTP POST {{RFC9110}} to the agent's override endpoint:
~~~
POST /.well-known/agent-override HTTP/1.1
Host: agent.example.com
Content-Type: application/jose
Authorization: Bearer <operator-jwt>
<signed-override-signal>
~~~
{: #fig-push title="Push Delivery"}
#### Pull (Polling Endpoint)
Agents that cannot receive inbound connections MAY poll for
pending overrides:
~~~
GET /.well-known/agent-override/pending HTTP/1.1
Host: override-service.example.com
Authorization: Bearer <agent-jwt>
~~~
{: #fig-pull title="Pull Delivery"}
The polling interval SHOULD NOT exceed 10 seconds. For
Emergency overrides, agents relying on pull delivery MUST
poll at least every 5 seconds.
#### Broadcast
For domain-wide or group overrides, the dispatcher MAY use a
broadcast mechanism. The dispatcher fans out the override
signal to all matching agents and collects acknowledgments.
~~~
POST /override/broadcast HTTP/1.1
Host: override-service.example.com
Content-Type: application/jose
<signed-override-signal with target_domain or target_group>
~~~
{: #fig-broadcast title="Broadcast Delivery"}
## Override Endpoint Discovery
Agents MUST advertise their override endpoint at the well-known
URI `/.well-known/agent-override` per {{RFC9110}}.
A GET request to `/.well-known/agent-override` MUST return the
agent's override capabilities:
~~~json
{
"agent_id": "spiffe://example.com/agent/firewall-mgr",
"supported_levels": [1, 2, 3],
"delivery_mechanisms": ["push", "pull"],
"max_response_time_ms": 1000,
"status_endpoint": "/.well-known/agent-override/status",
"protocol_version": "1.0"
}
~~~
{: #fig-discovery title="Override Capability Advertisement"}
# Compliance and Verification
## Acknowledgment Protocol
### Override Receipt Acknowledgment
Upon receiving an override signal, the agent MUST respond with an
acknowledgment within the following timeframes:
- Level 1 (Advisory): 5 seconds
- Level 2 (Mandatory): 2 seconds
- Level 3 (Emergency): 1 second
The acknowledgment is an ECT with `exec_act` set to the
appropriate override acknowledgment value:
~~~json
{
"exec_act": "override_ack",
"par": ["<override-signal-jti>"],
"ext": {
"override.status": "received",
"override.level": 3,
"override.prior_state": "autonomous",
"override.effective_at": "2026-03-06T12:00:00.123Z"
}
}
~~~
{: #fig-ack title="Override Receipt Acknowledgment ECT"}
### Compliance Confirmation
After the agent has changed its behavior in response to the
override, it MUST emit a compliance confirmation ECT:
~~~json
{
"exec_act": "override_complied",
"par": ["<ack-ect-jti>"],
"ext": {
"override.status": "complied",
"override.current_state": "stopped",
"override.actions_terminated": 3,
"override.evidence": "All autonomous tasks halted"
}
}
~~~
{: #fig-compliance title="Compliance Confirmation ECT"}
### Non-Compliance Reporting and Escalation
For Level 1 (Advisory) overrides, the agent MAY decline to
comply. In this case, the agent MUST emit a non-compliance ECT:
~~~json
{
"exec_act": "override_declined",
"par": ["<override-signal-jti>"],
"ext": {
"override.status": "declined",
"override.reason": "Action is within policy bounds",
"override.level": 1
}
}
~~~
{: #fig-noncompliance title="Non-Compliance ECT (Advisory Only)"}
For Level 2 and Level 3 overrides, the agent MUST NOT decline.
If the agent cannot fully comply (e.g., due to hardware
limitations), it MUST report partial compliance with a
description of what could not be done. The override dispatcher
MUST escalate partial compliance to the operator.
## Compliance Verification
### Behavioral Verification Post-Override
After an agent acknowledges an override, the compliance
verification system SHOULD monitor the agent's subsequent
behavior to confirm the override was actually applied.
Verification methods include:
- Observing that the agent's ECT emissions cease (for Level 3)
- Checking that subsequent ECTs contain only permitted actions
(for Level 2 with restrictions)
- Querying the agent's status endpoint
### Timeout and Retry Semantics
If the agent does not acknowledge within the required timeframe:
1. The dispatcher MUST retry the override signal once after 2
seconds.
2. If no acknowledgment is received after the retry, the
dispatcher MUST escalate to the operator.
3. For Level 3 (Emergency) overrides, the dispatcher SHOULD
attempt alternative delivery mechanisms (e.g., switching from
push to broadcast).
4. If all delivery attempts fail, the graceful degradation
policy applies (see {{graceful-degradation}}).
## Graceful Degradation {#graceful-degradation}
### Unreachable Override Target
When the override target agent is unreachable, the system MUST:
1. Log an ECT with `exec_act`: `"override_delivery_failed"`
documenting the failure.
2. Notify the operator of the delivery failure.
3. Attempt delivery via alternative mechanisms.
### Failsafe Defaults
Agents MUST implement a dead man's switch: if the agent loses
contact with the override service for a configurable duration
(default: 90 seconds), the agent MUST enter a failsafe state
equivalent to Level 2 (Mandatory) with restricted operations.
The failsafe policy is configured in the agent's ACP-DAG-HITL
policy and MUST specify one of:
- `safe_pause`: Enter Level 2 with read-only operations permitted.
- `full_stop`: Enter Level 3 equivalent (cease all actions).
- `continue_logged`: Continue operating but emit warning ECTs at
elevated frequency. This option is only permitted at HITL
intensity I0 or I1.
### Proxy Override for Offline Agents
When an agent is offline, the override dispatcher MAY apply the
override to the agent's proxy or orchestrator. The proxy MUST:
1. Queue the override signal for delivery when the agent
reconnects.
2. Prevent new tasks from being dispatched to the offline agent.
3. Emit an ECT recording the proxy override action.
When the agent reconnects, the proxy MUST deliver the queued
override signal. The agent MUST process it as if it were
received in real time, applying the override level and action
specified.
# Integration with ACP-DAG-HITL and ECT
## Override Authorization via ACP Policy
Override authority is governed by ACP-DAG-HITL policy tokens
{{I-D.nennemann-agent-dag-hitl-safety}}. The policy token
specifies:
- Which operator roles are authorized for each override level.
- Which agents or agent groups each role may override.
- Escalation chains when primary operators are unavailable.
The override dispatcher MUST verify the operator's JWT against
the ACP policy before routing the override signal. An override
signal from an unauthorized operator MUST be rejected with HTTP
403 and logged as a security event.
## Override Events as ECT Nodes
Every override interaction produces ECT nodes
{{I-D.nennemann-wimse-ect}} that are linked into the workflow
DAG:
| Event | `exec_act` value |
|-------|------------------|
| Advisory override issued | `override_advisory` |
| Mandatory override issued | `override_mandatory` |
| Emergency override issued | `override_emergency` |
| Override acknowledged | `override_ack` |
| Override complied | `override_complied` |
| Override declined (Advisory only) | `override_declined` |
| Override delivery failed | `override_delivery_failed` |
| Override lifted | `override_lifted` |
| Override expired | `override_expired` |
{: #fig-ect-actions title="Override ECT exec_act Values"}
Each override ECT references the triggering override signal's
`jti` via the `par` claim, maintaining the causal chain in the
DAG.
## Override Audit Trail
The sequence of override ECTs provides a complete,
tamper-evident audit trail:
1. The operator issues an override (override ECT with operator
identity, reason, and level).
2. The agent acknowledges (ack ECT linked to override ECT).
3. The agent confirms compliance (compliance ECT linked to ack
ECT).
4. Optionally, the operator lifts the override (lift ECT linked
to override ECT).
At AEM assurance level L3, all override ECTs MUST be committed
to the immutable audit ledger.
# Security Considerations
## Unauthorized Override Attempts
Override signals that fail authentication or authorization MUST
be rejected. The agent MUST NOT alter its behavior in response
to an unsigned or improperly signed override signal. All
rejected override attempts MUST be logged with the source
identity (if available) and the reason for rejection.
## Replay Protection for Override Signals
Agents MUST reject override signals with:
- An `iat` claim more than 30 seconds in the past.
- A `jti` that matches a previously processed override signal.
- A missing or invalid `nonce` claim.
Agents MUST maintain a cache of recently processed `jti` values
for at least 5 minutes to detect replays.
## Override Signal Tampering
Override signals are signed JWTs. Agents MUST verify the
signature against the operator's public key (as registered in
ACP-DAG-HITL policy) before processing. Agents MUST reject
signals with invalid or expired signatures.
## Denial-of-Service via Override Flooding
To prevent abuse, agents SHOULD implement rate limiting on the
override endpoint:
- Level 1 (Advisory): Maximum 10 signals per minute per operator.
- Level 2 (Mandatory): Maximum 5 signals per minute per operator.
- Level 3 (Emergency): No rate limit (to ensure emergency
overrides are never blocked), but agents MUST log high-frequency
Emergency overrides as potential abuse.
The override endpoint SHOULD be served on a separate port or
network interface from the agent's main API to ensure
availability during overload conditions.
## Authority Impersonation
Agents MUST verify override authority by:
1. Validating the operator JWT signature against trusted keys.
2. Confirming the operator's role matches the required role for
the override level.
3. Verifying the operator is authorized to override the
specific target agent(s) per ACP policy.
Deployments SHOULD implement multi-operator approval for Level 3
(Emergency) overrides affecting domain-wide scope, requiring two
independent operator JWTs.
# IANA Considerations
## Well-Known URI Registration
This document requests registration of the following well-known
URI suffix per {{RFC9110}}:
| URI Suffix | Description |
|------------|-------------|
| `agent-override` | Agent override endpoint for receiving override signals, querying capabilities, and reporting status |
{: #fig-wellknown title="Well-Known URI Registration"}
## Override exec_act Values
This document requests registration of the following `exec_act`
values in the ECT Action Type Registry:
| Value | Description | Reference |
|-------|-------------|-----------|
| `override_advisory` | Advisory override signal issued | This document |
| `override_mandatory` | Mandatory override signal issued | This document |
| `override_emergency` | Emergency override signal issued | This document |
| `override_ack` | Agent acknowledgment of override | This document |
| `override_complied` | Agent confirmed compliance | This document |
| `override_declined` | Agent declined advisory override | This document |
| `override_delivery_failed` | Override delivery failure | This document |
| `override_lifted` | Override explicitly lifted | This document |
| `override_expired` | Override expired by TTL | This document |
{: #fig-iana-actions title="Override exec_act Value Registrations"}
## Override JWT Claims
This document requests registration of the following JWT claims
in the IANA JSON Web Token Claims registry:
| Claim Name | Description | Reference |
|------------|-------------|-----------|
| `override_level` | Override authority level (1-3) | This document |
| `override_scope` | Target scope of the override | This document |
| `override_action` | Directed action for the agent | This document |
| `override_reason` | Human-readable override justification | This document |
| `override_expiry` | Override expiration timestamp | This document |
{: #fig-iana-claims title="Override JWT Claim Registrations"}
--- back
# Acknowledgments
{:numbered="false"}
This document absorbs and supersedes the override protocol aspects
of the Human Emergency Override Protocol (HEOP) and the HITL
Primitives specification. The override level design is inspired
by industrial safety systems (IEC 62061, ISO 13849). The protocol
integrates with the Agent Context Policy Token
{{I-D.nennemann-agent-dag-hitl-safety}} for authorization and the
Execution Context Token {{I-D.nennemann-wimse-ect}} for audit.

1111
workspace/drafts/gap-analysis/draft-nennemann-agent-override-protocol-00.xml Normal file
View File

File diff suppressed because it is too large Load Diff

2173
workspace/drafts/gap-analysis/draft-nennemann-agent-problem-statement-00.html Normal file
View File

File diff suppressed because it is too large Load Diff

465
workspace/drafts/gap-analysis/draft-nennemann-agent-problem-statement-00.md Normal file
View File

@@ -0,0 +1,465 @@
---
title: "Problem Statement for Autonomous Agent Protocol Gaps"
abbrev: "Agent Problem Statement"
category: info
docname: draft-nennemann-agent-problem-statement-00
area: "OPS"
workgroup: "NMOP"
submissiontype: IETF
v: 3
author:
- fullname: Christian Nennemann
organization: Independent Researcher
email: ietf@nennemann.de
normative:
RFC2119:
RFC8174:
informative:
RFC9334:
RFC9110:
I-D.nennemann-wimse-ect:
title: "Execution Context Tokens for Distributed Agentic Workflows"
target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
I-D.nennemann-agent-dag-hitl-safety:
title: "Agent Context Policy Token: DAG Delegation with Human Override"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/
I-D.nennemann-exec-audit:
title: "Cross-Domain Execution Audit Tokens"
target: https://datatracker.ietf.org/doc/draft-nennemann-exec-audit/
I-D.nennemann-agent-behavioral-verification:
title: "Agent Behavioral Verification and Performance Benchmarking"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-behavioral-verification/
I-D.nennemann-agent-cascade-prevention:
title: "Agent Failure Cascade Prevention and Rollback"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-cascade-prevention/
I-D.nennemann-agent-consensus:
title: "Multi-Agent Consensus and Capability Negotiation Protocols"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-consensus/
I-D.nennemann-agent-cross-domain-audit:
title: "Cross-Domain Agent Audit Trails and Resource Accounting"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-cross-domain-audit/
I-D.nennemann-agent-override-protocol:
title: "Standardized Human Override Protocol for Autonomous Agents"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-override-protocol/
I-D.nennemann-agent-federation-privacy:
title: "Federated Agent Learning Privacy and Cross-Protocol Migration"
target: https://datatracker.ietf.org/doc/draft-nennemann-agent-federation-privacy/
ARXIV-GAP:
title: "Gap Analysis for Autonomous Agent Protocols in the IETF Landscape"
author:
- fullname: Christian Nennemann
date: 2025
target: https://arxiv.org/abs/2507.02492
--- abstract
The IETF autonomous agent landscape spans over 260 drafts
touching agent communication, identity, safety, and
operations, yet critical gaps remain where standardization
is absent or insufficient. This document provides a
condensed problem statement identifying eleven protocol
gaps, classifies them by severity, and maps them to a
suite of companion drafts that form a coherent solution
framework. It is intended as an actionable reference for
working group chairs, area directors, and protocol
designers evaluating where autonomous-agent standardization
efforts should focus.
--- middle
# Introduction
Autonomous software agents are moving from research
prototypes to production deployments in network management,
cloud orchestration, supply-chain logistics, and AI-driven
workflows. A survey of IETF work reveals over 260 drafts
relevant to agent capabilities, yet no single reference
architecture ties them together. Several critical
capabilities -- runtime behavioral verification, failure
cascade prevention, cross-vendor human override -- lack
any standardization at all.
This document distills the findings of a comprehensive
gap analysis {{ARXIV-GAP}} into an actionable problem
statement. It identifies eleven gaps, groups them by
severity, and presents a solution roadmap of nine
companion drafts. The full analysis, including a survey
of existing IETF work across WIMSE, RATS, OAuth/GNAP,
SCITT, and NMOP, is available in
{{I-D.nennemann-agent-dag-hitl-safety}} and the
companion arXiv paper {{ARXIV-GAP}}.
The intended audience is working group chairs, area
directors, and protocol designers who need a concise
summary of what is missing and what to build next.
# Terminology
{::boilerplate bcp14-tagged}
The following terms are used throughout this document:
Agent:
: A software component that acts on behalf of a principal
(human or organizational) to perform tasks autonomously.
ECT (Execution Context Token):
: A cryptographically signed token carrying execution
context for an agent action.
See {{I-D.nennemann-wimse-ect}}.
ACP (Agent Context Policy):
: A policy specifying permitted behaviors, resource limits,
and escalation rules for an agent.
See {{I-D.nennemann-agent-dag-hitl-safety}}.
HITL (Human-in-the-Loop):
: A control pattern requiring human approval before an
agent action takes effect.
Cascade Failure:
: A failure mode where an error in one agent propagates
through a multi-agent workflow, causing successive
agents to fail.
Override Signal:
: A message from a human operator instructing an agent
to halt, modify, or roll back its current action.
# Problem Landscape
The autonomous agent ecosystem can be organized into four
layers, each with distinct standardization gaps. The
following diagram presents this reference architecture:
~~~ ascii-art
+-------------------------------------------------------------+
| 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] |
+-------------------------------------------------------------+
~~~
{: #fig-arch title="Agent Ecosystem Reference Architecture"}
Human Operators Layer:
: Provides override and human-in-the-loop controls.
Gap 7 addresses the absence of a cross-vendor override
protocol.
Agent Interaction Layer:
: Where agents communicate, negotiate capabilities
(Gap 10), reach consensus (Gap 3), and undergo
behavioral verification (Gap 1).
Execution Layer:
: Manages DAG-based workflows with cascade prevention
(Gap 2) and rollback (Gap 4), built on Execution
Context Tokens {{I-D.nennemann-wimse-ect}}.
Policy and Governance Layer:
: Enforces privacy in federated learning (Gap 5) and
cross-domain audit trails (Gap 6).
Infrastructure Layer:
: Handles identity, discovery, cross-protocol migration
(Gap 8), resource accounting (Gap 9), and performance
benchmarking (Gap 11).
# Critical Gaps
## CRITICAL Severity
### Gap 1: Agent Behavioral Verification
No standardized mechanism exists for runtime verification
of agent policy compliance. RATS {{RFC9334}} covers
platform attestation but not behavioral conformance.
Without this, operators cannot detect drifted, compromised,
or out-of-bounds agents -- especially dangerous in
multi-agent workflows where one misbehaving agent corrupts
downstream results.
Addressed by {{I-D.nennemann-agent-behavioral-verification}}.
### Gap 2: Agent Failure Cascade Prevention
Multi-agent dependency chains lack standardized circuit
breakers, failure isolation, or cascade containment.
Current ad-hoc timeout and retry logic is neither
interoperable nor sufficient for DAG-structured workflows.
A single agent failure can cascade through an entire
deployment with no automated containment.
Addressed by {{I-D.nennemann-agent-cascade-prevention}}.
## HIGH Severity
### Gap 3: Multi-Agent Consensus Protocols
No standardized consensus protocol exists for
heterogeneous agents with different capabilities, trust
levels, and policy constraints. Distributed systems
consensus (Raft, Paxos) does not address agent-specific
semantics like weighted voting and capability-based
participation. Multi-vendor coordination remains
impossible without proprietary mechanisms.
Addressed by {{I-D.nennemann-agent-consensus}}.
### Gap 4: Real-Time Agent Rollback
No generalized rollback mechanism exists for autonomous
agent actions. Protocol-specific approaches (e.g.,
NETCONF confirmed-commit) do not extend to arbitrary
agent actions or coordinated multi-agent rollbacks.
Operators cannot safely deploy agents for critical
operations without manual intervention for every action.
Addressed by {{I-D.nennemann-agent-cascade-prevention}}.
### Gap 5: Federated Agent Learning Privacy
Agents sharing operational data across domains need
privacy guarantees beyond transport encryption:
differential privacy parameters, data minimization for
shared telemetry, and consent management. Without these,
organizations face unacceptable privacy risks in
federated agent ecosystems.
Addressed by {{I-D.nennemann-agent-federation-privacy}}.
### Gap 6: Cross-Domain Agent Audit Trails
No standardized format exists for cross-domain audit
trails that preserve causal ordering and provide
tamper-evident logging. Execution Audit Tokens
{{I-D.nennemann-exec-audit}} provide per-action records,
but aggregation and correlation across domains remain
undefined. Compliance requirements for automated
decision-making make this urgent.
Addressed by {{I-D.nennemann-agent-cross-domain-audit}}.
### Gap 7: Human Override Standardization
No cross-vendor protocol exists for sending override
signals (emergency stop, graceful pause, forced rollback)
to running agents. ACP-DAG-HITL
{{I-D.nennemann-agent-dag-hitl-safety}} defines when
human approval is required but not how to deliver
override signals. This is a fundamental safety gap.
Addressed by {{I-D.nennemann-agent-override-protocol}}.
## MEDIUM Severity
### Gap 8: Cross-Protocol Agent Migration
Agents migrating between protocol environments (e.g.,
A2A to MCP) have no standard for preserving execution
context, identity, and state across protocol boundaries.
ECT {{I-D.nennemann-wimse-ect}} provides a
protocol-neutral token but not migration procedures.
Addressed by {{I-D.nennemann-agent-federation-privacy}}.
### Gap 9: Agent Resource Accounting and Billing
No mechanism exists for tracking and reconciling agent
resource consumption across administrative domains.
This is a prerequisite for sustainable multi-domain
agent ecosystems with cost attribution.
Addressed by {{I-D.nennemann-agent-cross-domain-audit}}.
### Gap 10: Agent Capability Negotiation
Agents lack a standardized protocol to dynamically
advertise functions, agree on interaction protocols,
and establish compatible parameters. HTTP content
negotiation {{RFC9110}} provides basic discovery but
not agent-specific capability semantics.
Addressed by {{I-D.nennemann-agent-consensus}}.
### Gap 11: Agent Performance Benchmarking
No standardized metrics or methodology exists for
evaluating agent performance across dimensions of
accuracy, latency, resource efficiency, safety
compliance, and behavioral consistency.
Addressed by {{I-D.nennemann-agent-behavioral-verification}}.
# Solution Roadmap
## Companion Draft Mapping
The following table maps each companion draft to the
gaps it addresses:
| Companion Draft | Gaps Addressed | Priority |
|:---|:---:|:---:|
| {{I-D.nennemann-wimse-ect}} | Foundation | CRITICAL |
| {{I-D.nennemann-agent-dag-hitl-safety}} | Foundation | CRITICAL |
| {{I-D.nennemann-exec-audit}} | Foundation | HIGH |
| {{I-D.nennemann-agent-behavioral-verification}} | 1, 11 | CRITICAL |
| {{I-D.nennemann-agent-cascade-prevention}} | 2, 4 | CRITICAL |
| {{I-D.nennemann-agent-consensus}} | 3, 10 | HIGH |
| {{I-D.nennemann-agent-cross-domain-audit}} | 6, 9 | HIGH |
| {{I-D.nennemann-agent-override-protocol}} | 7 | HIGH |
| {{I-D.nennemann-agent-federation-privacy}} | 5, 8 | HIGH |
{: #tab-roadmap title="Companion Draft to Gap Mapping"}
## Companion Draft Summaries
ECT ({{I-D.nennemann-wimse-ect}}):
: Defines Execution Context Tokens that carry task
identity, delegated authority, and constraints across
agent boundaries. Foundational for all other drafts.
ACP-DAG-HITL ({{I-D.nennemann-agent-dag-hitl-safety}}):
: Specifies Agent Context Policy tokens for DAG-based
delegation with human-in-the-loop safety gates.
Foundational for policy enforcement across all gaps.
Execution Audit ({{I-D.nennemann-exec-audit}}):
: Defines per-action audit tokens for tamper-evident
recording of agent actions. Foundation for
cross-domain audit trails.
Behavioral Verification ({{I-D.nennemann-agent-behavioral-verification}}):
: Defines behavioral profiles, verification evidence
formats, and appraisal procedures for runtime agent
compliance. Addresses Gaps 1 and 11.
Cascade Prevention ({{I-D.nennemann-agent-cascade-prevention}}):
: Specifies circuit breakers, failure isolation,
checkpointing, and rollback mechanisms for multi-agent
workflows. Addresses Gaps 2 and 4.
Consensus ({{I-D.nennemann-agent-consensus}}):
: Defines protocols for multi-agent agreement with
weighted voting, capability negotiation, and
policy-constrained proposals. Addresses Gaps 3 and 10.
Cross-Domain Audit ({{I-D.nennemann-agent-cross-domain-audit}}):
: Specifies audit trail aggregation, correlation, and
query across administrative domains, plus resource
accounting. Addresses Gaps 6 and 9.
Override Protocol ({{I-D.nennemann-agent-override-protocol}}):
: Defines a cross-vendor protocol for emergency stop,
graceful pause, parameter modification, and forced
rollback signals. Addresses Gap 7.
Federation Privacy ({{I-D.nennemann-agent-federation-privacy}}):
: Specifies privacy-preserving mechanisms for federated
agent learning and cross-protocol migration procedures.
Addresses Gaps 5 and 8.
## Dependencies
The companion drafts have the following dependency
structure:
~~~ ascii-art
behavioral-verification ---+
| |
v |
cascade-prevention |
| |
v v
override-protocol cross-domain-audit
| |
v v
consensus federation-privacy
~~~
{: #fig-deps title="Companion Draft Dependencies"}
Behavioral verification is foundational: its attestation
format is consumed by cascade prevention and cross-domain
audit. Cascade prevention defines failure containment
that override protocol builds upon. Consensus extends
behavioral verification with multi-agent agreement.
Cross-domain audit provides the infrastructure that
federation privacy adds privacy controls to.
# Recommended Prioritization
Work should proceed in three phases:
Phase 1 -- Safety Foundation (Immediate):
: Behavioral Verification (Gaps 1, 11) and Cascade
Prevention (Gaps 2, 4). These are CRITICAL severity
gaps with direct safety implications. Without runtime
verification and failure containment, no autonomous
agent deployment can be considered safe.
Phase 2 -- Control and Accountability (Near-term):
: Human Override (Gap 7) and Cross-Domain Audit (Gaps 6, 9).
Override capability is a prerequisite for any production
deployment. Audit trails are required for regulatory
compliance in enterprise environments.
Phase 3 -- Interoperability and Scale (Medium-term):
: Consensus (Gaps 3, 10) and Federation Privacy (Gaps 5, 8).
These enable multi-vendor and multi-domain agent
ecosystems but depend on the safety and accountability
foundations from Phases 1 and 2.
# Security Considerations
The gaps identified in this document have cross-cutting
security implications:
- Behavioral Verification (Gap 1): Without runtime
verification, compromised agents exploit trusted
identities to perform unauthorized actions undetected.
- Cascade Prevention (Gap 2): Absence of containment
creates a denial-of-service vector where compromising
a single agent disrupts entire multi-agent workflows.
- Human Override (Gap 7): Without a standard override
protocol, safety-critical agent actions may not be
stoppable in emergency situations.
- Cross-Domain Audit (Gap 6): Audit trail gaps across
domain boundaries enable agents to evade detection
and accountability.
- Federated Privacy (Gap 5): Sharing agent data across
domains without privacy controls exposes network
topology, operational patterns, and business logic.
Implementers of autonomous agent systems SHOULD treat
the CRITICAL and HIGH severity gaps as security
requirements and prioritize their resolution. The
companion drafts each contain detailed security
considerations specific to their scope.
# IANA Considerations
This document has no IANA actions.
--- back
# Acknowledgments
The author thanks the participants of the WIMSE, RATS,
and NMOP working groups for discussions that informed
this analysis. The full gap analysis is available as
{{ARXIV-GAP}}.

862
workspace/drafts/gap-analysis/draft-nennemann-agent-problem-statement-00.xml Normal file
View File

@@ -0,0 +1,862 @@
<?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-problem-statement-00" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
<front>
<title abbrev="Agent Problem Statement">Problem Statement for Autonomous Agent Protocol Gaps</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 57?>
<t>The IETF autonomous agent landscape spans over 260 drafts
touching agent communication, identity, safety, and
operations, yet critical gaps remain where standardization
is absent or insufficient. This document provides a
condensed problem statement identifying eleven protocol
gaps, classifies them by severity, and maps them to a
suite of companion drafts that form a coherent solution
framework. It is intended as an actionable reference for
working group chairs, area directors, and protocol
designers evaluating where autonomous-agent standardization
efforts should focus.</t>
</abstract>
</front>
<middle>
<?line 71?>
<section anchor="introduction"><name>Introduction</name>
<t>Autonomous software agents are moving from research
prototypes to production deployments in network management,
cloud orchestration, supply-chain logistics, and AI-driven
workflows. A survey of IETF work reveals over 260 drafts
relevant to agent capabilities, yet no single reference
architecture ties them together. Several critical
capabilities -- runtime behavioral verification, failure
cascade prevention, cross-vendor human override -- lack
any standardization at all.</t>
<t>This document distills the findings of a comprehensive
gap analysis <xref target="ARXIV-GAP"/> into an actionable problem
statement. It identifies eleven gaps, groups them by
severity, and presents a solution roadmap of nine
companion drafts. The full analysis, including a survey
of existing IETF work across WIMSE, RATS, OAuth/GNAP,
SCITT, and NMOP, is available in
<xref target="I-D.nennemann-agent-dag-hitl-safety"/> and the
companion arXiv paper <xref target="ARXIV-GAP"/>.</t>
<t>The intended audience is working group chairs, area
directors, and protocol designers who need a concise
summary of what is missing and what to build next.</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>
<?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 autonomously.</t>
</dd>
<dt>ECT (Execution Context Token):</dt>
<dd>
<t>A cryptographically signed token carrying execution
context for an agent action.
See <xref target="I-D.nennemann-wimse-ect"/>.</t>
</dd>
<dt>ACP (Agent Context Policy):</dt>
<dd>
<t>A policy specifying permitted behaviors, resource limits,
and escalation rules for an agent.
See <xref target="I-D.nennemann-agent-dag-hitl-safety"/>.</t>
</dd>
<dt>HITL (Human-in-the-Loop):</dt>
<dd>
<t>A control pattern requiring human approval before an
agent action takes effect.</t>
</dd>
<dt>Cascade Failure:</dt>
<dd>
<t>A failure mode where an error in one agent propagates
through a multi-agent workflow, causing successive
agents to fail.</t>
</dd>
<dt>Override Signal:</dt>
<dd>
<t>A message from a human operator instructing an agent
to halt, modify, or roll back its current action.</t>
</dd>
</dl>
</section>
<section anchor="problem-landscape"><name>Problem Landscape</name>
<t>The autonomous agent ecosystem can be organized into four
layers, each with distinct standardization gaps. The
following diagram presents this reference architecture:</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>
<dl>
<dt>Human Operators Layer:</dt>
<dd>
<t>Provides override and human-in-the-loop controls.
Gap 7 addresses the absence of a cross-vendor override
protocol.</t>
</dd>
<dt>Agent Interaction Layer:</dt>
<dd>
<t>Where agents communicate, negotiate capabilities
(Gap 10), reach consensus (Gap 3), and undergo
behavioral verification (Gap 1).</t>
</dd>
<dt>Execution Layer:</dt>
<dd>
<t>Manages DAG-based workflows with cascade prevention
(Gap 2) and rollback (Gap 4), built on Execution
Context Tokens <xref target="I-D.nennemann-wimse-ect"/>.</t>
</dd>
<dt>Policy and Governance Layer:</dt>
<dd>
<t>Enforces privacy in federated learning (Gap 5) and
cross-domain audit trails (Gap 6).</t>
</dd>
<dt>Infrastructure Layer:</dt>
<dd>
<t>Handles identity, discovery, cross-protocol migration
(Gap 8), resource accounting (Gap 9), and performance
benchmarking (Gap 11).</t>
</dd>
</dl>
</section>
<section anchor="critical-gaps"><name>Critical Gaps</name>
<section anchor="critical-severity"><name>CRITICAL Severity</name>
<section anchor="gap-1-agent-behavioral-verification"><name>Gap 1: Agent Behavioral Verification</name>
<t>No standardized mechanism exists for runtime verification
of agent policy compliance. RATS <xref target="RFC9334"/> covers
platform attestation but not behavioral conformance.
Without this, operators cannot detect drifted, compromised,
or out-of-bounds agents -- especially dangerous in
multi-agent workflows where one misbehaving agent corrupts
downstream results.
Addressed by <xref target="I-D.nennemann-agent-behavioral-verification"/>.</t>
</section>
<section anchor="gap-2-agent-failure-cascade-prevention"><name>Gap 2: Agent Failure Cascade Prevention</name>
<t>Multi-agent dependency chains lack standardized circuit
breakers, failure isolation, or cascade containment.
Current ad-hoc timeout and retry logic is neither
interoperable nor sufficient for DAG-structured workflows.
A single agent failure can cascade through an entire
deployment with no automated containment.
Addressed by <xref target="I-D.nennemann-agent-cascade-prevention"/>.</t>
</section>
</section>
<section anchor="high-severity"><name>HIGH Severity</name>
<section anchor="gap-3-multi-agent-consensus-protocols"><name>Gap 3: Multi-Agent Consensus Protocols</name>
<t>No standardized consensus protocol exists for
heterogeneous agents with different capabilities, trust
levels, and policy constraints. Distributed systems
consensus (Raft, Paxos) does not address agent-specific
semantics like weighted voting and capability-based
participation. Multi-vendor coordination remains
impossible without proprietary mechanisms.
Addressed by <xref target="I-D.nennemann-agent-consensus"/>.</t>
</section>
<section anchor="gap-4-real-time-agent-rollback"><name>Gap 4: Real-Time Agent Rollback</name>
<t>No generalized rollback mechanism exists for autonomous
agent actions. Protocol-specific approaches (e.g.,
NETCONF confirmed-commit) do not extend to arbitrary
agent actions or coordinated multi-agent rollbacks.
Operators cannot safely deploy agents for critical
operations without manual intervention for every action.
Addressed by <xref target="I-D.nennemann-agent-cascade-prevention"/>.</t>
</section>
<section anchor="gap-5-federated-agent-learning-privacy"><name>Gap 5: Federated Agent Learning Privacy</name>
<t>Agents sharing operational data across domains need
privacy guarantees beyond transport encryption:
differential privacy parameters, data minimization for
shared telemetry, and consent management. Without these,
organizations face unacceptable privacy risks in
federated agent ecosystems.
Addressed by <xref target="I-D.nennemann-agent-federation-privacy"/>.</t>
</section>
<section anchor="gap-6-cross-domain-agent-audit-trails"><name>Gap 6: Cross-Domain Agent Audit Trails</name>
<t>No standardized format exists for cross-domain audit
trails that preserve causal ordering and provide
tamper-evident logging. Execution Audit Tokens
<xref target="I-D.nennemann-exec-audit"/> provide per-action records,
but aggregation and correlation across domains remain
undefined. Compliance requirements for automated
decision-making make this urgent.
Addressed by <xref target="I-D.nennemann-agent-cross-domain-audit"/>.</t>
</section>
<section anchor="gap-7-human-override-standardization"><name>Gap 7: Human Override Standardization</name>
<t>No cross-vendor protocol exists for sending override
signals (emergency stop, graceful pause, forced rollback)
to running agents. ACP-DAG-HITL
<xref target="I-D.nennemann-agent-dag-hitl-safety"/> defines when
human approval is required but not how to deliver
override signals. This is a fundamental safety gap.
Addressed by <xref target="I-D.nennemann-agent-override-protocol"/>.</t>
</section>
</section>
<section anchor="medium-severity"><name>MEDIUM Severity</name>
<section anchor="gap-8-cross-protocol-agent-migration"><name>Gap 8: Cross-Protocol Agent Migration</name>
<t>Agents migrating between protocol environments (e.g.,
A2A to MCP) have no standard for preserving execution
context, identity, and state across protocol boundaries.
ECT <xref target="I-D.nennemann-wimse-ect"/> provides a
protocol-neutral token but not migration procedures.
Addressed by <xref target="I-D.nennemann-agent-federation-privacy"/>.</t>
</section>
<section anchor="gap-9-agent-resource-accounting-and-billing"><name>Gap 9: Agent Resource Accounting and Billing</name>
<t>No mechanism exists for tracking and reconciling agent
resource consumption across administrative domains.
This is a prerequisite for sustainable multi-domain
agent ecosystems with cost attribution.
Addressed by <xref target="I-D.nennemann-agent-cross-domain-audit"/>.</t>
</section>
<section anchor="gap-10-agent-capability-negotiation"><name>Gap 10: Agent Capability Negotiation</name>
<t>Agents lack a standardized protocol to dynamically
advertise functions, agree on interaction protocols,
and establish compatible parameters. HTTP content
negotiation <xref target="RFC9110"/> provides basic discovery but
not agent-specific capability semantics.
Addressed by <xref target="I-D.nennemann-agent-consensus"/>.</t>
</section>
<section anchor="gap-11-agent-performance-benchmarking"><name>Gap 11: Agent Performance Benchmarking</name>
<t>No standardized metrics or methodology exists for
evaluating agent performance across dimensions of
accuracy, latency, resource efficiency, safety
compliance, and behavioral consistency.
Addressed by <xref target="I-D.nennemann-agent-behavioral-verification"/>.</t>
</section>
</section>
</section>
<section anchor="solution-roadmap"><name>Solution Roadmap</name>
<section anchor="companion-draft-mapping"><name>Companion Draft Mapping</name>
<t>The following table maps each companion draft to the
gaps it addresses:</t>
<texttable title="Companion Draft to Gap Mapping" anchor="tab-roadmap">
<ttcol align='left'>Companion Draft</ttcol>
<ttcol align='center'>Gaps Addressed</ttcol>
<ttcol align='center'>Priority</ttcol>
<c><xref target="I-D.nennemann-wimse-ect"/></c>
<c>Foundation</c>
<c>CRITICAL</c>
<c><xref target="I-D.nennemann-agent-dag-hitl-safety"/></c>
<c>Foundation</c>
<c>CRITICAL</c>
<c><xref target="I-D.nennemann-exec-audit"/></c>
<c>Foundation</c>
<c>HIGH</c>
<c><xref target="I-D.nennemann-agent-behavioral-verification"/></c>
<c>1, 11</c>
<c>CRITICAL</c>
<c><xref target="I-D.nennemann-agent-cascade-prevention"/></c>
<c>2, 4</c>
<c>CRITICAL</c>
<c><xref target="I-D.nennemann-agent-consensus"/></c>
<c>3, 10</c>
<c>HIGH</c>
<c><xref target="I-D.nennemann-agent-cross-domain-audit"/></c>
<c>6, 9</c>
<c>HIGH</c>
<c><xref target="I-D.nennemann-agent-override-protocol"/></c>
<c>7</c>
<c>HIGH</c>
<c><xref target="I-D.nennemann-agent-federation-privacy"/></c>
<c>5, 8</c>
<c>HIGH</c>
</texttable>
</section>
<section anchor="companion-draft-summaries"><name>Companion Draft Summaries</name>
<dl>
<dt>ECT (<xref target="I-D.nennemann-wimse-ect"/>):</dt>
<dd>
<t>Defines Execution Context Tokens that carry task
identity, delegated authority, and constraints across
agent boundaries. Foundational for all other drafts.</t>
</dd>
<dt>ACP-DAG-HITL (<xref target="I-D.nennemann-agent-dag-hitl-safety"/>):</dt>
<dd>
<t>Specifies Agent Context Policy tokens for DAG-based
delegation with human-in-the-loop safety gates.
Foundational for policy enforcement across all gaps.</t>
</dd>
<dt>Execution Audit (<xref target="I-D.nennemann-exec-audit"/>):</dt>
<dd>
<t>Defines per-action audit tokens for tamper-evident
recording of agent actions. Foundation for
cross-domain audit trails.</t>
</dd>
<dt>Behavioral Verification (<xref target="I-D.nennemann-agent-behavioral-verification"/>):</dt>
<dd>
<t>Defines behavioral profiles, verification evidence
formats, and appraisal procedures for runtime agent
compliance. Addresses Gaps 1 and 11.</t>
</dd>
<dt>Cascade Prevention (<xref target="I-D.nennemann-agent-cascade-prevention"/>):</dt>
<dd>
<t>Specifies circuit breakers, failure isolation,
checkpointing, and rollback mechanisms for multi-agent
workflows. Addresses Gaps 2 and 4.</t>
</dd>
<dt>Consensus (<xref target="I-D.nennemann-agent-consensus"/>):</dt>
<dd>
<t>Defines protocols for multi-agent agreement with
weighted voting, capability negotiation, and
policy-constrained proposals. Addresses Gaps 3 and 10.</t>
</dd>
<dt>Cross-Domain Audit (<xref target="I-D.nennemann-agent-cross-domain-audit"/>):</dt>
<dd>
<t>Specifies audit trail aggregation, correlation, and
query across administrative domains, plus resource
accounting. Addresses Gaps 6 and 9.</t>
</dd>
<dt>Override Protocol (<xref target="I-D.nennemann-agent-override-protocol"/>):</dt>
<dd>
<t>Defines a cross-vendor protocol for emergency stop,
graceful pause, parameter modification, and forced
rollback signals. Addresses Gap 7.</t>
</dd>
<dt>Federation Privacy (<xref target="I-D.nennemann-agent-federation-privacy"/>):</dt>
<dd>
<t>Specifies privacy-preserving mechanisms for federated
agent learning and cross-protocol migration procedures.
Addresses Gaps 5 and 8.</t>
</dd>
</dl>
</section>
<section anchor="dependencies"><name>Dependencies</name>
<t>The companion drafts have the following dependency
structure:</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>Behavioral verification is foundational: its attestation
format is consumed by cascade prevention and cross-domain
audit. Cascade prevention defines failure containment
that override protocol builds upon. Consensus extends
behavioral verification with multi-agent agreement.
Cross-domain audit provides the infrastructure that
federation privacy adds privacy controls to.</t>
</section>
</section>
<section anchor="recommended-prioritization"><name>Recommended Prioritization</name>
<t>Work should proceed in three phases:</t>
<dl>
<dt>Phase 1 -- Safety Foundation (Immediate):</dt>
<dd>
<t>Behavioral Verification (Gaps 1, 11) and Cascade
Prevention (Gaps 2, 4). These are CRITICAL severity
gaps with direct safety implications. Without runtime
verification and failure containment, no autonomous
agent deployment can be considered safe.</t>
</dd>
<dt>Phase 2 -- Control and Accountability (Near-term):</dt>
<dd>
<t>Human Override (Gap 7) and Cross-Domain Audit (Gaps 6, 9).
Override capability is a prerequisite for any production
deployment. Audit trails are required for regulatory
compliance in enterprise environments.</t>
</dd>
<dt>Phase 3 -- Interoperability and Scale (Medium-term):</dt>
<dd>
<t>Consensus (Gaps 3, 10) and Federation Privacy (Gaps 5, 8).
These enable multi-vendor and multi-domain agent
ecosystems but depend on the safety and accountability
foundations from Phases 1 and 2.</t>
</dd>
</dl>
</section>
<section anchor="security-considerations"><name>Security Considerations</name>
<t>The gaps identified in this document have cross-cutting
security implications:</t>
<t><list style="symbols">
<t>Behavioral Verification (Gap 1): Without runtime
verification, compromised agents exploit trusted
identities to perform unauthorized actions undetected.</t>
<t>Cascade Prevention (Gap 2): Absence of containment
creates a denial-of-service vector where compromising
a single agent disrupts entire multi-agent workflows.</t>
<t>Human Override (Gap 7): Without a standard override
protocol, safety-critical agent actions may not be
stoppable in emergency situations.</t>
<t>Cross-Domain Audit (Gap 6): Audit trail gaps across
domain boundaries enable agents to evade detection
and accountability.</t>
<t>Federated Privacy (Gap 5): Sharing agent data across
domains without privacy controls exposes network
topology, operational patterns, and business logic.</t>
</list></t>
<t>Implementers of autonomous agent systems <bcp14>SHOULD</bcp14> treat
the CRITICAL and HIGH severity gaps as security
requirements and prioritize their resolution. The
companion drafts each contain detailed security
considerations specific to their scope.</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="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>
<reference anchor="ARXIV-GAP" target="https://arxiv.org/abs/2507.02492">
<front>
<title>Gap Analysis for Autonomous Agent Protocols in the IETF Landscape</title>
<author fullname="Christian Nennemann">
<organization></organization>
</author>
<date year="2025"/>
</front>
</reference>
</references>
</references>
<?line 476?>
<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. The full gap analysis is available as
<xref target="ARXIV-GAP"/>.</t>
</section>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA7Vc6XIbOZL+j6fIlSMmrG0Wbcl222b0zixNybYirGMluY/o
6B9gFUgiVAXUACjKHEv9LPss+2QbmTiqioetXbv9o4ek6kgk8vjyy8RkWcac
dKUYwd6F0dNSVHDluBOVUA5m2sC4cVrpSjcWxnP88cJop3Ndwjte2z3Gp1Mj
liPYS3/tP2SP5dyJuTarEUg106zQueKVGEFh+MxlSiglKq5UxvEBWe0fkNn4
gOzpU8aN4CPYO7+42mO32tzMjW7qEeydnZ5f7DHbTCtprdTKrWoxgpPj67ds
OYJnjPHGLbQZMYAMZk1Z+jdPFkZaJ7mCs/h2BgCgzZwr+S/upFYjOFGFqIUq
cFmXwgpu8oUwdKGouCxHIIWb/WdawLAQjCltKu7kUuA7L99ODg8OXoePrw5e
Ph8xhkroX/P62bPn8ePBwVP8eJIdDVvN3MrKikzkbkRvjxt2/EnkDcoKE62c
+OTgWt8IZWnfjqR1Rk4bJwq/cTKHX7S5mZX61u7553AzF24EC+dqO3rypOCO
O8PzG2GGuLShNvMnhc6frO9UkufJhqh+Ews+zxbSlZnlM+FWfbG9oUSRL3Qp
85WXfARH43dwJEoxpz2AW+kW8L6puILzpTBGFuIbRd8q3+YyxCeRZ7wp5JrK
J0Zbmx3piksFrf7HeGXQ/jcK2L55l3KnYsGXUhteZkth5Ezm3mC3KPlNuhR+
7lwKXBVwIQwZosoFvBEqX1Tc3Eg1/y4K3iHjriXl3Oa8EFltxBJNdftq3nJZ
NkbAxF8NF+lqWtClLsspz2++ywI2Jdopu1ZWKNvYvsinTelklmzdX0JyTnjN
p7KUbgVnYq6d9HsS4+q3GtCaVDvFJksuyJK/aul+GcHKDZelX8mlsLoxuYBx
nutGue9lPZuy7VqFDlEB0wZpr7+IK8dVwU0h/yWKtTjS5rFtWe77bMKGdLuW
MROFMGQGWW3kkudrIfOt/3sM5fBBcKOkmsOFv9rbFWktLetUzv0jv8tSNiXE
tYwvfz35OXs3vuiL+47XMFa8XFlpvwwiLEgFbiEoZ8MHrgqb8zoE+TZ547+H
JPCCOzGCw6eHL7aumZtPckkL5VP75PDF05fDp4fPXx8ylmUZ8KlFhTjGrqNA
vJWb1ABllBBszZUF3GE4/PGpBzOWOd3kC9wYf3muq6pRIfgNQCKWkG41AJ93
BrhvTNdBs3YAK+EgN9LJnJcw57UFI8gDbxfCCLDJnukGJi1KjW/SBqSyzWwm
cymUGwJcL6SFQucNQbna6KUshAXOco2YxooCAtaChLWChLMVLkGUGPog2i5D
cQaQl9xaOZPC4r5VMF2BFRjjw3KgQqnpT04DZ7aRToCeoS5qrjDSeV2BW3CC
mBVwyDWuTzmwuqSUymaGVwKx3hDgxIFES3GIxgrgGH2A53gdn5YCjJjh3bnA
xxFARPkJJEK+4NLYASCEhEIakTtN31XRLq0QVs6VMBbEkpcNx0gWVN6agPeE
jT0Qs5k2zoJd6KYsYKbzxg69RVWyKErB2CM4Uc7ooiGRGeu4g9Uzd8vxPRR2
UEyo9BLfPzO6AhOAJyNZEd9a1GudngaFqEu9quhuqUAJhwqAiis+p00dsLzU
TQEa8SuauDdG29R1ucpQPwpKPUeHyoNixidZYeRSKFImQcYhwBhsY5ZihbtJ
7kEvwgTJy01XMGg/XDkyA+8NMfFJEUxdabBSzbtbyHC10oncYap3yc6cngu3
EGYIcIX2xsvkKKz7YMgyMJiLKgEtCoEuChnAzCMJFrI8tFl+AD75LIUqtIEF
5YwYx/HZJc9vGFerdTsA7oCX5RCjR9fxCtRrWdIqYCZVIdXcogY5eYQRC6Gs
XAp0L+AxaH7+nELr/T1avl4z+eC6LLlucBPvv6iH4L7ea8kXkseyvsfWaGRk
fMn9wGheVLxGQZVUgq17LwUYQSE5ST0AqfKyKSj+BVthegbiE+pAzTtGw0nL
8MvJ6dXxAC7H11cDOB83bvHk3dn4YsCuJifX1146rPEG6P98yWVJi5eKff78
gLrj/p6e4BZd+bn5VS6h5rUwfTUPfeBvw0xTSAoq0sLumMJ2xBRoY8rtQoMS
+ETItcqlFcw2VcUNedIthkFpgUpY1Jwq/G9Ow7SRZQFKfHJDjCLXwlRS6VLP
V17WG7FC0QoLe6cfr673Bv5/4eycPl8e/9fHk8vjI/x89X784UP6wMIVV+/P
P344aj+1d07OT0+Pz478zWfn19D7ie2djn/b8yveO7+4Pjk/G3/Y88m8a/0Y
znAdXq2mNsJRAMeImxs5FQXe82Zy8T//ffAcPn/+t1Ay39+HL1g0399jLFb+
bVqVq/DVLcSK8boWHJMfeh+GGOl4iXtBEflWAUbxIWP//jtq5o8R/DTN64Pn
fw8/4IJ7P0ad9X4knW3+snGzV+KWn7a8Jmmz9/uapvvyjn/rfY967/z40z9K
qQRkB6/+8XfmbWSmy1LfomU5YSqfYRrM/m5hdDNf6Mb1N23EGIG0ERthyI8J
Cj1IK9xUStw8dxa0ohhbznxAq41Uuax5yQAeh9BpeqwKL/cpffnaExy3N7aT
YsvVkLHjyTU83sFt7HuhcrOqnZ4bXi8wAZQrIF8rwOFFkHNjPISJT2GArkfP
QTyKsZRSko+oQ4ZJRcB6UEk8BwWH8eQCHm8jL4JQtWcybC3ygKBq9FeHFh8z
kR1gRvdFUykr6eyAAdm1sDkvfSYxTSlsT85dAu6IekPG3p9cf4DHVPJkUmVu
IbIPWtdRfxrxSAk1d04YBUb8s5EGRfa7xmvEi7yEqZhpBCeowK7GwPEbzDGz
mcgxNsWSPJTo/i0hy0KlCxHRlAJhDIFV0CqgHoyZNZ9zJyyDaJbAoaIS2l8S
ccgAct5QnLRNngtLqRMienKaXjpkLJV5V3KueOkFqoS1fC48suIxuRP89vjZ
GQRVFIT9I1EeDQteugEuQ85WAzRpo8sSkGsA6SzkjTFdY2KPEg2aKhrvixv1
hMi1XVknKsg5+lJ0FoqLuBrdGFbylUDLETxfeEqMQIXKN8AoZXufmlnr94Xk
c8OrNs+Tu7eguYu4Roz9+eefwG0uZcaNYz9k3/LvB3YHW/69/3g6PoPzi+PL
8fX55dW2S8K/u7UH/J429m9ANv4BlYPA7N34Al7+seUBf8EKxu+Oz67h5Oz6
+HI8wSAMH8a/HV/uXkErww8P/tK9/y5SMHD309/jlzfdL5PulyO42/L+H7pv
+fqXjR24A1Lys1Hny8HTUedL/Mv2HbyDDhOGX3g9PBPzIf2FqMrh1+7v/Lz2
hfjN7fdHrfYM4YFfdhjA8a/Hk4+djX98PLne37r9YQFIbLc57Q4mC5Hf1Fqi
O94l6hL/IE3eSAdvjOA3iB79/b+jfg9HW7jPP8Ifn4/SY/5Ye/9f4AEX5x9O
Jr/B3+Dd+c/Hl2fjs8nxTh+gBYwnF9nR+F1GTnsH16axDq5yTVnnDsbWNoa4
6AujZxITYP9+WuOLEbRUWOC+4vp/HEGfs0Te8I+/TAEnZ28vx1fXlx8n1x8v
d6+9XcBJIH/gDnszOdaU+PlSYOXti3K4a1nJN0YW86CFVgGvRms0X1z969E2
NvaPdQUeHIx2Ev+bsfM7mtCff/7JPo/g0UzOM8w3niv8j8DsH6c0eJmy0riT
lfbuGQv0bcjW1gd+zOsXkdpKZTriqUUX+pRa1xH0WARTyFC+BF4URljrKQbP
pOUi1OZdFiA+mEEq74YBJCOzI0wARUmkXzzY8aCkJQHFAFRg/EWPDUG8jCId
PN1HgIh5PhH4/i/P9n3506hCmLlmsIvcCA/aRyCd4k0S7JRYIYvhKJtyrAIS
weORxSYjEmU73CcBTAxV9OPz/QEVqQ5LgeMO2l7rSH4ZWYceID7+HepakW0m
oY+xY5oLC4F5RvA4S2GgjFw4CfSCpES43+khUCnvwPnOBV33IyroRM0M96AP
cWp64XuuCoxALV9bRI+N/FAq86tIs0c9vdrvYHyeXNH/8XXYxrr1QdrK1gvD
/tEGPoJJ5IKx2c7Yo0cwuTy5PpmMP3gWTLoV/vqIDPpgBF9s+zF2pjuIURRQ
iXzBlbSV52h80RHZs65VIY0TsLrfK6wGS4nyD4H4G/j8ObSy7++BdGVZXXLn
CV7nBDJVaIvTBnk/17XfXKuojSH7RbpUkw4SOrcIkPG2QmBMgMLImRPFwJNo
upJWFAOGvtq4TM+yqW5UYaMLZhkIqsuoViy4mguDIFwqtq3IsKFawQqlktZL
2iH1jWlqZ1mhb7FkEJxo2qZ0dsjGIaQUSIxvL9d29EbJE+JWHsat3N3zZOy0
I3ocVcCtQUbXElHZ3+3cQws2DdAi8aAgrS4DNapNigEYMLlUxC6ySSxyimyh
c0ALwV2ikCCcWRGFnCORpYREopYR40P7h5yd0gba/oQfURi/y5L3dSLRkI0j
LewXF8XEGikKl8pEBagPI1hLhPtQpjTVWxVFid5aHrBJm/3fsD/w/uTd+y3O
92wE21u+qdW16X5tjE/hpPVDthCov7lQItWLNpZ/s5lvl/QpdYegiiHvW0Y2
MnorGipHtDmE3miIT7uWddLNJZ+5AVzwT9ruQ6GFJXcNudLLkXmSQ+bMotKw
cQClvBFwK+R8gc9dahfJzCTjyqccVnPjJPJEVC5D0FvItbnWppAqMCHU/LJM
VrW2VqId3YbwgJyBkcIhi5rC2MMcMK2153KInwUvs2uMfX4TI56mncONMLyk
jUtJcGsAbat81uVMUPXRGJICPdXCsTMDj8VwPhyws+PryfnZW4qK0lSiyBBB
SIebQVshPiFDTX0VM5XOcLPqvwi6esQw3wkUUXQ7ZOfrsRX5I4yP5EjR4nBF
qdPS9irTRlRcNbz0/G4cx8B7BAHcyIl8i8v5/elh/+1t8IDJkPnlVFckcXmJ
vWEe+w4eFlhi5VlEFfOGG66cEBamYqVRw4YrW2vjQCiiHGkwJXmf5GWCJDXH
fqWjqEpvqqSSVaRl0J1RJmQoRSkqDJjeQb0tuk67bgjQpkBhBWa1lkC1MOO5
gEbxPBe1C70gL4ORyKZKxVpwtMYyPcw/Nnv9vY3YKLQ2hkM2I50fees6ySY+
YwGfEb1MXJVZCqL7eAnaFMLEiBKa2czxqhYmE0sCapiB5lIhn7B9MmujadTO
Wt3fx4ciNMsCnjcix+bKgCFm4fO5iXNpfueMEYGxXTMrH7YYYvWZVKIYIh6O
eCmQraJK3pWyFCtELnGOMas4YcGK3wjP1jVm/uDUtTE909u+l6P1SZirtY42
7l6v/tmSncAKamW2tZElohWjWCVQWKTCna6x98hzMWuQbW6sGACB+TaG7jOn
EXOqhLCo19yhCx7c7PPqJvSm2BqTTYwnKb5IEHShbzGKFqKUS2FYqh/DUuIQ
BfYeYdaoguOe8TJMbyDZ+qAN2RgDilDi9Pjo5OPpFjCxUeYHJ0szPSnShfJD
zWEq3K3ozGuAUEtptPJ2FnLL+HCMKz6dXOzDgi8FdeDD9tO2Br/rN09C66Q7
wIIeQL3naPvptYS8uZHCDqmV84XSrzuVEu/PlGgcFgW+lRO3KpVZeE8uisaI
7xLMXkegvYU9oUW+kWUp1ZycYmu2pyGqeDVGDJXLMtkyS6UgRvqmqrvxgheY
JTz7sxQxfAxZa3W1EWS1FodoyO0aiziW4r5P6/4uth7pQzmvrcPqi+DegxPx
lwMIUr4B5G6dZEy2SRUI7yeCZCbodyvFK9+/Y7xYCuOkxZEClYdpKD43Aqsw
Dy5CUI5PsAPm+2aYBKVd+AEjRyCxzcZDgPfX1xe++6ccU52JS1+xHhw87Vri
lFuZt/U+GiAj/NvDvR1QCwkCfwP4PEi1+y52blvx7gwCb23w40IXNBjQrSA6
w0yheO88POYsWeEACqHGGeN53hierwZQcocxvMNliFC85Wl+jbUsgI8I/Zre
SkvP+PaqGK7iXMqln0vxVEia6TjCmRQ45XVNmlpre3tnwbG0wKz1RlnQEnFC
hKbtpGtJwRFjdxvvuCMmBtoFIWUrtSFil92Nsiyj/4zCf9ndFwPgHbylcBm7
ApHc2Xbfrqz3f3lGD/Gs3UiF7e4X79wguIODARwcPEz+bSgf7uBwAM8f+IDW
geAOng3g4OnXhd8W0uAOfhzA66/fvCV/wx28/PqN23IP3MGLAbxqb0ZW3PFp
FieuAjG+bnhOU6AINo6E+BYPuKKxIiSU/RTFF0yPJgGOAmDaeZKEsDiNU9Cs
BoMuJ+rPadCkFA7qJlzQYRtClEnTAx1wAB3r434KGyd4NHJHcciMhi7attHG
ena4BK3tyodqEUeO1w6cuM5RmUiGM4iLSodPNtsICfw5Qa2EjVUEzkV41tqP
QYV8X/qh3h437yuUjaV1PbW3V536JNDa7Ur6BRGDUMEQTp/BOhnR8X7MFl/g
zIeM7TpKsmNPdkaL3lo6+aIObb9Bv5vhl0Isua8hA7GFuJ5L628MeLDHXsfx
jR5RPU4NH4riB/Sog4POAEvnTMmOlW0LYGsGF4hW+BLRiqKlHrBU80G/u9JS
WrSqDoPDAHpDuf0lHdJjnuOKWkbvq4G0b2BpNn/tzR6PJYIVBenTfYMuLOog
rUHoyXjPyFJ88Hiw1tYXW2tLeeZ35ymuZaOxu3NRWwL92u50DLtb1A+6FX2U
+J+NJ7G+ANcHUJeNTTAJQ12qIDYX9SMt6nV3QinVeDuWtCX99PaL7yjWiYTr
1+IMNqrxBJX9fFMakUYxfaWOYSSaZVsZ99YFL4eMvU3ZLh1L2bGibXlxbZPC
71mnHl1ziURypeSSOoGUhHa06Xr148b2vKB7X/ny/Cj2VCihIqjcOMNANbTr
wc22E8NSc2Njqqrbvu0FSKBueafzvrUb335e7vj7ZpTafv//5/lLBrBhlPiH
Tef7Dm+iB6dYFv5tWlBvwqAQOOy+HUh1dxVh1JsdfXQ6utSm9hGN+nUamSxw
mtKG0t5XN5sN9I45xlodVYOk4Oa1kcJKLa+2b8UIjCWSqiVccEjcQlNTM6UN
+75NYNmuQQHCN1vD+zAE3B4SSBWyoyH5XuccJWPtniRGmhdF27WP8xfgNNV0
lwL7Gn7WPtRQiYHEk8rxRA05rB8UdwskBOoF9+XZBX6AA2zvXnlU1oE0j0+q
ShQ4akGhZSd+8UgAC5j9cDyTNoVBDwv45DqA5/t+vNIKGqRO9Uo8UYERFi8N
fTo8GhARo0Qg4t9qOyR/ACwM+rtD8XfTCAaxrRkaTDH2dZqfYZKUCvBCIN+J
Agyjug5RXZMwAEyHfXy6inn78ZngJsNZcdLbGldM0wkv9zsHDvtZ2Se5Abze
x+iabuvggu28Fp6oaQ81ERCPC8Jk053fQL0nKpcgn5g3JTayVj28hwYj/KkD
5JW6dGhSxjNUxknbqPYi4uKucl4KeHwqCtlUrTomvbEc6+tPr45t+c8nlQG8
InV4uxFd9i4kbTo416HzEnztEHpIhfrkgpQYemEwLMLDvU0ktBw9wfp5Z1pw
xLyHnlUReUPMxSTYir/e5zrPh8TzRMXm2Q7KfT6u5Y1DuMNsfGDX1keMZV90
PzjYH33FHXpzHrEzKT7VpSa7aKzHAaE4leGQXDhl0KhQoCJrFluk2JzBSRJR
4GG9bWfKw9TTCMbtYFg3HGO+E1gFAodCKMlLHDwhtJLj9AweCgqDJEl4VBIg
J9odbyikpYGSMMiwde6djhTucMZWeS3Zum1mLdJ2WTph2u8aV3wVJnMYEF6s
w2mrLoyUrgkhjNS2PQTAj6i2Ds4mY0pcQLDxlgyIPtGO8Ysl7obfIh8QNq2c
JNiYB41zYCO4Cl3goOW2/5tEsJ1xgrUkJT7VGv0lnKekgwA1MayDXls5HKEI
ZekUzybgmARNw+CIWVWXlFNxlBdr8PUTANG7wzkhHCfCTN9JLfhc4opijgna
tBDdjfVair5DGvIpoVNpqDzxFGo4HrABZePUIdo3Kp7LElNHfEXeCxGQiHDP
nkoDNte1oLByMj4bbwkp/diBUyX+ykhI+DOzft7iEYzzG6VvS1HMaVXp/MQC
aY4FVzceiKRZEly5ntFv3VOFLB4h7B/h8yUEsvyN9eQ3gSv//80iCkaRLp5r
7J517J3S7B1K5Nhf7h0n/F//DW+xXUcAAA==
-->
</rfc>