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

396
workspace/drafts/agent-context-policy/draft-nennemann-agent-dag-hitl-safety-00.generated.md Normal file
View File

@@ -0,0 +1,396 @@
---
title: "Agent Context Policy Token: DAG Delegation with Human Override"
abbrev: ACP-DAG-HITL
docname: draft-nennemann-agent-dag-hitl-safety-00
category: std
submissiontype: IETF
consensus: false
ipr: trust200902
area: "Security"
workgroup: "Security Dispatch"
keyword:
- agent
- delegation
- safety
- HITL
- token
author:
- ins: M. Nennemann
name: Markus Nennemann
org: Independent
date: 2026-02-28
normative:
RFC2119:
RFC8174:
RFC7519:
informative:
ECT:
title: "WIMSE Encrypted Context Transfer"
target: "https://www.ietf.org/archive/id/draft-nennemann-wimse-ect-00.html"
TOKEN-CONTAINER:
title: "WIMSE Token Container"
target: "https://www.ietf.org/archive/id/draft-richer-wimse-token-container-00.html"
---
# Abstract
This document defines a minimal token profile for safe agent context transfer. The profile has two contributions: (1) an Agent DAG Token for explicit delegation lineage and execution constraints across agents, and (2) a Human-in-the-Loop (HITL) policy mechanism for mandatory human override in safety-relevant situations.
The profile is intentionally narrow. It does not define encryption envelopes, trust onboarding, regulated-environment controls, or broader workflow frameworks. It specifies only interoperable base claims and processing behavior needed for DAG-based delegation and HITL safety intervention.
# Status of This Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
# Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
# 1. Introduction
Agentic systems frequently delegate tasks across multiple software agents. Existing ad hoc context passing rarely encodes explicit delegation topology or a standardized safety pause/escalation mechanism. This creates ambiguity in responsibility chains and weakens operational safety.
This specification defines a base token profile that addresses both concerns with minimal overhead:
- **Agent DAG Token**: expresses delegation as a Directed Acyclic Graph (DAG) with explicit node and edge semantics.
- **HITL Policy**: expresses machine-readable conditions under which processing MUST be paused for human decision.
The design goal is practical deployment in heterogeneous systems using existing token/signature machinery. Confidentiality and complex governance features are deferred to future extensions.
## 1.1. Scope
This document defines:
- A minimal claim set for DAG delegation and safety policy.
- Validation and processing rules for interoperable behavior.
- A minimal audit decision record for HITL actions.
This document does not define:
- Encryption envelopes or payload confidentiality mechanisms.
- Regulated-environment control catalogs.
- Trust framework onboarding or remote attestation.
- Full workflow orchestration semantics.
# 2. Conventions and 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.
## 2.1. Terms
- **Token Issuer**: Entity that issues the token.
- **Node**: A task or execution step identifier in the delegation graph.
- **Edge**: A directed delegation relation between nodes.
- **Current Node**: Node the processing component is currently executing.
- **HITL Trigger**: A condition requiring human decision.
- **Human Approver**: A human principal authorized to decide override actions.
- **Decision Record**: Minimal audit object capturing human intervention.
# 3. Safety-Centric Use Cases
## 3.1. Clinical Triage Assistant
An intake agent delegates symptom summarization to a model agent, then to a recommendation agent. If high-risk symptom keywords are detected, HITL policy requires clinician approval before recommendations are returned.
## 3.2. Industrial Robot Workcell
A planning agent delegates path optimization to motion agents. If path confidence drops below threshold near human workers, execution pauses and requests supervisor override.
## 3.3. Financial Fraud Escalation
A fraud scoring agent delegates to investigation agents. If a low-confidence/high-impact action (account freeze) is requested, HITL policy requires analyst confirmation.
# 4. Requirements
An implementation conforming to this specification:
1. MUST support all required base claims in Section 5.
2. MUST validate DAG acyclicity before acting on delegation context.
3. MUST enforce HITL trigger actions prior to safety-relevant continuation.
4. MUST produce a Decision Record for each HITL decision.
5. MUST fail closed when policy conflicts cannot be deterministically resolved.
6. MUST reject tokens missing required temporal or issuer context.
# 5. Token Model
This profile is carried as claims within a signed token format (for example, a JWT {{RFC7519}}). The exact serialization container is out of scope, provided claim semantics and processing behavior are preserved.
## 5.1. Base Claims
Required claims:
- `iss` (string): issuer identifier.
- `sub` (string): subject identifier of the principal/process context.
- `aud` (string or array): intended audience.
- `iat` (number): issued-at timestamp.
- `exp` (number): expiration timestamp.
- `jti` (string): unique token identifier.
- `actx_ver` (string): profile version, initially `"1.0"`.
## 5.2. DAG Claims
Required DAG claims:
- `dag` (object): DAG container.
- `nodes` (array, REQUIRED): each node object contains:
- `id` (string, REQUIRED)
- `type` (string, REQUIRED)
- `agent` (string, REQUIRED)
- `max_depth` (number, OPTIONAL)
- `constraints` (object, OPTIONAL)
- `edges` (array, REQUIRED): each edge object contains:
- `from` (string, REQUIRED)
- `to` (string, REQUIRED)
- `purpose` (string, OPTIONAL)
- `root` (string, REQUIRED): root node id.
- `cur` (string, REQUIRED): current node id.
- `path` (array of string, OPTIONAL): observed traversal path.
## 5.3. HITL Policy Claims
Required HITL claims:
- `hitl` (object): HITL policy container.
- `version` (string, REQUIRED), initially `"1.0"`.
- `rules` (array, REQUIRED, at least one item):
- `id` (string, REQUIRED)
- `trigger` (object, REQUIRED)
- `required_role` (string, REQUIRED)
- `action` (string, REQUIRED): one of `pause`, `escalate`, `abort`.
- `allow_override` (boolean, REQUIRED)
- `override_action` (string, OPTIONAL): one of `continue`, `abort`, `reroute`.
- `unreachable_human` (string, REQUIRED): one of `abort`, `safe_pause`.
## 5.4. Minimal Trigger Object
A trigger object MUST include:
- `kind` (string): e.g., `risk_score`, `keyword_match`, `confidence_below`.
- `op` (string): one of `gt`, `gte`, `lt`, `lte`, `eq`, `in`.
- `value` (number|string|array): threshold or matcher value.
- `input_ref` (string): processing attribute to evaluate.
# 6. Processing Semantics
## 6.1. Validation
Before processing, the receiver MUST:
1. Validate token signature and base temporal checks (`iat`, `exp`).
2. Validate presence and type of required claims.
3. Validate `dag.root`, `cur`, and all edge endpoints reference existing nodes.
4. Validate DAG acyclicity.
5. Validate `cur` is reachable from `root`.
If any check fails, processing MUST stop and return `invalid_token`.
## 6.2. Delegation and Traversal
When delegating from node A to node B:
1. An edge `A -> B` MUST exist.
2. If `max_depth` applies, resulting depth MUST NOT exceed limit.
3. Node constraints (if present) MUST be enforced before delegation.
4. On success, `cur` MUST be set to B and `path` SHOULD append B.
If delegation check fails, processing MUST stop and return `invalid_delegation`.
## 6.3. HITL Evaluation
For each safety-relevant operation, receivers MUST evaluate `hitl.rules` in deterministic order by array position.
- If no rule triggers, processing MAY continue.
- If one or more rules trigger:
- If any triggered rule has `action=abort`, receiver MUST abort.
- Else receiver MUST apply `pause`/`escalate` behavior and request human decision per `required_role`.
A human decision MUST result in one of:
- `continue` (if override allowed),
- `abort`,
- `reroute` (if supported and policy allows).
If no human approver is reachable, receiver MUST apply `unreachable_human` behavior.
## 6.4. Conflict Resolution
If multiple triggered rules prescribe different actions, receiver MUST apply strict precedence:
1. `abort`
2. `escalate`
3. `pause`
If ambiguity remains (for example multiple mutually exclusive override actions), receiver MUST fail closed with `policy_conflict`.
## 6.5. Decision Record
Each HITL decision MUST produce a Decision Record with at least:
- `decision_id` (string)
- `token_jti` (string)
- `rule_ids` (array of string)
- `human_id` (string)
- `human_role` (string)
- `decision` (string)
- `reason` (string, MAY be empty)
- `time` (number)
# 7. Interoperability and Deployment Considerations
Implementations SHOULD use stable node identifiers for cross-system processing. Unknown optional fields MUST be ignored unless explicitly marked critical by implementation policy.
Clock skew handling SHOULD be bounded and consistently configured across participants. Deployments SHOULD provide deterministic rule ordering and maintain decision logs with integrity protections.
# 8. Security Considerations
This profile targets safety and control-plane clarity, not confidentiality. Safety risks include bypassed HITL checks, forged delegation paths, replay of stale tokens, and policy downgrades.
Implementations SHOULD:
- enforce token signature verification and expiration,
- bind issuer trust to deployment policy,
- detect replay using `jti` where feasible,
- prohibit silent fallback when HITL evaluation fails,
- minimize override authority scope by role.
Confidentiality is explicitly out of scope for this base profile. Encrypted envelope mechanisms MAY be defined in future extensions.
# 9. Privacy Considerations
Tokens can reveal workflow topology and role metadata. Implementations SHOULD avoid unnecessary personal data in node, rule, and decision claims.
Decision Records SHOULD use least-identifying human identifiers consistent with accountability requirements, and retention windows SHOULD be minimized per deployment policy.
# 10. IANA Considerations
This document has no IANA actions.
# 11. References
## 11.1. Normative References
- {{RFC2119}}
- {{RFC8174}}
- {{RFC7519}}
## 11.2. Informative References
- {{ECT}}
- {{TOKEN-CONTAINER}}
# Appendix A. Compact JSON Examples
## A.1. Example DAG Token Claims
```json
{
"iss": "https://issuer.example",
"sub": "workflow:triage-42",
"aud": "https://runtime.example",
"iat": 1771939200,
"exp": 1771942800,
"jti": "9b524a7c-f2b8-4f41-9f23-472f63f24c95",
"actx_ver": "1.0",
"dag": {
"root": "n0",
"nodes": [
{ "id": "n0", "type": "intake", "agent": "agent:intake" },
{ "id": "n1", "type": "summarize", "agent": "agent:llm", "max_depth": 3 },
{ "id": "n2", "type": "recommend", "agent": "agent:reco" }
],
"edges": [
{ "from": "n0", "to": "n1", "purpose": "summarization" },
{ "from": "n1", "to": "n2", "purpose": "recommendation" }
]
},
"cur": "n1",
"path": ["n0", "n1"]
}
```
## A.2. Example HITL Policy Claims
```json
{
"hitl": {
"version": "1.0",
"unreachable_human": "safe_pause",
"rules": [
{
"id": "r-high-risk",
"trigger": {
"kind": "risk_score",
"op": "gte",
"value": 0.85,
"input_ref": "eval.risk"
},
"required_role": "clinician:oncall",
"action": "escalate",
"allow_override": true,
"override_action": "continue"
},
{
"id": "r-low-confidence",
"trigger": {
"kind": "confidence_below",
"op": "lt",
"value": 0.6,
"input_ref": "eval.confidence"
},
"required_role": "clinician:oncall",
"action": "pause",
"allow_override": true,
"override_action": "reroute"
}
]
}
}
```
## A.3. End-to-End Processing Example
```json
{
"event": "hitl_decision",
"decision_id": "dec-2f5a9f77",
"token_jti": "9b524a7c-f2b8-4f41-9f23-472f63f24c95",
"rule_ids": ["r-high-risk"],
"human_id": "user:alice",
"human_role": "clinician:oncall",
"decision": "continue",
"reason": "reviewed chart context",
"time": 1771940102
}
```
---
# Delta Note: Intentionally Deferred in This Base Draft
This base draft intentionally excludes encryption envelopes, regulated controls, remote attestation, trust onboarding, and broad workflow orchestration to keep interoperability achievable for early implementations.
## Why these are deferred
- **Encryption envelope**: confidentiality mechanisms add key management, envelope formats, and processing complexity that are orthogonal to core delegation and safety semantics.
- **Regulated controls**: jurisdiction-specific controls differ significantly and can be layered as profiles once base behavior is stable.
- **Remote attestation**: useful for stronger trust signals but not required to establish token-level delegation/HITL interoperability.
- **Trust onboarding**: federation metadata and legal trust framework artifacts are deployment concerns outside minimal protocol semantics.
- **Rich orchestration semantics**: full workflow languages and compensation logic exceed the scope of a compact token profile.
## Extension path
Future extensions can define:
1. Confidential profile (encrypted payload and selective disclosure).
2. Regulated profiles (health, finance, public sector control sets).
3. Trust profile (attestation claims and verifier behavior).
4. Advanced policy profile (multi-party approvals, quorum, time-bounded overrides).
This sequencing keeps the base draft focused on the immediate gap: explicit DAG delegation context plus deterministic human safety override behavior.

BIN
workspace/drafts/agent-context-policy/draft-nennemann-agent-dag-hitl-safety-00.generated.pdf Normal file
View File

Binary file not shown.

98
workspace/drafts/agent-context-policy/master-prompt-ietf-id.md Normal file
View File

@@ -0,0 +1,98 @@
# Master Prompt: Minimal IETF I-D for Agent DAG Token + HITL Policy
You are an expert IETF editor and protocol designer.
Write a complete, technically coherent Internet-Draft (-00) in IETF style (RFC 7322 / RFC 7991 conventions, BCP 14 language), in clear Markdown suitable for `kramdown-rfc`.
## Objective
Create a **minimal base specification** for safe agent context transfer with exactly two core contributions:
1. **Agent DAG Token**: a lightweight token container that models agent/task delegation as a DAG.
2. **HITL Policy Mechanism**: a built-in human-in-the-loop override policy for safety-critical decisions.
The draft should be inspired by:
- draft-nennemann-wimse-ect-00 (concept lineage)
- draft-richer-wimse-token-container-00 (base token container idea)
But this new draft MUST:
- **NOT require encryption overhead** in the base spec.
- **NOT depend on broader WIMSE framework components**.
- stay **small, sharp, and implementation-friendly**.
- focus on **safety first**, not regulated-environment complexity.
## Design Constraints
- Keep the draft intentionally narrow and deployable.
- Base profile only; define extension points for future work.
- Do not include advanced compliance features in the core.
- Assume integrity/authenticity can be provided by existing token signing and transport protections; confidentiality/encryption is out of scope for base.
- Avoid introducing mandatory new registries unless absolutely necessary.
## Required Content
Produce a full I-D with these sections:
1. Title, Abstract, Status, Copyright
2. Introduction (problem statement and why safety needs DAG + HITL)
3. Conventions and Terminology (BCP14 + terms)
4. Use Cases (2–3 concise safety-centric examples)
5. Requirements (minimal normative requirements)
6. Token Model
- Minimal claims set (base claims + DAG claims)
- DAG representation (nodes, edges, constraints)
- Processing semantics (validation, traversal, delegation checks)
7. HITL Policy Model
- Policy object structure (trigger, required human role, action)
- Runtime behavior (pause/escalate/override/abort/continue)
- Audit event requirements (minimal decision record)
8. Interoperability and Deployment Considerations
9. Security Considerations
- Safety failure modes
- Abuse/misuse
- Why confidentiality is out of scope in base
10. Privacy Considerations (minimal but explicit)
11. IANA Considerations (likely none, or minimal if truly needed)
12. References (normative + informative)
13. Appendix A: Compact JSON examples
- one DAG token example
- one HITL policy example
- one end-to-end processing example
## Token/Profile Specific Guidance
- Keep token structure aligned with a generic token container philosophy.
- Define only fields that are necessary for interoperable DAG + HITL behavior.
- Separate:
- **Token data model** (what is carried)
- **Processing rules** (how recipients act)
- Include clear error handling outcomes for:
- invalid DAG
- missing node context
- policy trigger without reachable human approver
- conflicting policy actions
- Include a strict “Out of Scope” subsection listing:
- encryption envelope
- regulated controls
- remote attestation
- trust framework onboarding
- rich workflow orchestration
## Style and Quality Bar
- Be concise and normative where needed.
- Avoid hand-wavy text; include precise behavior.
- Keep -00 realistic: minimal yet complete.
- Prefer clarity over completeness.
- Include TODO markers only where absolutely unavoidable.
## Output Format
Return:
1. **Suggested draft name** (`draft-<author>-<topic>-00`)
2. **Final full draft Markdown**
3. **A one-page delta note**: “What this base draft intentionally does NOT include yet (and why)”

12
workspace/drafts/ect-landscape-paper/Makefile Normal file
View File

@@ -0,0 +1,12 @@
.PHONY: pdf clean
pdf: main.pdf
main.pdf: main.tex references.bib
pdflatex -interaction=nonstopmode main.tex
bibtex main
pdflatex -interaction=nonstopmode main.tex
pdflatex -interaction=nonstopmode main.tex
clean:
rm -f main.aux main.bbl main.blg main.log main.out main.pdf main.toc

119
workspace/drafts/ect-landscape-paper/main.aux Normal file
View File

@@ -0,0 +1,119 @@
\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]{}
\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction}{1}{section.1}\protected@file@percent }
\citation{wimse-arch}
\citation{wimse-arch}
\citation{spiffe}
\@writefile{toc}{\contentsline {section}{\numberline {2}Background}{2}{section.2}\protected@file@percent }
\newlabel{sec:background}{{2}{2}{Background}{section.2}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}IETF AI Agent Standardization}{2}{subsection.2.1}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}WIMSE Architecture}{2}{subsection.2.2}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {2.3}The Identity--Authorization--Execution Stack}{2}{subsection.2.3}\protected@file@percent }
\citation{landscape-survey}
\@writefile{toc}{\contentsline {section}{\numberline {3}Landscape Analysis: Motivating Evidence}{3}{section.3}\protected@file@percent }
\newlabel{sec:landscape}{{3}{3}{Landscape Analysis: Motivating Evidence}{section.3}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}Corpus Overview}{3}{subsection.3.1}\protected@file@percent }
\@writefile{lot}{\contentsline {table}{\numberline {1}{\ignorespaces Corpus summary statistics.\relax }}{3}{table.caption.1}\protected@file@percent }
\providecommand*\caption@xref[2]{\@setref\relax\@undefined{#1}}
\newlabel{tab:corpus}{{1}{3}{Corpus summary statistics.\relax }{table.caption.1}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {3.2}Category Distribution and the Safety Deficit}{3}{subsection.3.2}\protected@file@percent }
\@writefile{lot}{\contentsline {table}{\numberline {2}{\ignorespaces Category distribution organized by accountability tier.\relax }}{3}{table.caption.2}\protected@file@percent }
\newlabel{tab:tiers}{{2}{3}{Category distribution organized by accountability tier.\relax }{table.caption.2}{}}
\citation{rfc7519}
\citation{rfc7515}
\@writefile{toc}{\contentsline {subsection}{\numberline {3.3}The Overlap Problem}{4}{subsection.3.3}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {3.4}Gaps Relevant to Execution Tracking}{4}{subsection.3.4}\protected@file@percent }
\newlabel{sec:landscape-gaps}{{3.4}{4}{Gaps Relevant to Execution Tracking}{subsection.3.4}{}}
\@writefile{lot}{\contentsline {table}{\numberline {3}{\ignorespaces Execution-layer gaps in the IETF landscape.\relax }}{4}{table.caption.3}\protected@file@percent }
\newlabel{tab:exec-gaps}{{3}{4}{Execution-layer gaps in the IETF landscape.\relax }{table.caption.3}{}}
\@writefile{toc}{\contentsline {section}{\numberline {4}Execution Context Token Specification}{4}{section.4}\protected@file@percent }
\newlabel{sec:ect}{{4}{4}{Execution Context Token Specification}{section.4}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {4.1}Design Principles}{4}{subsection.4.1}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {4.2}Token Structure}{5}{subsection.4.2}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.2.1}JOSE Header}{5}{subsubsection.4.2.1}\protected@file@percent }
\@writefile{lol}{\contentsline {lstlisting}{\numberline {1}{\ignorespaces ECT JOSE Header.}}{5}{lstlisting.1}\protected@file@percent }
\@writefile{toc}{\contentsline {subsubsection}{\numberline {4.2.2}Claims}{5}{subsubsection.4.2.2}\protected@file@percent }
\@writefile{lol}{\contentsline {lstlisting}{\numberline {2}{\ignorespaces Complete ECT payload example.}}{5}{lstlisting.2}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {4.3}DAG Construction and Validation}{5}{subsection.4.3}\protected@file@percent }
\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces A five-task DAG representing a cross-organization financial workflow. Task\nobreakspace {}A (root) fetches data; Tasks\nobreakspace {}B and\nobreakspace {}C execute in parallel (fan-out); Task\nobreakspace {}D merges results (fan-in); Task\nobreakspace {}E performs the final action. Each task references its predecessors via the \texttt {par} claim.\relax }}{6}{figure.caption.4}\protected@file@percent }
\newlabel{fig:dag}{{1}{6}{A five-task DAG representing a cross-organization financial workflow. Task~A (root) fetches data; Tasks~B and~C execute in parallel (fan-out); Task~D merges results (fan-in); Task~E performs the final action. Each task references its predecessors via the \texttt {par} claim.\relax }{figure.caption.4}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {4.4}Verification Procedure}{6}{subsection.4.4}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {4.5}HTTP Transport}{6}{subsection.4.5}\protected@file@percent }
\@writefile{lol}{\contentsline {lstlisting}{\numberline {3}{\ignorespaces HTTP request with WIMSE identity and ECT.}}{6}{lstlisting.3}\protected@file@percent }
\citation{daap-v2}
\citation{stamp}
\citation{agentic-jwt}
\citation{verif-conv}
\citation{trans-att}
\citation{txn-tokens}
\citation{actor-chain}
\citation{hjs}
\citation{actor-chain}
\citation{txn-tokens}
\citation{stamp}
\@writefile{lot}{\contentsline {table}{\numberline {4}{\ignorespaces ECT verification procedure (13 steps in 4 phases).\relax }}{7}{table.caption.5}\protected@file@percent }
\newlabel{tab:verify}{{4}{7}{ECT verification procedure (13 steps in 4 phases).\relax }{table.caption.5}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {4.6}Audit Ledger Interface}{7}{subsection.4.6}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {5}Comparative Analysis Against the Landscape}{7}{section.5}\protected@file@percent }
\newlabel{sec:comparison}{{5}{7}{Comparative Analysis Against the Landscape}{section.5}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {5.1}Comparison Framework}{7}{subsection.5.1}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {5.2}Head-to-Head Comparison}{7}{subsection.5.2}\protected@file@percent }
\citation{daap-v2}
\citation{trans-att}
\citation{hjs}
\@writefile{lot}{\contentsline {table}{\numberline {5}{\ignorespaces Feature comparison: ECT vs.\ eight competing/complementary proposals. {\fontfamily {pzd}\fontencoding {U}\fontseries {m}\fontshape {n}\selectfont \char 51} = full, $\sim $ = partial, {\fontfamily {pzd}\fontencoding {U}\fontseries {m}\fontshape {n}\selectfont \char 55} = none.\relax }}{8}{table.caption.6}\protected@file@percent }
\newlabel{tab:comparison}{{5}{8}{Feature comparison: ECT vs.\ eight competing/complementary proposals. \ding {51} = full, $\sim $ = partial, \ding {55} = none.\relax }{table.caption.6}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {5.3}Uniqueness Quantification}{8}{subsection.5.3}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {6}Gap Coverage Analysis}{8}{section.6}\protected@file@percent }
\newlabel{sec:gaps}{{6}{8}{Gap Coverage Analysis}{section.6}{}}
\citation{trans-att}
\@writefile{lot}{\contentsline {table}{\numberline {6}{\ignorespaces ECT coverage of the 12 identified landscape gaps.\relax }}{9}{table.caption.7}\protected@file@percent }
\newlabel{tab:all-gaps}{{6}{9}{ECT coverage of the 12 identified landscape gaps.\relax }{table.caption.7}{}}
\@writefile{toc}{\contentsline {section}{\numberline {7}Discussion and Limitations}{9}{section.7}\protected@file@percent }
\newlabel{sec:discussion}{{7}{9}{Discussion and Limitations}{section.7}{}}
\@writefile{toc}{\contentsline {subsection}{\numberline {7.1}The Self-Assertion Limitation}{9}{subsection.7.1}\protected@file@percent }
\citation{opentelemetry}
\citation{w3c-prov}
\citation{scitt}
\citation{hjs}
\@writefile{toc}{\contentsline {subsection}{\numberline {7.2}Scalability Considerations}{10}{subsection.7.2}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {7.3}Adoption Path}{10}{subsection.7.3}\protected@file@percent }
\@writefile{toc}{\contentsline {subsection}{\numberline {7.4}Limitations of the Landscape Analysis}{10}{subsection.7.4}\protected@file@percent }
\@writefile{toc}{\contentsline {section}{\numberline {8}Related Work}{10}{section.8}\protected@file@percent }
\newlabel{sec:related}{{8}{10}{Related Work}{section.8}{}}
\citation{ect-draft}
\bibstyle{plain}
\bibdata{references}
\bibcite{daap-v2}{1}
\bibcite{verif-conv}{2}
\bibcite{agentic-jwt}{3}
\bibcite{stamp}{4}
\bibcite{scitt}{5}
\bibcite{rfc7515}{6}
\bibcite{rfc7519}{7}
\bibcite{w3c-prov}{8}
\@writefile{toc}{\contentsline {section}{\numberline {9}Conclusion and Future Work}{11}{section.9}\protected@file@percent }
\newlabel{sec:conclusion}{{9}{11}{Conclusion and Future Work}{section.9}{}}
\bibcite{actor-chain}{9}
\bibcite{trans-att}{10}
\bibcite{ect-draft}{11}
\bibcite{landscape-survey}{12}
\bibcite{txn-tokens}{13}
\bibcite{opentelemetry}{14}
\bibcite{spiffe}{15}
\bibcite{hjs}{16}
\bibcite{wimse-arch}{17}
\gdef \@abspage@last{12}

93
workspace/drafts/ect-landscape-paper/main.bbl Normal file
View File

@@ -0,0 +1,93 @@
\begin{thebibliography}{10}
\bibitem{daap-v2}
Jonathan Aylward.
\newblock {Distributed AI Accountability Protocol (DAAP) Version 2.0}.
\newblock Internet-Draft draft-aylward-daap-v2, 2026.
\bibitem{verif-conv}
Henk Birkholz.
\newblock {Verifiable Agent Conversation Records}.
\newblock Internet-Draft draft-birkholz-verifiable-agent-conversations, 2025.
\bibitem{agentic-jwt}
Anirudh Goswami.
\newblock {Secure Intent Protocol: JWT Compatible Agentic Identity and Workflow
Management}.
\newblock Internet-Draft draft-goswami-agentic-jwt, 2025.
\bibitem{stamp}
Bary Guy.
\newblock {Secure Task-bound Agent Message Proof (STAMP) Protocol}.
\newblock Internet-Draft draft-guy-bary-stamp-protocol, 2025.
\bibitem{scitt}
{IETF SCITT Working Group}.
\newblock {Supply Chain Integrity, Transparency, and Trust (SCITT)}.
\newblock Internet-Draft, 2024.
\bibitem{rfc7515}
M.~Jones, J.~Bradley, and N.~Sakimura.
\newblock {JSON Web Signature (JWS)}.
\newblock RFC 7515, 2015.
\bibitem{rfc7519}
M.~Jones, J.~Bradley, and N.~Sakimura.
\newblock {JSON Web Token (JWT)}.
\newblock RFC 7519, 2015.
\bibitem{w3c-prov}
Luc Moreau and Paolo Missier.
\newblock {PROV-DM: The PROV Data Model}.
\newblock W3C Recommendation, 2013.
\bibitem{actor-chain}
{MW et al.}
\newblock {Cryptographically Verifiable Actor Chain for OAuth 2.0 Token
Exchange}.
\newblock Internet-Draft draft-mw-spice-actor-chain, 2025.
\bibitem{trans-att}
{MW et al.}
\newblock {Transitive Attestation for Sovereign Workloads: A WIMSE Profile}.
\newblock Internet-Draft draft-mw-wimse-transitive-attestation, 2025.
\bibitem{ect-draft}
Christian Nennemann.
\newblock {Execution Context Tokens for Distributed Agentic Workflows}.
\newblock Internet-Draft draft-nennemann-wimse-ect-00, February 2026.
\bibitem{landscape-survey}
Christian Nennemann.
\newblock {The AI Agent Standardization Wave: A Quantitative Analysis of 260
IETF Internet-Drafts on Autonomous Agents and Artificial Intelligence}.
\newblock arXiv preprint, 2026.
\newblock Companion landscape survey paper.
\bibitem{txn-tokens}
{OAuth Working Group}.
\newblock {Transaction Tokens For Agents}.
\newblock Internet-Draft draft-oauth-transaction-tokens-for-agents, 2025.
\bibitem{opentelemetry}
{OpenTelemetry Project}.
\newblock {OpenTelemetry Specification}.
\newblock CNCF Project, 2024.
\bibitem{spiffe}
{SPIFFE Project}.
\newblock {SPIFFE: Secure Production Identity Framework for Everyone}.
\newblock CNCF Project, 2024.
\bibitem{hjs}
et~al. Wang.
\newblock {HJS: An Accountability Layer for AI Agents}.
\newblock Internet-Draft draft-wang-hjs-accountability, 2025.
\bibitem{wimse-arch}
{WIMSE Working Group}.
\newblock {Workload Identity in Multi System Environments (WIMSE)
Architecture}.
\newblock Internet-Draft, 2025.
\end{thebibliography}

46
workspace/drafts/ect-landscape-paper/main.blg Normal file
View File

@@ -0,0 +1,46 @@
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
You've used 17 entries,
2118 wiz_defined-function locations,
567 strings with 5907 characters,
and the built_in function-call counts, 3739 in all, are:
= -- 355
> -- 147
< -- 0
+ -- 61
- -- 44
* -- 128
:= -- 638
add.period$ -- 52
call.type$ -- 17
change.case$ -- 73
chr.to.int$ -- 0
cite$ -- 17
duplicate$ -- 119
empty$ -- 375
format.name$ -- 44
if$ -- 816
int.to.chr$ -- 0
int.to.str$ -- 17
missing$ -- 0
newline$ -- 89
num.names$ -- 34
pop$ -- 141
preamble$ -- 1
purify$ -- 56
quote$ -- 0
skip$ -- 118
stack$ -- 0
substring$ -- 85
swap$ -- 17
text.length$ -- 0
text.prefix$ -- 0
top$ -- 0
type$ -- 68
warning$ -- 0
while$ -- 34
width$ -- 19
write$ -- 174

996
workspace/drafts/ect-landscape-paper/main.log Normal file
View File

@@ -0,0 +1,996 @@
This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023) (preloaded format=pdflatex 2026.2.27) 28 FEB 2026 16:17
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/base/inputenc.sty
Package: inputenc 2021/02/14 v1.3d Input encoding file
\inpenc@prehook=\toks16
\inpenc@posthook=\toks17
)
(/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/lm/lmodern.sty
Package: lmodern 2015/05/01 v1.6.1 Latin Modern Fonts
LaTeX Font Info: Overwriting symbol font `operators' in version `normal'
(Font) OT1/cmr/m/n --> OT1/lmr/m/n on input line 22.
LaTeX Font Info: Overwriting symbol font `letters' in version `normal'
(Font) OML/cmm/m/it --> OML/lmm/m/it on input line 23.
LaTeX Font Info: Overwriting symbol font `symbols' in version `normal'
(Font) OMS/cmsy/m/n --> OMS/lmsy/m/n on input line 24.
LaTeX Font Info: Overwriting symbol font `largesymbols' in version `normal'
(Font) OMX/cmex/m/n --> OMX/lmex/m/n on input line 25.
LaTeX Font Info: Overwriting symbol font `operators' in version `bold'
(Font) OT1/cmr/bx/n --> OT1/lmr/bx/n on input line 26.
LaTeX Font Info: Overwriting symbol font `letters' in version `bold'
(Font) OML/cmm/b/it --> OML/lmm/b/it on input line 27.
LaTeX Font Info: Overwriting symbol font `symbols' in version `bold'
(Font) OMS/cmsy/b/n --> OMS/lmsy/b/n on input line 28.
LaTeX Font Info: Overwriting symbol font `largesymbols' in version `bold'
(Font) OMX/cmex/m/n --> OMX/lmex/m/n on input line 29.
LaTeX Font Info: Overwriting math alphabet `\mathbf' in version `normal'
(Font) OT1/cmr/bx/n --> OT1/lmr/bx/n on input line 31.
LaTeX Font Info: Overwriting math alphabet `\mathsf' in version `normal'
(Font) OT1/cmss/m/n --> OT1/lmss/m/n on input line 32.
LaTeX Font Info: Overwriting math alphabet `\mathit' in version `normal'
(Font) OT1/cmr/m/it --> OT1/lmr/m/it on input line 33.
LaTeX Font Info: Overwriting math alphabet `\mathtt' in version `normal'
(Font) OT1/cmtt/m/n --> OT1/lmtt/m/n on input line 34.
LaTeX Font Info: Overwriting math alphabet `\mathbf' in version `bold'
(Font) OT1/cmr/bx/n --> OT1/lmr/bx/n on input line 35.
LaTeX Font Info: Overwriting math alphabet `\mathsf' in version `bold'
(Font) OT1/cmss/bx/n --> OT1/lmss/bx/n on input line 36.
LaTeX Font Info: Overwriting math alphabet `\mathit' in version `bold'
(Font) OT1/cmr/bx/it --> OT1/lmr/bx/it on input line 37.
LaTeX Font Info: Overwriting math alphabet `\mathtt' in version `bold'
(Font) OT1/cmtt/m/n --> OT1/lmtt/m/n on input line 38.
)
(/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@=\toks18
)
(/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=\toks19
)
(/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=\dimen149
\Gin@req@width=\dimen150
)
(/usr/share/texlive/texmf-dist/tex/latex/booktabs/booktabs.sty
Package: booktabs 2020/01/12 v1.61803398 Publication quality tables
\heavyrulewidth=\dimen151
\lightrulewidth=\dimen152
\cmidrulewidth=\dimen153
\belowrulesep=\dimen154
\belowbottomsep=\dimen155
\aboverulesep=\dimen156
\abovetopsep=\dimen157
\cmidrulesep=\dimen158
\cmidrulekern=\dimen159
\defaultaddspace=\dimen160
\@cmidla=\count196
\@cmidlb=\count197
\@aboverulesep=\dimen161
\@belowrulesep=\dimen162
\@thisruleclass=\count198
\@lastruleclass=\count199
\@thisrulewidth=\dimen163
)
(/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=\count266
)
\@linkdim=\dimen164
\Hy@linkcounter=\count267
\Hy@pagecounter=\count268
(/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=\count269
(/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=\count270
(/usr/share/texlive/texmf-dist/tex/latex/url/url.sty
\Urlmuskip=\muskip16
Package: url 2013/09/16 ver 3.4 Verb mode for urls, etc.
)
LaTeX Info: Redefining \url on input line 4763.
\XeTeXLinkMargin=\dimen165
(/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=\count271
\Field@Width=\dimen166
\Fld@charsize=\dimen167
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=\count272
\c@Item=\count273
\c@Hfootnote=\count274
)
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=\count275
\c@bookmark@seq@number=\count276
(/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=\skip50
)
(/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/amsmath/amsmath.sty
Package: amsmath 2022/04/08 v2.17n AMS math features
\@mathmargin=\skip51
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@=\dimen168
))
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsbsy.sty
Package: amsbsy 1999/11/29 v1.2d Bold Symbols
\pmbraise@=\dimen169
)
(/usr/share/texlive/texmf-dist/tex/latex/amsmath/amsopn.sty
Package: amsopn 2022/04/08 v2.04 operator names
)
\inf@bad=\count277
LaTeX Info: Redefining \frac on input line 234.
\uproot@=\count278
\leftroot@=\count279
LaTeX Info: Redefining \overline on input line 399.
LaTeX Info: Redefining \colon on input line 410.
\classnum@=\count280
\DOTSCASE@=\count281
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=\dimen170
LaTeX Font Info: Redeclaring font encoding OML on input line 743.
LaTeX Font Info: Redeclaring font encoding OMS on input line 744.
\macc@depth=\count282
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=\count283
\dotsspace@=\muskip17
\c@parentequation=\count284
\dspbrk@lvl=\count285
\tag@help=\toks21
\row@=\count286
\column@=\count287
\maxfields@=\count288
\andhelp@=\toks22
\eqnshift@=\dimen171
\alignsep@=\dimen172
\tagshift@=\dimen173
\tagwidth@=\dimen174
\totwidth@=\dimen175
\lineht@=\dimen176
\@envbody=\toks23
\multlinegap=\skip52
\multlinetaggap=\skip53
\mathdisplay@stack=\toks24
LaTeX Info: Redefining \[ on input line 2953.
LaTeX Info: Redefining \] on input line 2954.
)
(/usr/share/texlive/texmf-dist/tex/latex/float/float.sty
Package: float 2001/11/08 v1.3d Float enhancements (AL)
\c@float@type=\count289
\float@exts=\toks25
\float@box=\box53
\@float@everytoks=\toks26
\@floatcapt=\box54
)
(/usr/share/texlive/texmf-dist/tex/latex/caption/caption.sty
Package: caption 2023/03/12 v3.6j Customizing captions (AR)
(/usr/share/texlive/texmf-dist/tex/latex/caption/caption3.sty
Package: caption3 2023/03/12 v2.4 caption3 kernel (AR)
\caption@tempdima=\dimen177
\captionmargin=\dimen178
\caption@leftmargin=\dimen179
\caption@rightmargin=\dimen180
\caption@width=\dimen181
\caption@indent=\dimen182
\caption@parindent=\dimen183
\caption@hangindent=\dimen184
Package caption Info: Standard document class detected.
)
\c@caption@flags=\count290
\c@continuedfloat=\count291
Package caption Info: float package is loaded.
Package caption Info: hyperref package is loaded.
)
(/usr/share/texlive/texmf-dist/tex/latex/caption/subcaption.sty
Package: subcaption 2023/02/19 v1.6 Sub-captions (AR)
Package caption Info: New subtype `subfigure' on input line 239.
\c@subfigure=\count292
Package caption Info: New subtype `subtable' on input line 239.
\c@subtable=\count293
)
(/usr/share/texlive/texmf-dist/tex/latex/tools/tabularx.sty
Package: tabularx 2020/01/15 v2.11c `tabularx' package (DPC)
(/usr/share/texlive/texmf-dist/tex/latex/tools/array.sty
Package: array 2022/09/04 v2.5g Tabular extension package (FMi)
\col@sep=\dimen185
\ar@mcellbox=\box55
\extrarowheight=\dimen186
\NC@list=\toks27
\extratabsurround=\skip54
\backup@length=\skip55
\ar@cellbox=\box56
)
\TX@col@width=\dimen187
\TX@old@table=\dimen188
\TX@old@col=\dimen189
\TX@target=\dimen190
\TX@delta=\dimen191
\TX@cols=\count294
\TX@ftn=\toks28
)
(/usr/share/texlive/texmf-dist/tex/latex/enumitem/enumitem.sty
Package: enumitem 2019/06/20 v3.9 Customized lists
\labelindent=\skip56
\enit@outerparindent=\dimen192
\enit@toks=\toks29
\enit@inbox=\box57
\enit@count@id=\count295
\enitdp@description=\count296
)
(/usr/share/texlive/texmf-dist/tex/latex/psnfss/pifont.sty
Package: pifont 2020/03/25 PSNFSS-v9.3 Pi font support (SPQR)
LaTeX Font Info: Trying to load font information for U+pzd on input line 63.
(/usr/share/texlive/texmf-dist/tex/latex/psnfss/upzd.fd
File: upzd.fd 2001/06/04 font definitions for U/pzd.
)
LaTeX Font Info: Trying to load font information for U+psy on input line 64.
(/usr/share/texlive/texmf-dist/tex/latex/psnfss/upsy.fd
File: upsy.fd 2001/06/04 font definitions for U/psy.
))
(/usr/share/texlive/texmf-dist/tex/latex/listings/listings.sty
\lst@mode=\count297
\lst@gtempboxa=\box58
\lst@token=\toks30
\lst@length=\count298
\lst@currlwidth=\dimen193
\lst@column=\count299
\lst@pos=\count300
\lst@lostspace=\dimen194
\lst@width=\dimen195
\lst@newlines=\count301
\lst@lineno=\count302
\lst@maxwidth=\dimen196
(/usr/share/texlive/texmf-dist/tex/latex/listings/lstmisc.sty
File: lstmisc.sty 2023/02/27 1.9 (Carsten Heinz)
\c@lstnumber=\count303
\lst@skipnumbers=\count304
\lst@framebox=\box59
)
(/usr/share/texlive/texmf-dist/tex/latex/listings/listings.cfg
File: listings.cfg 2023/02/27 1.9 listings configuration
))
Package: listings 2023/02/27 1.9 (Carsten Heinz)
(/usr/share/texlive/texmf-dist/tex/latex/pgf/frontendlayer/tikz.sty
(/usr/share/texlive/texmf-dist/tex/latex/pgf/basiclayer/pgf.sty
(/usr/share/texlive/texmf-dist/tex/latex/pgf/utilities/pgfrcs.sty
(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfutil-common.tex
\pgfutil@everybye=\toks31
\pgfutil@tempdima=\dimen197
\pgfutil@tempdimb=\dimen198
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfutil-latex.def
\pgfutil@abb=\box60
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfrcs.code.tex
(/usr/share/texlive/texmf-dist/tex/generic/pgf/pgf.revision.tex)
Package: pgfrcs 2023-01-15 v3.1.10 (3.1.10)
))
Package: pgf 2023-01-15 v3.1.10 (3.1.10)
(/usr/share/texlive/texmf-dist/tex/latex/pgf/basiclayer/pgfcore.sty
(/usr/share/texlive/texmf-dist/tex/latex/pgf/systemlayer/pgfsys.sty
(/usr/share/texlive/texmf-dist/tex/generic/pgf/systemlayer/pgfsys.code.tex
Package: pgfsys 2023-01-15 v3.1.10 (3.1.10)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfkeys.code.tex
\pgfkeys@pathtoks=\toks32
\pgfkeys@temptoks=\toks33
(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfkeyslibraryfiltered
.code.tex
\pgfkeys@tmptoks=\toks34
))
\pgf@x=\dimen199
\pgf@y=\dimen256
\pgf@xa=\dimen257
\pgf@ya=\dimen258
\pgf@xb=\dimen259
\pgf@yb=\dimen260
\pgf@xc=\dimen261
\pgf@yc=\dimen262
\pgf@xd=\dimen263
\pgf@yd=\dimen264
\w@pgf@writea=\write3
\r@pgf@reada=\read2
\c@pgf@counta=\count305
\c@pgf@countb=\count306
\c@pgf@countc=\count307
\c@pgf@countd=\count308
\t@pgf@toka=\toks35
\t@pgf@tokb=\toks36
\t@pgf@tokc=\toks37
\pgf@sys@id@count=\count309
(/usr/share/texlive/texmf-dist/tex/generic/pgf/systemlayer/pgf.cfg
File: pgf.cfg 2023-01-15 v3.1.10 (3.1.10)
)
Driver file for pgf: pgfsys-pdftex.def
(/usr/share/texlive/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-pdftex.def
File: pgfsys-pdftex.def 2023-01-15 v3.1.10 (3.1.10)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/systemlayer/pgfsys-common-pdf.de
f
File: pgfsys-common-pdf.def 2023-01-15 v3.1.10 (3.1.10)
)))
(/usr/share/texlive/texmf-dist/tex/generic/pgf/systemlayer/pgfsyssoftpath.code.
tex
File: pgfsyssoftpath.code.tex 2023-01-15 v3.1.10 (3.1.10)
\pgfsyssoftpath@smallbuffer@items=\count310
\pgfsyssoftpath@bigbuffer@items=\count311
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/systemlayer/pgfsysprotocol.code.
tex
File: pgfsysprotocol.code.tex 2023-01-15 v3.1.10 (3.1.10)
))
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcore.code.tex
Package: pgfcore 2023-01-15 v3.1.10 (3.1.10)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmath.code.tex
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathutil.code.tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathparser.code.tex
\pgfmath@dimen=\dimen265
\pgfmath@count=\count312
\pgfmath@box=\box61
\pgfmath@toks=\toks38
\pgfmath@stack@operand=\toks39
\pgfmath@stack@operation=\toks40
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.code.tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.basic.code
.tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.trigonomet
ric.code.tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.random.cod
e.tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.comparison
.code.tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.base.code.
tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.round.code
.tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.misc.code.
tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.integerari
thmetics.code.tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathcalc.code.tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfloat.code.tex
\c@pgfmathroundto@lastzeros=\count313
))
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfint.code.tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorepoints.code.te
x
File: pgfcorepoints.code.tex 2023-01-15 v3.1.10 (3.1.10)
\pgf@picminx=\dimen266
\pgf@picmaxx=\dimen267
\pgf@picminy=\dimen268
\pgf@picmaxy=\dimen269
\pgf@pathminx=\dimen270
\pgf@pathmaxx=\dimen271
\pgf@pathminy=\dimen272
\pgf@pathmaxy=\dimen273
\pgf@xx=\dimen274
\pgf@xy=\dimen275
\pgf@yx=\dimen276
\pgf@yy=\dimen277
\pgf@zx=\dimen278
\pgf@zy=\dimen279
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorepathconstruct.
code.tex
File: pgfcorepathconstruct.code.tex 2023-01-15 v3.1.10 (3.1.10)
\pgf@path@lastx=\dimen280
\pgf@path@lasty=\dimen281
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorepathusage.code
.tex
File: pgfcorepathusage.code.tex 2023-01-15 v3.1.10 (3.1.10)
\pgf@shorten@end@additional=\dimen282
\pgf@shorten@start@additional=\dimen283
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorescopes.code.te
x
File: pgfcorescopes.code.tex 2023-01-15 v3.1.10 (3.1.10)
\pgfpic=\box62
\pgf@hbox=\box63
\pgf@layerbox@main=\box64
\pgf@picture@serial@count=\count314
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcoregraphicstate.c
ode.tex
File: pgfcoregraphicstate.code.tex 2023-01-15 v3.1.10 (3.1.10)
\pgflinewidth=\dimen284
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcoretransformation
s.code.tex
File: pgfcoretransformations.code.tex 2023-01-15 v3.1.10 (3.1.10)
\pgf@pt@x=\dimen285
\pgf@pt@y=\dimen286
\pgf@pt@temp=\dimen287
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorequick.code.tex
File: pgfcorequick.code.tex 2023-01-15 v3.1.10 (3.1.10)
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcoreobjects.code.t
ex
File: pgfcoreobjects.code.tex 2023-01-15 v3.1.10 (3.1.10)
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorepathprocessing
.code.tex
File: pgfcorepathprocessing.code.tex 2023-01-15 v3.1.10 (3.1.10)
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorearrows.code.te
x
File: pgfcorearrows.code.tex 2023-01-15 v3.1.10 (3.1.10)
\pgfarrowsep=\dimen288
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcoreshade.code.tex
File: pgfcoreshade.code.tex 2023-01-15 v3.1.10 (3.1.10)
\pgf@max=\dimen289
\pgf@sys@shading@range@num=\count315
\pgf@shadingcount=\count316
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcoreimage.code.tex
File: pgfcoreimage.code.tex 2023-01-15 v3.1.10 (3.1.10)
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcoreexternal.code.
tex
File: pgfcoreexternal.code.tex 2023-01-15 v3.1.10 (3.1.10)
\pgfexternal@startupbox=\box65
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorelayers.code.te
x
File: pgfcorelayers.code.tex 2023-01-15 v3.1.10 (3.1.10)
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcoretransparency.c
ode.tex
File: pgfcoretransparency.code.tex 2023-01-15 v3.1.10 (3.1.10)
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorepatterns.code.
tex
File: pgfcorepatterns.code.tex 2023-01-15 v3.1.10 (3.1.10)
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/basiclayer/pgfcorerdf.code.tex
File: pgfcorerdf.code.tex 2023-01-15 v3.1.10 (3.1.10)
)))
(/usr/share/texlive/texmf-dist/tex/generic/pgf/modules/pgfmoduleshapes.code.tex
File: pgfmoduleshapes.code.tex 2023-01-15 v3.1.10 (3.1.10)
\pgfnodeparttextbox=\box66
) (/usr/share/texlive/texmf-dist/tex/generic/pgf/modules/pgfmoduleplot.code.tex
File: pgfmoduleplot.code.tex 2023-01-15 v3.1.10 (3.1.10)
)
(/usr/share/texlive/texmf-dist/tex/latex/pgf/compatibility/pgfcomp-version-0-65
.sty
Package: pgfcomp-version-0-65 2023-01-15 v3.1.10 (3.1.10)
\pgf@nodesepstart=\dimen290
\pgf@nodesepend=\dimen291
)
(/usr/share/texlive/texmf-dist/tex/latex/pgf/compatibility/pgfcomp-version-1-18
.sty
Package: pgfcomp-version-1-18 2023-01-15 v3.1.10 (3.1.10)
)) (/usr/share/texlive/texmf-dist/tex/latex/pgf/utilities/pgffor.sty
(/usr/share/texlive/texmf-dist/tex/latex/pgf/utilities/pgfkeys.sty
(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfkeys.code.tex))
(/usr/share/texlive/texmf-dist/tex/latex/pgf/math/pgfmath.sty
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmath.code.tex))
(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgffor.code.tex
Package: pgffor 2023-01-15 v3.1.10 (3.1.10)
\pgffor@iter=\dimen292
\pgffor@skip=\dimen293
\pgffor@stack=\toks41
\pgffor@toks=\toks42
))
(/usr/share/texlive/texmf-dist/tex/generic/pgf/frontendlayer/tikz/tikz.code.tex
Package: tikz 2023-01-15 v3.1.10 (3.1.10)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/libraries/pgflibraryplothandlers
.code.tex
File: pgflibraryplothandlers.code.tex 2023-01-15 v3.1.10 (3.1.10)
\pgf@plot@mark@count=\count317
\pgfplotmarksize=\dimen294
)
\tikz@lastx=\dimen295
\tikz@lasty=\dimen296
\tikz@lastxsaved=\dimen297
\tikz@lastysaved=\dimen298
\tikz@lastmovetox=\dimen299
\tikz@lastmovetoy=\dimen300
\tikzleveldistance=\dimen301
\tikzsiblingdistance=\dimen302
\tikz@figbox=\box67
\tikz@figbox@bg=\box68
\tikz@tempbox=\box69
\tikz@tempbox@bg=\box70
\tikztreelevel=\count318
\tikznumberofchildren=\count319
\tikznumberofcurrentchild=\count320
\tikz@fig@count=\count321
(/usr/share/texlive/texmf-dist/tex/generic/pgf/modules/pgfmodulematrix.code.tex
File: pgfmodulematrix.code.tex 2023-01-15 v3.1.10 (3.1.10)
\pgfmatrixcurrentrow=\count322
\pgfmatrixcurrentcolumn=\count323
\pgf@matrix@numberofcolumns=\count324
)
\tikz@expandcount=\count325
(/usr/share/texlive/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tik
zlibrarytopaths.code.tex
File: tikzlibrarytopaths.code.tex 2023-01-15 v3.1.10 (3.1.10)
)))
(/usr/share/texlive/texmf-dist/tex/generic/pgf/libraries/pgflibraryarrows.meta.
code.tex
File: pgflibraryarrows.meta.code.tex 2023-01-15 v3.1.10 (3.1.10)
\pgfarrowinset=\dimen303
\pgfarrowlength=\dimen304
\pgfarrowwidth=\dimen305
\pgfarrowlinewidth=\dimen306
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tik
zlibrarypositioning.code.tex
File: tikzlibrarypositioning.code.tex 2023-01-15 v3.1.10 (3.1.10)
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/frontendlayer/tikz/libraries/tik
zlibraryshapes.geometric.code.tex
File: tikzlibraryshapes.geometric.code.tex 2023-01-15 v3.1.10 (3.1.10)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/libraries/shapes/pgflibraryshape
s.geometric.code.tex
File: pgflibraryshapes.geometric.code.tex 2023-01-15 v3.1.10 (3.1.10)
))
Package hyperref Info: Option `colorlinks' set `true' on input line 28.
LaTeX Font Info: Trying to load font information for T1+lmr on input line 53
.
(/usr/share/texlive/texmf-dist/tex/latex/lm/t1lmr.fd
File: t1lmr.fd 2015/05/01 v1.6.1 Font defs for Latin Modern
)
(/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=\count326
\l__pdf_internal_box=\box71
)
(./main.aux)
\openout1 = `main.aux'.
LaTeX Font Info: Checking defaults for OML/cmm/m/it on input line 53.
LaTeX Font Info: ... okay on input line 53.
LaTeX Font Info: Checking defaults for OMS/cmsy/m/n on input line 53.
LaTeX Font Info: ... okay on input line 53.
LaTeX Font Info: Checking defaults for OT1/cmr/m/n on input line 53.
LaTeX Font Info: ... okay on input line 53.
LaTeX Font Info: Checking defaults for T1/cmr/m/n on input line 53.
LaTeX Font Info: ... okay on input line 53.
LaTeX Font Info: Checking defaults for TS1/cmr/m/n on input line 53.
LaTeX Font Info: ... okay on input line 53.
LaTeX Font Info: Checking defaults for OMX/cmex/m/n on input line 53.
LaTeX Font Info: ... okay on input line 53.
LaTeX Font Info: Checking defaults for U/cmr/m/n on input line 53.
LaTeX Font Info: ... okay on input line 53.
LaTeX Font Info: Checking defaults for PD1/pdf/m/n on input line 53.
LaTeX Font Info: ... okay on input line 53.
LaTeX Font Info: Checking defaults for PU/pdf/m/n on input line 53.
LaTeX Font Info: ... okay on input line 53.
*geometry* driver: auto-detecting
*geometry* detected driver: pdftex
*geometry* verbose mode - [ preamble ] result:
* driver: pdftex
* paper: a4paper
* layout: <same size as paper>
* layoutoffset:(h,v)=(0.0pt,0.0pt)
* modes:
* h-part:(L,W,R)=(72.26999pt, 452.9679pt, 72.26999pt)
* v-part:(T,H,B)=(72.26999pt, 700.50687pt, 72.26999pt)
* \paperwidth=597.50787pt
* \paperheight=845.04684pt
* \textwidth=452.9679pt
* \textheight=700.50687pt
* \oddsidemargin=0.0pt
* \evensidemargin=0.0pt
* \topmargin=-37.0pt
* \headheight=12.0pt
* \headsep=25.0pt
* \topskip=11.0pt
* \footskip=30.0pt
* \marginparwidth=50.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
* \@twocolumnfalse
* \@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=\count327
\scratchdimen=\dimen307
\scratchbox=\box72
\nofMPsegments=\count328
\nofMParguments=\count329
\everyMPshowfont=\toks43
\MPscratchCnt=\count330
\MPscratchDim=\dimen308
\MPnumerator=\count331
\makeMPintoPDFobject=\count332
\everyMPtoPDFconversion=\toks44
) (/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 53.
(./main.out) (./main.out)
\@outlinefile=\write4
\openout4 = `main.out'.
Package caption Info: Begin \AtBeginDocument code.
Package caption Info: listings package is loaded.
Package caption Info: End \AtBeginDocument code.
\c@lstlisting=\count333
LaTeX Font Info: Trying to load font information for OT1+lmr on input line 5
5.
(/usr/share/texlive/texmf-dist/tex/latex/lm/ot1lmr.fd
File: ot1lmr.fd 2015/05/01 v1.6.1 Font defs for Latin Modern
)
LaTeX Font Info: Trying to load font information for OML+lmm on input line 5
5.
(/usr/share/texlive/texmf-dist/tex/latex/lm/omllmm.fd
File: omllmm.fd 2015/05/01 v1.6.1 Font defs for Latin Modern
)
LaTeX Font Info: Trying to load font information for OMS+lmsy on input line
55.
(/usr/share/texlive/texmf-dist/tex/latex/lm/omslmsy.fd
File: omslmsy.fd 2015/05/01 v1.6.1 Font defs for Latin Modern
)
LaTeX Font Info: Trying to load font information for OMX+lmex on input line
55.
(/usr/share/texlive/texmf-dist/tex/latex/lm/omxlmex.fd
File: omxlmex.fd 2015/05/01 v1.6.1 Font defs for Latin Modern
)
LaTeX Font Info: External font `lmex10' loaded for size
(Font) <12> on input line 55.
LaTeX Font Info: External font `lmex10' loaded for size
(Font) <8> on input line 55.
LaTeX Font Info: External font `lmex10' loaded for size
(Font) <6> on input line 55.
LaTeX Font Info: Trying to load font information for T1+lmtt on input line 5
5.
(/usr/share/texlive/texmf-dist/tex/latex/lm/t1lmtt.fd
File: t1lmtt.fd 2015/05/01 v1.6.1 Font defs for Latin Modern
)
LaTeX Font Info: External font `lmex10' loaded for size
(Font) <10> on input line 59.
LaTeX Font Info: External font `lmex10' loaded for size
(Font) <7> on input line 59.
LaTeX Font Info: External font `lmex10' loaded for size
(Font) <5> on input line 59.
LaTeX Font Info: External font `lmex10' loaded for size
(Font) <10.95> on input line 70.
[1
{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}{/usr/share/texlive/texmf-di
st/fonts/enc/dvips/lm/lm-ec.enc}{/usr/share/texlive/texmf-dist/fonts/enc/dvips/
lm/lm-mathsy.enc}]
LaTeX Font Info: Trying to load font information for TS1+lmr on input line 8
9.
(/usr/share/texlive/texmf-dist/tex/latex/lm/ts1lmr.fd
File: ts1lmr.fd 2015/05/01 v1.6.1 Font defs for Latin Modern
) [2{/usr/share/texlive/texmf-dist/fonts/enc/dvips/lm/lm-ts1.enc}] [3] [4]
Package hyperref Info: bookmark level for unknown lstlisting defaults to 0 on i
nput line 255.
LaTeX Font Info: Font shape `T1/lmtt/bx/n' in size <10.95> not available
(Font) Font shape `T1/lmtt/b/n' tried instead on input line 289.
[5]
LaTeX Warning: `h' float specifier changed to `ht'.
[6{/usr/share/texlive/texmf-dist/fonts/enc/dvips/lm/lm-mathit.enc}{/usr/share/t
exlive/texmf-dist/fonts/enc/dvips/lm/lm-rm.enc}]
Underfull \hbox (badness 10000) in alignment at lines 442--442
[][][][][][][][][][][]
[]
LaTeX Warning: `h' float specifier changed to `ht'.
[7]
Underfull \hbox (badness 10000) in paragraph at lines 502--502
[]|\T1/lmr/m/n/10 Signed \T1/lmtt/m/n/10 exec_act \T1/lmr/m/n/10 records what a
gent
[]
Underfull \hbox (badness 10000) in paragraph at lines 502--502
[]|\T1/lmr/m/n/10 DAG en-ables post-mortem trac-ing;
[]
Underfull \hbox (badness 10000) in paragraph at lines 502--502
\T1/lmtt/m/n/10 inp_hash\T1/lmr/m/n/10 /\T1/lmtt/m/n/10 out_hash \T1/lmr/m/n/10
lo-cate data cor-
[]
Underfull \hbox (badness 2326) in paragraph at lines 502--502
[]|\T1/lmr/m/n/10 Timestamp-based ex-e-cu-tion tim-ing from
[]
LaTeX Warning: `h' float specifier changed to `ht'.
[8] [9]
Overfull \hbox (1.95187pt too wide) in paragraph at lines 572--573
[]\T1/lmr/bx/n/10.95 Supply chain trans-parency. \T1/lmr/m/n/10.95 SCITT (Sup-p
ly Chain In-tegrity, Trans-parency, and Trust) [[]]
[]
[10]
Overfull \hbox (2.66985pt too wide) in paragraph at lines 593--594
[]\T1/lmr/bx/n/10.95 Privacy-preserving ECTs\T1/lmr/m/n/10.95 : Se-lec-tive dis
-clo-sure of ex-e-cu-tion de-tails us-ing zero-knowledge
[]
Overfull \hbox (3.58261pt too wide) in paragraph at lines 597--598
\T1/lmr/m/n/10.95 The ECT spec-i-fi-ca-tion is avail-able as IETF Internet-Draf
t \T1/lmtt/m/n/10.95 draft-nennemann-wimse-ect-00 \T1/lmr/m/n/10.95 [[]].
[]
(./main.bbl [11]) [12] (./main.aux)
Package rerunfilecheck Info: File `main.out' has not changed.
(rerunfilecheck) Checksum: AF2FEAF11DA883504BCE89CC47A5CD09;5550.
)
Here is how much of TeX's memory you used:
25121 strings out of 477985
466749 string characters out of 5839380
2001388 words of memory out of 6000000
44749 multiletter control sequences out of 15000+600000
602532 words of font info for 88 fonts, out of 8000000 for 9000
14 hyphenation exceptions out of 8191
84i,12n,80p,1462b,1097s stack positions out of 10000i,1000n,20000p,200000b,200000s
</usr/share/texlive/texmf-dist/fonts/type1/public/lm/lmbx10.pfb></usr/share/t
exlive/texmf-dist/fonts/type1/public/lm/lmbx12.pfb></usr/share/texlive/texmf-di
st/fonts/type1/public/lm/lmbx7.pfb></usr/share/texlive/texmf-dist/fonts/type1/p
ublic/lm/lmbx8.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/lm/lmbx9.p
fb></usr/share/texlive/texmf-dist/fonts/type1/public/lm/lmmi10.pfb></usr/share/
texlive/texmf-dist/fonts/type1/public/lm/lmr10.pfb></usr/share/texlive/texmf-di
st/fonts/type1/public/lm/lmr12.pfb></usr/share/texlive/texmf-dist/fonts/type1/p
ublic/lm/lmr6.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/lm/lmr8.pfb
></usr/share/texlive/texmf-dist/fonts/type1/public/lm/lmr9.pfb></usr/share/texl
ive/texmf-dist/fonts/type1/public/lm/lmri10.pfb></usr/share/texlive/texmf-dist/
fonts/type1/public/lm/lmsy10.pfb></usr/share/texlive/texmf-dist/fonts/type1/pub
lic/lm/lmsy9.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/lm/lmtk10.pf
b></usr/share/texlive/texmf-dist/fonts/type1/public/lm/lmtt10.pfb></usr/share/t
exlive/texmf-dist/fonts/type1/public/lm/lmtt12.pfb></usr/share/texlive/texmf-di
st/fonts/type1/public/lm/lmtt8.pfb></usr/share/texlive/texmf-dist/fonts/type1/p
ublic/lm/lmtt9.pfb></usr/share/texlive/texmf-dist/fonts/type1/urw/zapfding/uzdr
.pfb>
Output written on main.pdf (12 pages, 464732 bytes).
PDF statistics:
468 PDF objects out of 1000 (max. 8388607)
400 compressed objects within 4 object streams
135 named destinations out of 1000 (max. 500000)
261 words of extra memory for PDF output out of 10000 (max. 10000000)

31
workspace/drafts/ect-landscape-paper/main.out Normal file
View File

@@ -0,0 +1,31 @@
\BOOKMARK [1][-]{section.1}{\376\377\000I\000n\000t\000r\000o\000d\000u\000c\000t\000i\000o\000n}{}% 1
\BOOKMARK [1][-]{section.2}{\376\377\000B\000a\000c\000k\000g\000r\000o\000u\000n\000d}{}% 2
\BOOKMARK [2][-]{subsection.2.1}{\376\377\000I\000E\000T\000F\000\040\000A\000I\000\040\000A\000g\000e\000n\000t\000\040\000S\000t\000a\000n\000d\000a\000r\000d\000i\000z\000a\000t\000i\000o\000n}{section.2}% 3
\BOOKMARK [2][-]{subsection.2.2}{\376\377\000W\000I\000M\000S\000E\000\040\000A\000r\000c\000h\000i\000t\000e\000c\000t\000u\000r\000e}{section.2}% 4
\BOOKMARK [2][-]{subsection.2.3}{\376\377\000T\000h\000e\000\040\000I\000d\000e\000n\000t\000i\000t\000y\040\023\000A\000u\000t\000h\000o\000r\000i\000z\000a\000t\000i\000o\000n\040\023\000E\000x\000e\000c\000u\000t\000i\000o\000n\000\040\000S\000t\000a\000c\000k}{section.2}% 5
\BOOKMARK [1][-]{section.3}{\376\377\000L\000a\000n\000d\000s\000c\000a\000p\000e\000\040\000A\000n\000a\000l\000y\000s\000i\000s\000:\000\040\000M\000o\000t\000i\000v\000a\000t\000i\000n\000g\000\040\000E\000v\000i\000d\000e\000n\000c\000e}{}% 6
\BOOKMARK [2][-]{subsection.3.1}{\376\377\000C\000o\000r\000p\000u\000s\000\040\000O\000v\000e\000r\000v\000i\000e\000w}{section.3}% 7
\BOOKMARK [2][-]{subsection.3.2}{\376\377\000C\000a\000t\000e\000g\000o\000r\000y\000\040\000D\000i\000s\000t\000r\000i\000b\000u\000t\000i\000o\000n\000\040\000a\000n\000d\000\040\000t\000h\000e\000\040\000S\000a\000f\000e\000t\000y\000\040\000D\000e\000f\000i\000c\000i\000t}{section.3}% 8
\BOOKMARK [2][-]{subsection.3.3}{\376\377\000T\000h\000e\000\040\000O\000v\000e\000r\000l\000a\000p\000\040\000P\000r\000o\000b\000l\000e\000m}{section.3}% 9
\BOOKMARK [2][-]{subsection.3.4}{\376\377\000G\000a\000p\000s\000\040\000R\000e\000l\000e\000v\000a\000n\000t\000\040\000t\000o\000\040\000E\000x\000e\000c\000u\000t\000i\000o\000n\000\040\000T\000r\000a\000c\000k\000i\000n\000g}{section.3}% 10
\BOOKMARK [1][-]{section.4}{\376\377\000E\000x\000e\000c\000u\000t\000i\000o\000n\000\040\000C\000o\000n\000t\000e\000x\000t\000\040\000T\000o\000k\000e\000n\000\040\000S\000p\000e\000c\000i\000f\000i\000c\000a\000t\000i\000o\000n}{}% 11
\BOOKMARK [2][-]{subsection.4.1}{\376\377\000D\000e\000s\000i\000g\000n\000\040\000P\000r\000i\000n\000c\000i\000p\000l\000e\000s}{section.4}% 12
\BOOKMARK [2][-]{subsection.4.2}{\376\377\000T\000o\000k\000e\000n\000\040\000S\000t\000r\000u\000c\000t\000u\000r\000e}{section.4}% 13
\BOOKMARK [3][-]{subsubsection.4.2.1}{\376\377\000J\000O\000S\000E\000\040\000H\000e\000a\000d\000e\000r}{subsection.4.2}% 14
\BOOKMARK [3][-]{subsubsection.4.2.2}{\376\377\000C\000l\000a\000i\000m\000s}{subsection.4.2}% 15
\BOOKMARK [2][-]{subsection.4.3}{\376\377\000D\000A\000G\000\040\000C\000o\000n\000s\000t\000r\000u\000c\000t\000i\000o\000n\000\040\000a\000n\000d\000\040\000V\000a\000l\000i\000d\000a\000t\000i\000o\000n}{section.4}% 16
\BOOKMARK [2][-]{subsection.4.4}{\376\377\000V\000e\000r\000i\000f\000i\000c\000a\000t\000i\000o\000n\000\040\000P\000r\000o\000c\000e\000d\000u\000r\000e}{section.4}% 17
\BOOKMARK [2][-]{subsection.4.5}{\376\377\000H\000T\000T\000P\000\040\000T\000r\000a\000n\000s\000p\000o\000r\000t}{section.4}% 18
\BOOKMARK [2][-]{subsection.4.6}{\376\377\000A\000u\000d\000i\000t\000\040\000L\000e\000d\000g\000e\000r\000\040\000I\000n\000t\000e\000r\000f\000a\000c\000e}{section.4}% 19
\BOOKMARK [1][-]{section.5}{\376\377\000C\000o\000m\000p\000a\000r\000a\000t\000i\000v\000e\000\040\000A\000n\000a\000l\000y\000s\000i\000s\000\040\000A\000g\000a\000i\000n\000s\000t\000\040\000t\000h\000e\000\040\000L\000a\000n\000d\000s\000c\000a\000p\000e}{}% 20
\BOOKMARK [2][-]{subsection.5.1}{\376\377\000C\000o\000m\000p\000a\000r\000i\000s\000o\000n\000\040\000F\000r\000a\000m\000e\000w\000o\000r\000k}{section.5}% 21
\BOOKMARK [2][-]{subsection.5.2}{\376\377\000H\000e\000a\000d\000-\000t\000o\000-\000H\000e\000a\000d\000\040\000C\000o\000m\000p\000a\000r\000i\000s\000o\000n}{section.5}% 22
\BOOKMARK [2][-]{subsection.5.3}{\376\377\000U\000n\000i\000q\000u\000e\000n\000e\000s\000s\000\040\000Q\000u\000a\000n\000t\000i\000f\000i\000c\000a\000t\000i\000o\000n}{section.5}% 23
\BOOKMARK [1][-]{section.6}{\376\377\000G\000a\000p\000\040\000C\000o\000v\000e\000r\000a\000g\000e\000\040\000A\000n\000a\000l\000y\000s\000i\000s}{}% 24
\BOOKMARK [1][-]{section.7}{\376\377\000D\000i\000s\000c\000u\000s\000s\000i\000o\000n\000\040\000a\000n\000d\000\040\000L\000i\000m\000i\000t\000a\000t\000i\000o\000n\000s}{}% 25
\BOOKMARK [2][-]{subsection.7.1}{\376\377\000T\000h\000e\000\040\000S\000e\000l\000f\000-\000A\000s\000s\000e\000r\000t\000i\000o\000n\000\040\000L\000i\000m\000i\000t\000a\000t\000i\000o\000n}{section.7}% 26
\BOOKMARK [2][-]{subsection.7.2}{\376\377\000S\000c\000a\000l\000a\000b\000i\000l\000i\000t\000y\000\040\000C\000o\000n\000s\000i\000d\000e\000r\000a\000t\000i\000o\000n\000s}{section.7}% 27
\BOOKMARK [2][-]{subsection.7.3}{\376\377\000A\000d\000o\000p\000t\000i\000o\000n\000\040\000P\000a\000t\000h}{section.7}% 28
\BOOKMARK [2][-]{subsection.7.4}{\376\377\000L\000i\000m\000i\000t\000a\000t\000i\000o\000n\000s\000\040\000o\000f\000\040\000t\000h\000e\000\040\000L\000a\000n\000d\000s\000c\000a\000p\000e\000\040\000A\000n\000a\000l\000y\000s\000i\000s}{section.7}% 29
\BOOKMARK [1][-]{section.8}{\376\377\000R\000e\000l\000a\000t\000e\000d\000\040\000W\000o\000r\000k}{}% 30
\BOOKMARK [1][-]{section.9}{\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}{}% 31

BIN
workspace/drafts/ect-landscape-paper/main.pdf Normal file
View File

Binary file not shown.

610
workspace/drafts/ect-landscape-paper/main.tex Normal file
View File

@@ -0,0 +1,610 @@
\documentclass[11pt,a4paper]{article}
% ── Packages ──────────────────────────────────────────────────────────────
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{lmodern}
\usepackage[margin=1in]{geometry}
\usepackage{graphicx}
\usepackage{booktabs}
\usepackage{hyperref}
\usepackage{xcolor}
\usepackage{amsmath}
\usepackage{float}
\usepackage{caption}
\usepackage{subcaption}
\usepackage{tabularx}
\usepackage{enumitem}
\usepackage{pifont}
\usepackage{listings}
\usepackage{tikz}
\usetikzlibrary{arrows.meta, positioning, shapes.geometric}
\hypersetup{
colorlinks=true,
linkcolor=blue!60!black,
citecolor=blue!60!black,
urlcolor=blue!60!black,
}
\lstset{
basicstyle=\ttfamily\small,
frame=single,
breaklines=true,
columns=flexible,
keepspaces=true,
}
% ── Title ─────────────────────────────────────────────────────────────────
\title{%
\textbf{Execution Context Tokens for Distributed Agentic Workflows:\\
A Data-Driven Design Grounded in 260 IETF Internet-Drafts}%
}
\author{
Christian Nennemann\\
Independent Researcher\\
\texttt{ietf@nennemann.de}
}
\date{February 2026}
\begin{document}
\maketitle
% ── Abstract ──────────────────────────────────────────────────────────────
\begin{abstract}
The Internet Engineering Task Force (IETF) has seen 260 Internet-Drafts addressing AI agents and autonomous systems between June 2025 and February 2026---a 36$\times$ increase in monthly submissions over nine months. Yet a quantitative analysis of this corpus reveals a striking gap: while 98 drafts address agent \emph{identity}, 92 address agent-to-agent \emph{communication}, and 60 address \emph{authorization}, effectively zero proposals provide a standard format for recording what agents \emph{actually did}. We introduce Execution Context Tokens (ECTs), a JWT-based extension to the WIMSE (Workload Identity in Multi-System Environments) architecture that records task execution across distributed agentic workflows. Each ECT is a cryptographically signed record documenting a single task, with predecessor tasks linked through a directed acyclic graph (DAG). Using embedding-based similarity analysis, LLM-assisted multi-dimensional rating, and automated gap detection across the full 260-draft landscape, we demonstrate that ECTs address three identified gaps---agent behavior verification (critical), error recovery (critical), and data provenance (medium)---while maintaining low overlap (2/5) with existing proposals. A head-to-head comparison against eight competing drafts shows that ECTs are the only proposal combining DAG-based workflow modeling, cryptographic input/output integrity, and native WIMSE integration.
\end{abstract}
\noindent\textbf{Keywords:} execution context, agentic workflows, WIMSE, JWT, directed acyclic graph, IETF standardization, landscape analysis
% ══════════════════════════════════════════════════════════════════════════
% 1. INTRODUCTION
% ══════════════════════════════════════════════════════════════════════════
\section{Introduction}
The rapid deployment of autonomous AI agents---software systems that can independently plan, execute tasks, and collaborate with other agents---has created urgent demand for infrastructure standards. The IETF, as the primary venue for Internet protocol standardization, has responded with unprecedented speed: between June 2025 and February 2026, submissions grew from 2 AI-related Internet-Drafts per month to 72, a 36$\times$ increase in nine months.
However, this activity has not been evenly distributed. A quantitative survey of 260 drafts reveals that the community has focused heavily on three questions:
\begin{enumerate}[nosep]
\item \textbf{Who is this agent?} (Identity/authentication: 98 drafts)
\item \textbf{What may this agent do?} (Authorization/policy: 60 drafts)
\item \textbf{How do agents talk?} (Communication protocols: 92 drafts)
\end{enumerate}
\noindent A fourth, equally critical question remains effectively unanswered:
\begin{quote}
\textbf{What did this agent actually do?}
\end{quote}
\noindent Of 1,262 technical ideas extracted from the corpus, only 6 address error recovery in agentic workflows, 52 partially touch behavior verification, and zero provide hash-based data lineage tracking. This paper addresses this gap with two contributions:
\begin{itemize}[nosep]
\item \textbf{Execution Context Tokens (ECTs)}: A JWT-based extension to the WIMSE architecture~\cite{wimse-arch} that records task execution as cryptographically signed, DAG-linked tokens. ECTs answer the ``what did it do?'' question with verifiable execution records.
\item \textbf{Quantitative landscape positioning}: Using a purpose-built analysis pipeline (260 drafts, 33,670 pairwise similarity computations, 12 identified gaps), we demonstrate that ECTs occupy a genuinely novel niche---overlap score 2/5, composite quality 4.0/5---and are the only proposal simultaneously addressing all three execution-layer gaps.
\end{itemize}
\noindent The remainder of this paper is organized as follows. Section~\ref{sec:background} provides background on the WIMSE architecture and related standardization efforts. Section~\ref{sec:landscape} presents the quantitative landscape analysis that motivates ECTs. Section~\ref{sec:ect} describes the ECT specification. Section~\ref{sec:comparison} provides a head-to-head comparison against eight competing proposals. Section~\ref{sec:gaps} maps ECT mechanisms to the 12 identified landscape gaps. Section~\ref{sec:discussion} discusses limitations and adoption considerations. Sections~\ref{sec:related}--\ref{sec:conclusion} cover related work and conclusions.
% ══════════════════════════════════════════════════════════════════════════
% 2. BACKGROUND
% ══════════════════════════════════════════════════════════════════════════
\section{Background}
\label{sec:background}
\subsection{IETF AI Agent Standardization}
The IETF's AI-related work spans multiple working groups and areas. The WIMSE (Workload Identity in Multi-System Environments) working group focuses on cross-system identity for workloads and services. The SPICE (Secure Patterns for Internet CrEdentials) group addresses verifiable credentials. The RATS (Remote ATtestation procedureS) group develops attestation evidence formats. The OAuth working group has produced several agent-specific extensions for delegated authorization.
These groups collectively address the identity and authorization layers but leave execution accountability to individual implementations. No IETF working group currently has a charter covering execution record formats for agentic workflows.
\subsection{WIMSE Architecture}
The WIMSE architecture~\cite{wimse-arch} provides identity infrastructure for workloads operating across trust domains. Its core components are:
\begin{itemize}[nosep]
\item \textbf{Workload Identity Token (WIT)}: A JWT asserting the identity of a workload, typically using SPIFFE IDs~\cite{spiffe} as subject identifiers.
\item \textbf{Workload Proof Token (WPT)}: A proof-of-possession token binding a request to a specific WIT, preventing token theft.
\item \textbf{Trust Domains}: Administrative boundaries within which workload identities are issued and recognized. Cross-domain federation follows established patterns.
\end{itemize}
\noindent WIMSE answers ``who is this workload?'' and ``can it prove its identity?'' but does not answer ``what did it do?'' ECTs extend WIMSE to record execution context, reusing its signing infrastructure and trust model.
\subsection{The Identity--Authorization--Execution Stack}
We identify three layers of agent accountability:
\begin{enumerate}[nosep]
\item \textbf{Identity Layer}: Establishes \emph{who} the agent is (WIMSE WIT, X.509, DID).
\item \textbf{Authorization Layer}: Determines \emph{what} the agent may do (OAuth tokens, capability tokens, policy frameworks).
\item \textbf{Execution Layer}: Records \emph{what} the agent actually did (execution context, audit trails, provenance).
\end{enumerate}
\noindent The IETF landscape heavily invests in layers 1 and 2 (98 + 60 = 158 drafts) while layer 3 remains effectively vacant. This asymmetry means agents can be authenticated and authorized but their actual behavior cannot be independently audited---a significant gap for production deployments.
% ══════════════════════════════════════════════════════════════════════════
% 3. LANDSCAPE ANALYSIS
% ══════════════════════════════════════════════════════════════════════════
\section{Landscape Analysis: Motivating Evidence}
\label{sec:landscape}
To ground the ECT design in empirical evidence, we conducted a systematic analysis of 260 IETF Internet-Drafts related to AI agents, published between June 2025 and February 2026. The methodology, dataset, and analysis toolkit are described in a companion paper~\cite{landscape-survey} and released as open source.
\subsection{Corpus Overview}
Table~\ref{tab:corpus} summarizes the dataset.
\begin{table}[h]
\centering
\caption{Corpus summary statistics.}
\label{tab:corpus}
\begin{tabular}{lr}
\toprule
\textbf{Metric} & \textbf{Value} \\
\midrule
Internet-Drafts analyzed & 260 \\
Unique authors & 403 \\
Author--draft relationships & 742 \\
Technical ideas extracted & 1,262 \\
Semantic categories & 19 \\
Pairwise similarity pairs & 33,670 \\
Identified landscape gaps & 12 \\
Time span & Jun 2025 -- Feb 2026 \\
\bottomrule
\end{tabular}
\end{table}
\noindent Each draft was rated on five dimensions (novelty, maturity, overlap, momentum, relevance; scale 1--5) using LLM-assisted analysis (Anthropic Claude Sonnet~4), embedded using a local model (nomic-embed-text via Ollama), and processed for technical idea extraction.
\subsection{Category Distribution and the Safety Deficit}
LLM-assisted classification assigned each draft to one or more of 19 categories. Table~\ref{tab:tiers} organizes the top categories into three accountability tiers.
\begin{table}[h]
\centering
\caption{Category distribution organized by accountability tier.}
\label{tab:tiers}
\begin{tabular}{llrr}
\toprule
\textbf{Tier} & \textbf{Category} & \textbf{Drafts} & \textbf{Avg Score} \\
\midrule
Infrastructure & Data formats / interop & 102 & 3.3 \\
Infrastructure & A2A protocols & 92 & 3.4 \\
Infrastructure & Agent discovery / reg & 57 & 3.5 \\
\midrule
Authorization & Agent identity / auth & 98 & 3.4 \\
Authorization & Policy / governance & 60 & 3.3 \\
Authorization & Human-agent interaction & 22 & 3.3 \\
\midrule
Accountability & AI safety / alignment & 36 & 3.4 \\
Accountability & Autonomous netops & 60 & 3.3 \\
\bottomrule
\end{tabular}
\end{table}
\noindent The infrastructure and authorization tiers collectively account for 431 category assignments (noting that multi-assignment is possible). The accountability tier, despite including safety-critical concerns, accounts for only 96---a ratio of roughly \textbf{4:1}. Within the accountability tier, only 36 drafts address AI safety/alignment, the category most relevant to execution auditing.
\subsection{The Overlap Problem}
Pairwise cosine similarity analysis across 33,670 draft pairs reveals significant redundancy:
\begin{itemize}[nosep]
\item 56 pairs (0.2\%) exceed 0.90 similarity (near-duplicate)
\item 344 pairs (1.0\%) exceed 0.85 (highly similar)
\item 2,668 pairs (7.9\%) exceed 0.80 (significantly overlapping)
\end{itemize}
\noindent The redundancy concentrates in crowded areas. The OAuth-for-agents cluster contains 13 drafts proposing variations of delegated agent authorization. The agent-gateway cluster contains 10 drafts. Meanwhile, \textbf{zero} dedicated drafts exist for execution record formats prior to ECTs. The community is duplicating effort in well-explored spaces while leaving critical gaps unfilled.
\subsection{Gaps Relevant to Execution Tracking}
\label{sec:landscape-gaps}
Automated gap analysis identified 12 under-addressed areas (3 critical, 6 high, 3 medium severity). Three directly concern the execution layer:
\begin{table}[h]
\centering
\caption{Execution-layer gaps in the IETF landscape.}
\label{tab:exec-gaps}
\begin{tabularx}{\textwidth}{llcX}
\toprule
\textbf{Gap} & \textbf{Severity} & \textbf{Ideas\textsuperscript{a}} & \textbf{Problem} \\
\midrule
Behavior Verification & Critical & 52 & No mechanisms to verify agents behave per declared policies. 36 safety drafts vs 260 total. \\
Error Recovery & Critical & 6 & No standards for cascading failure recovery. Only 6 of 1,262 ideas address this. \\
Data Provenance & Medium & 0\textsuperscript{b} & No hash-based data lineage tracking despite 102 data format drafts. \\
\bottomrule
\multicolumn{4}{l}{\footnotesize\textsuperscript{a}Number of extracted ideas (of 1,262 total) that partially address the gap.} \\
\multicolumn{4}{l}{\footnotesize\textsuperscript{b}79 ideas mention ``data'' broadly, but none implement cryptographic lineage.} \\
\end{tabularx}
\end{table}
\noindent The error recovery gap is particularly stark: of 1,262 technical ideas extracted from the entire corpus, only \textbf{6} touch error handling in agentic workflows. The two proposals that do exist address the problem partially but lack a common execution record format for systematic post-mortem analysis.
% ══════════════════════════════════════════════════════════════════════════
% 4. ECT SPECIFICATION
% ══════════════════════════════════════════════════════════════════════════
\section{Execution Context Token Specification}
\label{sec:ect}
\subsection{Design Principles}
ECTs are guided by four principles:
\begin{enumerate}[nosep]
\item \textbf{Records, not permissions.} ECTs document what an agent did, not what it may do. They complement rather than replace authorization tokens.
\item \textbf{DAG, not chain.} Real-world workflows involve parallel execution and convergence (fan-out/fan-in). A directed acyclic graph captures this; a linear chain cannot.
\item \textbf{WIMSE-native.} ECTs reuse WIMSE's signing keys, identity model, and trust domains. No additional key infrastructure is required.
\item \textbf{Minimal mandatory claims.} Only three execution-specific claims are required (\texttt{jti}, \texttt{exec\_act}, \texttt{par}), keeping the base token compact.
\end{enumerate}
\subsection{Token Structure}
An ECT is a JWT~\cite{rfc7519} using JWS Compact Serialization~\cite{rfc7515}. It comprises a JOSE header, standard JWT claims, and execution-specific claims.
\subsubsection{JOSE Header}
\begin{lstlisting}[caption={ECT JOSE Header.}]
{
"alg": "ES256",
"typ": "wimse-exec+jwt",
"kid": "agent-a-key-id-123"
}
\end{lstlisting}
\noindent The \texttt{typ} parameter \texttt{wimse-exec+jwt} distinguishes ECTs from other JWTs. The \texttt{kid} references the agent's WIMSE public key, binding the ECT to the agent's verified identity.
\subsubsection{Claims}
\begin{lstlisting}[caption={Complete ECT payload example.}]
{
"iss": "spiffe://trust-domain.example/agent/payment-processor",
"aud": "spiffe://trust-domain.example/agent/compliance-check",
"iat": 1740600000,
"exp": 1740600900,
"jti": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
"wid": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"exec_act": "process_payment",
"par": ["c9d2e3f4-a5b6-7890-cdef-123456789012",
"d8e9f0a1-b2c3-4567-89ab-cdef01234567"],
"inp_hash": "base64url(SHA-256(input_data))",
"out_hash": "base64url(SHA-256(output_data))",
"ext": {
"com.example.amount_range": "1000-5000"
}
}
\end{lstlisting}
\noindent The execution-specific claims are:
\begin{itemize}[nosep]
\item \textbf{\texttt{exec\_act}}: A structured identifier for the action performed (e.g., \texttt{process\_payment}, \texttt{validate\_input}).
\item \textbf{\texttt{par}}: An array of parent task identifiers (\texttt{jti} values), forming the DAG edges. An empty array indicates a root task.
\item \textbf{\texttt{wid}}: Optional workflow identifier grouping related ECTs.
\item \textbf{\texttt{inp\_hash}} / \textbf{\texttt{out\_hash}}: SHA-256 hashes of input and output data, providing integrity without exposing content.
\item \textbf{\texttt{ext}}: Optional extension object (max 4,096 bytes, max 5 nesting levels) using reverse-domain notation.
\end{itemize}
\subsection{DAG Construction and Validation}
ECTs form a directed acyclic graph through the \texttt{par} claim. Each \texttt{par} entry references the \texttt{jti} of a predecessor task. Validation enforces five rules:
\begin{enumerate}[nosep]
\item \textbf{Uniqueness}: Each \texttt{jti} must be unique within the workflow scope (or globally if \texttt{wid} is absent).
\item \textbf{Parent existence}: All \texttt{par} entries must reference existing ECTs in the store.
\item \textbf{Temporal ordering}: Parent \texttt{iat} timestamps must not exceed child \texttt{iat} plus clock skew tolerance (recommended 30 seconds).
\item \textbf{Acyclicity}: Parent chains must not cycle back to the current task.
\item \textbf{Trust domain consistency}: Parents should belong to the same or federated trust domains.
\end{enumerate}
\noindent A maximum ancestor traversal limit of 10,000 nodes prevents denial-of-service via deep DAGs.
Figure~\ref{fig:dag} illustrates a five-task workflow with fan-out and fan-in.
\begin{figure}[h]
\centering
\begin{tikzpicture}[
node distance=1.5cm and 2.5cm,
task/.style={rectangle, draw, rounded corners, minimum width=2.2cm, minimum height=0.8cm, align=center, font=\footnotesize},
edge/.style={-{Stealth[length=3mm]}, thick}
]
\node[task, fill=blue!10] (t1) {Task A\\{\tiny\texttt{par:[]}}\\{\tiny fetch\_data}};
\node[task, fill=green!10, below left=of t1] (t2) {Task B\\{\tiny\texttt{par:[A]}}\\{\tiny analyze\_risk}};
\node[task, fill=green!10, below right=of t1] (t3) {Task C\\{\tiny\texttt{par:[A]}}\\{\tiny check\_credit}};
\node[task, fill=orange!10, below right=of t2] (t4) {Task D\\{\tiny\texttt{par:[B,C]}}\\{\tiny verify\_compliance}};
\node[task, fill=red!10, below=of t4] (t5) {Task E\\{\tiny\texttt{par:[D]}}\\{\tiny execute\_trade}};
\draw[edge] (t1) -- (t2);
\draw[edge] (t1) -- (t3);
\draw[edge] (t2) -- (t4);
\draw[edge] (t3) -- (t4);
\draw[edge] (t4) -- (t5);
\end{tikzpicture}
\caption{A five-task DAG representing a cross-organization financial workflow. Task~A (root) fetches data; Tasks~B and~C execute in parallel (fan-out); Task~D merges results (fan-in); Task~E performs the final action. Each task references its predecessors via the \texttt{par} claim.}
\label{fig:dag}
\end{figure}
\subsection{Verification Procedure}
ECT verification proceeds in 13 steps, grouped into four phases:
\begin{table}[h]
\centering
\caption{ECT verification procedure (13 steps in 4 phases).}
\label{tab:verify}
\small
\begin{tabularx}{\textwidth}{clX}
\toprule
\textbf{Step} & \textbf{Phase} & \textbf{Action} \\
\midrule
1 & Serialization & Parse JWS Compact Serialization (header.payload.signature) \\
2 & & Verify \texttt{typ} = \texttt{wimse-exec+jwt} \\
3 & & Verify \texttt{alg} $\in$ allowlist (must include ES256; reject \texttt{none}) \\
\midrule
4 & Identity & Verify \texttt{kid} references valid public key from agent's WIT \\
5 & Binding & Verify JWS signature per RFC~7515 \\
6 & & Confirm signing key not revoked \\
7 & & Verify \texttt{alg} matches WIT algorithm \\
8 & & Verify \texttt{iss} matches WIT \texttt{sub} claim \\
\midrule
9 & Temporal \& & Verify verifier's identity $\in$ \texttt{aud} \\
10 & Audience & Verify \texttt{exp} not passed \\
11 & & Verify \texttt{iat} $\leq$ now + 30s and $\geq$ now $-$ 15min \\
\midrule
12 & Structural & Verify \texttt{jti}, \texttt{exec\_act}, \texttt{par} present and well-formed \\
13 & & Perform DAG validation (Section~4.3) \\
\bottomrule
\end{tabularx}
\end{table}
\noindent Failed verification returns HTTP 403 (invalid ECT with valid WIT) or HTTP 401 (signature failure). The overall complexity is $O(1)$ per token except DAG traversal, which is $O(|V|+|E|)$ bounded by the 10,000-node limit.
\subsection{HTTP Transport}
ECTs travel via a new \texttt{Execution-Context} HTTP header alongside WIMSE identity:
\begin{lstlisting}[caption={HTTP request with WIMSE identity and ECT.}]
GET /api/compliance-check HTTP/1.1
Host: compliance-agent.example.com
Workload-Identity: eyJhbGci...WIT...
Execution-Context: eyJhbGci...ECT...
\end{lstlisting}
\noindent Multiple \texttt{Execution-Context} headers may appear when multiple parent tasks contribute context (fan-in). Receivers must individually verify each ECT and reject the request if any fails.
\subsection{Audit Ledger Interface}
An optional audit ledger provides immutable storage. Implementations must satisfy four requirements:
\begin{enumerate}[nosep]
\item \textbf{Append-only}: No modification or deletion after recording.
\item \textbf{Ordering}: Monotonically increasing sequence numbers.
\item \textbf{Lookup}: Efficient retrieval by \texttt{jti}.
\item \textbf{Integrity}: Hash chains or Merkle trees for tamper detection.
\end{enumerate}
\noindent Ledgers should be maintained independently of workflow agents to reduce collusion risk.
% ══════════════════════════════════════════════════════════════════════════
% 5. COMPARATIVE ANALYSIS
% ══════════════════════════════════════════════════════════════════════════
\section{Comparative Analysis Against the Landscape}
\label{sec:comparison}
\subsection{Comparison Framework}
We compare ECTs against eight proposals from the landscape along eight dimensions relevant to execution accountability:
\begin{enumerate}[nosep]
\item \textbf{Execution Recording}: Does it record what an agent did?
\item \textbf{DAG Support}: Can it represent parallel/fan-in workflows?
\item \textbf{I/O Integrity}: Does it protect input/output data integrity?
\item \textbf{Audit Trail}: Does it support immutable audit storage?
\item \textbf{WIMSE Integration}: Does it build on the WIMSE trust model?
\item \textbf{Authorization Scope}: Does it handle delegation/permission?
\item \textbf{Token Format}: Is it based on established standards (JWT/CWT)?
\item \textbf{Verification Depth}: How thorough is the verification procedure?
\end{enumerate}
\subsection{Head-to-Head Comparison}
Table~\ref{tab:comparison} presents the feature matrix. Composite scores are from our landscape analysis (1--5 scale, higher is better); overlap is the LLM-assessed redundancy with other drafts (lower is more unique).
\begin{table}[h]
\centering
\caption{Feature comparison: ECT vs.\ eight competing/complementary proposals. \ding{51} = full, $\sim$ = partial, \ding{55} = none.}
\label{tab:comparison}
\footnotesize
\renewcommand{\arraystretch}{1.15}
\begin{tabularx}{\textwidth}{l c c c c c c c c c c}
\toprule
\textbf{Proposal} & \textbf{Score} & \textbf{Ovlp} & \rotatebox{70}{\textbf{Exec Record}} & \rotatebox{70}{\textbf{DAG}} & \rotatebox{70}{\textbf{I/O Hash}} & \rotatebox{70}{\textbf{Audit}} & \rotatebox{70}{\textbf{WIMSE}} & \rotatebox{70}{\textbf{AuthZ}} & \rotatebox{70}{\textbf{JWT/CWT}} & \rotatebox{70}{\textbf{Verif.\ Depth}} \\
\midrule
\textbf{ECT (this work)} & 4.0 & 2 & \ding{51} & \ding{51} & \ding{51} & \ding{51} & \ding{51} & \ding{55} & \ding{51} & 13 steps \\
DAAP v2~\cite{daap-v2} & 4.8 & 1 & $\sim$ & \ding{55} & \ding{55} & \ding{51} & \ding{55} & \ding{51} & \ding{51} & Broad \\
STAMP~\cite{stamp} & 4.6 & 1 & \ding{55} & \ding{55} & $\sim$ & \ding{51} & \ding{55} & \ding{51} & \ding{51} & 8 steps \\
Agentic JWT~\cite{agentic-jwt} & 4.5 & 2 & \ding{55} & $\sim$ & \ding{55} & \ding{55} & \ding{55} & \ding{51} & \ding{51} & 6 steps \\
Verif.\ Conv.~\cite{verif-conv} & 4.5 & 2 & $\sim$ & \ding{55} & $\sim$ & \ding{51} & \ding{55} & \ding{55} & COSE & Schema \\
Trans.\ Attest.~\cite{trans-att} & 4.3 & 2 & \ding{55} & \ding{55} & \ding{55} & \ding{55} & \ding{51} & \ding{55} & \ding{51} & Env.\ only \\
Txn Tokens~\cite{txn-tokens} & 4.2 & 3 & \ding{55} & \ding{55} & \ding{55} & \ding{55} & \ding{55} & \ding{51} & \ding{51} & Linear \\
Actor Chain~\cite{actor-chain} & 4.1 & 2 & \ding{55} & \ding{55} & \ding{55} & $\sim$ & \ding{55} & \ding{51} & \ding{51} & Linear \\
HJS~\cite{hjs} & 3.5 & 1 & \ding{51} & \ding{55} & \ding{55} & \ding{51} & \ding{55} & \ding{55} & Custom & Blockchain \\
\bottomrule
\end{tabularx}
\end{table}
\noindent Key observations:
\textbf{ECT is the only proposal combining execution recording with DAG support.} The Actor Chain~\cite{actor-chain} and Transaction Tokens~\cite{txn-tokens} propagate linear context but cannot represent fan-in workflows where multiple parent tasks converge. The ECT DAG model is strictly more expressive.
\textbf{No other proposal provides cryptographic I/O integrity.} ECTs' \texttt{inp\_hash} and \texttt{out\_hash} claims create a verifiable data lineage chain. STAMP~\cite{stamp} includes message-level proofs but focuses on delegation authorization, not execution data.
\textbf{DAAP v2~\cite{daap-v2} is the most comprehensive competitor.} Scoring 4.8, it covers authentication, behavioral monitoring, and remote shutdown---a broader scope than ECTs. However, it does not define a structured execution record format or support DAG workflow modeling. ECTs are complementary: DAAP could use ECTs as its execution record layer.
\textbf{Transitive Attestation~\cite{trans-att} is a natural WIMSE sibling.} It binds identities to execution environments (TEEs). Combined with ECTs, the WIMSE stack would provide a complete accountability chain: \emph{who} (WIT), \emph{where} (transitive attestation), \emph{what} (ECT).
\textbf{HJS~\cite{hjs} shares ECT's goals but uses a heavier trust model.} Blockchain-anchored timestamps provide decentralized accountability but introduce latency and infrastructure requirements that ECTs avoid through standard JWT infrastructure.
\subsection{Uniqueness Quantification}
To quantify ECT's positioning beyond subjective comparison, we use embedding-based similarity from the landscape analysis:
\begin{itemize}[nosep]
\item \textbf{Maximum pairwise similarity}: 0.836 (with \texttt{draft-nederveld-adl}, an agent definition language---a different problem domain).
\item \textbf{Overlap rating}: 2/5 (low---among the most unique 25\% of all 260 drafts).
\item \textbf{Cluster membership}: ECT does not belong to any of the high-similarity clusters identified at the 0.85 threshold.
\item \textbf{Composite score}: 4.0/5, placing ECT in the top 20\% of the corpus.
\end{itemize}
\noindent These metrics confirm that ECTs occupy a genuinely novel niche rather than duplicating existing work.
% ══════════════════════════════════════════════════════════════════════════
% 6. GAP COVERAGE ANALYSIS
% ══════════════════════════════════════════════════════════════════════════
\section{Gap Coverage Analysis}
\label{sec:gaps}
We map ECT mechanisms to each of the 12 identified landscape gaps. Table~\ref{tab:all-gaps} provides the full matrix.
\begin{table}[h]
\centering
\caption{ECT coverage of the 12 identified landscape gaps.}
\label{tab:all-gaps}
\small
\begin{tabularx}{\textwidth}{llccX}
\toprule
\textbf{Gap} & \textbf{Sev.} & \textbf{Exist.\textsuperscript{a}} & \textbf{ECT} & \textbf{ECT Mechanism} \\
\midrule
Agent Behavior Verification & Crit. & 52 & \ding{51} & Signed \texttt{exec\_act} records what agent claimed to do \\
Agent Error Recovery & Crit. & 6 & \ding{51} & DAG enables post-mortem tracing; \texttt{inp\_hash}/\texttt{out\_hash} locate data corruption \\
Agent Resource Mgmt & Crit. & 117 & \ding{55} & --- \\
Cross-Protocol Translation & High & 0 & \ding{55} & --- \\
Agent Lifecycle Mgmt & High & 90 & \ding{55} & --- \\
Multi-Agent Consensus & High & 5 & \ding{55} & --- \\
Human Override & High & 4 & \ding{55} & --- \\
Cross-Domain Security & High & 10 & $\sim$ & DAG validation rule~5 (trust domain consistency) \\
Dynamic Trust & High & 5 & $\sim$ & Execution history enables reputation assessment \\
Agent Performance Mon. & Med. & 26 & $\sim$ & Timestamp-based execution timing from \texttt{iat} of parent/child \\
Agent Explainability & Med. & 5 & \ding{55} & --- \\
Agent Data Provenance & Med. & 0 & \ding{51} & \texttt{inp\_hash}/\texttt{out\_hash} chains create verifiable data lineage \\
\bottomrule
\multicolumn{5}{l}{\footnotesize\textsuperscript{a}Number of existing ideas (of 1,262) that partially address the gap.} \\
\end{tabularx}
\end{table}
\noindent ECTs fully address 3 gaps and partially address 3 more. Notably, ECTs are the \textbf{only single proposal in the 260-draft landscape that simultaneously addresses all three execution-layer gaps} (behavior verification, error recovery, data provenance). No other draft combines signed execution records, DAG-based workflow modeling, and cryptographic data lineage.
The error recovery coverage is particularly significant: with only 6 of 1,262 ideas touching this topic, the existing landscape provides essentially no support for debugging failed multi-agent workflows. ECT DAGs directly enable the kind of ``execution replay'' analysis that production deployments require.
% ══════════════════════════════════════════════════════════════════════════
% 7. DISCUSSION
% ══════════════════════════════════════════════════════════════════════════
\section{Discussion and Limitations}
\label{sec:discussion}
\subsection{The Self-Assertion Limitation}
ECTs are fundamentally self-asserted: an agent creates its own execution record. A compromised or malicious agent can claim to have performed actions it did not, or omit actions it did perform. This is the most significant limitation of the design.
Mitigations include:
\begin{itemize}[nosep]
\item \textbf{Independent audit ledgers}: Maintained separately from workflow agents, enabling cross-verification of ECT sequences.
\item \textbf{Multi-replica comparison}: Multiple observers independently record ECTs and flag discrepancies.
\item \textbf{TEE integration}: Combining ECTs with transitive attestation~\cite{trans-att} to verify the execution environment. If the agent runs in a Trusted Execution Environment, the ECT's credibility increases significantly.
\item \textbf{Input/output hash verification}: While agents can falsify \texttt{exec\_act}, the \texttt{inp\_hash} and \texttt{out\_hash} claims can be independently verified by recipients who possess the actual data.
\end{itemize}
\subsection{Scalability Considerations}
Large-scale workflows may generate thousands of ECTs. The 10,000-node traversal limit constrains verification cost but may prove insufficient for long-running industrial workflows. Practical deployments may require:
\begin{itemize}[nosep]
\item \textbf{Checkpoint ECTs}: Periodic summarization of sub-DAGs into single checkpoint tokens, resetting traversal depth.
\item \textbf{Lazy verification}: Verifying only the immediate parents during normal operation, with full DAG traversal reserved for audit and debugging.
\item \textbf{Ledger-assisted verification}: Offloading DAG validation to the audit ledger, which maintains an indexed view of the complete workflow graph.
\end{itemize}
\subsection{Adoption Path}
ECTs are designed for incremental adoption:
\begin{enumerate}[nosep]
\item Agents can emit ECTs even if not all recipients verify them (the header is simply ignored by unaware systems).
\item The JWT format leverages existing libraries and tooling in every major programming language.
\item Integration with WIMSE requires only that the agent already possesses a WIT---no additional key infrastructure.
\item The single new HTTP header (\texttt{Execution-Context}) requires no changes to request routing or load balancing.
\end{enumerate}
\subsection{Limitations of the Landscape Analysis}
The quantitative evidence supporting ECTs inherits limitations from the analysis methodology:
\begin{itemize}[nosep]
\item \textbf{Keyword selection}: Six seed keywords may miss relevant drafts using different terminology.
\item \textbf{Single-LLM assessment}: Claude Sonnet~4 may have systematic biases in its ratings.
\item \textbf{Snapshot}: The analysis captures February 2026; the landscape evolves continuously.
\item \textbf{Disambiguation}: Author affiliations may be inconsistent (e.g., ``Huawei'' vs.\ ``Huawei Technologies'' are counted separately).
\end{itemize}
% ══════════════════════════════════════════════════════════════════════════
% 8. RELATED WORK
% ══════════════════════════════════════════════════════════════════════════
\section{Related Work}
\label{sec:related}
\textbf{Distributed tracing.} OpenTelemetry~\cite{opentelemetry} provides observability for microservice architectures with trace/span hierarchies. However, spans are unsigned and designed for monitoring, not accountability. ECTs provide cryptographic integrity and are designed for audit, not debugging (though they enable both).
\textbf{Provenance standards.} The W3C PROV data model~\cite{w3c-prov} provides a semantic framework for provenance tracking. PROV is comprehensive but heavyweight---ECTs provide a runtime-embeddable JWT format suitable for HTTP request flows rather than offline provenance databases.
\textbf{Supply chain transparency.} SCITT (Supply Chain Integrity, Transparency, and Trust)~\cite{scitt} defines transparent ledgers for signed statements about supply chain artifacts. ECT audit ledgers share design principles but target runtime execution rather than build-time artifacts. ECTs could correlate with SCITT Signed Statements for end-to-end accountability.
\textbf{Blockchain-based accountability.} Various proposals use blockchain for agent accountability (e.g., HJS~\cite{hjs}). ECTs deliberately avoid blockchain dependency to minimize latency and infrastructure requirements, using optional append-only ledgers instead.
% ══════════════════════════════════════════════════════════════════════════
% 9. CONCLUSION
% ══════════════════════════════════════════════════════════════════════════
\section{Conclusion and Future Work}
\label{sec:conclusion}
We have presented Execution Context Tokens (ECTs), a JWT-based extension to the WIMSE architecture for recording task execution in distributed agentic workflows. By analyzing 260 IETF Internet-Drafts using embedding similarity, LLM-assisted rating, and automated gap detection, we demonstrated that the execution accountability layer is the most under-served area in the current standardization landscape.
ECTs address this gap with a design that is both technically sound (DAG-based workflow modeling, cryptographic I/O integrity, 13-step verification) and practically deployable (JWT format, single HTTP header, incremental adoption). A head-to-head comparison against eight competing proposals confirms that ECTs are the only specification combining execution recording, DAG support, and WIMSE-native integration.
\textbf{Future work} includes:
\begin{enumerate}[nosep]
\item \textbf{Reference implementation}: An open-source library for ECT creation, verification, and DAG visualization.
\item \textbf{Formal verification}: Applying ProVerif or Tamarin to the ECT security model.
\item \textbf{Integration testing}: Deploying ECTs alongside WIMSE WIT/WPT and transitive attestation in a multi-agent testbed to validate the ``WIMSE trinity'' concept.
\item \textbf{Privacy-preserving ECTs}: Selective disclosure of execution details using zero-knowledge proofs or redactable signatures.
\item \textbf{Longitudinal tracking}: Monitoring the landscape as it evolves and assessing whether ECTs catalyze additional execution-layer proposals.
\end{enumerate}
\noindent The ECT specification is available as IETF Internet-Draft \texttt{draft-nennemann-wimse-ect-00}~\cite{ect-draft}. The landscape analysis toolkit and dataset are released as open source.\footnote{Repository: \url{https://github.com/TODO/ietf-draft-analyzer}}
% ── Acknowledgments ──────────────────────────────────────────────────────
\section*{Acknowledgments}
The landscape analysis was performed using Anthropic Claude (Sonnet 4) for rating and idea extraction, and Ollama with nomic-embed-text for embedding generation. The author thanks the IETF community for maintaining the open Datatracker API and the WIMSE working group for providing the identity foundation on which ECTs build.
% ── References ───────────────────────────────────────────────────────────
\bibliographystyle{plain}
\bibliography{references}
\end{document}

207
workspace/drafts/ect-landscape-paper/references.bib Normal file
View File

@@ -0,0 +1,207 @@
% ── IETF RFCs and Standards ──────────────────────────────────────────────
@misc{rfc7519,
author = {M. Jones and J. Bradley and N. Sakimura},
title = {{JSON Web Token (JWT)}},
howpublished = {RFC 7519},
year = {2015},
url = {https://www.rfc-editor.org/rfc/rfc7519},
}
@misc{rfc7515,
author = {M. Jones and J. Bradley and N. Sakimura},
title = {{JSON Web Signature (JWS)}},
howpublished = {RFC 7515},
year = {2015},
url = {https://www.rfc-editor.org/rfc/rfc7515},
}
@misc{rfc2026,
author = {S. Bradner},
title = {{The Internet Standards Process -- Revision 3}},
howpublished = {RFC 2026},
year = {1996},
url = {https://www.rfc-editor.org/rfc/rfc2026},
}
@misc{rfc8693,
author = {M. Jones and A. Nadalin and B. Campbell and J. Bradley and C. Mortimore},
title = {{OAuth 2.0 Token Exchange}},
howpublished = {RFC 8693},
year = {2020},
url = {https://www.rfc-editor.org/rfc/rfc8693},
}
% ── WIMSE Architecture ──────────────────────────────────────────────────
@misc{wimse-arch,
author = {{WIMSE Working Group}},
title = {{Workload Identity in Multi System Environments (WIMSE) Architecture}},
howpublished = {Internet-Draft},
year = {2025},
url = {https://datatracker.ietf.org/wg/wimse/about/},
}
@misc{spiffe,
author = {{SPIFFE Project}},
title = {{SPIFFE: Secure Production Identity Framework for Everyone}},
howpublished = {CNCF Project},
year = {2024},
url = {https://spiffe.io},
}
% ── The ECT Draft ───────────────────────────────────────────────────────
@misc{ect-draft,
author = {Christian Nennemann},
title = {{Execution Context Tokens for Distributed Agentic Workflows}},
howpublished = {Internet-Draft draft-nennemann-wimse-ect-00},
year = {2026},
month = feb,
url = {https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/},
}
% ── Competing/Complementary IETF Drafts ─────────────────────────────────
@misc{daap-v2,
author = {Aylward, Jonathan},
title = {{Distributed AI Accountability Protocol (DAAP) Version 2.0}},
howpublished = {Internet-Draft draft-aylward-daap-v2},
year = {2026},
url = {https://datatracker.ietf.org/doc/draft-aylward-daap-v2/},
}
@misc{stamp,
author = {Guy, Bary},
title = {{Secure Task-bound Agent Message Proof (STAMP) Protocol}},
howpublished = {Internet-Draft draft-guy-bary-stamp-protocol},
year = {2025},
url = {https://datatracker.ietf.org/doc/draft-guy-bary-stamp-protocol/},
}
@misc{agentic-jwt,
author = {Goswami, Anirudh},
title = {{Secure Intent Protocol: JWT Compatible Agentic Identity and Workflow Management}},
howpublished = {Internet-Draft draft-goswami-agentic-jwt},
year = {2025},
url = {https://datatracker.ietf.org/doc/draft-goswami-agentic-jwt/},
}
@misc{verif-conv,
author = {Birkholz, Henk},
title = {{Verifiable Agent Conversation Records}},
howpublished = {Internet-Draft draft-birkholz-verifiable-agent-conversations},
year = {2025},
url = {https://datatracker.ietf.org/doc/draft-birkholz-verifiable-agent-conversations/},
}
@misc{trans-att,
author = {{MW et al.}},
title = {{Transitive Attestation for Sovereign Workloads: A WIMSE Profile}},
howpublished = {Internet-Draft draft-mw-wimse-transitive-attestation},
year = {2025},
url = {https://datatracker.ietf.org/doc/draft-mw-wimse-transitive-attestation/},
}
@misc{txn-tokens,
author = {{OAuth Working Group}},
title = {{Transaction Tokens For Agents}},
howpublished = {Internet-Draft draft-oauth-transaction-tokens-for-agents},
year = {2025},
url = {https://datatracker.ietf.org/doc/draft-oauth-transaction-tokens-for-agents/},
}
@misc{actor-chain,
author = {{MW et al.}},
title = {{Cryptographically Verifiable Actor Chain for OAuth 2.0 Token Exchange}},
howpublished = {Internet-Draft draft-mw-spice-actor-chain},
year = {2025},
url = {https://datatracker.ietf.org/doc/draft-mw-spice-actor-chain/},
}
@misc{hjs,
author = {Wang, et al.},
title = {{HJS: An Accountability Layer for AI Agents}},
howpublished = {Internet-Draft draft-wang-hjs-accountability},
year = {2025},
url = {https://datatracker.ietf.org/doc/draft-wang-hjs-accountability/},
}
% ── Other Referenced Drafts ──────────────────────────────────────────────
@misc{agent-recovery,
author = {Yue, et al.},
title = {{Task-Oriented Multi-Agent Recovery Framework for High-Reliability in Converged Mobile Networks}},
howpublished = {Internet-Draft draft-yue-anima-agent-recovery-networks},
year = {2025},
url = {https://datatracker.ietf.org/doc/draft-yue-anima-agent-recovery-networks/},
}
@misc{agents-policy,
author = {Srijal},
title = {{AGENTS.TXT: Strict Policy File for Automated Clients}},
howpublished = {Internet-Draft draft-srijal-agents-policy},
year = {2025},
url = {https://datatracker.ietf.org/doc/draft-srijal-agents-policy/},
}
% ── Companion Paper ─────────────────────────────────────────────────────
@misc{landscape-survey,
author = {Nennemann, Christian},
title = {{The AI Agent Standardization Wave: A Quantitative Analysis of 260 IETF Internet-Drafts on Autonomous Agents and Artificial Intelligence}},
howpublished = {arXiv preprint},
year = {2026},
note = {Companion landscape survey paper},
}
% ── Related Work ────────────────────────────────────────────────────────
@misc{opentelemetry,
author = {{OpenTelemetry Project}},
title = {{OpenTelemetry Specification}},
howpublished = {CNCF Project},
year = {2024},
url = {https://opentelemetry.io},
}
@misc{w3c-prov,
author = {Luc Moreau and Paolo Missier},
title = {{PROV-DM: The PROV Data Model}},
howpublished = {W3C Recommendation},
year = {2013},
url = {https://www.w3.org/TR/prov-dm/},
}
@misc{scitt,
author = {{IETF SCITT Working Group}},
title = {{Supply Chain Integrity, Transparency, and Trust (SCITT)}},
howpublished = {Internet-Draft},
year = {2024},
url = {https://datatracker.ietf.org/wg/scitt/about/},
}
@misc{a2a-protocol,
author = {{Google}},
title = {{Agent-to-Agent (A2A) Protocol Specification}},
howpublished = {Technical Report},
year = {2025},
url = {https://github.com/google/A2A},
}
@misc{mcp-protocol,
author = {{Anthropic}},
title = {{Model Context Protocol (MCP) Specification}},
howpublished = {Technical Report},
year = {2025},
url = {https://modelcontextprotocol.io},
}
% ── Academic References ─────────────────────────────────────────────────
@inproceedings{brown2020,
author = {Brown, Tom and Mann, Benjamin and Ryder, Nick and others},
title = {{Language Models are Few-Shot Learners}},
booktitle = {Advances in Neural Information Processing Systems},
year = {2020},
}

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>

0
workspace/drafts/ietf-exec-audit/draft-nennemann-exec-audit-00.xml Normal file
View File

2292
workspace/drafts/ietf-exec-audit/draft-nennemann-exec-audit.md Normal file
View File

File diff suppressed because it is too large Load Diff

1
workspace/drafts/ietf-wimse-ect Submodule

Submodule workspace/drafts/ietf-wimse-ect added at 884d2dc836

289
workspace/drafts/new-drafts/draft-a-aem-agent-ecosystem-model-00.md Normal file
View File

@@ -0,0 +1,289 @@
---
title: "Agent Ecosystem Model (AEM): Architecture and Terminology"
abbrev: "AEM"
category: info
docname: draft-aem-agent-ecosystem-model-00
submissiontype: IETF
number:
date:
v: 3
area: "OPS"
workgroup: "NMOP"
keyword:
- agent ecosystem
- DAG
- HITL
- agentic workflows
author:
-
fullname: TBD
organization: Independent
email: placeholder@example.com
normative:
RFC2119:
RFC8174:
informative:
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/
--- abstract
This document defines the Agent Ecosystem Model (AEM), a shared
architecture and terminology for building interoperable agent
systems that incorporate DAG-based execution, human-in-the-loop
safety, and graduated assurance levels. AEM is not a protocol.
It is a reference model that establishes common vocabulary and
architectural concepts so that companion specifications (ATD,
HITL, AEPB, APAE) and implementors share a consistent frame of
reference. The model builds on Execution Context Tokens (ECT)
for execution evidence and ACP-DAG-HITL for delegation policy.
--- middle
# Introduction
The IETF AI/agent landscape includes over 260 drafts proposing
protocols for agent communication, identity, safety, and
operations. These drafts share many implicit concepts — tasks,
delegation, workflows, safety checks — but use inconsistent
terminology and incompatible models.
AEM provides a single reference architecture so that:
- Companion drafts (ATD, HITL, AEPB, APAE) share vocabulary.
- Implementors understand how the pieces compose.
- New proposals can position themselves within an existing model
rather than inventing another one.
AEM is deliberately not a protocol. It defines no wire formats,
no endpoints, and no new token types. It is the map; the
companion drafts are the territory.
## Design Principles
1. **ECT is the execution backbone.** All significant agent
actions produce Execution Context Tokens
{{I-D.nennemann-wimse-ect}}. The ecosystem does not define a
second DAG or audit format.
2. **ACP-DAG-HITL is the policy backbone.**
{{I-D.nennemann-agent-dag-hitl-safety}} defines delegation
DAGs and HITL rules. The ecosystem extends these with
operational semantics, not replacement structures.
3. **Same model, different assurance.** The architecture works
identically from a relaxed K8s dev cluster (ECT L1) to a
regulated healthcare environment (ECT L3 with audit ledger).
4. **Protocol-agnostic.** The ecosystem sits above any A2A
protocol. Agents may speak different protocols and still
participate through translation.
# Conventions and Definitions
{::boilerplate bcp14-tagged}
# Terminology {#terminology}
Agent:
: An autonomous software entity that performs tasks, makes
decisions, and communicates with other agents or humans.
Task:
: A discrete unit of work performed by an agent, recorded as a
single ECT node.
Workflow:
: A set of tasks linked by dependencies, forming a DAG.
Identified by the ECT `wid` claim.
DAG (Directed Acyclic Graph):
: The execution graph formed by ECT parent references (`par`
claims). Also used in ACP-DAG-HITL for delegation structure.
Checkpoint:
: An ECT node recording agent state before a consequential
action, enabling rollback.
HITL Point:
: A position in the workflow where human intervention is
required or available, governed by ACP-DAG-HITL rules.
Override:
: A human-initiated command that alters an agent's autonomous
operation, taking precedence over the agent's own decisions.
Trust Score:
: A floating-point value in \[0.0, 1.0\] representing one
agent's assessed reliability of another.
Protocol Binding:
: The mapping between ecosystem semantics and a specific A2A
communication protocol.
Assurance Level:
: The degree of cryptographic and audit protection applied to
ECTs: L1 (unsigned JSON), L2 (signed JWT), L3 (signed +
audit ledger). Defined by {{I-D.nennemann-wimse-ect}}.
# Architectural Model {#architecture}
The ecosystem is organized in four layers:
~~~
┌─────────────────────────────────────────────────────┐
│ Policy Layer │
│ ACP-DAG-HITL: delegation DAG, HITL rules, │
│ node constraints, trust thresholds │
├─────────────────────────────────────────────────────┤
│ Semantics Layer │
│ ATD: execution order, checkpoints, rollback, │
│ circuit breakers, resource hints │
│ HITL: override levels, approval gates, escalation │
│ AEPB: capability ads, negotiation, translation │
│ APAE: trust scoring, behavior verification, │
│ provenance, assurance profiles │
├─────────────────────────────────────────────────────┤
│ Evidence Layer │
│ ECT: signed DAG of execution records (L1/L2/L3) │
│ inp_hash/out_hash, ext claims, audit ledger │
├─────────────────────────────────────────────────────┤
│ Identity Layer │
│ WIMSE / X.509 / OAuth / JWK: agent identity │
└─────────────────────────────────────────────────────┘
~~~
{: #fig-stack title="Ecosystem Layer Stack"}
Identity Layer:
: Answers "who is this agent?" AEM does not define identity
mechanisms; it assumes WIMSE, X.509, OAuth, or equivalent.
Evidence Layer:
: Answers "what did this agent do?" ECT provides per-task
signed records linked into a DAG, with three assurance levels.
Semantics Layer:
: Answers "what does it mean and what to do about it?" The
four companion drafts define operational semantics on top of
ECT:
- **ATD** (Agent Task DAG): execution order, checkpoints,
rollback, circuit breakers, resource hints.
- **HITL** (Human-in-the-Loop): override levels, approval
gates, escalation paths, explainability.
- **AEPB** (Agent Ecosystem Protocol Binding): capability
advertisement, protocol negotiation, translation gateways,
agent lifecycle.
- **APAE** (Assurance Profiles): dynamic trust scoring,
behavior verification, data provenance, assurance profiles.
Policy Layer:
: Answers "what's allowed?" ACP-DAG-HITL defines delegation
constraints and HITL trigger rules. Companion drafts extend
`constraints` with protocol-specific fields (trust thresholds,
checkpoint policies, protocol restrictions).
## How ECT Extensions Work
Each companion draft defines `ext` claim namespaces on ECT:
| Draft | `ext` prefix | Example claims |
|-------|-------------|----------------|
| ATD | `atd.*` | `atd.reversible`, `atd.severity`, `atd.circuit_state` |
| HITL | `hitl.*` | `hitl.level`, `hitl.operator_id`, `hitl.prior_state` |
| AEPB | `aepb.*` | `aepb.source_protocol`, `aepb.dest_protocol` |
| APAE | `apae.*` | `apae.trust_score`, `apae.confidence`, `apae.hops` |
{: #fig-ext title="ECT Extension Namespaces"}
## How Policy Extensions Work
Each companion draft defines `constraints` fields on
ACP-DAG-HITL DAG nodes:
| Draft | Constraint fields |
|-------|------------------|
| ATD | `atd.checkpoint_policy`, `atd.circuit_threshold` |
| HITL | (uses HITL rules directly) |
| AEPB | `aepb.allowed_protocols`, `aepb.max_translation_hops` |
| APAE | `apae.min_trust`, `apae.min_confidence`, `apae.assurance_profile` |
{: #fig-constraints title="ACP-DAG-HITL Node Constraint Extensions"}
# Assurance as an Orthogonal Axis {#assurance}
The entire semantics layer operates identically at all ECT
assurance levels. The DAG structure, HITL processing, trust
scoring, and protocol translation are the same whether the ECT
is unsigned JSON (L1) or a ledger-committed signed JWT (L3).
What changes across levels is the security envelope:
| Property | L1 | L2 | L3 |
|----------|----|----|-----|
| Structured execution records | Yes | Yes | Yes |
| DAG validation | Yes | Yes | Yes |
| Non-repudiation | No | Yes | Yes |
| Tamper detection | Transport only | Signature | Signature + ledger |
| Regulatory audit trail | No | No | Yes |
{: #fig-assurance title="Assurance Level Properties"}
A deployment MAY use different levels for different workflows.
Internal dev pipelines might use L1; cross-org integrations L2;
regulated clinical workflows L3.
# Protocol Agnosticism {#agnosticism}
The ecosystem layer sits above any A2A communication protocol.
Agents communicate via their native protocol (A2A, MCP, SLIM,
uACP, etc.) while the Execution-Context HTTP header
{{I-D.nennemann-wimse-ect}} carries ECTs alongside protocol
messages.
When two agents speak different protocols, a translation gateway
(defined by AEPB) converts between protocols while preserving
ECT DAG continuity. The translation hop is itself an ECT node,
so the cross-protocol path is one auditable DAG.
# Companion Draft Summary {#companions}
| Draft | Abbrev | Concern | Gaps Addressed |
|-------|--------|---------|----------------|
| Agent Task DAG | ATD | Execution, checkpoints, rollback | #1 Resource Mgmt, #3 Error Recovery |
| Human-in-the-Loop | HITL | Override, approval, escalation | #7 Human Override, #11 Explainability |
| Protocol Binding | AEPB | Interop, translation, lifecycle | #4 Cross-Protocol, #5 Lifecycle |
| Assurance Profiles | APAE | Trust, verification, provenance | #2 Behavior Verification, #8 Cross-Domain, #9 Dynamic Trust, #12 Provenance |
{: #fig-companions title="Companion Draft Family"}
Together with ECT (evidence) and ACP-DAG-HITL (policy), these
six documents cover all 3 critical and 6 high-severity gaps
identified in the IETF AI/agent draft landscape.
# Security Considerations
AEM defines no protocol mechanisms and therefore introduces no
direct security considerations. Security properties are
inherited from the evidence layer (ECT assurance levels) and
the policy layer (ACP-DAG-HITL validation).
Implementors MUST ensure that all layers are consistently
configured: an L3 ECT deployment provides no additional
assurance if the policy layer accepts unsigned tokens.
# IANA Considerations
This document has no IANA actions.
--- back
# Acknowledgments
{:numbered="false"}
This architecture 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}}.

461
workspace/drafts/new-drafts/draft-a-aem-agent-ecosystem-model-01.md Normal file
View File

@@ -0,0 +1,461 @@
---
title: "Agent Ecosystem Model (AEM): Architecture and Terminology"
abbrev: "AEM"
category: info
docname: draft-aem-agent-ecosystem-model-01
submissiontype: IETF
number:
date:
v: 3
area: "OPS"
workgroup: "NMOP"
keyword:
- agent ecosystem
- DAG
- HITL
- agentic workflows
author:
-
fullname: TBD
organization: Independent
email: placeholder@example.com
normative:
RFC2119:
RFC8174:
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:
RFC9334:
RFC7519:
RFC8615:
--- abstract
This document defines the Agent Ecosystem Model (AEM), a shared
architecture and terminology for building interoperable agent
systems that incorporate DAG-based execution, human-in-the-loop
safety, and graduated assurance levels. AEM is not a protocol.
It is a reference model that establishes common vocabulary and
architectural concepts so that companion specifications (ATD,
HITL, AEPB, APAE) and implementors share a consistent frame of
reference. The model builds on Execution Context Tokens (ECT)
for execution evidence and ACP-DAG-HITL for delegation policy.
--- middle
# Introduction
The IETF AI/agent landscape includes over 260 drafts proposing
protocols for agent communication, identity, safety, and
operations. These drafts share many implicit concepts — tasks,
delegation, workflows, safety checks — but use inconsistent
terminology and incompatible models.
AEM provides a single reference architecture so that:
- Companion drafts (ATD, HITL, AEPB, APAE) share vocabulary.
- Implementors understand how the pieces compose.
- New proposals can position themselves within an existing model
rather than inventing another one.
AEM is deliberately not a protocol. It defines no wire formats,
no endpoints, and no new token types. It is the map; the
companion drafts are the territory.
## Design Principles
1. **ECT is the execution backbone.** All significant agent
actions produce Execution Context Tokens
{{I-D.nennemann-wimse-ect}}. The ecosystem does not define a
second DAG or audit format.
2. **ACP-DAG-HITL is the policy backbone.**
{{I-D.nennemann-agent-dag-hitl-safety}} defines delegation
DAGs and HITL rules. The ecosystem extends these with
operational semantics, not replacement structures.
3. **Same model, different assurance.** The architecture works
identically from a relaxed K8s dev cluster (ECT L1) to a
regulated healthcare environment (ECT L3 with audit ledger).
4. **Protocol-agnostic.** The ecosystem sits above any A2A
protocol. Agents may speak different protocols and still
participate through translation.
# Conventions and Definitions
{::boilerplate bcp14-tagged}
# Terminology {#terminology}
Agent:
: An autonomous software entity that performs tasks, makes
decisions, and communicates with other agents or humans.
Task:
: A discrete unit of work performed by an agent, recorded as a
single ECT node.
Workflow:
: A set of tasks linked by dependencies, forming a DAG.
Identified by the ECT `wid` claim {{I-D.nennemann-wimse-ect}}.
DAG (Directed Acyclic Graph):
: The execution graph formed by ECT parent references (`par`
claims). Also used in ACP-DAG-HITL for delegation structure.
Checkpoint:
: An ECT node recording agent state before a consequential
action, enabling rollback. Fully specified in ATD.
HITL Point:
: A position in the workflow where human intervention is
required or available, governed by ACP-DAG-HITL rules.
Override:
: A human-initiated command that alters an agent's autonomous
operation, taking precedence over the agent's own decisions.
Fully specified in HITL.
Trust Score:
: A floating-point value in \[0.0, 1.0\] representing one
agent's assessed reliability of another. Updated using an
AIMD model; fully specified in APAE.
Protocol Binding:
: The mapping between ecosystem semantics and a specific A2A
communication protocol. Fully specified in AEPB.
Assurance Level:
: The degree of cryptographic and audit protection applied to
ECTs, defined in {{I-D.nennemann-wimse-ect}}:
| Level | ECT Format | Non-repudiation | Tamper detection | Audit ledger |
|-------|-----------|----------------|-----------------|-------------|
| L1 | Unsigned JSON | No | Transport only | No |
| L2 | Signed JWT | Yes | Signature | No |
| L3 | Signed JWT | Yes | Signature | Yes (ledger-committed) |
{: #fig-levels title="ECT Assurance Levels"}
Assurance Profile:
: A named configuration (Relaxed, Standard, Regulated) selecting
which mechanisms are required at a given deployment. Fully
specified in APAE.
Blast Radius:
: The set of agents and systems affected by a single failure.
Translation Gateway:
: A service converting messages between two agent protocols,
recording each hop as an ECT DAG node. Fully specified in AEPB.
# Architectural Model {#architecture}
The ecosystem is organized in four layers:
~~~
┌─────────────────────────────────────────────────────┐
│ Policy Layer │
│ ACP-DAG-HITL: delegation DAG, HITL rules, │
│ node constraints, trust thresholds │
├─────────────────────────────────────────────────────┤
│ Semantics Layer │
│ ATD: execution order, checkpoints, rollback, │
│ circuit breakers, resource hints │
│ HITL: override levels, approval gates, escalation │
│ AEPB: capability ads, negotiation, translation │
│ APAE: trust scoring, behavior verification, │
│ provenance, assurance profiles │
├─────────────────────────────────────────────────────┤
│ Evidence Layer │
│ ECT: signed DAG of execution records (L1/L2/L3) │
│ inp_hash/out_hash, ext claims, audit ledger │
├─────────────────────────────────────────────────────┤
│ Identity Layer │
│ WIMSE / X.509 / OAuth / JWK: agent identity │
└─────────────────────────────────────────────────────┘
~~~
{: #fig-stack title="Ecosystem Layer Stack"}
Identity Layer:
: Answers "who is this agent?" AEM does not define identity
mechanisms; it assumes WIMSE, X.509, OAuth, or equivalent.
Evidence Layer:
: Answers "what did this agent do?" ECT provides per-task
signed records linked into a DAG, with three assurance levels.
Semantics Layer:
: Answers "what does it mean and what to do about it?" The
four companion drafts define operational semantics on top of
ECT:
- **ATD** (Agent Task DAG): execution order, checkpoints,
rollback, circuit breakers, resource hints.
- **HITL** (Human-in-the-Loop): override levels, approval
gates, escalation paths, explainability.
- **AEPB** (Agent Ecosystem Protocol Binding): capability
advertisement, protocol negotiation, translation gateways,
agent lifecycle.
- **APAE** (Assurance Profiles): dynamic trust scoring,
behavior verification, data provenance, assurance profiles.
Policy Layer:
: Answers "what's allowed?" ACP-DAG-HITL defines delegation
constraints and HITL trigger rules. Companion drafts extend
`constraints` with protocol-specific fields (trust thresholds,
checkpoint policies, protocol restrictions).
## How ECT Extensions Work {#ect-ext}
Each companion draft defines `ext` claim namespaces on ECT:
| Draft | `ext` prefix | Example claims |
|-------|-------------|----------------|
| ATD | `atd.*` | `atd.reversible`, `atd.severity`, `atd.circuit_state` |
| HITL | `hitl.*` | `hitl.level`, `hitl.operator_id`, `hitl.prior_state` |
| AEPB | `aepb.*` | `aepb.source_protocol`, `aepb.dest_protocol` |
| APAE | `apae.*` | `apae.trust_score`, `apae.confidence`, `apae.hops` |
{: #fig-ext title="ECT Extension Namespaces"}
No draft MAY use another draft's `ext` namespace without a
normative reference to that draft.
## How Policy Extensions Work {#policy-ext}
Each companion draft defines `constraints` fields on
ACP-DAG-HITL DAG nodes:
| Draft | Constraint fields |
|-------|------------------|
| ATD | `atd.checkpoint_policy`, `atd.circuit_threshold` |
| HITL | (uses ACP-DAG-HITL HITL rule fields directly) |
| AEPB | `aepb.allowed_protocols`, `aepb.max_translation_hops` |
| APAE | `apae.min_trust`, `apae.min_confidence`, `apae.assurance_profile` |
{: #fig-constraints title="ACP-DAG-HITL Node Constraint Extensions"}
# Assurance as an Orthogonal Axis {#assurance}
The entire semantics layer operates identically at all ECT
assurance levels. The DAG structure, HITL processing, trust
scoring, and protocol translation are the same whether the ECT
is unsigned JSON (L1) or a ledger-committed signed JWT (L3).
What changes across levels is the security envelope (see
{{fig-levels}}). A deployment MAY use different levels for
different workflows. Internal dev pipelines might use L1;
cross-org integrations L2; regulated clinical workflows L3.
Implementations MUST ensure consistency across layers: an L3
evidence configuration provides no additional assurance if the
policy layer accepts unsigned tokens.
# Protocol Agnosticism {#agnosticism}
The ecosystem layer sits above any A2A communication protocol.
Agents communicate via their native protocol (A2A, MCP, SLIM,
uACP, etc.) while the `Execution-Context` HTTP header
{{I-D.nennemann-wimse-ect}} carries ECTs alongside protocol
messages.
When two agents speak different protocols, a translation gateway
(defined by AEPB) converts between protocols while preserving
ECT DAG continuity. The translation hop is itself an ECT node,
so the cross-protocol path is one auditable DAG.
# Relationship to Existing Standards {#standards}
The ecosystem builds on existing IETF and industry standards.
It does not replace any of them.
| Standard | Scope | Relationship to AEM |
|----------|-------|---------------------|
| WIMSE (draft-ietf-wimse-arch) | Workload identity and security context propagation | Identity Layer; AEM assumes WIMSE for agent credentials and context propagation. |
| ECT (I-D.nennemann-wimse-ect) | JWT-based execution evidence; DAG linkage via `par` | Evidence Layer; every significant action in the ecosystem produces an ECT. |
| ACP-DAG-HITL (I-D.nennemann-agent-dag-hitl-safety) | Delegation DAG policy; HITL trigger rules | Policy Layer; ATD/HITL/AEPB/APAE extend `constraints` fields, not replace the policy language. |
| OAuth 2.0 / RAR (RFC9396) | Authorization for API access | Identity Layer; operators and agents authenticate to HITL endpoints and capability documents via OAuth. |
| RATS (RFC9334) | Remote attestation for verifying evidence freshness | Informative to APAE Regulated profile; behavior verification attestations are RATS-compatible. |
| SPIFFE/SPIRE | Workload identity URI scheme (`spiffe://`) | Identity Layer; agent identities in ECT `sub` and ACP-DAG-HITL node `agent` fields use SPIFFE URIs by convention. |
{: #fig-standards title="Relationship to Existing Standards"}
## Working Group Targets
| Companion Draft | Suggested WG | Rationale |
|----------------|-------------|-----------|
| AEM (this document) | NMOP | Informational reference model for network operations automation. |
| ATD | NMOP | Execution semantics and error recovery for network agent workflows. |
| HITL | NMOP or OPS | Human override for autonomous network management. |
| AEPB | DISPATCH or ART | Protocol binding and interoperability layer; dispatch to appropriate WG. |
| APAE | RATS or Security Dispatch | Attestation-based trust and assurance profiles for agents. |
{: #fig-wgs title="Suggested Working Group Targets"}
# Companion Draft Summary {#companions}
| Draft | Abbrev | Concern | Gaps Addressed | Normative/Informative |
|-------|--------|---------|----------------|----------------------|
| Agent Task DAG | ATD | Execution, checkpoints, rollback, circuit breakers | #1 Resource Mgmt, #3 Error Recovery | Normative |
| Human-in-the-Loop | HITL | Override, approval, escalation, explainability | #7 Human Override, #11 Explainability | Normative |
| Protocol Binding | AEPB | Interop, translation, lifecycle | #4 Cross-Protocol, #5 Lifecycle | Normative |
| Assurance Profiles | APAE | Trust, verification, provenance, dual-regime | #2 Behavior Verification, #8 Cross-Domain, #9 Dynamic Trust, #12 Provenance | Informative/Normative |
{: #fig-companions title="Companion Draft Family"}
Together with ECT (evidence) and ACP-DAG-HITL (policy), these
six documents cover all 3 critical and 6 high-severity gaps
identified in the IETF AI/agent draft landscape analysis.
# Implementation Guidance {#implementation}
## Choosing an Assurance Level
Operators select the assurance level based on deployment context:
Relaxed (L1):
: Appropriate for internal development, testing, and
observability pipelines. No cryptographic overhead.
Operators SHOULD NOT use L1 where ECT records could be
relied upon as evidence in disputes.
Standard (L2):
: Appropriate for production cross-organization deployments.
Signed ECTs provide non-repudiation. RECOMMENDED as the
default for any deployment where agents cross trust domains.
Regulated (L3):
: Required for deployments subject to regulatory audit
requirements (healthcare, finance, critical infrastructure).
ECTs are committed to an append-only audit ledger.
Operators MUST use L3 when a regulatory framework mandates
tamper-evident audit trails.
## Minimum Viable Implementation
An implementation is AEM-compliant if it satisfies:
1. **Evidence**: Emits ECTs for all consequential actions.
MAY use L1 initially.
2. **Policy**: Evaluates ACP-DAG-HITL node constraints before
delegating tasks.
3. **Checkpoints**: Implements ATD §4 (checkpoints before
consequential actions). MUST declare `atd.reversible`.
4. **HITL endpoint**: Implements HITL `/.well-known/hitl/override`
and responds within 1 second.
5. **Capability document**: Serves AEPB `/.well-known/aepb` so
peers can discover protocol support.
The following are OPTIONAL at L1 but REQUIRED at L2+:
- Cryptographic signing of ECTs.
- APAE trust scoring.
- Behavior verification.
The following are REQUIRED only at L3 (Regulated profile):
- Audit ledger commitment.
- Continuous behavior verification.
- Provenance claims on data-transforming ECT nodes.
## Upgrade Path
Upgrading from L1 to L2:
: Add a signing key (WIMSE WIT or X.509). Update ECT emission
to sign tokens. Update all agents to verify signatures.
No protocol changes needed; ECT format is compatible.
Upgrading from L2 to L3:
: Configure an audit ledger endpoint. Update ECT emission to
commit each ECT. Enable APAE continuous behavior
verification. Enable provenance claims.
Operators MUST NOT downgrade assurance level during an active
workflow.
# Security Considerations
## Threat Model
The AEM threat model covers the following adversary classes:
**Compromised Agent**: An agent that emits false ECTs, fabricates
errors, or attempts unauthorized rollbacks. Mitigated by ECT
signature verification (L2+) and ACP-DAG-HITL policy validation.
**Rogue Operator**: A human who issues unauthorized overrides.
Mitigated by HITL authentication requirements (signed JWTs,
mutual TLS) and multi-operator approval for Level 4 TAKEOVER.
**Translation Gateway Attack**: A malicious or compromised
gateway that alters message content in transit. Mitigated by
ECT `inp_hash`/`out_hash` integrity checks; receivers MUST
detect hash mismatches.
**Trust Score Manipulation**: An agent accumulates high trust
through benign behavior, then executes a malicious action.
Mitigated by APAE double-penalty for `policy_violation` events
and anomaly detection.
**Downgrade Attack**: An attacker forces use of L1 ECTs where
L2+ is required. Mitigated by explicit assurance level checks
in ACP-DAG-HITL constraints (`apae.assurance_profile` field).
## Layer Consistency Requirement
Implementations MUST configure the semantics, evidence, and
policy layers consistently. Specifically:
- An L3 evidence deployment MUST NOT accept L1 ECTs as proof
of action in audit or policy decisions.
- A Regulated assurance profile MUST be paired with L3 ECTs.
- HITL Level 2+ (approval required) MUST be authenticated.
## Translation Gateway Supply Chain
Translation gateways are privileged intermediaries: they have
access to plaintext message content and can inject ECT nodes.
Operators MUST:
- Authenticate gateways using the same identity mechanisms as
agents (WIMSE/SPIFFE).
- Audit gateway ECT nodes at L2+ for tamper detection.
- Limit `aepb.max_translation_hops` to prevent unbounded
delegation chains through untrusted gateways.
# IANA Considerations
## AEM Ecosystem Extension Registry
This document requests the creation of the "AEM Ecosystem
Extension Registry" under IANA. This registry collects:
1. **ECT Extension Namespaces**: Companion draft `ext` claim
prefixes (see {{fig-ext}}).
2. **ACP-DAG-HITL Constraint Field Namespaces**: Companion draft
`constraints` field prefixes (see {{fig-constraints}}).
3. **ECT `exec_act` Values**: All `exec_act` strings registered
by companion drafts (see each companion's IANA section).
Registration policy: Specification Required.
Initial entries: as defined in {{fig-ext}}, {{fig-constraints}},
and the companion draft `exec_act` registrations.
--- back
# Acknowledgments
{:numbered="false"}
This architecture 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
working group targets in {{fig-wgs}} reflect the current IETF
AI/agent draft landscape analysis.

397
workspace/drafts/new-drafts/draft-aerr-agent-error-recovery-rollback-00.md Normal file
View File

@@ -0,0 +1,397 @@
---
title: "Agent Error Recovery and Rollback (AERR)"
abbrev: "AERR"
category: std
docname: draft-aerr-agent-error-recovery-rollback-00
submissiontype: IETF
number:
date:
v: 3
area: "OPS"
workgroup: "NMOP"
keyword:
- error recovery
- rollback
- circuit breaker
- agentic workflows
- execution context
author:
-
fullname: Generated by IETF Draft Analyzer
organization: Independent
email: placeholder@example.com
normative:
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/
informative:
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/
--- abstract
This document defines the Agent Error Recovery and Rollback (AERR)
protocol, a standard for handling errors, cascading failures, and
rollback in multi-agent systems. AERR defines three mechanisms:
state checkpoints recorded as Execution Context Token (ECT) DAG
nodes, a circuit breaker pattern to contain cascading failures,
and a rollback protocol that walks the ECT DAG backwards to revert
agent actions to a known-good state. By building on ECT, AERR
inherits cryptographic audit trails, assurance levels, and DAG
validation without inventing parallel infrastructure.
--- middle
# Introduction
The IETF AI/agent landscape includes 60 drafts on autonomous
network operations but none that standardize error recovery. When
an autonomous agent misconfigures a router, allocates resources
incorrectly, or triggers a cascade of failures across a multi-agent
system, there is no standard mechanism for detecting the failure,
containing its blast radius, or reverting to a safe state.
AERR borrows proven patterns from distributed systems -- checkpoints
from database transactions, circuit breakers from microservice
architectures, rollback from version control -- and adapts them for
AI agent workflows. Rather than inventing its own audit and
tracing layer, AERR records all checkpoints, errors, and rollbacks
as ECT DAG nodes {{I-D.nennemann-wimse-ect}}, giving every
recovery action a cryptographic proof chain.
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.
# Conventions and Definitions
{::boilerplate bcp14-tagged}
Checkpoint:
: An ECT recording an agent's state hash before a consequential
action, providing a restore point for rollback.
Circuit Breaker:
: A mechanism that stops an agent from propagating requests to a
failing downstream agent, preventing cascading failures.
Rollback:
: The process of reverting an agent's actions and state to a
previously recorded checkpoint, walking the ECT DAG backwards.
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.
# Problem Statement
Consider a network operations scenario: Agent A instructs Agent B
to update firewall rules, which causes Agent C's traffic monitoring
to fail, which causes Agent D to misclassify traffic. Today each
agent handles errors independently. There is no standard way for
Agent D to signal that the root cause is upstream, for the cascade
to be halted, or for the chain of actions to be rolled back.
The ECT DAG {{I-D.nennemann-wimse-ect}} already records causal
ordering of agent actions via `par` references. AERR adds
checkpoint semantics, error propagation, and rollback operations
on top of this existing structure.
# Checkpoint Mechanism {#checkpoints}
An AERR-compliant agent MUST create a checkpoint ECT before any
action it classifies as consequential. An action is consequential
if it modifies external state (e.g., network config, database
records, API calls with side effects).
## Checkpoint as ECT
A checkpoint is an ECT with:
- `exec_act`: `"aerr:checkpoint"`
- `par`: the `jti` of the preceding task ECT in the workflow
- `out_hash`: SHA-256 hash of the agent's state snapshot at
checkpoint time (for rollback integrity verification)
The `ext` claim carries AERR-specific metadata:
~~~json
{
"ext": {
"aerr.action_type": "config_update",
"aerr.target": "router-07.example.com",
"aerr.reversible": true,
"aerr.rollback_uri": "https://agent-b.example.com/aerr/rollback",
"aerr.ttl": 86400
}
}
~~~
{: #fig-checkpoint title="Checkpoint ECT Extension Claims"}
The `aerr.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}}.
Agents MAY create hierarchical checkpoints using the ECT DAG: a
parent checkpoint ECT with `par` references to multiple child
checkpoint ECTs. Rolling back the parent rolls back all children.
## Checkpoint Storage
Checkpoint ECTs MUST be stored for at least the duration specified
by `aerr.ttl`. At L3 {{I-D.nennemann-wimse-ect}}, checkpoints
are automatically preserved in the audit ledger. At L1 and L2,
agents MUST store checkpoints in durable local storage that
survives agent restarts.
# Error Signaling {#error-signals}
When an agent detects an error, it MUST produce an error ECT and
propagate it to affected agents in the DAG.
## Error ECT
An error signal is an ECT with:
- `exec_act`: `"aerr:error"`
- `par`: the `jti` of the checkpoint ECT associated with the
failing action
The `ext` claim carries error details:
~~~json
{
"ext": {
"aerr.severity": "critical",
"aerr.error_type": "action_failed",
"aerr.description": "BGP session did not establish",
"aerr.checkpoint_id": "550e8400-e29b-41d4-a716-446655440001",
"aerr.upstream_errors": []
}
}
~~~
{: #fig-error title="Error ECT Extension Claims"}
Severity levels: `info`, `warning`, `error`, `critical`.
Error types: `action_failed`, `timeout`, `constraint_violation`,
`resource_exhausted`, `upstream_cascade`, `unknown`.
## Error Propagation via DAG
When an agent receives an error ECT caused by an action it
initiated, it MUST either:
(a) Attempt automatic rollback of its checkpoint ({{rollback}}), or
(b) Escalate to its operator if the action was irreversible.
The `aerr.upstream_errors` array allows agents to chain error
context by referencing `jti` values of predecessor error ECTs,
building a causal trace from symptom to root cause through the
DAG.
## HITL Escalation
When an error requires human intervention, the error ECT SHOULD
trigger a HITL rule per {{I-D.nennemann-agent-dag-hitl-safety}}.
Example policy:
~~~json
{
"hitl": {
"rules": [{
"id": "r-critical-error",
"trigger": {
"kind": "keyword_match",
"op": "eq",
"value": "critical",
"input_ref": "ext.aerr.severity"
},
"required_role": "operator:oncall",
"action": "escalate",
"allow_override": true,
"override_action": "continue"
}]
}
}
~~~
{: #fig-hitl-error title="HITL Policy for Critical Errors"}
# Circuit Breaker Pattern {#circuit-breaker}
Each agent MUST implement a circuit breaker for every downstream
agent it communicates with.
## States
CLOSED (normal):
: Requests flow through. The agent tracks the error rate over a
sliding window (default: 60 seconds).
OPEN (failure detected):
: When the error rate exceeds a threshold (default: 50% over the
window), the breaker opens. All requests to the downstream
agent are immediately rejected with `aerr.error_type`:
`circuit_open`. The agent MUST produce an error ECT and emit
it to upstream peers.
HALF-OPEN (recovery probe):
: After a cooldown period (default: 30 seconds), the breaker
allows a single probe request. If it succeeds, the breaker
returns to CLOSED. If it fails, it returns to OPEN with doubled
cooldown (exponential backoff, max 300 seconds).
## State Change ECTs
Each circuit breaker state change MUST produce an ECT:
- `exec_act`: `"aerr:circuit_open"`, `"aerr:circuit_half_open"`,
or `"aerr:circuit_closed"`
- `par`: the `jti` of the error ECT that triggered the transition
This records the health topology of the agent network in the ECT
DAG, queryable from the audit ledger at L3.
## Observability
Agents MUST expose circuit breaker state at:
~~~
GET /aerr/circuits
~~~
Response:
~~~json
{
"circuits": [{
"downstream_agent": "spiffe://example.com/agent/router-mgr",
"state": "open",
"error_rate": 0.75,
"last_failure_ect": "550e8400-e29b-41d4-a716-446655440099",
"cooldown_remaining_s": 22
}]
}
~~~
{: #fig-circuits title="Circuit Breaker Status"}
# Rollback Protocol {#rollback}
## Rollback Request
A rollback is initiated by sending an HTTP POST to the target
agent's rollback endpoint:
~~~
POST /aerr/rollback HTTP/1.1
Content-Type: application/json
Execution-Context: <rollback-request-ECT>
{
"rollback_id": "urn:uuid:...",
"checkpoint_id": "550e8400-e29b-41d4-a716-446655440001",
"reason": "Upstream action caused cascading failure",
"cascade": true
}
~~~
{: #fig-rollback-req title="Rollback Request"}
The request MUST include an ECT in the Execution-Context header
with `exec_act`: `"aerr:rollback_request"` and `par` referencing
the error ECT that motivated the rollback.
When `cascade` is `true`, the receiving agent MUST also initiate
rollback of any downstream checkpoints created as a consequence
of the checkpointed action. The ECT DAG's `par` chain identifies
these downstream actions.
## Rollback Response
The agent produces a rollback result ECT with:
- `exec_act`: `"aerr:rollback_complete"` (or `"aerr:rollback_escalated"`)
- `par`: the `jti` of the rollback request ECT
- `out_hash`: SHA-256 hash of the agent's state after rollback
~~~json
{
"ext": {
"aerr.rollback_id": "urn:uuid:...",
"aerr.status": "completed",
"aerr.state_hash_before": "sha256:...",
"aerr.state_hash_after": "sha256:...",
"aerr.cascaded": [
{"agent": "spiffe://example.com/agent/monitor", "status": "completed"},
{"agent": "spiffe://example.com/agent/classify", "status": "escalated"}
]
}
}
~~~
{: #fig-rollback-resp title="Rollback Result ECT"}
Status values: `completed`, `partial`, `escalated`, `failed`.
`escalated` means the action was irreversible and a human operator
has been notified via HITL. `partial` means some but not all
downstream rollbacks succeeded.
## Idempotency
Agents MUST implement idempotent rollback: receiving the same
`rollback_id` twice MUST return the same result without
re-executing the rollback.
# Security Considerations
Rollback requests are sensitive operations. Agents MUST
authenticate rollback requests via the ECT signature chain -- only
agents whose ECTs appear in the same workflow DAG (identified by
`wid`) SHOULD be authorized to request rollback.
Checkpoint ECTs contain `out_hash` of agent state but not the
state itself. Agents MUST encrypt stored state snapshots at rest.
Circuit breaker status exposes system health topology. The
`/aerr/circuits` endpoint SHOULD be access-controlled.
Malicious agents could emit false error ECTs to trigger rollbacks.
Agents SHOULD verify that error ECTs reference valid checkpoint
`jti` values from their own workflow DAG before initiating
rollback. At L2 and L3, ECT signatures prevent forgery.
# IANA Considerations
This document requests the following IANA registrations:
1. An "AERR Error Type" registry under Specification Required
policy. Initial entries: `action_failed`, `timeout`,
`constraint_violation`, `resource_exhausted`,
`upstream_cascade`, `circuit_open`, `unknown`.
2. Registration of `exec_act` values `aerr:checkpoint`,
`aerr:error`, `aerr:rollback_request`, `aerr:rollback_complete`,
`aerr:circuit_open`, `aerr:circuit_half_open`,
`aerr:circuit_closed` in a future ECT action type registry.
--- back
# Acknowledgments
{:numbered="false"}
This document 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.

309
workspace/drafts/new-drafts/draft-aerr-agent-error-recovery-rollback-00.txt Normal file
View File

@@ -0,0 +1,309 @@
Internet-Draft AI/Agent WG
Intended status: Standards Track March 2026
Expires: September 15, 2026
Agent Error Recovery and Rollback (AERR)
draft-aerr-agent-error-recovery-rollback-00
Abstract
This document defines the Agent Error Recovery and Rollback
(AERR) protocol, a lightweight standard for handling errors,
cascading failures, and rollback in multi-agent systems.
Autonomous AI agents increasingly make unsupervised decisions,
yet no standard exists for how agents checkpoint state, signal
errors to peers, contain cascading failures, or roll back
autonomous decisions gone wrong. AERR defines three mechanisms:
state checkpoints that agents create before consequential
actions, a circuit breaker pattern to contain cascading failures
across agent networks, and a rollback protocol for reverting
agent actions to a known-good state. The protocol is transport-
agnostic and builds on JSON and standard HTTP semantics.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document is intended to have Standards Track status.
Distribution of this memo is unlimited.
Table of Contents
1. Introduction
2. Terminology
3. Problem Statement
4. Checkpoint Mechanism
5. Error Signaling
6. Circuit Breaker Pattern
7. Rollback Protocol
8. Security Considerations
9. IANA Considerations
1. Introduction
The IETF AI/agent landscape includes 60 drafts on autonomous
network operations but none that standardize error recovery.
When an autonomous agent misconfigures a router, allocates
resources incorrectly, or triggers an unintended cascade of
actions across a multi-agent system, there is currently no
standard mechanism for detecting the failure, containing its
blast radius, or reverting to a safe state.
AERR borrows proven patterns from distributed systems:
checkpoints from database transactions, circuit breakers from
microservice architectures, and rollback from version control.
It adapts these patterns to the specific needs of AI agents,
where actions may be partially reversible and where the agent
that caused the error may not be the best one to fix it.
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.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119 [RFC2119].
Checkpoint: A snapshot of an agent's state and the external
effects of its actions at a point in time, sufficient to
restore the system to that state.
Circuit Breaker: A mechanism that stops an agent from
propagating requests to a failing downstream agent, preventing
cascading failures.
Rollback: The process of reverting an agent's actions and state
to a previously recorded checkpoint.
Blast Radius: The set of agents and systems affected by a
single agent's failure.
3. Problem Statement
Consider a network operations scenario: Agent A instructs
Agent B to update firewall rules, which causes Agent C's
traffic monitoring to fail, which causes Agent D to
misclassify traffic patterns. Today each agent handles errors
independently with no coordination. There is no standard way
for Agent D to signal that the root cause is upstream, for the
cascade to be halted, or for the chain of actions to be rolled
back.
The only existing draft that partially addresses this space
(draft-yue-anima-agent-recovery-networks) focuses on mobile
network fault recovery and does not provide general-purpose
error recovery primitives usable across agent types.
4. Checkpoint Mechanism
An AERR-compliant agent MUST create a checkpoint before any
action it classifies as "consequential." An action is
consequential if it modifies external state (e.g., network
config, database records, API calls with side effects).
A checkpoint is a JSON object:
{
"checkpoint_id": "urn:uuid:...",
"agent_id": "urn:uuid:...",
"timestamp": "2026-03-01T12:00:00Z",
"action": {
"type": "config_update",
"target": "router-07.example.com",
"description": "Update BGP peer config"
},
"reversible": true,
"rollback_procedure": {
"method": "POST",
"uri": "https://agent-b.example.com/aerr/rollback",
"payload_ref": "urn:uuid:...prior-config-snapshot"
},
"state_hash": "sha256:abcdef...",
"ttl": 86400
}
The "reversible" field MUST be present. If false, the agent
declares that this action cannot be automatically undone and
rollback requests for this checkpoint MUST be escalated to a
human operator.
The "state_hash" provides integrity verification: the agent
hashes its relevant state at checkpoint time so that rollback
can verify it is restoring to an authentic prior state.
Checkpoints MUST be stored for at least the duration specified
by "ttl" (seconds). Agents SHOULD store checkpoints in durable
storage that survives agent restarts.
Agents MAY create hierarchical checkpoints where a parent
checkpoint groups multiple child checkpoints from a multi-step
operation. Rolling back the parent rolls back all children.
5. Error Signaling
When an agent detects an error, it MUST emit an AERR error
signal to all agents in the current action chain. The error
signal is an HTTP POST to each peer's AERR endpoint:
POST /aerr/error HTTP/1.1
Content-Type: application/json
{
"error_id": "urn:uuid:...",
"source_agent": "urn:uuid:...",
"severity": "critical",
"checkpoint_id": "urn:uuid:...",
"error_type": "action_failed",
"description": "BGP session did not establish after config update",
"timestamp": "2026-03-01T12:05:00Z",
"upstream_errors": []
}
Severity levels: "info", "warning", "error", "critical".
Error types: "action_failed", "timeout", "constraint_violation",
"resource_exhausted", "upstream_cascade", "unknown".
When an agent receives an error signal caused by an action it
initiated, it MUST either:
(a) Attempt automatic rollback of its checkpoint, or
(b) Escalate to its operator if the action was irreversible.
The "upstream_errors" array allows agents to chain error
context, building a causal trace from the symptom back to the
root cause.
6. Circuit Breaker Pattern
Each agent MUST implement a circuit breaker for every downstream
agent it communicates with. The circuit breaker has three
states:
CLOSED (normal operation): Requests flow through. The agent
tracks the error rate over a sliding window (default: 60s).
OPEN (failure detected): When the error rate exceeds a
threshold (default: 50% over the window), the circuit breaker
opens. All requests to the downstream agent are immediately
rejected with error_type "circuit_open". The agent MUST emit
an error signal to upstream peers.
HALF-OPEN (recovery probe): After a cooldown period (default:
30s), the circuit breaker allows a single probe request. If it
succeeds, the breaker returns to CLOSED. If it fails, it
returns to OPEN with a doubled cooldown (exponential backoff,
max 300s).
Agents MUST expose circuit breaker state at:
GET /aerr/circuits
Response:
{
"circuits": [
{
"downstream_agent": "urn:uuid:...",
"state": "open",
"error_rate": 0.75,
"last_failure": "2026-03-01T12:05:00Z",
"cooldown_remaining_s": 22
}
]
}
This enables monitoring systems and upstream agents to
understand the health topology of the agent network.
7. Rollback Protocol
A rollback is initiated by sending an HTTP POST to the target
agent's rollback endpoint:
POST /aerr/rollback HTTP/1.1
Content-Type: application/json
{
"rollback_id": "urn:uuid:...",
"checkpoint_id": "urn:uuid:...",
"reason": "Upstream action caused cascading failure",
"initiator": "urn:uuid:...",
"cascade": true
}
When "cascade" is true, the receiving agent MUST also initiate
rollback of any downstream checkpoints that were created as a
consequence of the checkpointed action. This enables a single
rollback request to unwind an entire chain of agent actions.
The agent MUST respond with a rollback result:
{
"rollback_id": "urn:uuid:...",
"status": "completed",
"checkpoint_id": "urn:uuid:...",
"state_hash_before": "sha256:...",
"state_hash_after": "sha256:...",
"cascaded_rollbacks": [
{"agent_id": "urn:uuid:...", "status": "completed"},
{"agent_id": "urn:uuid:...", "status": "escalated"}
]
}
Rollback status values: "completed", "partial", "escalated",
"failed".
"escalated" means the action was irreversible and a human
operator has been notified. "partial" means some but not all
downstream rollbacks succeeded.
Agents MUST implement idempotent rollback: receiving the same
rollback_id twice MUST return the same result without re-
executing the rollback.
8. Security Considerations
Rollback requests are sensitive operations. Agents MUST
authenticate rollback requests using mutual TLS or signed JWTs.
Only agents in the same action chain (identified by checkpoint
lineage) SHOULD be authorized to request rollback.
Checkpoint data may contain sensitive system state. Agents
MUST encrypt stored checkpoints at rest and MUST NOT include
checkpoint contents in error signals.
Circuit breaker state is observable information about system
health. The /aerr/circuits endpoint SHOULD be access-
controlled to prevent adversaries from mapping system topology.
Malicious agents could send false error signals to trigger
unnecessary rollbacks. Agents SHOULD verify that error signals
reference valid checkpoint IDs from their own action chains
before initiating rollback.
9. IANA Considerations
This document requests IANA establish the following:
1. An "AERR Error Type" registry under Specification Required
policy. Initial entries: "action_failed", "timeout",
"constraint_violation", "resource_exhausted",
"upstream_cascade", "unknown".
2. An "AERR Severity Level" registry under Specification
Required policy. Initial entries: "info", "warning",
"error", "critical".
3. Well-known URI registrations for "aerr/error",
"aerr/rollback", and "aerr/circuits" per RFC 8615.
Author's Address
Generated by IETF Draft Analyzer
2026-03-01

386
workspace/drafts/new-drafts/draft-b-atd-agent-task-dag-00.md Normal file
View File

@@ -0,0 +1,386 @@
---
title: "Agent Task DAG (ATD): Execution Model, Checkpoints, and Recovery"
abbrev: "ATD"
category: std
docname: draft-atd-agent-task-dag-00
submissiontype: IETF
number:
date:
v: 3
area: "OPS"
workgroup: "NMOP"
keyword:
- agent DAG
- checkpoint
- rollback
- error recovery
- circuit breaker
author:
-
fullname: TBD
organization: Independent
email: placeholder@example.com
normative:
RFC2119:
RFC8174:
RFC8446:
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:
--- abstract
This document defines the Agent Task DAG (ATD) specification:
execution semantics, checkpoints, error signaling, circuit
breakers, and rollback for agent workflows. ATD does not define a
new DAG or token format. It defines when agents MUST emit ECT
nodes, what those nodes mean, and how to recover when things go
wrong. Checkpoints, errors, and rollback results are ECT nodes
with specific `exec_act` values and `ext` claims. Rollback walks
the ECT DAG backwards. Circuit breakers contain cascading
failures. Resource hints enable scheduling. The protocol is
transport-agnostic and builds on ECT for evidence and ACP-DAG-HITL
for policy.
--- middle
# Introduction
Autonomous agents increasingly make unsupervised decisions, yet no
standard exists for how agents checkpoint state, signal errors to
peers, contain cascading failures, or roll back decisions gone
wrong.
ATD borrows proven patterns from distributed systems: checkpoints
from database transactions, circuit breakers from microservice
architectures, and rollback from version control. It adapts these
to agent workflows where actions may be partially reversible and
where the agent that caused the error may not be the best one to
fix it.
ATD does not define a new DAG format. The ECT DAG
{{I-D.nennemann-wimse-ect}} IS the execution graph. ATD defines
the semantics of specific node types within that graph.
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.
# Conventions and Definitions
{::boilerplate bcp14-tagged}
Checkpoint:
: An ECT node recording agent state before a consequential action,
sufficient to restore the system to that state.
Circuit Breaker:
: A mechanism that stops an agent from propagating requests to a
failing downstream agent, preventing cascading failures.
Rollback:
: The process of reverting an agent's actions and state to a
previously recorded checkpoint.
Blast Radius:
: The set of agents and systems affected by a single failure.
# Node States {#node-states}
Each task node in the ECT DAG has an implicit state derived from
subsequent ECT nodes:
- **pending**: A delegation node exists in ACP-DAG-HITL but no
corresponding ECT has been emitted.
- **running**: An ECT with `exec_act` matching the task type has
been emitted but no completion or error ECT follows.
- **done**: A completion ECT (or the next `par`-linked ECT) exists.
- **failed**: An `atd:error` ECT references this node.
- **rolled_back**: An `atd:rollback_result` ECT references this
node's checkpoint.
# Checkpoint Mechanism {#checkpoints}
An ATD-compliant agent MUST create a checkpoint before any action
it classifies as consequential. An action is consequential if it
modifies external state (network config, database records, API
calls with side effects).
A checkpoint is an ECT with:
- `exec_act`: `"atd:checkpoint"`
- `par`: the ECT of the action being checkpointed
~~~json
{
"jti": "ckpt-uuid",
"exec_act": "atd:checkpoint",
"par": ["action-ect-uuid"],
"out_hash": "sha256-of-agent-state-snapshot",
"ext": {
"atd.reversible": true,
"atd.rollback_uri": "https://agent-b.example.com/atd/rollback",
"atd.target": "router-07.example.com",
"atd.description": "Update BGP peer config",
"atd.ttl": 86400
}
}
~~~
{: #fig-checkpoint title="Checkpoint ECT"}
The `atd.reversible` field MUST be present. If `false`, the agent
declares that this action cannot be automatically undone and
rollback requests MUST be escalated per the ACP-DAG-HITL
`unreachable_human` policy.
The `out_hash` provides integrity verification: the agent hashes
its state at checkpoint time so that rollback can verify it is
restoring to an authentic prior state.
Checkpoints MUST be stored for at least `atd.ttl` seconds. Agents
SHOULD store checkpoints in durable storage that survives restarts.
## Hierarchical Checkpoints
Agents MAY create hierarchical checkpoints where a parent groups
multiple child checkpoints from a multi-step operation. Rolling
back the parent rolls back all children. The parent checkpoint's
`par` array references all child checkpoint `jti` values.
# Error Signaling {#errors}
When an agent detects an error, it MUST emit an error ECT:
- `exec_act`: `"atd:error"`
- `par`: the ECT of the failed action
~~~json
{
"jti": "error-uuid",
"exec_act": "atd:error",
"par": ["failed-action-ect-uuid"],
"ext": {
"atd.severity": "critical",
"atd.error_type": "action_failed",
"atd.description": "BGP session did not establish",
"atd.checkpoint_id": "ckpt-uuid",
"atd.upstream_errors": []
}
}
~~~
{: #fig-error title="Error ECT"}
Severity levels: `info`, `warning`, `error`, `critical`.
Error types: `action_failed`, `timeout`, `constraint_violation`,
`resource_exhausted`, `upstream_cascade`, `unknown`.
When an agent receives an error signal caused by an action it
initiated, it MUST either:
(a) Attempt automatic rollback of its checkpoint, or
(b) Escalate per ACP-DAG-HITL HITL rules if the action was
irreversible.
The `atd.upstream_errors` array allows agents to chain error
context, building a causal trace from symptom to root cause.
## HITL Escalation on Error
Error ECTs MAY trigger ACP-DAG-HITL rules. A deployment can
define HITL rules such as:
~~~json
{
"id": "r-critical-error",
"trigger": {
"kind": "keyword_match",
"op": "eq",
"value": "critical",
"input_ref": "atd.severity"
},
"required_role": "operator:oncall",
"action": "escalate",
"allow_override": true,
"override_action": "continue"
}
~~~
{: #fig-error-hitl title="HITL Rule for Critical Errors"}
# Circuit Breaker Pattern {#circuit-breaker}
Each agent MUST implement a circuit breaker for every downstream
agent it communicates with. The circuit breaker has three states:
CLOSED (normal):
: Requests flow through. The agent tracks the error rate over a
sliding window (default: 60 seconds).
OPEN (failure detected):
: When the error rate exceeds a threshold (default: 50%), the
breaker opens. All requests are immediately rejected. The
agent MUST emit a circuit breaker ECT:
~~~json
{
"exec_act": "atd:circuit_open",
"ext": {
"atd.downstream_agent": "spiffe://example.com/agent/b",
"atd.error_rate": 0.75,
"atd.window_s": 60
}
}
~~~
{: #fig-circuit title="Circuit Breaker ECT"}
HALF-OPEN (recovery probe):
: After a cooldown period (default: 30s), the breaker allows one
probe request. If it succeeds, the breaker returns to CLOSED.
If it fails, it returns to OPEN with doubled cooldown
(exponential backoff, max 300s).
Circuit breaker thresholds can be configured as ACP-DAG-HITL
node constraints:
~~~json
{
"constraints": {
"atd.circuit_threshold": 0.5,
"atd.circuit_window_s": 60
}
}
~~~
{: #fig-circuit-policy title="Circuit Breaker Policy"}
# Rollback Protocol {#rollback}
A rollback is initiated by emitting a rollback request ECT and
sending an HTTP POST to the target agent's rollback endpoint:
~~~
POST /atd/rollback HTTP/1.1
Content-Type: application/json
Execution-Context: <rollback-request-ect>
~~~
- `exec_act`: `"atd:rollback_request"`
- `par`: the checkpoint ECT to roll back to
~~~json
{
"exec_act": "atd:rollback_request",
"par": ["ckpt-uuid"],
"ext": {
"atd.reason": "Upstream action caused cascading failure",
"atd.cascade": true
}
}
~~~
{: #fig-rollback-req title="Rollback Request ECT"}
When `atd.cascade` is `true`, the receiving agent MUST also
initiate rollback of any downstream checkpoints created as a
consequence of the checkpointed action.
The agent MUST respond with a rollback result ECT:
- `exec_act`: `"atd:rollback_result"`
- `par`: the rollback request ECT
~~~json
{
"exec_act": "atd:rollback_result",
"par": ["rollback-request-uuid"],
"out_hash": "sha256-of-restored-state",
"ext": {
"atd.status": "completed",
"atd.checkpoint_id": "ckpt-uuid",
"atd.cascaded": [
{"agent": "spiffe://example.com/agent/c", "status": "completed"},
{"agent": "spiffe://example.com/agent/d", "status": "escalated"}
]
}
}
~~~
{: #fig-rollback-result title="Rollback Result ECT"}
Status values: `completed`, `partial`, `escalated`, `failed`.
`escalated` means the action was irreversible and a human operator
has been notified per ACP-DAG-HITL `unreachable_human` policy.
Agents MUST implement idempotent rollback: receiving the same
rollback request ECT `jti` twice MUST return the same result.
# Resource Hints {#resources}
Agents MAY declare resource requirements as ECT extension claims
or ACP-DAG-HITL node constraints:
~~~json
{
"constraints": {
"atd.resource_cpu": "2",
"atd.resource_memory_mb": 4096,
"atd.resource_timeout_s": 300,
"atd.resource_priority": "high"
}
}
~~~
{: #fig-resources title="Resource Hints as Node Constraints"}
Orchestrators (e.g., Kubernetes schedulers, agent gateways) MAY
use these hints for scheduling and quota enforcement. Resource
hints are advisory; agents MUST NOT depend on them for
correctness.
# Security Considerations
Rollback requests are sensitive operations. Agents MUST
authenticate rollback requests using the ECT identity binding
(L2/L3). Only agents in the same workflow (`wid`) with
checkpoint lineage in the DAG SHOULD be authorized to request
rollback.
Checkpoint data may contain sensitive system state. Agents MUST
encrypt stored checkpoints at rest and MUST NOT include checkpoint
contents in error ECTs.
Circuit breaker state reveals system health topology. The
`atd:circuit_open` ECT is part of the audit trail; access to the
audit ledger SHOULD be controlled.
Malicious agents could send false error ECTs to trigger
unnecessary rollbacks. Agents SHOULD verify that error ECTs
reference valid `par` values within their own workflow DAG.
# IANA Considerations
This document requests registration of the following `exec_act`
values in a future ECT action type registry:
- `atd:checkpoint`
- `atd:error`
- `atd:circuit_open`
- `atd:rollback_request`
- `atd:rollback_result`
--- back
# Acknowledgments
{:numbered="false"}
ATD builds on ECT {{I-D.nennemann-wimse-ect}} for execution
evidence and ACP-DAG-HITL {{I-D.nennemann-agent-dag-hitl-safety}}
for delegation policy. The circuit breaker pattern is adapted
from microservice architecture best practices.

725
workspace/drafts/new-drafts/draft-b-atd-agent-task-dag-01.md Normal file
View File

@@ -0,0 +1,725 @@
---
title: "Agent Task DAG (ATD): Execution Model, Checkpoints, and Recovery"
abbrev: "ATD"
category: std
docname: draft-atd-agent-task-dag-01
submissiontype: IETF
number:
date:
v: 3
area: "OPS"
workgroup: "NMOP"
keyword:
- agent DAG
- checkpoint
- rollback
- error recovery
- circuit breaker
author:
-
fullname: TBD
organization: Independent
email: placeholder@example.com
normative:
RFC2119:
RFC8174:
RFC8446:
RFC9110:
RFC8615:
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:
--- abstract
This document defines the Agent Task DAG (ATD) specification:
execution semantics, checkpoints, error signaling, circuit
breakers, and rollback for agent workflows. ATD does not define a
new DAG or token format. It defines when agents MUST emit ECT
nodes, what those nodes mean, and how to recover when things go
wrong. Checkpoints, errors, and rollback results are ECT nodes
with specific `exec_act` values and `ext` claims. Rollback walks
the ECT DAG backwards. Circuit breakers contain cascading
failures. Resource hints enable scheduling. The protocol is
transport-agnostic and builds on ECT for evidence and ACP-DAG-HITL
for policy.
--- middle
# Introduction
Autonomous agents increasingly make unsupervised decisions, yet no
standard exists for how agents checkpoint state, signal errors to
peers, contain cascading failures, or roll back decisions gone
wrong.
ATD borrows proven patterns from distributed systems: checkpoints
from database transactions, circuit breakers from microservice
architectures, and rollback from version control. It adapts these
to agent workflows where actions may be partially reversible and
where the agent that caused the error may not be the best one to
fix it.
ATD does not define a new DAG format. The ECT DAG
{{I-D.nennemann-wimse-ect}} IS the execution graph. ATD defines
the semantics of specific node types within that graph.
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.
# Conventions and Definitions
{::boilerplate bcp14-tagged}
Checkpoint:
: An ECT node recording agent state before a consequential action,
sufficient to restore the system to that state.
Circuit Breaker:
: A mechanism that stops an agent from propagating requests to a
failing downstream agent, preventing cascading failures.
Rollback:
: The process of reverting an agent's actions and state to a
previously recorded checkpoint.
Blast Radius:
: The set of agents and systems affected by a single failure.
Consequential Action:
: An action that modifies external state (network configuration,
database records, API calls with side effects) such that
reversal requires explicit effort.
# Execution Semantics {#execution}
## Topological Order
Tasks in the ECT DAG MUST execute in topological order: a task
MUST NOT begin execution until all tasks referenced by its ECT
`par` claims are in state `done`.
Two tasks with no common ancestor in the DAG (no shared `par`
lineage) MAY execute concurrently. Orchestrators SHOULD
exploit this parallelism for performance.
Circular dependencies are prohibited. Agents MUST reject
ACP-DAG-HITL delegation DAGs containing cycles.
## Workflow Boundary ECTs
When a workflow begins, the initiating agent MUST emit:
~~~json
{
"exec_act": "atd:workflow_start",
"ext": {
"atd.wf_id": "wf-uuid",
"atd.description": "BGP failover workflow",
"atd.node_count": 5
}
}
~~~
{: #fig-wf-start title="Workflow Start ECT"}
When the workflow reaches a terminal state (all leaf nodes
complete or any node failed with no rollback path), the
orchestrator MUST emit:
~~~json
{
"exec_act": "atd:workflow_complete",
"par": ["wf-start-ect-uuid"],
"ext": {
"atd.wf_id": "wf-uuid",
"atd.terminal_status": "success",
"atd.elapsed_s": 42
}
}
~~~
{: #fig-wf-complete title="Workflow Complete ECT"}
Terminal status values: `success`, `partial`, `failed`,
`rolled_back`, `escalated`.
# Node States {#node-states}
Each task node in the ECT DAG has an implicit state derived from
subsequent ECT nodes:
- **pending**: A delegation node exists in ACP-DAG-HITL but no
corresponding ECT has been emitted.
- **running**: An ECT matching the task type has been emitted
but no completion or error ECT follows.
- **done**: A completion ECT (or the next `par`-linked ECT) exists.
- **failed**: An `atd:error` ECT references this node.
- **rolled_back**: An `atd:rollback_result` ECT references this
node's checkpoint.
- **escalated**: The task failed and a human has been notified
per HITL escalation rules.
# Checkpoint Mechanism {#checkpoints}
## Checkpoint Placement Policy
An ATD-compliant agent MUST create a checkpoint before any action
it classifies as consequential. The following actions are always
consequential and MUST be checkpointed:
1. Any modification to network device configuration.
2. Any write to a shared database or external data store.
3. Any API call with side effects (non-idempotent HTTP methods).
4. Any delegation to another agent that will itself take
consequential actions.
The following SHOULD be checkpointed:
1. Long-running computations (> `atd.resource_timeout_s`).
2. Actions that cannot be verified without external state.
The following are exempt from checkpoint requirements:
1. Read-only queries.
2. Sending notifications with no side effects.
3. Internal state computations with no external observable effect.
## Checkpoint ECT Format
A checkpoint is an ECT with:
- `exec_act`: `"atd:checkpoint"`
- `par`: the ECT of the action being checkpointed
~~~json
{
"jti": "ckpt-uuid",
"exec_act": "atd:checkpoint",
"par": ["action-ect-uuid"],
"out_hash": "sha256-of-agent-state-snapshot",
"ext": {
"atd.reversible": true,
"atd.rollback_uri": "https://agent-b.example.com/.well-known/atd/rollback",
"atd.target": "router-07.example.com",
"atd.description": "Update BGP peer config",
"atd.ttl": 86400
}
}
~~~
{: #fig-checkpoint title="Checkpoint ECT"}
The `atd.reversible` field MUST be present. If `false`, the agent
declares that this action cannot be automatically undone and
rollback requests MUST be escalated per the ACP-DAG-HITL
`unreachable_human` policy.
The `out_hash` provides integrity verification: the agent hashes
its state at checkpoint time so that rollback can verify it is
restoring to an authentic prior state.
Checkpoints MUST be stored for at least `atd.ttl` seconds. Agents
SHOULD store checkpoints in durable storage that survives restarts.
The rollback URI MUST be a well-known URI per {{RFC8615}} at the
path `/.well-known/atd/rollback`.
## Hierarchical Checkpoints
Agents MAY create hierarchical checkpoints where a parent groups
multiple child checkpoints from a multi-step operation. Rolling
back the parent rolls back all children. The parent checkpoint's
`par` array references all child checkpoint `jti` values.
## Checkpoint `exec_act` Table
| `exec_act` value | When emitted | Required `ext` fields |
|-----------------|-------------|----------------------|
| `atd:checkpoint` | Before consequential action | `atd.reversible`, `atd.rollback_uri`, `atd.ttl` |
| `atd:error` | On failure detection | `atd.severity`, `atd.error_type`, `atd.checkpoint_id` |
| `atd:circuit_open` | When error rate exceeds threshold | `atd.downstream_agent`, `atd.error_rate`, `atd.window_s` |
| `atd:circuit_close` | When probe succeeds in HALF-OPEN | `atd.downstream_agent`, `atd.cooldown_s` |
| `atd:rollback_request` | To initiate rollback | `atd.reason`, `atd.cascade` |
| `atd:rollback_result` | Rollback complete or failed | `atd.status`, `atd.checkpoint_id`, `atd.cascaded` |
| `atd:workflow_start` | Workflow begins | `atd.wf_id`, `atd.description` |
| `atd:workflow_complete` | Workflow terminal | `atd.wf_id`, `atd.terminal_status` |
{: #fig-actions title="ATD exec_act Values"}
# Error Signaling {#errors}
When an agent detects an error, it MUST emit an error ECT:
- `exec_act`: `"atd:error"`
- `par`: the ECT of the failed action
~~~json
{
"jti": "error-uuid",
"exec_act": "atd:error",
"par": ["failed-action-ect-uuid"],
"ext": {
"atd.severity": "critical",
"atd.error_type": "action_failed",
"atd.description": "BGP session did not establish",
"atd.checkpoint_id": "ckpt-uuid",
"atd.upstream_errors": []
}
}
~~~
{: #fig-error title="Error ECT"}
Severity levels (in increasing order): `info`, `warning`,
`error`, `critical`.
Error types: `action_failed`, `timeout`, `constraint_violation`,
`resource_exhausted`, `upstream_cascade`, `unknown`.
When an agent receives an error signal caused by an action it
initiated, it MUST either:
(a) Attempt automatic rollback of its checkpoint, or
(b) Escalate per ACP-DAG-HITL HITL rules if the action was
irreversible.
The `atd.upstream_errors` array allows agents to chain error
context, building a causal trace from symptom to root cause.
## HITL Escalation on Error
Error ECTs with severity `critical` SHOULD trigger HITL
escalation. Deployments SHOULD define ACP-DAG-HITL rules such
as:
~~~json
{
"id": "r-critical-error",
"trigger": {
"kind": "keyword_match",
"op": "eq",
"value": "critical",
"input_ref": "atd.severity"
},
"required_role": "operator:oncall",
"action": "escalate",
"allow_override": true,
"override_action": "continue"
}
~~~
{: #fig-error-hitl title="HITL Rule for Critical Errors"}
# Circuit Breaker Pattern {#circuit-breaker}
Each agent MUST implement a circuit breaker for every downstream
agent it communicates with. The circuit breaker has three states:
CLOSED (normal):
: Requests flow through. The agent tracks the error rate over a
sliding window (default: 60 seconds).
OPEN (failure detected):
: When the error rate exceeds a threshold (default: 50%), the
breaker opens. All requests are immediately rejected. The
agent MUST emit a circuit breaker open ECT:
~~~json
{
"exec_act": "atd:circuit_open",
"ext": {
"atd.downstream_agent": "spiffe://example.com/agent/b",
"atd.error_rate": 0.75,
"atd.window_s": 60
}
}
~~~
{: #fig-circuit-open title="Circuit Breaker Open ECT"}
HALF-OPEN (recovery probe):
: After a cooldown period (default: 30s), the breaker allows one
probe request. If it succeeds, the breaker returns to CLOSED
and MUST emit:
~~~json
{
"exec_act": "atd:circuit_close",
"ext": {
"atd.downstream_agent": "spiffe://example.com/agent/b",
"atd.cooldown_s": 30
}
}
~~~
{: #fig-circuit-close title="Circuit Breaker Close ECT"}
If the probe fails, the breaker returns to OPEN with doubled
cooldown (exponential backoff, max 300s).
## Circuit Breaker State Machine
~~~
error_rate > threshold
CLOSED ─────────────────────────► OPEN
▲ │
│ probe success │ cooldown expires
│ ▼
└────────────────────────── HALF-OPEN
probe failure ──► OPEN (cooldown * 2)
~~~
{: #fig-fsm title="Circuit Breaker State Machine"}
## Coordinated Circuit Breaking
When multiple agents share a downstream dependency, each maintains
its own circuit breaker independently. However, agents SHOULD
publish circuit breaker state via their ECT stream so peers can
observe the signal.
If an orchestrator observes N circuit breakers opening for the
same downstream agent within a short window, it SHOULD initiate
a HITL escalation rather than allowing N parallel recovery probes.
## Circuit Breaker Policy Configuration
Circuit breaker thresholds can be configured as ACP-DAG-HITL
node constraints:
~~~json
{
"constraints": {
"atd.circuit_threshold": 0.5,
"atd.circuit_window_s": 60
}
}
~~~
{: #fig-circuit-policy title="Circuit Breaker Policy"}
# Rollback Protocol {#rollback}
## Basic Rollback
A rollback is initiated by emitting a rollback request ECT and
sending an HTTP POST to the target agent's rollback endpoint:
~~~
POST /.well-known/atd/rollback HTTP/1.1
Content-Type: application/json
Execution-Context: <rollback-request-ect>
~~~
- `exec_act`: `"atd:rollback_request"`
- `par`: the checkpoint ECT to roll back to
~~~json
{
"exec_act": "atd:rollback_request",
"par": ["ckpt-uuid"],
"ext": {
"atd.reason": "Upstream action caused cascading failure",
"atd.cascade": true
}
}
~~~
{: #fig-rollback-req title="Rollback Request ECT"}
When `atd.cascade` is `true`, the receiving agent MUST also
initiate rollback of any downstream checkpoints created as a
consequence of the checkpointed action.
The agent MUST respond with a rollback result ECT:
~~~json
{
"exec_act": "atd:rollback_result",
"par": ["rollback-request-uuid"],
"out_hash": "sha256-of-restored-state",
"ext": {
"atd.status": "completed",
"atd.checkpoint_id": "ckpt-uuid",
"atd.cascaded": [
{"agent": "spiffe://example.com/agent/c", "status": "completed"},
{"agent": "spiffe://example.com/agent/d", "status": "escalated"}
]
}
}
~~~
{: #fig-rollback-result title="Rollback Result ECT"}
Status values: `completed`, `partial`, `escalated`, `failed`.
`escalated` means the action was irreversible and a human operator
has been notified per ACP-DAG-HITL `unreachable_human` policy.
## Partial Rollback and Blast Radius Containment
When a failure occurs in the middle of a DAG, it is often
undesirable to roll back the entire workflow. ATD defines
partial rollback as rolling back the failed subgraph while
preserving completed sibling branches.
Partial rollback MUST only proceed if:
1. The checkpoints to be rolled back are in the same workflow
(`atd.wf_id`).
2. No completed sibling task depends on the output of the
failed task (verified by walking the DAG forward from the
checkpoint).
The blast radius is the set of agents holding checkpoints that
are descendants of the failed node. Orchestrators SHOULD
compute blast radius before initiating cascade rollback to
avoid unnecessary disruption.
## Rollback Timeout and Escalation
Rollback requests MUST include a timeout implicitly derived from
the original checkpoint's `atd.ttl`. If rollback is not
completed within `atd.ttl / 2` seconds, the agent MUST:
1. Emit an `atd:error` with `error_type: "timeout"` and
`atd.description` noting rollback timeout.
2. Escalate to HITL per {{hitl-escalation}}.
Agents MUST implement idempotent rollback: receiving the same
rollback request ECT `jti` twice MUST return the same result.
## Rollback Authorization {#rollback-authz}
Only agents within the same workflow (`wid`) with checkpoint
lineage in the DAG SHOULD be authorized to request rollback.
Rollback requests from outside the originating workflow MUST be
rejected with HTTP 403.
# Interaction with HITL {#hitl-escalation}
ATD escalates to HITL in the following scenarios:
1. **Irreversible action failure**: An error ECT with
`atd.reversible: false` on the checkpoint MUST trigger
HITL Level 2 (approval required) per the companion HITL
specification.
2. **Rollback failure**: A rollback result with `atd.status:
"failed"` MUST trigger HITL Level 3 (STOP) on the workflow.
3. **Cascaded rollback of critical nodes**: When `atd.cascade:
true` rollback propagates to a node with `atd.severity:
critical`, HITL SHOULD be triggered at Level 1 (PAUSE)
to allow human review before proceeding.
4. **Circuit breaker permanent open**: If a circuit breaker
re-opens after 3 successive HALF-OPEN probes, HITL Level 2
escalation SHOULD be triggered.
ATD-to-HITL escalation is recorded as an ECT linked to both
the triggering error ECT and the HITL override ECT, preserving
the causal chain in the audit DAG.
# Resource Hints {#resources}
## Resource Claim Format
Agents MAY declare resource requirements as ACP-DAG-HITL node
constraints:
~~~json
{
"constraints": {
"atd.resource_cpu": "2",
"atd.resource_memory_mb": 4096,
"atd.resource_timeout_s": 300,
"atd.resource_priority": "high",
"atd.resource_gpu": "0",
"atd.resource_network_mbps": 100
}
}
~~~
{: #fig-resources title="Resource Hints as Node Constraints"}
## Priority Levels
The `atd.resource_priority` field MUST be one of: `critical`,
`high`, `normal`, `low`. Orchestrators SHOULD map these to
scheduling priority classes (e.g., Kubernetes QoS classes:
`critical` → Guaranteed, `high`/`normal` → Burstable, `low`
→ BestEffort).
## Fair-Share Scheduling
When multiple agents compete for a shared resource pool,
orchestrators SHOULD implement fair-share scheduling:
1. Each active workflow receives an equal base allocation.
2. Unused allocation from `low` priority agents is redistributed
to `high`/`critical` agents within the same scheduling cycle.
3. Starvation prevention: `low` priority agents MUST eventually
be scheduled within a configurable maximum wait (default: 300s).
## Unsatisfiable Resource Hints
Resource hints are advisory; agents MUST NOT depend on them for
correctness. When resource hints cannot be satisfied:
- If `atd.resource_priority` is `critical`: orchestrator SHOULD
pre-empt lower-priority tasks.
- If `critical` tasks still cannot be scheduled within 60s:
emit `atd:error` with `error_type: "resource_exhausted"` and
escalate to HITL.
- All other priorities: proceed with degraded resources; log
a warning via `atd:error` with severity `warning`.
# Optional Declarative Workflow Format {#workflow-format}
To support pre-run planning and tooling, ATD defines an optional
declarative workflow descriptor. This is a planning artifact
only; at runtime it is realized as ECTs per this specification.
~~~json
{
"wf_id": "bgp-failover-v2",
"description": "BGP peer failover with validation",
"nodes": [
{
"id": "n1",
"label": "validate-config",
"reversible": true,
"hitl_required": false,
"resource_hints": {
"priority": "normal",
"timeout_s": 30
}
},
{
"id": "n2",
"label": "update-bgp-peer",
"reversible": true,
"hitl_required": true,
"resource_hints": {
"priority": "critical",
"timeout_s": 120
}
},
{
"id": "n3",
"label": "verify-session",
"reversible": false,
"hitl_required": false,
"resource_hints": {
"priority": "high",
"timeout_s": 60
}
}
],
"edges": [
{"from": "n1", "to": "n2"},
{"from": "n2", "to": "n3"}
]
}
~~~
{: #fig-workflow title="Declarative Workflow Descriptor"}
The workflow descriptor media type is
`application/atd-workflow+json`. Orchestrators MAY store and
version workflow descriptors independently of their ECT runtime
realization.
The `hitl_required` field is a hint to the HITL system that this
node MUST have an approval gate as defined in the companion HITL
specification.
# Security Considerations
## Rollback Authorization
Rollback requests are high-privilege operations. Agents MUST
authenticate rollback requests using the ECT identity binding
(L2/L3). The rollback endpoint MUST require mutual TLS or a
signed JWT from an agent within the same workflow DAG.
Only agents that are ancestors in the ECT DAG of the checkpoint
being rolled back SHOULD be authorized to request that rollback.
## Checkpoint Confidentiality
Checkpoint data may contain sensitive system state (API keys,
session tokens, configuration). Agents MUST:
- Encrypt stored checkpoints at rest.
- Reference checkpoint state via `out_hash` only in ECTs.
- MUST NOT include checkpoint contents in error ECTs.
## False Error Injection
A malicious agent could send false `atd:error` ECTs to trigger
unnecessary rollbacks and disrupt workflows. Mitigation:
- Agents SHOULD verify that error ECTs reference valid `par`
values within their own workflow DAG (`wid` claim).
- Rollback MUST require authentication (see {{rollback-authz}}).
- L2/L3 ECT signing prevents unauthenticated error injection.
## Checkpoint Flooding
An adversary could exhaust checkpoint storage by triggering
many checkpoints. Mitigation:
- Agents SHOULD enforce a maximum checkpoint count per workflow.
- Expired checkpoints (past `atd.ttl`) MUST be purged.
- Checkpoint creation rate SHOULD be rate-limited per calling
workflow.
## Circuit Breaker State Leakage
The `atd:circuit_open` ECT reveals system health topology. The
audit ledger SHOULD enforce access controls: only agents within
the same workflow or authorized operators SHOULD be able to query
circuit breaker history.
# IANA Considerations
This document requests registration of the following values in
the AEM Ecosystem Extension Registry established by
draft-aem-agent-ecosystem-model:
## `exec_act` Values
| Value | Description | Reference |
|-------|-------------|-----------|
| `atd:checkpoint` | State snapshot before consequential action | This document |
| `atd:error` | Error signal with severity and type | This document |
| `atd:circuit_open` | Circuit breaker opened to downstream agent | This document |
| `atd:circuit_close` | Circuit breaker returned to CLOSED state | This document |
| `atd:rollback_request` | Initiate rollback to named checkpoint | This document |
| `atd:rollback_result` | Result of rollback attempt | This document |
| `atd:workflow_start` | Workflow began execution | This document |
| `atd:workflow_complete` | Workflow reached terminal state | This document |
{: #fig-iana-actions title="ATD exec_act Registrations"}
## Well-Known URI
This document requests registration of `atd/rollback` as a
well-known URI suffix per {{RFC8615}}.
## Media Type
This document requests registration of
`application/atd-workflow+json` for the declarative workflow
descriptor format defined in {{workflow-format}}.
--- back
# Acknowledgments
{:numbered="false"}
ATD builds on ECT {{I-D.nennemann-wimse-ect}} for execution
evidence and ACP-DAG-HITL {{I-D.nennemann-agent-dag-hitl-safety}}
for delegation policy. The circuit breaker pattern is adapted
from microservice architecture best practices. The declarative
workflow format is inspired by workflow description languages
(BPEL, BPMN) adapted for lightweight agent coordination.

368
workspace/drafts/new-drafts/draft-c-hitl-human-in-the-loop-00.md Normal file
View File

@@ -0,0 +1,368 @@
---
title: "Human-in-the-Loop (HITL) Primitives for Agent Ecosystems"
abbrev: "HITL"
category: std
docname: draft-hitl-human-in-the-loop-00
submissiontype: IETF
number:
date:
v: 3
area: "OPS"
workgroup: "NMOP"
keyword:
- human override
- HITL
- emergency stop
- agentic safety
author:
-
fullname: TBD
organization: Independent
email: placeholder@example.com
normative:
RFC2119:
RFC8174:
RFC7519:
RFC8446:
RFC8615:
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:
--- abstract
This document defines runtime HITL (Human-in-the-Loop) primitives
for agent ecosystems: four escalating override levels, approval
gates, escalation paths, and explainability hooks. ACP-DAG-HITL
defines WHEN humans must intervene (policy rules and triggers).
This specification defines HOW the intervention actually happens at
the protocol level: the HTTP endpoints, override semantics, agent
compliance requirements, and acknowledgment flows. All overrides
and decisions produce ECT nodes, making human interventions part of
the same auditable DAG as agent actions.
--- middle
# Introduction
The current ratio of autonomous capability drafts to human
oversight drafts in the IETF is roughly 7:1. Agents can act but
humans cannot reliably stop them.
ACP-DAG-HITL {{I-D.nennemann-agent-dag-hitl-safety}} defines the
policy: trigger conditions, required roles, and actions (`pause`,
`escalate`, `abort`). But it deliberately defers the runtime
protocol — how does an operator actually send a stop command? How
does the agent acknowledge it? What happens if the operator is
unreachable?
This specification fills that gap. It is the runtime enforcement
companion to ACP-DAG-HITL, inspired by industrial safety systems:
the e-stop button on factory equipment, the circuit breaker in
electrical systems, and the kill switch in robotics.
HITL is deliberately not a governance framework, policy language,
or accountability protocol. It is a panic button with a
well-defined interface.
# Conventions and Definitions
{::boilerplate bcp14-tagged}
Override:
: A human-initiated command that alters an agent's autonomous
operation, taking precedence over the agent's own decisions.
Operator:
: A human user authorized to issue override commands.
Approval Gate:
: A DAG node that blocks workflow progression until a human
approves or rejects continuation.
# Relationship to ACP-DAG-HITL {#mapping}
ACP-DAG-HITL defines three HITL actions. This specification
maps them to four runtime override levels and extends with
CONSTRAIN (partial restriction):
| ACP-DAG-HITL action | HITL Override Level | Behavior |
|---------------------|---------------------|----------|
| `pause` | Level 1: PAUSE | Suspend autonomous actions, hold state |
| (no equivalent) | Level 2: CONSTRAIN | Restrict to an allowlist of actions |
| `abort` | Level 3: STOP | Cease all actions, enter inert state |
| `escalate` | Level 4: TAKEOVER | Transfer control to human operator |
{: #fig-mapping title="ACP-DAG-HITL to HITL Level Mapping"}
When ACP-DAG-HITL rules trigger, the runtime system uses the
corresponding HITL level to enforce the action.
# Override Levels {#levels}
## Level 1: PAUSE
The agent MUST suspend all autonomous actions and hold current
state. It MUST NOT initiate new actions but MAY complete
in-progress actions if stopping mid-execution would cause harm
(e.g., an in-flight database transaction). The agent resumes
when a RESUME command is received.
## Level 2: CONSTRAIN
The agent MUST restrict its actions to a specified subset. The
override command includes an allowlist of permitted action types.
The agent MUST reject any action not on the allowlist.
## Level 3: STOP
The agent MUST immediately cease all autonomous actions and enter
an inert state. It MUST NOT take any autonomous actions until
explicitly restarted. This is the e-stop.
## Level 4: TAKEOVER
The agent MUST transfer operational control to the human operator.
It enters a pass-through mode where it executes only explicit
operator commands. The agent's sensors and outputs remain
available to the operator as tools.
# Override Protocol {#protocol}
## Override Command
Override commands are sent as HTTP POST to the agent's well-known
endpoint:
~~~
POST /.well-known/hitl/override HTTP/1.1
Content-Type: application/json
Authorization: Bearer <operator-jwt>
Execution-Context: <override-ect>
~~~
The override ECT MUST contain:
- `exec_act`: `"hitl:override"`
- `par`: the most recent ECT from the agent being overridden
(linking the override into the workflow DAG)
~~~json
{
"exec_act": "hitl:override",
"par": ["agent-last-action-ect"],
"ext": {
"hitl.level": 3,
"hitl.reason": "Agent blocking legitimate traffic",
"hitl.operator_id": "user:alice",
"hitl.scope": "*",
"hitl.constraints": null,
"hitl.ttl": null
}
}
~~~
{: #fig-override title="Override ECT"}
Field definitions:
- `hitl.level`: Integer 1-4. MUST be present.
- `hitl.reason`: Human-readable text. MUST be logged.
- `hitl.scope`: `"*"` for all functions, or an array of function
IDs for partial override.
- `hitl.constraints`: For Level 2 only. Array of permitted action
types.
- `hitl.ttl`: Duration in seconds. If set, override auto-expires.
If null, persists until explicitly lifted.
## Acknowledgment
The agent MUST respond with an acknowledgment ECT:
- `exec_act`: `"hitl:ack"`
- `par`: the override ECT
~~~json
{
"exec_act": "hitl:ack",
"par": ["override-ect-uuid"],
"ext": {
"hitl.status": "accepted",
"hitl.prior_state": "autonomous",
"hitl.current_state": "stopped",
"hitl.effective_at": "2026-03-01T12:00:00.123Z"
}
}
~~~
{: #fig-ack title="Acknowledgment ECT"}
The override/ack ECT pair serves as the Decision Record defined
in ACP-DAG-HITL Section 6.5. No separate audit mechanism is
needed.
## Resume and Lift
To resume from PAUSE:
~~~
POST /.well-known/hitl/resume HTTP/1.1
Execution-Context: <resume-ect with exec_act="hitl:resume">
~~~
To lift any override:
~~~
POST /.well-known/hitl/lift HTTP/1.1
Execution-Context: <lift-ect with exec_act="hitl:lift">
~~~
Both produce ECTs linked to the original override ECT via `par`.
# Agent Compliance Requirements {#compliance}
Every HITL-compliant agent MUST:
1. Implement the `/.well-known/hitl/override` endpoint.
2. Process override commands within 1 second of receipt. The
override path MUST be independent of the agent's main
processing loop.
3. Acknowledge every override with an ECT response.
4. An agent MUST NOT respond with "rejected". Overrides are
mandatory. If the agent cannot fully comply, it MUST respond
with status `partial` and describe what it could not do.
5. Expose current override status at:
~~~
GET /.well-known/hitl/status
~~~
~~~json
{
"agent_id": "spiffe://example.com/agent/firewall",
"override_active": true,
"current_level": 3,
"override_ect": "override-ect-uuid",
"since": "2026-03-01T12:00:00Z",
"operator_id": "user:alice"
}
~~~
{: #fig-status title="Override Status Response"}
# Approval Gates {#approval-gates}
An approval gate is a DAG node that blocks workflow progression
until a human approves. Unlike overrides (which interrupt running
agents), approval gates are planned checkpoints in the workflow.
Approval gates are defined as ACP-DAG-HITL nodes with HITL rules:
~~~json
{
"dag": {
"nodes": [
{
"id": "n-approve",
"type": "hitl:approval_gate",
"agent": "system:hitl-gateway",
"constraints": {
"hitl.required_role": "clinician:oncall",
"hitl.timeout_s": 300,
"hitl.timeout_action": "safe_pause"
}
}
]
}
}
~~~
{: #fig-gate title="Approval Gate as DAG Node"}
When the workflow reaches an approval gate, the system:
1. Emits an ECT with `exec_act: "hitl:approval_request"`
2. Notifies the required human role
3. Waits for approval (ECT: `"hitl:approval_granted"`) or
rejection (ECT: `"hitl:approval_denied"`)
4. On timeout, applies `hitl.timeout_action`
# Broadcast Override {#broadcast}
For environments with many agents, an operator MAY send a
broadcast override to a management endpoint:
~~~
POST /hitl/broadcast HTTP/1.1
Execution-Context: <broadcast-override-ect>
{
"targets": ["spiffe://example.com/agent/a",
"spiffe://example.com/agent/b"],
"level": 3,
"reason": "Coordinated emergency stop"
}
~~~
The broadcast endpoint fans out individual override ECTs to each
target and returns per-agent results.
# Dead Man's Switch {#dead-man}
For maximum reliability, agents SHOULD implement a heartbeat
mechanism: the agent periodically pings an operator heartbeat
endpoint. If the heartbeat is missed for a configurable duration,
the agent automatically enters Level 1 (PAUSE).
This provides a safety net when network connectivity to the
operator is lost. The `unreachable_human` policy from
ACP-DAG-HITL governs behavior when the dead man's switch
activates: either `abort` or `safe_pause`.
# Security Considerations
Override commands are high-privilege operations. All override
endpoints MUST require authentication via mutual TLS or signed
JWTs.
Override ECTs MUST be signed at L2 or L3. Agents MUST verify
signatures before processing.
To prevent replay attacks, agents MUST reject override ECTs with
`iat` more than 30 seconds in the past. The `jti` MUST be unique;
agents MUST reject duplicate `jti` values.
Deployments SHOULD implement multi-operator approval for Level 4
(TAKEOVER), requiring two independent operator identities.
The override endpoint SHOULD be served on a separate port or
network interface from the agent's main API to ensure availability
during overload.
# IANA Considerations
This document requests the following registrations:
1. Well-known URI registrations for `hitl/override`,
`hitl/resume`, `hitl/lift`, and `hitl/status` per {{RFC8615}}.
2. Registration of `exec_act` values: `hitl:override`,
`hitl:ack`, `hitl:resume`, `hitl:lift`,
`hitl:approval_request`, `hitl:approval_granted`,
`hitl:approval_denied` in a future ECT action type registry.
--- back
# Acknowledgments
{:numbered="false"}
This specification is the runtime enforcement companion to
ACP-DAG-HITL {{I-D.nennemann-agent-dag-hitl-safety}}. Override
design is inspired by industrial safety systems (IEC 62061,
ISO 13849).

612
workspace/drafts/new-drafts/draft-c-hitl-human-in-the-loop-01.md Normal file
View File

@@ -0,0 +1,612 @@
---
title: "Human-in-the-Loop (HITL) Primitives for Agent Ecosystems"
abbrev: "HITL"
category: std
docname: draft-hitl-human-in-the-loop-01
submissiontype: IETF
number:
date:
v: 3
area: "OPS"
workgroup: "NMOP"
keyword:
- human override
- HITL
- emergency stop
- agentic safety
- explainability
author:
-
fullname: TBD
organization: Independent
email: placeholder@example.com
normative:
RFC2119:
RFC8174:
RFC7519:
RFC8446:
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/
informative:
--- abstract
This document defines runtime HITL (Human-in-the-Loop) primitives
for agent ecosystems: four escalating override levels, approval
gates, timeout and fallback policies, and explainability hooks.
ACP-DAG-HITL defines WHEN humans must intervene (policy rules and
triggers). This specification defines HOW the intervention
actually happens at the protocol level: the HTTP endpoints,
override semantics, agent compliance requirements,
acknowledgment flows, and explainability tokens that allow
operators to make informed decisions. All overrides and decisions
produce ECT nodes, making human interventions part of the same
auditable DAG as agent actions.
--- middle
# Introduction
The current ratio of autonomous capability drafts to human
oversight drafts in the IETF is roughly 7:1. Agents can act but
humans cannot reliably stop them.
ACP-DAG-HITL {{I-D.nennemann-agent-dag-hitl-safety}} defines the
policy: trigger conditions, required roles, and actions (`pause`,
`escalate`, `abort`). But it deliberately defers the runtime
protocol — how does an operator actually send a stop command? How
does the agent acknowledge it? What happens if the operator is
unreachable?
This specification fills that gap. It is the runtime enforcement
companion to ACP-DAG-HITL, inspired by industrial safety systems:
the e-stop button on factory equipment, the circuit breaker in
electrical systems, and the kill switch in robotics.
HITL is deliberately not a governance framework, policy language,
or accountability protocol. It is a panic button with a
well-defined interface.
# Conventions and Definitions
{::boilerplate bcp14-tagged}
Override:
: A human-initiated command that alters an agent's autonomous
operation, taking precedence over the agent's own decisions.
Operator:
: A human user authorized to issue override commands.
Approval Gate:
: A DAG node that blocks workflow progression until a human
approves or rejects continuation.
HITL Intensity Level:
: A deployment-wide configuration of how actively human oversight
is required. Distinct from override levels (which are runtime
commands).
# HITL Intensity Levels {#intensity}
A deployment configures a HITL intensity level that determines
the baseline human oversight requirement. This is orthogonal to
the four runtime override levels ({{levels}}): intensity levels
govern planning; override levels govern runtime intervention.
| Intensity | Label | Human requirement | When to use |
|-----------|-------|-------------------|-------------|
| I0 | Autonomous | No HITL required by default | Dev/test; fully trusted agents |
| I1 | Advisory | Notifications; no blocking | Monitoring-only production deployments |
| I2 | Selective | Approval required on critical paths only | Standard production cross-org deployments |
| I3 | Mandatory | Approval required on every consequential action | Regulated environments; EU AI Act critical systems |
{: #fig-intensity title="HITL Intensity Levels"}
Intensity levels are declared in ACP-DAG-HITL workflow policy and
map to AEM assurance levels (see {{assurance-binding}}):
| HITL Intensity | Minimum AEM Assurance Level |
|---------------|----------------------------|
| I0 | L1 |
| I1 | L1 |
| I2 | L2 |
| I3 | L3 |
{: #fig-intensity-assurance title="Intensity to Assurance Level Mapping"}
# Relationship to ACP-DAG-HITL {#mapping}
ACP-DAG-HITL defines three HITL actions. This specification
maps them to four runtime override levels and extends with
CONSTRAIN (partial restriction):
| ACP-DAG-HITL action | HITL Override Level | Behavior |
|---------------------|---------------------|----------|
| `pause` | Level 1: PAUSE | Suspend autonomous actions, hold state |
| (no equivalent) | Level 2: CONSTRAIN | Restrict to an allowlist of actions |
| `abort` | Level 3: STOP | Cease all actions, enter inert state |
| `escalate` | Level 4: TAKEOVER | Transfer control to human operator |
{: #fig-mapping title="ACP-DAG-HITL to HITL Level Mapping"}
When ACP-DAG-HITL rules trigger, the runtime system uses the
corresponding HITL level to enforce the action.
# Override Levels {#levels}
## Level 1: PAUSE
The agent MUST suspend all autonomous actions and hold current
state. It MUST NOT initiate new actions but MAY complete
in-progress actions if stopping mid-execution would cause harm
(e.g., an in-flight database transaction). The agent resumes
when a RESUME command is received.
## Level 2: CONSTRAIN
The agent MUST restrict its actions to a specified subset. The
override command includes an allowlist of permitted action types.
The agent MUST reject any action not on the allowlist, responding
with HTTP 403 and an ECT noting the constraint violation.
## Level 3: STOP
The agent MUST immediately cease all autonomous actions and enter
an inert state. It MUST NOT take any autonomous actions until
explicitly restarted. This is the e-stop. Any in-progress
consequential actions MUST be abandoned; if abandonment would
leave external state inconsistent, the agent MUST emit an
`atd:error` ECT and the ATD rollback protocol applies.
## Level 4: TAKEOVER
The agent MUST transfer operational control to the human operator.
It enters a pass-through mode where it executes only explicit
operator commands. The agent's sensors and outputs remain
available to the operator as tools. Deployments SHOULD require
two-operator authorization for TAKEOVER (see {{security}}).
# Override Protocol {#protocol}
## Override Command
Override commands are sent as HTTP POST to the agent's well-known
endpoint:
~~~
POST /.well-known/hitl/override HTTP/1.1
Content-Type: application/json
Authorization: Bearer <operator-jwt>
Execution-Context: <override-ect>
~~~
The override ECT MUST contain:
- `exec_act`: `"hitl:override"`
- `par`: the most recent ECT from the agent being overridden
(linking the override into the workflow DAG)
~~~json
{
"exec_act": "hitl:override",
"par": ["agent-last-action-ect"],
"ext": {
"hitl.level": 3,
"hitl.reason": "Agent blocking legitimate traffic",
"hitl.operator_id": "user:alice",
"hitl.scope": "*",
"hitl.constraints": null,
"hitl.ttl": null,
"hitl.nonce": "a3f8b2c1"
}
}
~~~
{: #fig-override title="Override ECT"}
Field definitions:
- `hitl.level`: Integer 1-4. MUST be present.
- `hitl.reason`: Human-readable text. MUST be logged.
- `hitl.scope`: `"*"` for all functions, or an array of function
IDs for partial override.
- `hitl.constraints`: For Level 2 only. Array of permitted action
types.
- `hitl.ttl`: Duration in seconds. If set, override auto-expires.
If null, persists until explicitly lifted.
- `hitl.nonce`: REQUIRED. A random value to prevent replay attacks.
## Acknowledgment
The agent MUST respond within 1 second with an acknowledgment ECT:
- `exec_act`: `"hitl:ack"`
- `par`: the override ECT
~~~json
{
"exec_act": "hitl:ack",
"par": ["override-ect-uuid"],
"ext": {
"hitl.status": "accepted",
"hitl.prior_state": "autonomous",
"hitl.current_state": "stopped",
"hitl.effective_at": "2026-03-01T12:00:00.123Z"
}
}
~~~
{: #fig-ack title="Acknowledgment ECT"}
The override/ack ECT pair serves as the Decision Record defined
in ACP-DAG-HITL Section 6.5. No separate audit mechanism is
needed.
## Resume and Lift
To resume from PAUSE:
~~~
POST /.well-known/hitl/resume HTTP/1.1
Execution-Context: <resume-ect with exec_act="hitl:resume">
~~~
To lift any override:
~~~
POST /.well-known/hitl/lift HTTP/1.1
Execution-Context: <lift-ect with exec_act="hitl:lift">
~~~
Both produce ECTs linked to the original override ECT via `par`.
# Agent Compliance Requirements {#compliance}
Every HITL-compliant agent MUST:
1. Implement the `/.well-known/hitl/override` endpoint per
{{RFC8615}}.
2. Process override commands within 1 second of receipt. The
override path MUST be independent of the agent's main
processing loop and MUST NOT be blocked by ongoing tasks.
3. Acknowledge every override with an ECT response.
4. An agent MUST NOT respond with "rejected". Overrides are
mandatory. If the agent cannot fully comply, it MUST respond
with status `partial` and describe what it could not do.
5. Expose current override status at:
~~~
GET /.well-known/hitl/status
~~~
~~~json
{
"agent_id": "spiffe://example.com/agent/firewall",
"override_active": true,
"current_level": 3,
"override_ect": "override-ect-uuid",
"since": "2026-03-01T12:00:00Z",
"operator_id": "user:alice"
}
~~~
{: #fig-status title="Override Status Response"}
6. The override endpoint SHOULD be served on a separate port or
network interface from the agent's main API to ensure
availability under load.
# Approval Gates {#approval-gates}
An approval gate is a DAG node that blocks workflow progression
until a human approves. Unlike overrides (which interrupt running
agents), approval gates are planned checkpoints in the workflow.
Approval gates are defined as ACP-DAG-HITL nodes with HITL rules:
~~~json
{
"dag": {
"nodes": [
{
"id": "n-approve",
"type": "hitl:approval_gate",
"agent": "system:hitl-gateway",
"constraints": {
"hitl.required_role": "clinician:oncall",
"hitl.timeout_s": 300,
"hitl.timeout_action": "safe_pause"
}
}
]
}
}
~~~
{: #fig-gate title="Approval Gate as DAG Node"}
When the workflow reaches an approval gate, the system:
1. Emits an ECT with `exec_act: "hitl:approval_request"`.
2. Notifies the required human role with an explainability
token (see {{explainability}}).
3. Waits for approval (ECT: `"hitl:approval_granted"`) or
rejection (ECT: `"hitl:approval_denied"`).
4. On timeout, applies `hitl.timeout_action` per {{timeout}}.
## Approval Request and Response ECTs
~~~json
{
"exec_act": "hitl:approval_request",
"par": ["pre-gate-ect-uuid"],
"ext": {
"hitl.required_role": "clinician:oncall",
"hitl.context": "Medication dosage adjustment for patient P-1042",
"hitl.timeout_s": 300,
"hitl.explainability_ref": "expl-ect-uuid"
}
}
~~~
{: #fig-approval-req title="Approval Request ECT"}
~~~json
{
"exec_act": "hitl:approval_granted",
"par": ["approval-request-ect-uuid"],
"ext": {
"hitl.operator_id": "user:dr-jones",
"hitl.scope": "medication:adjust",
"hitl.expires": "2026-03-01T13:00:00Z"
}
}
~~~
{: #fig-approval-grant title="Approval Granted ECT"}
~~~json
{
"exec_act": "hitl:approval_denied",
"par": ["approval-request-ect-uuid"],
"ext": {
"hitl.operator_id": "user:dr-jones",
"hitl.reason": "Dosage exceeds safe maximum for patient weight",
"hitl.alternative": "Use standard protocol dosage"
}
}
~~~
{: #fig-approval-deny title="Approval Denied ECT"}
# Timeout and Fallback Policy {#timeout}
When a human does not respond within `hitl.timeout_s`, the
agent applies `hitl.timeout_action`. Three policies are
supported:
fail-closed:
: Abort the workflow. The agent emits `atd:error` with
`error_type: "timeout"` and the ATD rollback protocol
applies. Use when safety requires no action over wrong action.
fail-open:
: Continue as if approved, recording an audit ECT that no human
approved. Use only when workflow continuity is more important
than human review (I0/I1 intensity deployments).
escalate:
: Move the approval request to the next operator in the
escalation chain (defined in ACP-DAG-HITL policy). If the
escalation chain is exhausted, fall back to `fail-closed`.
The timeout policy is set in ACP-DAG-HITL node constraints:
~~~json
{
"constraints": {
"hitl.timeout_s": 300,
"hitl.timeout_action": "escalate"
}
}
~~~
{: #fig-timeout title="Timeout Policy as Node Constraint"}
Timeout policy MUST be `fail-closed` at HITL intensity I3.
Timeout policy MUST NOT be `fail-open` when assurance level is L3.
# Explainability {#explainability}
When a HITL point is triggered, the agent SHOULD provide an
explainability token that allows the operator to make an informed
decision. At AEM assurance L2+, explainability is REQUIRED for
approval gate requests.
An explainability token is an ECT:
- `exec_act`: `"hitl:explanation"`
~~~json
{
"exec_act": "hitl:explanation",
"par": ["last-agent-action-ect"],
"ext": {
"hitl.summary": "Agent proposes to reroute BGP traffic from AS64496 to AS64497 due to packet loss exceeding 15% threshold over 5-minute window.",
"hitl.proposed_action": "update-bgp-peer router-07 neighbor 198.51.100.1 remove-private-as",
"hitl.evidence_ects": [
"snmp-poll-1-ect-uuid",
"snmp-poll-2-ect-uuid",
"loss-calc-ect-uuid"
],
"hitl.confidence": 0.91,
"hitl.risk_level": "medium",
"hitl.reversible": true
}
}
~~~
{: #fig-explanation title="Explainability Token ECT"}
Field definitions:
- `hitl.summary`: Human-readable description of what the agent
was doing and why HITL was reached. REQUIRED.
- `hitl.proposed_action`: What the agent proposes to do.
REQUIRED.
- `hitl.evidence_ects`: Array of `jti` values from prior ECTs
that support the proposal. SHOULD be present.
- `hitl.confidence`: Float 0.0-1.0; agent's self-assessed
confidence in the proposed action. SHOULD be present.
- `hitl.risk_level`: One of `low`, `medium`, `high`, `critical`.
SHOULD be present.
- `hitl.reversible`: Whether the proposed action can be rolled
back. REQUIRED.
The `hitl.explainability_ref` field in the approval request ECT
({{fig-approval-req}}) references the `jti` of this ECT.
# Binding to AEM Assurance Levels {#assurance-binding}
HITL requirements vary by AEM assurance level. The following
table is normative:
| AEM Level | Required HITL Intensity | Override signing | Explainability |
|-----------|------------------------|-----------------|----------------|
| L1 | I0 (optional) | Optional | Optional |
| L2 | I2 or higher | REQUIRED (signed JWT) | REQUIRED for I2+ |
| L3 | I3 | REQUIRED (signed JWT, L3 ECT) | REQUIRED |
{: #fig-assurance-hitl title="HITL Requirements by Assurance Level"}
At L3, approval gate responses (hitl:approval_granted) MUST be
committed to the audit ledger.
# Broadcast Override {#broadcast}
For environments with many agents, an operator MAY send a
broadcast override to a management endpoint:
~~~
POST /hitl/broadcast HTTP/1.1
Execution-Context: <broadcast-override-ect>
{
"targets": ["spiffe://example.com/agent/a",
"spiffe://example.com/agent/b"],
"level": 3,
"reason": "Coordinated emergency stop"
}
~~~
The broadcast endpoint fans out individual override ECTs to each
target and returns per-agent results. Each fan-out is itself an
ECT linked to the broadcast override ECT.
Broadcast overrides MUST be authenticated at L2 or higher.
# Dead Man's Switch {#dead-man}
For maximum reliability, agents SHOULD implement a heartbeat
mechanism: the agent periodically pings an operator heartbeat
endpoint. If the heartbeat is missed for a configurable duration,
the agent automatically enters Level 1 (PAUSE).
The heartbeat interval SHOULD be 30 seconds. The trigger
threshold SHOULD be 3 missed heartbeats.
This provides a safety net when network connectivity to the
operator is lost. The `unreachable_human` policy from
ACP-DAG-HITL governs behavior when the dead man's switch
activates: either `abort` (→ Level 3) or `safe_pause` (→ Level 1).
# Security Considerations {#security}
## Authentication of Override Commands
All override endpoints MUST require authentication via mutual
TLS ({{RFC8446}}) or signed JWTs ({{RFC7519}}). The JWT MUST
contain the operator's identity and be signed by a trusted key
(per ACP-DAG-HITL operator role configuration).
## Replay Prevention
To prevent replay attacks, agents MUST:
1. Reject override ECTs with `iat` more than 30 seconds in the
past.
2. Reject duplicate `jti` values (require a nonce per override).
3. Require the `hitl.nonce` field in override ECTs.
## Impersonation
Override commands carry high privilege. Agents MUST verify:
- The operator JWT is signed by a trusted key in the ACP-DAG-HITL
operator registry.
- The operator role matches the `required_role` in the triggering
HITL rule.
## Two-Operator Approval for TAKEOVER
Deployments SHOULD implement multi-operator approval for Level 4
(TAKEOVER), requiring two independent operator identities. The
two approval ECTs MUST both appear as `par` in the TAKEOVER
override ECT.
## HITL Bypass Prevention
Agents that claim a HITL gate was satisfied MUST provide the
`jti` of the corresponding `hitl:approval_granted` ECT in the
ECT that follows the gate. Agents MUST NOT proceed past an
approval gate without a valid signed approval ECT.
## Escalation Chain Integrity
The escalation chain in ACP-DAG-HITL policy defines which roles
receive escalations. This chain MUST be signed as part of the
policy token to prevent tampering. Agents MUST NOT follow
escalation chains from unsigned or unverified policy tokens.
# IANA Considerations
## Well-Known URI Registrations
This document requests the following registrations per {{RFC8615}}:
| URI Suffix | Purpose |
|------------|---------|
| `hitl/override` | Override command endpoint |
| `hitl/resume` | Resume from PAUSE |
| `hitl/lift` | Lift any active override |
| `hitl/status` | Override status query |
{: #fig-wellknown title="Well-Known URI Registrations"}
## `exec_act` Values
This document requests registration in the AEM Ecosystem
Extension Registry:
| Value | Description | Reference |
|-------|-------------|-----------|
| `hitl:override` | Human override command | This document |
| `hitl:ack` | Agent acknowledgment of override | This document |
| `hitl:resume` | Resume from PAUSE state | This document |
| `hitl:lift` | Lift any active override | This document |
| `hitl:approval_request` | Workflow blocked at approval gate | This document |
| `hitl:approval_granted` | Human approved continuation | This document |
| `hitl:approval_denied` | Human denied continuation | This document |
| `hitl:explanation` | Explainability token for HITL decision | This document |
{: #fig-iana-actions title="HITL exec_act Registrations"}
--- back
# Acknowledgments
{:numbered="false"}
This specification is the runtime enforcement companion to
ACP-DAG-HITL {{I-D.nennemann-agent-dag-hitl-safety}}. Override
design is inspired by industrial safety systems (IEC 62061,
ISO 13849). The explainability token design is informed by
EU AI Act Article 13 transparency requirements.

354
workspace/drafts/new-drafts/draft-cpat-cross-protocol-agent-translation-00.md Normal file
View File

@@ -0,0 +1,354 @@
---
title: "Cross-Protocol Agent Translation (CPAT)"
abbrev: "CPAT"
category: std
docname: draft-cpat-cross-protocol-agent-translation-00
submissiontype: IETF
number:
date:
v: 3
area: "ART"
workgroup: "DISPATCH"
keyword:
- agent interoperability
- protocol translation
- agentic workflows
- execution context
author:
-
fullname: Generated by IETF Draft Analyzer
organization: Independent
email: placeholder@example.com
normative:
RFC7519:
RFC7515:
RFC9110:
RFC8615:
I-D.nennemann-wimse-ect:
title: "Execution Context Tokens for Distributed Agentic Workflows"
target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
informative:
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/
--- abstract
This document defines the Cross-Protocol Agent Translation (CPAT)
framework, a mechanism enabling AI agents using different
communication protocols to interoperate. With over 90 competing
agent-to-agent protocol drafts and no interoperability standard,
protocol fragmentation is the primary barrier to multi-vendor agent
ecosystems. CPAT defines capability advertisement, protocol
negotiation, and translation gateways. Translation hops are
recorded as Execution Context Token (ECT) DAG nodes, giving every
cross-protocol interaction a cryptographic audit trail without
inventing a parallel tracing mechanism.
--- middle
# Introduction
The IETF AI/agent landscape includes over 90 drafts proposing
agent-to-agent communication protocols, yet no standard exists
for agents using different protocols to exchange messages.
CPAT takes a pragmatic approach: rather than mandating a single
protocol, it defines the minimum machinery for agents to discover
each other's protocol support, agree on a common format, and fall
back to translation gateways when no common protocol exists.
CPAT builds on Execution Context Tokens
{{I-D.nennemann-wimse-ect}} as its audit and tracing backbone.
Every translation hop produces an ECT, linking into the workflow
DAG alongside the source and destination agents. This eliminates
the need for a separate tracing or provenance mechanism -- the ECT
DAG already provides it.
Design principles:
1. Reuse existing standards (HTTP, JSON, TLS, ECT) wherever
possible.
2. Keep the core mechanism small enough to implement in a day.
3. Do not require agents to support any protocol beyond their own
plus CPAT negotiation.
# Conventions and Definitions
{::boilerplate bcp14-tagged}
The following terms are used in this document:
Agent Protocol:
: A communication protocol used by an AI agent for peer-to-peer
message exchange (e.g., A2A, MCP, SLIM, uACP).
Capability Document:
: A JSON object describing the protocols an agent supports, served
at a well-known URI.
Translation Gateway:
: A service that converts messages between two agent protocols,
recording each translation as an ECT DAG node.
# Problem Statement
Consider three agents: Agent A speaks Protocol X, Agent B speaks
Protocol Y, and Agent C speaks both X and Z. Today there is no
standard way for A to discover that B uses a different protocol,
negotiate a common format, or route through a translator.
Existing work on Agent Name Service (ANS) and agent discovery
addresses finding agents but not protocol compatibility. CPAT
fills the gap between discovery and communication.
# Protocol Capability Advertisement {#capability-ad}
Each CPAT-compliant agent MUST serve a capability document at the
well-known URI `/.well-known/cpat` {{RFC8615}}. The document is a
JSON object:
~~~json
{
"cpat_version": "1.0",
"agent_id": "spiffe://example.com/agent/pricing",
"protocols": [
{
"id": "a2a-v1",
"version": "1.0",
"endpoint": "https://agent.example.com/a2a",
"priority": 10
},
{
"id": "mcp-v1",
"version": "2025-03-26",
"endpoint": "https://agent.example.com/mcp",
"priority": 20
}
],
"translation_gateways": [
"https://gateway.example.com/cpat/translate"
],
"ect_assurance_level": "L2"
}
~~~
{: #fig-capability title="Capability Document Example"}
The `protocols` array MUST contain at least one entry. Each entry
MUST include `id` (a registered protocol identifier), `version`,
and `endpoint`. The `priority` field is OPTIONAL; lower values
indicate higher preference.
The `ect_assurance_level` field declares the minimum ECT assurance
level the agent requires for interactions. This enables gateways
to produce ECTs at the correct level.
Agents SHOULD also advertise their capability document URI in DNS
SVCB records. The DNS record type `_cpat._tcp` SHOULD be used.
# Negotiation Handshake {#negotiation}
When Agent A wants to communicate with Agent B:
Step 1:
: Agent A fetches Agent B's capability document from B's
well-known CPAT URI over HTTPS.
Step 2:
: Agent A computes the intersection of its own protocol list with
Agent B's. If the intersection is non-empty, the protocol with
the lowest combined priority score is selected. Communication
proceeds directly using that protocol.
Step 3:
: If no common protocol exists, Agent A checks whether any
translation gateway listed by either agent supports both
protocols. Agent A queries the gateway:
~~~
GET /.well-known/cpat/gateway?from=a2a-v1&to=slim-v1
~~~
The gateway responds with 200 OK if it supports the pair, or
404 if not.
Step 4:
: If a suitable gateway is found, Agent A sends its message to the
gateway, which translates and forwards it to Agent B. The
gateway records the translation as an ECT (see {{ect-integration}}).
Step 5:
: If no gateway supports the required pair, Agent A returns an
error to its caller with error code `no_translation_path`.
The entire negotiation is stateless and cacheable. Agents SHOULD
cache capability documents for the duration indicated by HTTP
Cache-Control headers, defaulting to 3600 seconds.
# ECT Integration {#ect-integration}
Every translation hop produces an ECT {{I-D.nennemann-wimse-ect}}
that links into the workflow DAG. This provides cryptographic
proof of protocol translation without a separate tracing mechanism.
## Translation ECT Claims
A gateway producing a translation ECT MUST set:
- `exec_act`: `"cpat:translate"`
- `par`: array containing the `jti` of the source agent's ECT
- `wid`: the workflow identifier from the source ECT (preserving
workflow continuity across protocol boundaries)
The `ext` claim carries CPAT-specific metadata:
~~~json
{
"ext": {
"cpat.source_protocol": "a2a-v1",
"cpat.dest_protocol": "slim-v1",
"cpat.gateway_id": "spiffe://gw.example.com/cpat",
"cpat.translation_warnings": []
}
}
~~~
{: #fig-translation-ect title="Translation ECT Extension Claims"}
The `inp_hash` claim MUST contain the SHA-256 hash of the source
protocol message. The `out_hash` claim MUST contain the SHA-256
hash of the translated message. This allows verifiers to confirm
that a specific input produced a specific output without accessing
the message content.
## Assurance Level Inheritance
The gateway MUST produce ECTs at the higher of:
- The source agent's declared `ect_assurance_level`
- The destination agent's declared `ect_assurance_level`
At L3, the translation ECT MUST be recorded in the audit ledger
before the translated message is forwarded to the destination agent.
## DAG Continuity
The translation creates a three-node subgraph in the workflow DAG:
~~~
Source Agent ECT (exec_act: "send_task")
|
v [par reference]
Gateway ECT (exec_act: "cpat:translate")
|
v [par reference]
Dest Agent ECT (exec_act: "receive_task")
~~~
{: #fig-dag-continuity title="Translation DAG Subgraph"}
The Execution-Context HTTP header {{I-D.nennemann-wimse-ect}}
survives protocol translation: the gateway includes the
translation ECT in the Execution-Context header of the forwarded
request to the destination agent.
# Translation Gateway Requirements {#gateway-reqs}
A CPAT translation gateway MUST:
1. Serve a capability document listing all supported protocol
pairs at `/.well-known/cpat/gateway`.
2. Accept messages via HTTP POST at its translate endpoint.
3. Produce an ECT for every translation per {{ect-integration}}.
4. Preserve message semantics: the intent, core payload content,
and metadata MUST survive translation. Fields with no
equivalent in the destination protocol SHOULD be carried in a
protocol-specific extension field or dropped with a warning
recorded in `cpat.translation_warnings`.
5. Return the translated message in the response body, or forward
it directly to the destination agent.
A gateway MUST NOT modify payload semantics during translation.
Gateways MUST require TLS 1.3 for all connections and SHOULD
implement rate limiting per source agent.
# Policy Integration {#policy-integration}
When used with the Agent Context Policy Token
{{I-D.nennemann-agent-dag-hitl-safety}}, CPAT-related policies
can be expressed as DAG node constraints:
~~~json
{
"dag": {
"nodes": [
{
"id": "n-translate",
"type": "cpat:translate",
"agent": "spiffe://gw.example.com/cpat",
"constraints": {
"allowed_source_protocols": ["a2a-v1", "mcp-v1"],
"allowed_dest_protocols": ["slim-v1"],
"max_translation_hops": 2
}
}
]
}
}
~~~
{: #fig-policy title="CPAT Policy as DAG Node Constraints"}
The `max_translation_hops` constraint prevents messages from being
translated through an excessive number of gateways. Agents
receiving a message SHOULD reject it if the ECT DAG contains more
translation hops than allowed by policy.
# Security Considerations
Capability documents are served over HTTPS, ensuring transport
security. Agents SHOULD verify TLS certificates before trusting
capability documents.
Gateways are trusted intermediaries with access to message content
during translation. For end-to-end confidentiality, agents MAY
encrypt the message payload using a shared key established out of
band; the gateway translates only the protocol framing, not the
encrypted content.
The ECT audit trail ({{ect-integration}}) enables detection of:
- Unauthorized gateways (unexpected `cpat.gateway_id` in the DAG)
- Content tampering (mismatched `inp_hash`/`out_hash` relative to
message content)
- Routing loops (repeated gateway IDs in the DAG ancestry)
At L3, the audit ledger provides tamper-evident proof of all
translations for regulatory compliance.
# IANA Considerations
This document requests the following IANA registrations:
1. A "CPAT Protocol Identifier" registry under Expert Review
policy. Initial entries: "a2a-v1", "mcp-v1", "slim-v1",
"uacp-v1", "ainp-v1".
2. A well-known URI registration for "cpat" per {{RFC8615}}.
3. Registration of the `exec_act` value "cpat:translate" in a
future ECT action type registry.
--- 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}}.

281
workspace/drafts/new-drafts/draft-cpat-cross-protocol-agent-translation-00.txt Normal file
View File

@@ -0,0 +1,281 @@
Internet-Draft AI/Agent WG
Intended status: Standards Track March 2026
Expires: September 15, 2026
Cross-Protocol Agent Translation (CPAT)
draft-cpat-cross-protocol-agent-translation-00
Abstract
This document defines the Cross-Protocol Agent Translation (CPAT)
framework, a lightweight mechanism enabling AI agents using
different communication protocols to interoperate through
capability advertisement and message translation. With over 90
competing agent-to-agent (A2A) protocol drafts and no
interoperability standard, protocol fragmentation is the primary
barrier to multi-vendor agent ecosystems. CPAT defines three
components: a capability advertisement format for agents to
declare supported protocols, a negotiation handshake to select a
common protocol or translation path, and a canonical envelope
format that enables translation gateways to convert messages
between incompatible protocols. CPAT reuses existing HTTP
content negotiation patterns and builds on JSON for simplicity.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document is intended to have Standards Track status.
Distribution of this memo is unlimited.
Table of Contents
1. Introduction
2. Terminology
3. Problem Statement
4. Protocol Capability Advertisement
5. Negotiation Handshake
6. Canonical Envelope Format
7. Translation Gateway Requirements
8. Security Considerations
9. IANA Considerations
1. Introduction
The IETF AI/agent landscape includes over 90 drafts proposing
agent-to-agent communication protocols, yet no standard exists
for agents using different protocols to exchange messages. This
fragmentation mirrors the early days of instant messaging, where
users on different networks could not communicate until gateway
and federation standards emerged.
CPAT takes a pragmatic approach: rather than mandating a single
protocol, it defines the minimum machinery for agents to
discover each other's protocol support, agree on a common
format, and fall back to translation gateways when no common
protocol exists. The design follows three principles:
1. Reuse existing standards (HTTP, JSON, TLS) wherever possible.
2. Keep the core mechanism small enough to implement in a day.
3. Do not require agents to support any protocol beyond their own
plus CPAT negotiation.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119 [RFC2119].
Agent Protocol: A communication protocol used by an AI agent for
peer-to-peer message exchange (e.g., A2A, MCP, SLIM, uACP).
Capability Document: A JSON object describing the protocols an
agent supports, served at a well-known URI.
Translation Gateway: A service that converts messages between
two agent protocols using the CPAT canonical envelope as an
intermediate representation.
3. Problem Statement
Consider three agents: Agent A speaks Protocol X, Agent B speaks
Protocol Y, and Agent C speaks both X and Z. Today there is no
standard way for A to discover that B uses a different protocol,
negotiate a common format, or route through a translator. Each
protocol defines its own discovery and messaging layer, creating
isolated silos.
Existing work on Agent Name Service (ANS) and agent discovery
addresses finding agents but not protocol compatibility. The
ADOL draft addresses token efficiency within a single protocol
but not cross-protocol translation. CPAT fills the gap between
discovery and communication.
4. Protocol Capability Advertisement
Each CPAT-compliant agent MUST serve a capability document at
the well-known URI /.well-known/cpat. The document is a JSON
object with the following structure:
{
"cpat_version": "1.0",
"agent_id": "urn:uuid:550e8400-e29b-41d4-a716-446655440000",
"protocols": [
{
"id": "a2a-v1",
"version": "1.0",
"endpoint": "https://agent.example.com/a2a",
"priority": 10
},
{
"id": "mcp-v1",
"version": "2025-03-26",
"endpoint": "https://agent.example.com/mcp",
"priority": 20
}
],
"translation_gateways": [
"https://gateway.example.com/cpat/translate"
],
"envelope_formats": ["cpat-envelope-v1"]
}
The "protocols" array MUST contain at least one entry. Each
entry MUST include "id" (a registered protocol identifier),
"version", and "endpoint". The "priority" field is OPTIONAL;
lower values indicate higher preference.
Agents SHOULD also advertise their capability document URI in
DNS SRV or SVCB records for automated discovery. The DNS
record type "_cpat._tcp" SHOULD be used.
5. Negotiation Handshake
When Agent A wants to communicate with Agent B, the following
negotiation procedure applies:
Step 1: Agent A fetches Agent B's capability document from
B's well-known CPAT URI over HTTPS.
Step 2: Agent A computes the intersection of its own protocol
list with Agent B's. If the intersection is non-empty, the
protocol with the lowest combined priority score is selected.
Communication proceeds directly using that protocol.
Step 3: If no common protocol exists, Agent A checks whether
any translation gateway listed by either agent supports both
protocols. Agent A queries the gateway's capability endpoint
at /.well-known/cpat/gateway:
GET /.well-known/cpat/gateway?from=a2a-v1&to=slim-v1
The gateway responds with 200 OK and a translation descriptor
if it supports the pair, or 404 if not.
Step 4: If a suitable gateway is found, Agent A sends its
message wrapped in a CPAT envelope (Section 6) to the gateway,
which translates and forwards it to Agent B.
Step 5: If no gateway supports the required pair, Agent A
SHOULD return an error to its caller indicating protocol
incompatibility, using the CPAT error code "no_translation_path".
The entire negotiation is stateless and cacheable. Agents
SHOULD cache capability documents for the duration indicated by
HTTP Cache-Control headers, defaulting to 3600 seconds.
6. Canonical Envelope Format
The CPAT envelope wraps a protocol-specific message in a
standard container for gateway translation. The envelope is a
JSON object:
{
"cpat_version": "1.0",
"message_id": "urn:uuid:6ba7b810-9dad-11d1-80b4-00c04fd430c8",
"timestamp": "2026-03-01T12:00:00Z",
"source": {
"agent_id": "urn:uuid:...",
"protocol": "a2a-v1"
},
"destination": {
"agent_id": "urn:uuid:...",
"protocol": "slim-v1"
},
"intent": "task_request",
"payload": {
"content_type": "application/json",
"body": "...base64-encoded protocol-specific message..."
},
"trace": ["urn:uuid:...source", "urn:uuid:...gateway"]
}
The "intent" field MUST be one of: "task_request",
"task_response", "notification", "error", "capability_query".
This allows gateways to perform semantic translation even when
protocol message structures differ significantly.
The "trace" array provides a simple provenance chain of all
agents and gateways that have handled the message. Each
intermediary MUST append its own identifier.
The "payload.body" field contains the original protocol message,
base64-encoded. Gateways translate by decoding the source
protocol message, mapping it to the CPAT semantic model (intent
+ standard fields), and re-encoding in the destination protocol.
7. Translation Gateway Requirements
A CPAT translation gateway MUST:
1. Serve a capability document listing all supported protocol
pairs at /.well-known/cpat/gateway.
2. Accept CPAT envelopes via HTTP POST at its translate endpoint.
3. Validate envelope integrity before translation.
4. Preserve message semantics: the intent, core payload content,
and metadata MUST survive translation. Fields with no
equivalent in the destination protocol SHOULD be carried in
a protocol-specific extension field or dropped with a warning.
5. Return the translated envelope in the response body, or
forward it directly to the destination agent.
6. Log all translations with source, destination, and timestamp
for audit purposes.
A gateway MUST NOT modify the payload semantics during
translation. If exact translation is not possible, the gateway
MUST include a "translation_warnings" array in the envelope
listing fields that were approximated or dropped.
Gateways SHOULD implement rate limiting per source agent and
MUST require TLS 1.3 [RFC8446] for all connections.
8. Security Considerations
Capability documents are served over HTTPS, ensuring transport
security. Agents SHOULD verify the TLS certificate of peers
before trusting their capability documents.
CPAT envelopes in transit through gateways are visible to the
gateway operator. For end-to-end confidentiality, agents MAY
encrypt the payload.body field using a shared key established
out of band. The envelope metadata (intent, agent IDs,
timestamps) remains visible to enable routing.
Gateways are trusted intermediaries. Deployments SHOULD use
gateways operated by mutually trusted parties or verified
through attestation mechanisms such as those in
draft-aylward-daap-v2.
The trace array enables detection of routing loops and
unauthorized intermediaries. Agents SHOULD reject messages
with unexpected entries in the trace.
Denial-of-service attacks against gateways are mitigated by
rate limiting (Section 7) and standard HTTP-layer protections.
9. IANA Considerations
This document requests IANA establish the following:
1. A "CPAT Protocol Identifier" registry under Expert Review
policy. Initial entries: "a2a-v1", "mcp-v1", "slim-v1",
"uacp-v1", "ainp-v1".
2. A "CPAT Intent Type" registry under Specification Required
policy. Initial entries: "task_request", "task_response",
"notification", "error", "capability_query".
3. A well-known URI registration for "cpat" per RFC 8615.
Author's Address
Generated by IETF Draft Analyzer
2026-03-01

315
workspace/drafts/new-drafts/draft-d-aepb-protocol-binding-00.md Normal file
View File

@@ -0,0 +1,315 @@
---
title: "Agent Ecosystem Protocol Binding (AEPB): Interop and Lifecycle"
abbrev: "AEPB"
category: std
docname: draft-aepb-agent-ecosystem-protocol-binding-00
submissiontype: IETF
number:
date:
v: 3
area: "ART"
workgroup: "DISPATCH"
keyword:
- agent interoperability
- protocol translation
- lifecycle
- agentic workflows
author:
-
fullname: TBD
organization: Independent
email: placeholder@example.com
normative:
RFC2119:
RFC8174:
RFC8446:
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/
informative:
--- abstract
This document defines the Agent Ecosystem Protocol Binding (AEPB),
the interoperability and lifecycle layer of the agent ecosystem.
With over 90 competing A2A protocol drafts and no interoperability
standard, AEPB defines capability advertisement, protocol
negotiation, translation gateways, and agent lifecycle management
(versioning, graceful shutdown, retirement). Translation hops
produce ECT nodes, preserving DAG continuity across protocol
boundaries. Protocol constraints are expressed as ACP-DAG-HITL
node constraints.
--- middle
# Introduction
The IETF AI/agent landscape includes over 90 drafts proposing
agent-to-agent communication protocols. No standard exists for
agents using different protocols to exchange messages, and no
standard exists for how agents evolve, get replaced, or retire
without disrupting dependent services.
AEPB addresses both gaps with a pragmatic approach: rather than
mandating a single protocol, it defines the minimum machinery for
agents to discover each other's protocol support, agree on a
common format, fall back to translation gateways, and manage their
lifecycle.
AEPB builds on ECT {{I-D.nennemann-wimse-ect}} for audit (every
translation hop is a DAG node) and ACP-DAG-HITL
{{I-D.nennemann-agent-dag-hitl-safety}} for policy (protocol
constraints as node constraints).
# Conventions and Definitions
{::boilerplate bcp14-tagged}
Agent Protocol:
: A communication protocol used by an AI agent for peer-to-peer
message exchange (e.g., A2A, MCP, SLIM, uACP).
Capability Document:
: A JSON object describing the protocols an agent supports.
Translation Gateway:
: A service that converts messages between two agent protocols,
recording each translation as an ECT DAG node.
# Capability Advertisement {#capability}
Each AEPB-compliant agent MUST serve a capability document at
`/.well-known/aepb` {{RFC8615}}:
~~~json
{
"aepb_version": "1.0",
"agent_id": "spiffe://example.com/agent/pricing",
"protocols": [
{
"id": "a2a-v1",
"version": "1.0",
"endpoint": "https://agent.example.com/a2a",
"priority": 10
},
{
"id": "mcp-v1",
"version": "2025-03-26",
"endpoint": "https://agent.example.com/mcp",
"priority": 20
}
],
"translation_gateways": [
"https://gateway.example.com/aepb/translate"
],
"ect_assurance_level": "L2",
"lifecycle": {
"status": "active",
"version": "2.1.0",
"deprecated_at": null,
"sunset_at": null,
"successor": null
}
}
~~~
{: #fig-capability title="Capability Document"}
The `protocols` array MUST contain at least one entry. `priority`
is OPTIONAL; lower values indicate higher preference.
The `lifecycle` object (see {{lifecycle}}) provides versioning and
deprecation metadata.
Agents SHOULD advertise via DNS SVCB records (`_aepb._tcp`).
# Protocol Negotiation {#negotiation}
When Agent A wants to communicate with Agent B:
1. Agent A fetches B's capability document over HTTPS.
2. Agent A computes the intersection of protocol lists. If
non-empty, the protocol with the lowest combined priority is
selected. Communication proceeds directly.
3. If no common protocol exists, Agent A checks translation
gateways listed by either agent:
~~~
GET /.well-known/aepb/gateway?from=a2a-v1&to=slim-v1
~~~
The gateway responds 200 if it supports the pair, 404 if not.
4. If a suitable gateway is found, Agent A sends its message to
the gateway, which translates and forwards.
5. If no gateway supports the pair, Agent A returns error
`no_translation_path`.
Negotiation is stateless and cacheable (Cache-Control, default
3600s).
# Translation as ECT DAG Nodes {#translation-ect}
Every translation hop produces an ECT:
- `exec_act`: `"aepb:translate"`
- `par`: the source agent's ECT
- `inp_hash`: SHA-256 of source protocol message
- `out_hash`: SHA-256 of translated message
~~~json
{
"exec_act": "aepb:translate",
"par": ["source-agent-ect-uuid"],
"inp_hash": "sha256-of-source-message",
"out_hash": "sha256-of-translated-message",
"ext": {
"aepb.source_protocol": "a2a-v1",
"aepb.dest_protocol": "slim-v1",
"aepb.gateway_id": "spiffe://gw.example.com/aepb",
"aepb.translation_warnings": []
}
}
~~~
{: #fig-translate-ect title="Translation ECT"}
This creates a three-node subgraph:
~~~
Source ECT → Gateway ECT (aepb:translate) → Dest ECT
~~~
The Execution-Context HTTP header survives protocol translation:
the gateway includes the translation ECT in the header of the
forwarded request.
## Translation Policy
Protocol constraints are ACP-DAG-HITL node constraints:
~~~json
{
"constraints": {
"aepb.allowed_source_protocols": ["a2a-v1", "mcp-v1"],
"aepb.allowed_dest_protocols": ["slim-v1"],
"aepb.max_translation_hops": 2
}
}
~~~
{: #fig-policy title="Translation Policy"}
Agents receiving a message SHOULD reject it if the ECT DAG
contains more translation hops than `aepb.max_translation_hops`.
# Translation Gateway Requirements {#gateway}
A gateway MUST:
1. Serve a capability document at `/.well-known/aepb/gateway`.
2. Accept messages via HTTP POST at its translate endpoint.
3. Produce an ECT per {{translation-ect}} for every translation.
4. Preserve message semantics. Fields without a destination
equivalent are carried in an extension field or dropped with
a warning in `aepb.translation_warnings`.
5. Require TLS 1.3 {{RFC8446}} for all connections.
6. Implement rate limiting per source agent.
A gateway MUST NOT modify payload semantics.
# Agent Lifecycle Management {#lifecycle}
## Lifecycle States
An agent's `lifecycle.status` MUST be one of:
- `active`: Normal operation. Default state.
- `deprecated`: Agent is functional but will be retired.
`deprecated_at` MUST be set. Clients SHOULD migrate to
`successor` if provided.
- `draining`: Agent is rejecting new workflows but completing
in-progress ones. New delegation requests return HTTP 503
with `Retry-After` header pointing to `successor`.
- `retired`: Agent is offline. Capability document returns
HTTP 410 Gone with `successor` for redirect.
## Versioning
The `lifecycle.version` field uses semantic versioning. Agents
MUST increment the major version when breaking changes occur
(incompatible protocol or behavior changes).
Capability documents MUST include the version. Agents SHOULD
include version in ECT `ext` claims (`aepb.agent_version`) so
the audit trail records which version performed each action.
## Graceful Shutdown
When an agent transitions to `draining`:
1. Update capability document: `status: "draining"`,
set `sunset_at` timestamp.
2. Reject new workflow delegations with HTTP 503.
3. Complete all in-progress workflows.
4. Emit a final ECT: `exec_act: "aepb:shutdown"`.
5. Transition to `retired`.
Agents SHOULD provide at least 24 hours between `deprecated`
and `draining` to allow clients to discover the change via
cached capability documents.
## Successor Discovery
When `successor` is set, it MUST be the URI of the replacement
agent's capability document. Clients SHOULD transparently
redirect to the successor after verifying its capability
document.
# Security Considerations
Capability documents are served over HTTPS. Agents SHOULD verify
TLS certificates before trusting capability documents.
Gateways are trusted intermediaries with access to message content.
For end-to-end confidentiality, agents MAY encrypt message payloads
with a shared key established out of band.
The ECT audit trail enables detection of unauthorized gateways,
content tampering (mismatched `inp_hash`/`out_hash`), and routing
loops (repeated gateway IDs in DAG ancestry).
Lifecycle transitions (especially `draining` and `retired`) can be
exploited for denial of service. Only the agent operator (verified
via identity binding) SHOULD be able to update lifecycle status.
# IANA Considerations
This document requests:
1. A "AEPB Protocol Identifier" registry under Expert Review.
Initial entries: `a2a-v1`, `mcp-v1`, `slim-v1`, `uacp-v1`,
`ainp-v1`.
2. Well-known URI registrations for `aepb` and `aepb/gateway`
per {{RFC8615}}.
3. Registration of `exec_act` values: `aepb:translate`,
`aepb:shutdown` in a future ECT action type registry.
--- back
# Acknowledgments
{:numbered="false"}
AEPB builds on ECT {{I-D.nennemann-wimse-ect}} for translation
audit trails and ACP-DAG-HITL
{{I-D.nennemann-agent-dag-hitl-safety}} for protocol policy.

577
workspace/drafts/new-drafts/draft-d-aepb-protocol-binding-01.md Normal file
View File

@@ -0,0 +1,577 @@
---
title: "Agent Ecosystem Protocol Binding (AEPB): Interop and Lifecycle"
abbrev: "AEPB"
category: std
docname: draft-aepb-agent-ecosystem-protocol-binding-01
submissiontype: IETF
number:
date:
v: 3
area: "ART"
workgroup: "DISPATCH"
keyword:
- agent interoperability
- protocol translation
- lifecycle
- agentic workflows
author:
-
fullname: TBD
organization: Independent
email: placeholder@example.com
normative:
RFC2119:
RFC8174:
RFC8446:
RFC8615:
RFC9110:
RFC8594:
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:
--- abstract
This document defines the Agent Ecosystem Protocol Binding (AEPB),
the interoperability and lifecycle layer of the agent ecosystem.
With over 90 competing A2A protocol drafts and no interoperability
standard, AEPB defines capability advertisement, protocol
negotiation, formal binding requirements, translation gateway
architecture, and agent lifecycle management (versioning, graceful
shutdown, retirement). Translation hops produce ECT nodes,
preserving DAG continuity across protocol boundaries. Protocol
constraints are expressed as ACP-DAG-HITL node constraints.
--- middle
# Introduction
The IETF AI/agent landscape includes over 90 drafts proposing
agent-to-agent communication protocols. No standard exists for
agents using different protocols to exchange messages, and no
standard exists for how agents evolve, get replaced, or retire
without disrupting dependent services.
AEPB addresses both gaps with a pragmatic approach: rather than
mandating a single protocol, it defines the minimum machinery for
agents to discover each other's protocol support, agree on a
common format, fall back to translation gateways, and manage their
lifecycle.
AEPB builds on ECT {{I-D.nennemann-wimse-ect}} for audit (every
translation hop is a DAG node) and ACP-DAG-HITL
{{I-D.nennemann-agent-dag-hitl-safety}} for policy (protocol
constraints as node constraints).
# Conventions and Definitions
{::boilerplate bcp14-tagged}
Agent Protocol:
: A communication protocol used by an AI agent for peer-to-peer
message exchange (e.g., A2A, MCP, SLIM, uACP).
Capability Document:
: A JSON object describing the protocols an agent supports,
lifecycle status, and ECT assurance level.
Translation Gateway:
: A service that converts messages between two agent protocols,
recording each translation as an ECT DAG node.
Protocol Binding:
: The mapping between the AEPB ecosystem semantics and a specific
agent protocol. Each binding has a stable identifier string.
Binding Identifier:
: A short string identifying a specific protocol binding
version (e.g., `a2a-v1`, `mcp-v1`).
# Capability Advertisement {#capability}
## Capability Document Format
Each AEPB-compliant agent MUST serve a capability document at
`/.well-known/aepb` per {{RFC8615}}:
~~~json
{
"aepb_version": "1.0",
"agent_id": "spiffe://example.com/agent/pricing",
"protocols": [
{
"id": "a2a-v1",
"version": "1.0",
"endpoint": "https://agent.example.com/a2a",
"priority": 10
},
{
"id": "mcp-v1",
"version": "2025-03-26",
"endpoint": "https://agent.example.com/mcp",
"priority": 20
}
],
"translation_gateways": [
"https://gateway.example.com/aepb/translate"
],
"ect_assurance_level": "L2",
"ect_namespaces": ["atd", "hitl", "apae"],
"lifecycle": {
"status": "active",
"version": "2.1.0",
"deprecated_at": null,
"sunset_at": null,
"successor": null
}
}
~~~
{: #fig-capability title="Capability Document"}
The `protocols` array MUST contain at least one entry. `priority`
is OPTIONAL; lower values indicate higher preference.
The `ect_namespaces` field MUST list all ECT extension namespaces
(ATD, HITL, APAE) that this agent emits and can process. Peers
use this to determine whether ecosystem semantics are compatible.
The `lifecycle` object (see {{lifecycle}}) provides versioning and
deprecation metadata.
## DNS-SD Advertisement
Agents SHOULD advertise via DNS SVCB records (`_aepb._tcp`) as
an alternative to well-known URI discovery. The SVCB record
MUST include a `hint` parameter pointing to the well-known URI.
## Capability Document Caching
Capability documents MAY be cached per HTTP cache-control
semantics per {{RFC9110}}. The default max-age is 3600 seconds.
Agents MUST set `Expires` or `Cache-Control: max-age` on
capability document responses.
# Protocol Negotiation {#negotiation}
When Agent A wants to communicate with Agent B:
1. Agent A fetches B's capability document over HTTPS.
2. Agent A computes the intersection of protocol lists. If
non-empty, the protocol with the lowest combined priority is
selected. Communication proceeds directly.
3. If no common protocol exists, Agent A checks translation
gateways listed by either agent:
~~~
GET /.well-known/aepb/gateway?from=a2a-v1&to=slim-v1 HTTP/1.1
~~~
The gateway responds 200 if it supports the pair, 404 if not.
4. If a suitable gateway is found, Agent A sends its message to
the gateway, which translates and forwards.
5. If no gateway supports the pair, Agent A MUST return error
`no_translation_path` and MUST NOT proceed.
Negotiation is stateless and cacheable (Cache-Control, default
3600s).
## Protocol Downgrade Prevention
Protocol negotiation MUST NOT result in selection of a binding
below the minimum configured in ACP-DAG-HITL node constraints:
~~~json
{
"constraints": {
"aepb.min_protocol_security": "tls-1.3"
}
}
~~~
Agents MUST reject capability documents that advertise only
protocols below their configured minimum security requirement.
Specifically, all protocols MUST use TLS 1.3 {{RFC8446}}; no
plaintext bindings are permitted in production deployments.
# Conforming Protocol Binding Requirements {#binding-requirements}
A protocol binding MUST satisfy the following requirements to be
registered in the AEPB Protocol Binding Registry.
## ECT Carriage
A conforming binding MUST provide a mechanism to carry ECTs
alongside protocol messages. For HTTP-based protocols, this
MUST be the `Execution-Context` header as defined in
{{I-D.nennemann-wimse-ect}}. For non-HTTP protocols, the
binding specification MUST define an equivalent envelope field.
## Task Invocation with Parent Reference
A conforming binding MUST support task invocation messages that
include a reference to the parent ECT `jti`. This allows the
receiving agent to link the new task into the ECT DAG.
## Checkpoint and Rollback Signal Carriage
A conforming binding MUST support conveying ATD rollback requests
and results. For HTTP-based bindings, the `/.well-known/atd/rollback`
endpoint MUST be accessible independent of the main protocol
endpoint.
## HITL Callback Registration
A conforming binding MUST support HITL approval callback
registration. When a task involves a planned approval gate, the
initiating agent MUST be able to register a callback URI that
receives the `hitl:approval_granted` or `hitl:approval_denied`
ECT when the human responds. For HTTP bindings, this is a
standard webhook registration.
## Summary Table
| Requirement | Minimum | Rationale |
|-------------|---------|-----------|
| ECT carriage | `Execution-Context` header or equivalent | DAG continuity |
| Parent ECT reference | In task invocation | DAG linkage |
| Rollback signal | `/.well-known/atd/rollback` accessible | Error recovery |
| HITL callback | Webhook or equivalent | Async approval |
| Transport security | TLS 1.3 | Integrity and confidentiality |
{: #fig-requirements title="Protocol Binding Conformance Requirements"}
# Translation Gateway Architecture {#translation}
## Gateway as DAG Node
Every translation hop produces an ECT:
- `exec_act`: `"aepb:translate"`
- `par`: the source agent's ECT
~~~json
{
"exec_act": "aepb:translate",
"par": ["source-agent-ect-uuid"],
"inp_hash": "sha256-of-source-message",
"out_hash": "sha256-of-translated-message",
"ext": {
"aepb.source_protocol": "a2a-v1",
"aepb.dest_protocol": "slim-v1",
"aepb.gateway_id": "spiffe://gw.example.com/aepb",
"aepb.translation_warnings": []
}
}
~~~
{: #fig-translate-ect title="Translation ECT"}
This creates a three-node subgraph in the ECT DAG:
~~~
Source ECT → Gateway ECT (aepb:translate) → Dest ECT
~~~
The `Execution-Context` HTTP header survives protocol translation:
the gateway includes the translation ECT in the header of the
forwarded request, maintaining DAG continuity.
## Multi-Hop Translation
When a single gateway cannot handle a translation pair, messages
may traverse multiple gateways. Each hop produces an
`aepb:translate` ECT, all linked in the same DAG:
~~~
Agent-A ECT
│
▼
Gateway-1 ECT (a2a-v1 → mcp-v1)
│
▼
Gateway-2 ECT (mcp-v1 → slim-v1)
│
▼
Agent-B ECT
~~~
{: #fig-multihop title="Multi-Hop Translation DAG"}
The maximum number of translation hops is configured as a
node constraint:
~~~json
{
"constraints": {
"aepb.max_translation_hops": 2
}
}
~~~
Agents receiving a message MUST count `aepb:translate` ECTs in
the `par` ancestry and MUST reject messages exceeding
`aepb.max_translation_hops`. The default maximum is 3.
## Gateway Requirements
A gateway MUST:
1. Serve a capability document at `/.well-known/aepb/gateway`
listing supported translation pairs.
2. Accept messages via HTTP POST at its translate endpoint.
3. Produce an `aepb:translate` ECT per {{translation}} for
every translation.
4. Preserve message semantics. Fields without a destination
equivalent are carried in an extension field or dropped with
a warning in `aepb.translation_warnings`.
5. Require TLS 1.3 {{RFC8446}} for all connections.
6. Implement per-source-agent rate limiting.
7. Verify gateway ECTs at L2 or higher (signed JWT minimum).
A gateway MUST NOT modify payload semantics beyond what is
required for protocol translation.
## Translation Failure Handling
When a gateway fails to translate a message, it MUST emit an
error ECT:
~~~json
{
"exec_act": "aepb:translate_error",
"par": ["source-agent-ect-uuid"],
"ext": {
"aepb.source_protocol": "a2a-v1",
"aepb.dest_protocol": "slim-v1",
"aepb.error": "semantic_loss",
"aepb.description": "Source message contains field 'action.stream' with no slim-v1 equivalent"
}
}
~~~
{: #fig-translate-error title="Translation Error ECT"}
Error values: `semantic_loss` (untranslatable field), `timeout`,
`policy_violation` (exceeds hop limit), `internal_error`.
On translation failure:
- The ATD circuit breaker for the gateway agent SHOULD be
updated.
- If `atd.cascade: false`, the calling agent returns
`no_translation_path` to its upstream caller.
- If `atd.cascade: true`, the ATD rollback protocol applies
to the entire workflow subgraph.
## Translation Policy
Protocol constraints are ACP-DAG-HITL node constraints:
~~~json
{
"constraints": {
"aepb.allowed_source_protocols": ["a2a-v1", "mcp-v1"],
"aepb.allowed_dest_protocols": ["slim-v1"],
"aepb.max_translation_hops": 2
}
}
~~~
{: #fig-policy title="Translation Policy"}
# Agent Lifecycle Management {#lifecycle}
## Lifecycle States
An agent's `lifecycle.status` MUST be one of:
active:
: Normal operation. Default state.
deprecated:
: Agent is functional but will be retired.
`deprecated_at` MUST be set. The agent MUST include a
`Deprecation` header per {{RFC8594}} in all responses.
Clients SHOULD migrate to `successor` if provided.
draining:
: Agent is rejecting new workflows but completing in-progress
ones. New delegation requests MUST return HTTP 503 with
`Retry-After` header and, if set, `Location` pointing to
`successor`.
retired:
: Agent is offline. Capability document MUST return HTTP 410
Gone with `Link: <successor>; rel="successor-version"`.
## Lifecycle State Transitions
~~~
deprecate drain
active ──────────► deprecated ────────► draining ──► retired
▲ │ │
│ │ immediate drain │
└────────────────────┴────────────────────┘
(operator discretion)
~~~
{: #fig-lifecycle-fsm title="Lifecycle State Machine"}
All transitions MUST be recorded as ECTs:
~~~json
{
"exec_act": "aepb:lifecycle_change",
"ext": {
"aepb.agent_id": "spiffe://example.com/agent/pricing",
"aepb.from_state": "active",
"aepb.to_state": "deprecated",
"aepb.reason": "Replaced by pricing-v3"
}
}
~~~
{: #fig-lifecycle-ect title="Lifecycle Change ECT"}
## Versioning
The `lifecycle.version` field uses semantic versioning. Agents
MUST increment the major version when breaking changes occur
(incompatible protocol or behavior changes).
Capability documents MUST include the version. Agents SHOULD
include version in ECT `ext` claims (`aepb.agent_version`) so
the audit trail records which version performed each action.
## Graceful Shutdown
When an agent transitions to `draining`:
1. Update capability document: `status: "draining"`,
set `sunset_at` timestamp.
2. Reject new workflow delegations with HTTP 503.
3. Complete all in-progress workflows.
4. Emit a final ECT: `exec_act: "aepb:shutdown"`.
5. Transition to `retired`.
Agents SHOULD provide at least 24 hours between `deprecated`
and `draining` to allow clients to discover the change via
cached capability documents.
## Successor Discovery
When `successor` is set, it MUST be the URI of the replacement
agent's capability document. Clients SHOULD transparently
redirect to the successor after verifying its capability
document. Clients MUST verify that the successor's assurance
level is equal to or greater than the predecessor's.
# Security Considerations
## Capability Document Integrity
Capability documents are served over HTTPS with TLS 1.3.
Agents SHOULD verify TLS certificates before trusting capability
documents. For high-assurance deployments, capability documents
SHOULD be signed as JWTs ({{RFC7519}}) so their integrity can
be verified independently of transport security.
## Gateway Trust
Gateways are trusted intermediaries with access to message
content. For end-to-end confidentiality, agents MAY encrypt
message payloads with a shared key established out of band.
The ECT audit trail enables detection of:
- Unauthorized gateways (unknown `aepb.gateway_id`).
- Content tampering (`inp_hash`/`out_hash` mismatch).
- Routing loops (repeated gateway IDs in DAG ancestry).
Gateways MUST authenticate using WIMSE/SPIFFE identities at
ECT assurance L2+.
## Protocol Downgrade Attacks
An attacker may attempt to force negotiation to a weaker
protocol. Mitigation:
- Agents MUST enforce `aepb.min_protocol_security` constraint.
- TLS 1.3 is the minimum transport; lower versions MUST be
rejected.
- Protocol negotiation results MUST be logged as part of the
workflow ECT DAG.
## Translation Amplification
A single cross-protocol request could trigger a chain of N
translations, each consuming resources. Mitigation:
- `aepb.max_translation_hops` (default 3) prevents unbounded
chains.
- Per-source rate limiting at each gateway prevents a single
agent from flooding the translation infrastructure.
## Lifecycle Denial of Service
Transitioning an agent to `draining` or `retired` disrupts
its callers. Only the agent operator (verified via ACP-DAG-HITL
identity binding) SHOULD be able to trigger lifecycle
transitions. Lifecycle-change ECTs MUST be signed at L2+.
# IANA Considerations
## AEPB Protocol Binding Registry
This document requests the creation of the "AEPB Protocol Binding
Registry" under IANA. Registration policy: Specification Required.
Required fields: Binding Identifier, Protocol Name, Specification
Reference, Minimum ECT Assurance Level, HITL Callback Support.
Initial entries:
| Identifier | Protocol | Spec Reference | Min Assurance | HITL Callback |
|------------|----------|---------------|--------------|---------------|
| `a2a-v1` | A2A | (TBD) | L1 | Webhook |
| `mcp-v1` | Model Context Protocol | (TBD) | L1 | Webhook |
| `slim-v1` | SLIM | (TBD) | L1 | Webhook |
| `uacp-v1` | uACP | (TBD) | L1 | Webhook |
| `ainp-v1` | AINP | (TBD) | L1 | Webhook |
{: #fig-registry title="Initial Protocol Binding Registry Entries"}
## Well-Known URIs
This document requests registration per {{RFC8615}}:
| URI Suffix | Purpose |
|------------|---------|
| `aepb` | Agent capability document |
| `aepb/gateway` | Translation gateway capability |
{: #fig-wellknown title="Well-Known URI Registrations"}
## `exec_act` Values
This document requests registration in the AEM Ecosystem
Extension Registry:
| Value | Description | Reference |
|-------|-------------|-----------|
| `aepb:translate` | Protocol translation hop | This document |
| `aepb:translate_error` | Translation failure | This document |
| `aepb:shutdown` | Agent graceful shutdown complete | This document |
| `aepb:lifecycle_change` | Lifecycle state transition | This document |
{: #fig-iana-actions title="AEPB exec_act Registrations"}
--- back
# Acknowledgments
{:numbered="false"}
AEPB builds on ECT {{I-D.nennemann-wimse-ect}} for translation
audit trails and ACP-DAG-HITL
{{I-D.nennemann-agent-dag-hitl-safety}} for protocol policy.
The lifecycle model is inspired by Kubernetes graceful shutdown
semantics and the `Deprecation` header {{RFC8594}}.

360
workspace/drafts/new-drafts/draft-dats-dynamic-agent-trust-scoring-00.md Normal file
View File

@@ -0,0 +1,360 @@
---
title: "Dynamic Agent Trust Scoring (DATS)"
abbrev: "DATS"
category: std
docname: draft-dats-dynamic-agent-trust-scoring-00
submissiontype: IETF
number:
date:
v: 3
area: "SEC"
workgroup: "Security Dispatch"
keyword:
- dynamic trust
- reputation
- agentic workflows
- execution context
author:
-
fullname: Generated by IETF Draft Analyzer
organization: Independent
email: placeholder@example.com
normative:
RFC7519:
RFC7515:
RFC7518:
RFC9110:
I-D.nennemann-wimse-ect:
title: "Execution Context Tokens for Distributed Agentic Workflows"
target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
informative:
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/
--- abstract
This document defines the Dynamic Agent Trust Scoring (DATS)
protocol, a mechanism for AI agents to build, assess, and revoke
trust relationships based on observed behavior over time. Static
authentication verifies identity but says nothing about reliability.
DATS augments identity-based auth with a numeric trust score that
adjusts dynamically based on interaction outcomes recorded in the
ECT DAG. Trust events are derived from ECT action outcomes rather
than agent-local tracking, making trust computation auditable and
tamper-evident. Trust assertions are ECTs themselves, and trust
thresholds integrate with ACP-DAG-HITL node constraints as
enforceable policy.
--- middle
# Introduction
The IETF has 98 drafts addressing agent identity and
authentication, providing strong mechanisms for verifying who an
agent is. But identity alone is insufficient for long-running
autonomous systems. A properly authenticated agent may still
produce bad results, violate expectations, or degrade over time.
DATS adds a behavioral dimension to trust. It answers: "I know
who you are, but should I rely on you?" The model is deliberately
simple -- a single floating-point score between 0.0 and 1.0 per
agent relationship -- because complex reputation systems tend to
be gamed or ignored.
By building on ECT {{I-D.nennemann-wimse-ect}}, DATS derives trust
from the cryptographically signed record of actual interactions
rather than agent-local counters that can be manipulated. At L3,
the audit ledger provides an immutable interaction history.
The protocol is inspired by:
- TCP congestion control: trust increases slowly (additive) and
decreases quickly (multiplicative) on failure.
- TLS certificate transparency: trust assertions are logged.
- Web of trust (PGP): trust propagates through intermediaries
with attenuation.
# Conventions and Definitions
{::boilerplate bcp14-tagged}
Trust Score:
: A floating-point value in \[0.0, 1.0\] representing one agent's
assessed reliability of another, based on observed ECT outcomes.
Trust Event:
: An observable interaction outcome that causes a trust score
adjustment. Derived from ECTs in the workflow DAG.
Trust Decay:
: Automatic reduction of trust scores over inactivity, reflecting
the principle that trust requires ongoing evidence.
Trust Assertion:
: An ECT recording one agent's trust score for another,
transportable as a signed token.
# Problem Statement
Agent A delegates a task to Agent B. After 100 successful
interactions, Agent B starts returning incorrect results (model
drift, adversarial manipulation, or degradation). Agent A has no
standard way to:
1. Track B's reliability over time.
2. Reduce B's privileges based on degraded performance.
3. Share its experience with Agent C.
4. Automatically revoke B's access when trust drops below
acceptable levels.
Existing attestation drafts (STAMP, DAAP) provide cryptographic
proof of specific actions but not ongoing behavioral assessment.
The ECT DAG records what happened; DATS adds evaluation of
whether what happened was good.
# Trust Score Model {#trust-model}
Each agent maintains a trust table: a mapping from peer agent IDs
to trust scores.
~~~json
{
"spiffe://example.com/agent/b": {
"score": 0.82,
"interactions": 147,
"last_updated": "2026-03-01T11:30:00Z",
"last_event_ect": "550e8400-e29b-41d4-a716-446655440099"
}
}
~~~
{: #fig-trust-table title="Trust Table Entry"}
Initial trust for an unknown agent is deployment-configured. A
value of 0.5 is RECOMMENDED as a neutral starting point.
Zero-trust deployments MAY use 0.1.
Trust scores are updated using additive-increase,
multiplicative-decrease (AIMD):
On positive event:
: `score = min(1.0, score + alpha)`
On negative event:
: `score = max(0.0, score * beta)`
Default parameters: `alpha = 0.01`, `beta = 0.8`.
This means trust builds slowly (100 successes from 0.5 to ~1.0)
but drops quickly (a single failure takes 0.82 to 0.66). This
asymmetry is intentional: in autonomous systems, the cost of
trusting a bad agent exceeds the cost of slow trust building.
# Trust Events from ECT {#trust-events}
Trust events are derived from ECTs in the workflow DAG rather than
agent-local tracking. This makes trust computation auditable.
## Standard Trust Events
| ECT condition | Event | Adjustment |
|--------------|-------|------------|
| `exec_act` completed, no error ECT follows | `task_success` | +1x alpha |
| `exec_act` completed, partial result | `task_partial` | +0.5x alpha |
| `aerr:error` ECT with `par` referencing agent | `task_failure` | 1x beta |
| Timeout (no response ECT within threshold) | `task_timeout` | 1x beta |
| `aerr:error` with `constraint_violation` | `policy_violation` | beta^2 |
| ECT signature verification fails | `attestation_invalid` | beta^2 |
| `aerr:rollback_request` targeting agent | `rollback_triggered` | 1x beta |
{: #fig-events title="Trust Events Derived from ECT"}
`beta^2` means the multiplicative decrease is applied twice
(`score * beta * beta`), reflecting the severity of policy
violations versus simple failures.
## Trust Decay
If no interaction (no ECT involving the peer) occurs for a
configurable period (default: 7 days), the trust score decays:
`score = max(initial_default, score - decay_rate)`
Default `decay_rate`: 0.01 per day.
Agents MUST record all trust events in a local audit log. At L3,
the trust events are derivable from the audit ledger, providing
independent verifiability.
# Trust Assertions as ECT {#trust-assertions}
Agent A shares its trust assessment of Agent B with Agent C via a
trust assertion ECT:
- `exec_act`: `"dats:assertion"`
- `par`: empty (trust assertions are standalone) or referencing
the most recent interaction ECT
~~~json
{
"iss": "spiffe://example.com/agent/a",
"ext": {
"dats.subject": "spiffe://example.com/agent/b",
"dats.score": 0.82,
"dats.interactions": 147,
"dats.confidence": "high",
"dats.hops": 0
}
}
~~~
{: #fig-assertion title="Trust Assertion ECT"}
`dats.confidence` is based on interaction count: `low` (<10),
`medium` (10-99), `high` (100+).
## Trust Propagation with Attenuation
When Agent C receives a trust assertion from Agent A about Agent B,
it MAY incorporate it:
~~~
c_score_for_b = max(c_score_for_b,
a_score_for_b * trust_of_a * attenuation)
~~~
Where:
- `a_score_for_b` = A's reported score for B (0.82)
- `trust_of_a` = C's own trust score for A
- `attenuation` = constant (default: 0.5)
Trust assertions are advisory. An agent's own direct observations
always take precedence over propagated trust.
## Anti-Gaming Measures
To prevent trust laundering (colluding agents inflating each
other's scores):
- Agents SHOULD limit propagation depth to 1 hop by default
- The `dats.hops` field tracks depth; agents MUST NOT propagate
assertions where `dats.hops` exceeds their configured maximum
- At L3, trust assertions are recorded in the audit ledger,
making collusion patterns detectable through graph analysis
# Trust Thresholds as Policy {#trust-policy}
## Threshold-Based Access
Agents SHOULD define trust thresholds per action type:
~~~json
{
"thresholds": {
"read_data": 0.3,
"execute_task": 0.5,
"modify_config": 0.7,
"delegate_auth": 0.9
}
}
~~~
{: #fig-thresholds title="Trust Thresholds"}
When a request arrives, the agent checks the requester's trust
score against the threshold. If below threshold, the request is
denied with HTTP 403 and error `trust_insufficient`.
## Integration with ACP-DAG-HITL
Trust thresholds can be expressed as DAG node constraints
{{I-D.nennemann-agent-dag-hitl-safety}}:
~~~json
{
"dag": {
"nodes": [{
"id": "n-critical-action",
"type": "modify_config",
"agent": "spiffe://example.com/agent/b",
"constraints": {
"dats.min_trust": 0.7,
"dats.min_confidence": "medium"
}
}]
},
"hitl": {
"rules": [{
"id": "r-low-trust",
"trigger": {
"kind": "confidence_below",
"op": "lt",
"value": 0.5,
"input_ref": "dats.peer_trust_score"
},
"required_role": "operator:security",
"action": "escalate",
"allow_override": true,
"override_action": "continue"
}]
}
}
~~~
{: #fig-policy title="Trust Policy as DAG Constraints + HITL"}
This means: if the delegated agent's trust score drops below 0.5,
escalate to a human security operator before proceeding.
## Automatic Revocation
When an agent's trust score drops below a configured floor
(default: 0.2), the trusting agent SHOULD:
1. Revoke all outstanding delegations to that agent
2. Produce a revocation ECT (`exec_act`: `"dats:revoke"`)
3. Emit an error ECT per AERR if the agent was part of an
active workflow
# Security Considerations
Trust scores are sensitive metadata. Agents MUST NOT expose
their full trust tables to peers. Only pairwise trust assertions
should be shared intentionally.
Trust assertion ECTs MUST be signed at L2 or L3. Agents MUST
verify signatures before processing.
Score manipulation: a malicious agent could behave well to build
trust, then exploit it. Mitigation: `policy_violation` events
apply double penalties, and deployments SHOULD set high thresholds
for critical actions.
Sybil attacks: an attacker creates many agents for fake positive
assertions. Mitigation: attenuation ({{trust-assertions}}),
hop limits, and requiring agents to be registered in a trusted
directory before accepting assertions.
All trust-related communications MUST use TLS 1.3.
# IANA Considerations
This document requests the following IANA registrations:
1. Registration of `exec_act` values `dats:assertion` and
`dats:revoke` in a future ECT action type registry.
2. A "DATS Trust Event Type" registry under Specification Required
policy. Initial entries: `task_success`, `task_partial`,
`task_failure`, `task_timeout`, `policy_violation`,
`attestation_invalid`, `rollback_triggered`.
--- back
# Acknowledgments
{:numbered="false"}
This document builds on the Execution Context Token specification
{{I-D.nennemann-wimse-ect}} for interaction evidence and the
Agent Context Policy Token {{I-D.nennemann-agent-dag-hitl-safety}}
for trust threshold policy enforcement.

298
workspace/drafts/new-drafts/draft-dats-dynamic-agent-trust-scoring-00.txt Normal file
View File

@@ -0,0 +1,298 @@
Internet-Draft AI/Agent WG
Intended status: Standards Track March 2026
Expires: September 15, 2026
Dynamic Agent Trust Scoring (DATS)
draft-dats-dynamic-agent-trust-scoring-00
Abstract
This document defines the Dynamic Agent Trust Scoring (DATS)
protocol, a mechanism for AI agents to build, assess, and
revoke trust relationships based on observed behavior over
time. Static authentication (certificates, API keys) verifies
identity but says nothing about whether an agent is reliable,
accurate, or well-behaved. DATS augments identity-based auth
with a numeric trust score that adjusts dynamically based on
interaction outcomes. The protocol defines trust score
computation, propagation between agents, decay over inactivity,
and threshold-based access policies. DATS is intentionally
simple: a single score per agent-pair, standard adjustment
events, and a JWT-based transport for trust assertions.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document is intended to have Standards Track status.
Distribution of this memo is unlimited.
Table of Contents
1. Introduction
2. Terminology
3. Problem Statement
4. Trust Score Model
5. Trust Events and Adjustments
6. Trust Propagation
7. Threshold-Based Access Policies
8. Security Considerations
9. IANA Considerations
1. Introduction
The IETF has 98 drafts addressing agent identity and
authentication, providing strong mechanisms for verifying who
an agent is. But identity alone is insufficient for long-
running autonomous systems. A properly authenticated agent
may still produce bad results, violate expectations, or
degrade over time. Static certificates cannot capture this.
DATS adds a behavioral dimension to agent trust. It answers
the question: "I know who you are, but should I rely on you?"
The model is deliberately simple — a single floating-point
score between 0.0 and 1.0 per agent relationship — because
complex reputation systems tend to be gamed or ignored.
The protocol is inspired by:
- TCP congestion control: trust increases slowly (additive)
and decreases quickly (multiplicative) on failure.
- TLS certificate transparency: trust assertions are logged
for auditability.
- Web of trust (PGP): trust can propagate through
intermediaries, with attenuation.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119 [RFC2119].
Trust Score: A floating-point value in [0.0, 1.0] representing
one agent's assessed reliability of another, based on observed
interaction outcomes.
Trust Event: An observable interaction outcome that causes a
trust score adjustment. Events are either positive (task
completed successfully) or negative (task failed, timeout,
policy violation).
Trust Decay: The automatic reduction of trust scores over
periods of inactivity, reflecting the principle that trust
requires ongoing evidence.
Trust Assertion: A signed statement by one agent about another
agent's trust score, transportable as a JWT claim.
3. Problem Statement
Agent A delegates a task to Agent B. Agent B completes it
correctly. Agent A delegates again. After 100 successful
interactions, Agent B starts returning subtly incorrect results
(model drift, adversarial manipulation, or simple degradation).
Agent A has no standard way to:
1. Track B's reliability over time.
2. Reduce B's privileges based on degraded performance.
3. Share its experience with Agent C, who is considering
delegating to Agent B.
4. Automatically revoke B's access when trust drops below
acceptable levels.
Existing attestation drafts (STAMP, DAAP) provide
cryptographic proof of specific actions but not ongoing
behavioral assessment. DATS fills this gap.
4. Trust Score Model
Each agent maintains a trust table: a mapping from peer agent
IDs to trust scores.
{
"urn:uuid:agent-b": {
"score": 0.82,
"interactions": 147,
"last_updated": "2026-03-01T11:30:00Z",
"last_event": "task_success"
}
}
Initial trust for an unknown agent is a deployment-configured
default. A value of 0.5 is RECOMMENDED as a neutral starting
point, but deployments MAY use lower values (e.g., 0.1) for
zero-trust environments.
Trust scores are updated using an additive-increase,
multiplicative-decrease (AIMD) algorithm:
On positive event:
score = min(1.0, score + alpha)
On negative event:
score = max(0.0, score * beta)
Default parameters: alpha = 0.01, beta = 0.8.
This means trust builds slowly (100 successes to go from 0.5
to ~1.0) but drops quickly (a single failure reduces an 0.82
score to 0.66). This asymmetry is intentional: in autonomous
systems, the cost of trusting a bad agent exceeds the cost of
being slow to trust a good one.
Agents MAY tune alpha and beta per relationship or per action
type, but MUST use the AIMD structure.
5. Trust Events and Adjustments
The following standard trust events are defined:
| Event | Direction | Default Weight |
|----------------------|-----------|----------------|
| task_success | positive | 1x alpha |
| task_partial_success | positive | 0.5x alpha |
| task_failure | negative | 1x beta |
| task_timeout | negative | 1x beta |
| policy_violation | negative | applied twice |
| attestation_invalid | negative | applied twice |
| rollback_triggered | negative | 1x beta |
"applied twice" means the multiplicative decrease is applied
two times in succession (score * beta * beta), reflecting the
severity of policy violations versus simple failures.
Trust decay: if no interaction occurs for a configurable
period (default: 7 days), the trust score decays:
score = max(initial_default, score - decay_rate)
Default decay_rate: 0.01 per day. This ensures that stale
trust relationships gradually return to the default level
rather than persisting indefinitely.
Agents MUST record all trust events in a local audit log.
6. Trust Propagation
Agent A may share its trust assessment of Agent B with Agent C
through a signed trust assertion. The assertion is a JWT
(RFC 7519) with the following claims:
{
"iss": "urn:uuid:agent-a",
"sub": "urn:uuid:agent-b",
"iat": 1709294400,
"exp": 1709380800,
"dats_score": 0.82,
"dats_interactions": 147,
"dats_confidence": "high"
}
"dats_confidence" is based on interaction count: "low" (<10),
"medium" (10-99), "high" (100+).
When Agent C receives this assertion, it MAY incorporate it
into its own trust score for Agent B using attenuation:
c_score_for_b = max(c_score_for_b,
a_score_for_b * trust_of_a * attenuation)
Where:
- a_score_for_b is Agent A's reported score for B (0.82)
- trust_of_a is Agent C's trust score for Agent A
- attenuation is a constant (default: 0.5) preventing
unbounded trust propagation
Trust assertions are advisory. Agents MUST NOT blindly adopt
propagated scores. An agent's own direct observations always
take precedence over propagated trust.
To prevent trust laundering (colluding agents inflating each
other's scores), agents SHOULD limit propagation depth to 1
hop by default. The "dats_hops" claim tracks propagation
depth; agents MUST NOT propagate assertions where dats_hops
exceeds their configured maximum.
7. Threshold-Based Access Policies
Agents SHOULD define trust thresholds for different action
categories:
{
"thresholds": {
"read_data": 0.3,
"execute_task": 0.5,
"modify_config": 0.7,
"delegate_auth": 0.9
}
}
When an agent requests an action, the serving agent checks the
requester's trust score against the threshold for that action
type. If the score is below the threshold, the request is
denied with a 403 response including a DATS-specific error:
{
"error": "trust_insufficient",
"required_score": 0.7,
"current_score": 0.54,
"action": "modify_config"
}
The response SHOULD NOT reveal the exact current score in
production deployments to prevent score probing. Instead, it
MAY return only the "trust_insufficient" error.
Automatic revocation: when an agent's trust score drops below
a configured floor (default: 0.2), the trusting agent SHOULD
revoke all outstanding delegations and emit a trust revocation
event. This provides automatic containment of agents that
have become unreliable.
8. Security Considerations
Trust scores are sensitive metadata. Agents MUST NOT expose
their full trust tables to peers. Only pairwise trust
assertions (Section 6) should be shared, and only
intentionally.
Trust assertion JWTs MUST be signed using algorithms from
RFC 7518 (e.g., ES256, EdDSA). Agents MUST verify signatures
before processing trust assertions.
Score manipulation attacks: a malicious agent could
intentionally behave well for many interactions to build trust,
then exploit high trust for a damaging action. Mitigation:
policy_violation events apply double penalties, and
deployments SHOULD set trust thresholds high for critical
actions regardless of accumulated trust.
Sybil attacks: an attacker could create many agents to
generate fake positive trust assertions. Mitigation: agents
SHOULD weight propagated trust by their own direct trust in
the asserting agent (Section 6 attenuation) and SHOULD
require agents to be registered in a trusted directory (e.g.,
ANS) before accepting trust assertions.
All trust-related communications MUST use TLS 1.3 [RFC8446].
9. IANA Considerations
This document requests IANA establish the following:
1. Registration of JWT claims "dats_score",
"dats_interactions", "dats_confidence", and "dats_hops"
in the JSON Web Token Claims registry per RFC 7519.
2. A "DATS Trust Event Type" registry under Specification
Required policy. Initial entries: "task_success",
"task_partial_success", "task_failure", "task_timeout",
"policy_violation", "attestation_invalid",
"rollback_triggered".
Author's Address
Generated by IETF Draft Analyzer
2026-03-01

384
workspace/drafts/new-drafts/draft-e-apae-assurance-profiles-00.md Normal file
View File

@@ -0,0 +1,384 @@
---
title: "Assurance Profiles for Agent Ecosystems (APAE)"
abbrev: "APAE"
category: info
docname: draft-apae-assurance-profiles-00
submissiontype: IETF
number:
date:
v: 3
area: "SEC"
workgroup: "Security Dispatch"
keyword:
- dynamic trust
- assurance
- behavior verification
- data provenance
author:
-
fullname: TBD
organization: Independent
email: placeholder@example.com
normative:
RFC2119:
RFC8174:
RFC7519:
RFC7518:
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:
--- abstract
This document defines Assurance Profiles for Agent Ecosystems
(APAE): dynamic trust scoring, behavior verification, data
provenance, and graduated assurance profiles that allow the same
agent ecosystem to operate in relaxed (dev/K8s) and regulated
(healthcare, finance) environments. Trust events are derived from
ECT outcomes. Trust assertions are ECTs. Behavior verification
references ECT claims. Provenance chains are implicit in the ECT
DAG. Assurance profiles select which combination of these
mechanisms is required for a given deployment, mapping to ECT
assurance levels L1/L2/L3.
--- middle
# Introduction
Identity verifies who an agent is. ECT records what an agent did.
But neither answers: should I rely on this agent? Is it doing what
it promised? Can I trace where this data came from?
APAE adds three capabilities to the ecosystem:
1. **Dynamic trust scoring** — behavioral reputation that adjusts
based on interaction outcomes (AIMD model).
2. **Behavior verification** — checking agent actions against
declared specifications.
3. **Data provenance** — tracing data lineage through the DAG.
These three capabilities are bundled into assurance profiles
(relaxed, standard, regulated) that map to ECT assurance levels,
so the same ecosystem works from a dev cluster to a hospital.
# Conventions and Definitions
{::boilerplate bcp14-tagged}
Trust Score:
: A floating-point value in \[0.0, 1.0\] representing one agent's
assessed reliability of another.
Trust Event:
: An interaction outcome that causes a trust score adjustment.
Derived from ECTs.
Behavior Specification:
: A machine-readable declaration of permitted agent actions and
constraints.
Provenance Chain:
: The sequence of ECT nodes recording how a piece of data was
produced, transformed, and consumed.
Assurance Profile:
: A named configuration selecting which trust, verification, and
provenance mechanisms are required.
# Dynamic Trust Scoring {#trust}
## Trust Score Model
Each agent maintains a trust table: peer agent IDs mapped to
trust scores. Initial trust for unknown agents is deployment-
configured (RECOMMENDED: 0.5; zero-trust: 0.1).
Scores update using additive-increase, multiplicative-decrease
(AIMD):
- Positive event: `score = min(1.0, score + alpha)`
- Negative event: `score = max(0.0, score * beta)`
Defaults: `alpha = 0.01`, `beta = 0.8`.
Trust builds slowly (100 successes: 0.5 → ~1.0) and drops fast
(one failure: 0.82 → 0.66).
## Trust Events from ECT {#trust-events}
Trust events are derived from ECTs rather than agent-local
counters, making trust computation auditable:
| ECT condition | Event | Adjustment |
|--------------|-------|------------|
| Completed, no error follows | `task_success` | +1x alpha |
| Completed, partial result | `task_partial` | +0.5x alpha |
| `atd:error` referencing agent | `task_failure` | 1x beta |
| No response within threshold | `task_timeout` | 1x beta |
| `atd:error` with `constraint_violation` | `policy_violation` | beta^2 |
| ECT signature verification fails | `attestation_invalid` | beta^2 |
| `atd:rollback_request` targeting agent | `rollback_triggered` | 1x beta |
{: #fig-events title="Trust Events from ECT"}
## Trust Decay
If no interaction occurs for a configurable period (default:
7 days): `score = max(initial_default, score - 0.01/day)`.
## Trust Assertions as ECT {#trust-assertions}
Agent A shares its trust assessment via a trust assertion ECT:
- `exec_act`: `"apae:trust_assertion"`
~~~json
{
"exec_act": "apae:trust_assertion",
"ext": {
"apae.subject": "spiffe://example.com/agent/b",
"apae.trust_score": 0.82,
"apae.interactions": 147,
"apae.confidence": "high",
"apae.hops": 0
}
}
~~~
{: #fig-assertion title="Trust Assertion ECT"}
Confidence: `low` (<10 interactions), `medium` (10-99),
`high` (100+).
## Trust Propagation
When Agent C receives A's assertion about B:
~~~
c_score_for_b = max(c_score_for_b,
a_score * trust_of_a * attenuation)
~~~
Default `attenuation`: 0.5. Direct observations always take
precedence. `apae.hops` tracks propagation depth; agents MUST NOT
propagate beyond their configured maximum (default: 1).
## Trust Thresholds as Policy
Trust thresholds are ACP-DAG-HITL node constraints:
~~~json
{
"constraints": {
"apae.min_trust": 0.7,
"apae.min_confidence": "medium"
}
}
~~~
{: #fig-threshold title="Trust Threshold as Node Constraint"}
Requests from agents below threshold are denied with HTTP 403.
Low trust can trigger HITL escalation:
~~~json
{
"id": "r-low-trust",
"trigger": {
"kind": "confidence_below",
"op": "lt",
"value": 0.5,
"input_ref": "apae.peer_trust_score"
},
"required_role": "operator:security",
"action": "escalate",
"allow_override": true,
"override_action": "continue"
}
~~~
{: #fig-trust-hitl title="HITL Rule for Low Trust"}
## Automatic Revocation
When trust drops below a floor (default: 0.2), the trusting agent
SHOULD revoke delegations and emit:
`exec_act: "apae:trust_revoke"`.
# Behavior Verification {#behavior}
## Behavior Specifications
A behavior specification declares what an agent is permitted to do.
Specifications are JSON documents referencing ECT claims:
~~~json
{
"spec_version": "1.0",
"agent_id": "spiffe://example.com/agent/firewall",
"allowed_actions": ["update_rules", "read_config", "report"],
"constraints": {
"max_actions_per_minute": 60,
"forbidden_targets": ["core-router-*"],
"require_checkpoint_before": ["update_rules"]
},
"verification_frequency": "continuous"
}
~~~
{: #fig-spec title="Behavior Specification"}
## Verification Against ECT Stream
A verifier monitors the agent's ECT stream and checks:
1. `exec_act` values are in `allowed_actions`.
2. Action rate does not exceed `max_actions_per_minute` (computed
from `iat` timestamps).
3. `atd:checkpoint` ECTs precede `update_rules` ECTs (from
`require_checkpoint_before`).
4. Targets in `ext` claims do not match `forbidden_targets`.
Verification results are ECTs:
- `exec_act`: `"apae:compliance_check"`
~~~json
{
"exec_act": "apae:compliance_check",
"par": ["latest-agent-ect-uuid"],
"ext": {
"apae.compliance_status": "passing",
"apae.violations": [],
"apae.spec_version": "1.0",
"apae.window": "2026-03-01T12:00:00Z/PT1H"
}
}
~~~
{: #fig-compliance title="Compliance Check ECT"}
Violations trigger trust score decreases (`policy_violation` event)
and MAY trigger HITL escalation.
# Data Provenance {#provenance}
## DAG as Provenance Chain
The ECT DAG already encodes data provenance: each ECT's `par`
references show which prior tasks produced its inputs. The
`inp_hash` and `out_hash` claims prove what was processed without
revealing the data.
For deployments requiring explicit provenance metadata, agents
MAY include:
~~~json
{
"ext": {
"apae.data_source": "database:patients",
"apae.data_classification": "pii",
"apae.retention_days": 365,
"apae.transformations": ["anonymize", "aggregate"]
}
}
~~~
{: #fig-provenance title="Provenance Extension Claims"}
## Provenance Queries
At L3, the audit ledger enables provenance queries:
- "Which agents touched this data?" → walk `par` chain from
final ECT to roots.
- "Was this data transformed?" → check `apae.transformations`
along the chain.
- "Is provenance complete?" → verify all `par` references
resolve to ledger entries.
# Assurance Profiles {#profiles}
An assurance profile is a named configuration that selects which
mechanisms are required:
| | Relaxed | Standard | Regulated |
|---|---------|----------|-----------|
| **ECT level** | L1 | L2 | L3 |
| **Trust scoring** | Optional | RECOMMENDED | REQUIRED |
| **Trust threshold enforcement** | Optional | RECOMMENDED | REQUIRED |
| **Behavior verification** | Off | Periodic | Continuous |
| **HITL approval gates** | Optional | Critical paths | Mandatory |
| **Data provenance** | Off | Optional | REQUIRED |
| **Checkpoint before consequential** | RECOMMENDED | REQUIRED | REQUIRED |
| **Audit ledger** | Optional | Optional | REQUIRED |
{: #fig-profiles title="Assurance Profiles"}
Relaxed:
: Internal dev/staging. L1 ECTs. Trust and verification
optional. Useful for debugging and observability without
cryptographic overhead.
Standard:
: Production cross-org. L2 ECTs. Trust scoring and thresholds
recommended. Periodic behavior verification. HITL on critical
paths.
Regulated:
: Healthcare, finance, EU AI Act. L3 ECTs with audit ledger.
Continuous behavior verification. All trust mechanisms
required. Full provenance chain. Mandatory HITL gates.
Profiles are declared in ACP-DAG-HITL node constraints:
~~~json
{
"constraints": {
"apae.assurance_profile": "regulated"
}
}
~~~
{: #fig-profile-policy title="Profile as Node Constraint"}
A single deployment MAY use different profiles for different
workflows.
# Security Considerations
Trust scores are sensitive metadata. Agents MUST NOT expose full
trust tables. Only pairwise assertions should be shared.
Trust assertion ECTs MUST be signed at L2/L3.
Score manipulation (building trust then exploiting it): mitigated
by double penalties for `policy_violation` and high thresholds for
critical actions.
Sybil attacks (fake agents inflating trust): mitigated by
attenuation ({{trust-assertions}}), hop limits, and requiring
agents to be registered in a trusted directory.
Behavior specifications could be tampered with. Specifications
SHOULD be signed and versioned. Changes MUST be recorded as ECTs.
All trust and verification communications MUST use TLS 1.3.
# IANA Considerations
This document requests registration of `exec_act` values:
- `apae:trust_assertion`
- `apae:trust_revoke`
- `apae:compliance_check`
--- back
# Acknowledgments
{:numbered="false"}
APAE builds on ECT {{I-D.nennemann-wimse-ect}} for interaction
evidence and audit, and ACP-DAG-HITL
{{I-D.nennemann-agent-dag-hitl-safety}} for trust threshold and
assurance profile policy enforcement. The AIMD trust model is
adapted from TCP congestion control.

695
workspace/drafts/new-drafts/draft-e-apae-assurance-profiles-01.md Normal file
View File

@@ -0,0 +1,695 @@
---
title: "Assurance Profiles for Agent Ecosystems (APAE)"
abbrev: "APAE"
category: info
docname: draft-apae-assurance-profiles-01
submissiontype: IETF
number:
date:
v: 3
area: "SEC"
workgroup: "Security Dispatch"
keyword:
- dynamic trust
- assurance
- behavior verification
- data provenance
- quarantine
author:
-
fullname: TBD
organization: Independent
email: placeholder@example.com
normative:
RFC2119:
RFC8174:
RFC7519:
RFC7518:
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:
RFC9334:
--- abstract
This document defines Assurance Profiles for Agent Ecosystems
(APAE): dynamic trust scoring, behavior verification, data
provenance, cross-domain trust, and graduated assurance profiles
that allow the same agent ecosystem to operate in relaxed
(dev/K8s) and regulated (healthcare, finance) environments.
Trust events are derived from ECT outcomes. Trust assertions are
ECTs. Behavior verification references ECT claims. Provenance
chains are implicit in the ECT DAG. Assurance profiles select
which combination of these mechanisms is required for a given
deployment, mapping to ECT assurance levels L1/L2/L3. Agents
whose trust falls below a floor are quarantined via a protocol
defined here.
--- middle
# Introduction
Identity verifies who an agent is. ECT records what an agent did.
But neither answers: should I rely on this agent? Is it doing what
it promised? Can I trace where this data came from?
APAE adds four capabilities to the ecosystem:
1. **Dynamic trust scoring** — behavioral reputation that adjusts
based on interaction outcomes (AIMD model).
2. **Behavior verification** — checking agent actions against
declared specifications.
3. **Data provenance** — tracing data lineage through the DAG.
4. **Cross-domain trust** — federating trust across administrative
domains.
These capabilities are bundled into assurance profiles
(Relaxed, Standard, Regulated) that map to ECT assurance levels,
so the same ecosystem works from a dev cluster to a hospital.
# Conventions and Definitions
{::boilerplate bcp14-tagged}
Trust Score:
: A floating-point value in \[0.0, 1.0\] representing one agent's
assessed reliability of another.
Trust Event:
: An interaction outcome that causes a trust score adjustment.
Derived from ECTs.
Trust Domain:
: An administrative boundary within which a single trust anchor
(CA or JWK set) governs agent identity.
Behavior Specification:
: A machine-readable declaration of permitted agent actions and
constraints.
Provenance Chain:
: The sequence of ECT nodes recording how a piece of data was
produced, transformed, and consumed.
Assurance Profile:
: A named configuration selecting which trust, verification, and
provenance mechanisms are required.
Quarantine:
: A state in which an agent's trust score has dropped below a
configured floor; the agent is prohibited from accepting new
delegations.
# Dynamic Trust Scoring {#trust}
## Trust Score Model
Each agent maintains a trust table: peer agent IDs mapped to
trust scores. Initial trust for unknown agents is deployment-
configured (RECOMMENDED: 0.5; zero-trust deployments: 0.1).
Scores update using additive-increase, multiplicative-decrease
(AIMD):
- Positive event: `score = min(1.0, score + alpha)`
- Negative event: `score = max(0.0, score * beta)`
Defaults: `alpha = 0.01`, `beta = 0.8`.
Trust builds slowly (100 successes: 0.5 → ~1.0) and drops fast
(one failure: 0.82 → 0.66).
## Trust Events from ECT {#trust-events}
Trust events are derived from ECTs rather than agent-local
counters, making trust computation auditable:
| ECT condition | Event | Adjustment |
|--------------|-------|------------|
| Completed, no error follows | `task_success` | +1x alpha |
| Completed, partial result | `task_partial` | +0.5x alpha |
| `atd:error` referencing agent | `task_failure` | 1x beta |
| No response within threshold | `task_timeout` | 1x beta |
| `atd:error` with `constraint_violation` | `policy_violation` | beta^2 |
| ECT signature verification fails | `attestation_invalid` | beta^2 |
| `atd:rollback_request` targeting agent | `rollback_triggered` | 1x beta |
{: #fig-events title="Trust Events from ECT"}
## Trust Decay
If no interaction occurs for a configurable period (default:
7 days): `score = max(initial_default, score - 0.01/day)`.
## Trust Assertions as ECT {#trust-assertions}
Agent A shares its trust assessment via a trust assertion ECT:
- `exec_act`: `"apae:trust_assertion"`
~~~json
{
"exec_act": "apae:trust_assertion",
"ext": {
"apae.subject": "spiffe://example.com/agent/b",
"apae.trust_score": 0.82,
"apae.interactions": 147,
"apae.confidence": "high",
"apae.hops": 0
}
}
~~~
{: #fig-assertion title="Trust Assertion ECT"}
Confidence: `low` (<10 interactions), `medium` (10-99),
`high` (100+).
Trust assertion ECTs MUST be signed at L2/L3.
## Trust Propagation
When Agent C receives A's assertion about B:
~~~
c_score_for_b = max(c_score_for_b,
a_score * trust_of_a * attenuation)
~~~
Default `attenuation`: 0.5. Direct observations always take
precedence. `apae.hops` tracks propagation depth; agents MUST NOT
propagate beyond their configured maximum (default: 1).
## Trust Thresholds as Policy
Trust thresholds are ACP-DAG-HITL node constraints:
~~~json
{
"constraints": {
"apae.min_trust": 0.7,
"apae.min_confidence": "medium"
}
}
~~~
{: #fig-threshold title="Trust Threshold as Node Constraint"}
Requests from agents below threshold MUST be denied with HTTP 403.
The `apae.peer_trust_score` is a runtime context value derived
from the trusting agent's trust table for the requesting peer;
it is not an ECT claim itself.
Low trust can trigger HITL escalation:
~~~json
{
"id": "r-low-trust",
"trigger": {
"kind": "confidence_below",
"op": "lt",
"value": 0.5,
"input_ref": "apae.peer_trust_score"
},
"required_role": "operator:security",
"action": "escalate",
"allow_override": true,
"override_action": "continue"
}
~~~
{: #fig-trust-hitl title="HITL Rule for Low Trust"}
## Automatic Revocation
When trust drops below a floor (default: 0.2), the trusting agent
SHOULD revoke delegations and emit:
`exec_act: "apae:trust_revoke"`.
# Quarantine Protocol {#quarantine}
When a trust score drops below the configured quarantine floor
(default: 0.15), the agent enters quarantine.
## Quarantine Entry
The detecting agent MUST emit a quarantine ECT:
~~~json
{
"exec_act": "apae:quarantine",
"ext": {
"apae.subject": "spiffe://example.com/agent/b",
"apae.score": 0.12,
"apae.threshold": 0.15,
"apae.quarantine_until": "2026-03-02T12:00:00Z",
"apae.reason": "Repeated policy_violation events (3 in 1 hour)"
}
}
~~~
{: #fig-quarantine title="Quarantine ECT"}
The quarantine ECT MUST be broadcast to all agents that have
received trust assertions about the quarantined agent
(via `apae:trust_assertion` with matching `apae.subject`).
## Quarantined Agent Behavior
While quarantined, a subject agent:
- MUST NOT accept new delegations. New delegation requests MUST
return HTTP 503 with `Retry-After` set to `apae.quarantine_until`.
- MUST complete in-progress workflows (drain behavior per AEPB).
- MAY accept direct operator commands (HITL Level 4 is unaffected).
Agents receiving the quarantine notification MUST update their
trust table and MUST NOT delegate new tasks to the quarantined
agent until the quarantine expires or is lifted.
## Quarantine Duration
The default quarantine duration is 1 hour, doubling on each
successive quarantine entry:
| Quarantine count | Duration |
|-----------------|---------|
| 1 | 1 hour |
| 2 | 2 hours |
| 3 | 4 hours |
| n | 2^(n-1) hours (max 168 hours / 7 days) |
{: #fig-quarantine-duration title="Quarantine Duration Escalation"}
## Quarantine Expiry and Recovery
When the quarantine period expires:
1. The agent's trust score is reset to the initial default
(deployment-configured; RECOMMENDED: 0.5 for recovery).
2. The agent transitions back to active status per AEPB lifecycle.
3. A recovery ECT MAY be emitted: `exec_act: "apae:quarantine"` with
`apae.to_state: "active"`.
An operator MAY lift a quarantine early by issuing a HITL override
(Level 1 or higher) with scope `apae:quarantine_lift` for the
subject agent.
# Behavior Verification {#behavior}
## Behavior Specifications
A behavior specification declares what an agent is permitted to do.
Specifications are JSON documents referencing ECT claims:
~~~json
{
"spec_version": "1.0",
"agent_id": "spiffe://example.com/agent/firewall",
"allowed_actions": ["update_rules", "read_config", "report"],
"constraints": {
"max_actions_per_minute": 60,
"forbidden_targets": ["core-router-*"],
"require_checkpoint_before": ["update_rules"]
},
"verification_frequency": "continuous"
}
~~~
{: #fig-spec title="Behavior Specification"}
Behavior specifications SHOULD be signed and versioned. Changes
MUST be recorded as ECTs.
## Verification Against ECT Stream
A verifier monitors the agent's ECT stream and checks:
1. `exec_act` values are in `allowed_actions`.
2. Action rate does not exceed `max_actions_per_minute` (computed
from `iat` timestamps).
3. `atd:checkpoint` ECTs precede `update_rules` ECTs (from
`require_checkpoint_before`).
4. Targets in `ext` claims do not match `forbidden_targets`.
Verification results are ECTs:
- `exec_act`: `"apae:compliance_check"`
~~~json
{
"exec_act": "apae:compliance_check",
"par": ["latest-agent-ect-uuid"],
"ext": {
"apae.compliance_status": "passing",
"apae.violations": [],
"apae.spec_version": "1.0",
"apae.window": "2026-03-01T12:00:00Z/PT1H"
}
}
~~~
{: #fig-compliance title="Compliance Check ECT"}
Violations trigger trust score decreases (`policy_violation` event)
and MAY trigger HITL escalation.
A violation compliance check ECT looks like:
~~~json
{
"exec_act": "apae:compliance_check",
"par": ["offending-ect-uuid"],
"ext": {
"apae.compliance_status": "failing",
"apae.violations": [
{
"rule": "require_checkpoint_before",
"action": "update_rules",
"ect": "offending-ect-uuid",
"description": "update_rules at 12:03:15 has no preceding atd:checkpoint within 10s"
}
],
"apae.spec_version": "1.0",
"apae.window": "2026-03-01T12:00:00Z/PT1H"
}
}
~~~
{: #fig-violation title="Compliance Violation ECT"}
# Data Provenance {#provenance}
## DAG as Provenance Chain
The ECT DAG already encodes data provenance: each ECT's `par`
references show which prior tasks produced its inputs. The
`inp_hash` and `out_hash` claims prove what was processed without
revealing the data.
For deployments requiring explicit provenance metadata, agents
MAY include:
~~~json
{
"ext": {
"apae.data_source": "database:patients",
"apae.data_classification": "pii",
"apae.retention_days": 365,
"apae.transformations": ["anonymize", "aggregate"]
}
}
~~~
{: #fig-provenance title="Provenance Extension Claims"}
At Regulated assurance level, all data-transforming ECT nodes
MUST include provenance claims.
## Provenance Queries
At L3, the audit ledger enables provenance queries:
- "Which agents touched this data?" → walk `par` chain from
final ECT to roots.
- "Was this data transformed?" → check `apae.transformations`
along the chain.
- "Is provenance complete?" → verify all `par` references
resolve to ledger entries.
# Cross-Domain Trust {#cross-domain}
## Trust Domain Basics
A trust domain is an administrative boundary within which a
single trust anchor (CA certificate or JWK set) governs agent
identity. Trust scores are local to a trust domain by default.
## Trust Domain Registration
Each trust domain MUST publish a trust anchor at a well-known URI:
~~~
GET /.well-known/apae/trust-anchor HTTP/1.1
~~~
The response MUST be a JSON object containing:
~~~json
{
"domain": "example.com",
"trust_anchor_type": "jwks",
"trust_anchor_uri": "https://example.com/.well-known/jwks.json",
"contact": "trust-admin@example.com"
}
~~~
{: #fig-trust-anchor title="Trust Anchor Document"}
## Cross-Domain Delegation
When Agent A (domain X) delegates to Agent B (domain Y):
1. A MUST verify that its ACP-DAG-HITL policy permits cross-domain
delegation to domain Y (bilateral trust agreement).
2. A fetches B's trust anchor document to verify B's identity.
3. A creates an `apae:cross_domain_assertion` ECT linking the
two domains.
4. Both A and B include their domain in ECT `iss` claims.
~~~json
{
"exec_act": "apae:cross_domain_assertion",
"ext": {
"apae.source_domain": "example.com",
"apae.dest_domain": "hospital.example",
"apae.bilateral_agreement_ref": "agreement-id-2026-001",
"apae.min_assurance": "L2"
}
}
~~~
{: #fig-cross-domain title="Cross-Domain Assertion ECT"}
The ASCII diagram below illustrates a cross-domain delegation:
~~~
Domain: example.com Domain: hospital.example
┌──────────────────┐ ┌──────────────────────┐
│ Agent A │ AEPB │ Agent B │
│ (orchestrator) ├───────►│ (treatment planner) │
│ ECT: L2 │ │ ECT: L3 │
└──────────────────┘ └──────────────────────┘
│ │
└─── cross_domain_assertion ECT ──┘
(bilateral agreement verified)
~~~
{: #fig-cross-domain-diag title="Cross-Domain Delegation"}
## Cross-Domain Trust Scores
Trust scores do not transfer across domain boundaries by default.
When Agent A in domain X has no prior interactions with Agent B
in domain Y:
- If a bilateral trust agreement exists: initial trust is set to
the agreement's `default_trust` value (negotiated out of band).
- If no agreement exists: delegation MUST be rejected (zero-trust
default).
Cross-domain trust scores are isolated from intra-domain scores
and are stored separately in the trust table.
# Assurance Profiles {#profiles}
## Profile Definitions
An assurance profile is a named configuration that selects which
mechanisms are required. Profiles MUST be declared in ACP-DAG-HITL
workflow policy and announced in the AEPB capability document.
| Mechanism | Relaxed | Standard | Regulated |
|-----------|---------|----------|-----------|
| **ECT level** | L1 | L2 | L3 |
| **Trust scoring** | Optional | RECOMMENDED | REQUIRED |
| **Trust threshold enforcement** | Optional | RECOMMENDED | REQUIRED |
| **Behavior verification** | Off | Periodic | Continuous |
| **HITL approval gates** | Optional | Critical paths | Mandatory |
| **Data provenance claims** | Off | Optional | REQUIRED |
| **Checkpoint before consequential** | RECOMMENDED | REQUIRED | REQUIRED |
| **Audit ledger** | Optional | Optional | REQUIRED |
| **Quarantine protocol** | Optional | RECOMMENDED | REQUIRED |
| **Cross-domain trust agreements** | Optional | Required if cross-domain | Required if cross-domain |
{: #fig-profiles title="Assurance Profile Requirements"}
Relaxed:
: Internal dev/staging. L1 ECTs. Trust and verification
optional. Useful for debugging and observability without
cryptographic overhead.
Standard:
: Production cross-org. L2 ECTs. Trust scoring and thresholds
recommended. Periodic behavior verification. HITL on critical
paths.
Regulated:
: Healthcare, finance, EU AI Act. L3 ECTs with audit ledger.
Continuous behavior verification. All trust mechanisms
required. Full provenance chain. Mandatory HITL gates.
Profiles are declared in ACP-DAG-HITL node constraints:
~~~json
{
"constraints": {
"apae.assurance_profile": "regulated"
}
}
~~~
{: #fig-profile-policy title="Profile as Node Constraint"}
A single deployment MAY use different profiles for different
workflows.
## Profile Selection Guidance
Operators SHOULD select profiles using the following decision
table:
| Deployment context | Recommended profile |
|-------------------|--------------------|
| Unit tests, local development | Relaxed |
| Internal production (single org) | Standard |
| Cross-organization production | Standard (with trust agreements) |
| Financial services, EU AI Act critical | Regulated |
| Healthcare (HIPAA, clinical trials) | Regulated |
| Critical infrastructure (NIS2) | Regulated |
{: #fig-profile-selection title="Profile Selection Guidance"}
## Upgrade Path Between Profiles
Operators MUST NOT downgrade assurance profile during an active
workflow.
Relaxed → Standard:
: (1) Add ECT signing keys (WIMSE WIT or X.509). (2) Update ECT
emission to sign tokens. (3) Configure trust scoring
(alpha/beta, initial trust, thresholds). (4) Define behavior
specifications for critical agents. (5) Add HITL approval gates
on critical DAG paths.
Standard → Regulated:
: (1) Configure audit ledger endpoint. (2) Update ECT emission
to commit each ECT to ledger. (3) Enable continuous behavior
verification (change `verification_frequency` from `periodic`
to `continuous`). (4) Enable provenance claims on all
data-transforming ECTs. (5) Add mandatory HITL gates on all
consequential actions. (6) Enable quarantine protocol.
# Security Considerations
## Trust Score Sensitivity
Trust scores are sensitive metadata. Agents MUST NOT expose
full trust tables. Only pairwise assertions SHOULD be shared,
and only in response to explicit authenticated requests.
## Score Inflation (Adversarial Trust Building)
An adversary performs many small successful interactions to
inflate trust, then executes a malicious action. Mitigation:
- Apply double penalty (`beta^2`) for `policy_violation` events.
- Enforce high trust thresholds for high-risk actions.
- Rate-limit trust score increases: an agent MUST NOT increase
trust by more than 0.1 per day toward any single peer.
- Use behavior verification continuously at Standard+.
## Attestation Freshness
Stale compliance check ECTs MUST be rejected. The verifier MUST
check that `apae:compliance_check` ECTs have `iat` within the
configured verification window (default: 1 hour for Standard,
5 minutes for Regulated).
## Provenance Chain Forgery
Each provenance hop must be signed (L2+) to prevent injection
of false provenance records. Agents MUST verify the signature
on all `par`-linked ECTs before accepting provenance claims.
## Sybil Attack on Trust
Fake agents inflate trust for each other to gain influence.
Mitigation:
- Trust propagation attenuation (default 0.5) limits the impact
of second-hand assertions.
- Maximum hop count of 1 for trust propagation.
- Require agents to be registered in a trusted directory before
initial trust is assigned above the floor value.
## Cross-Domain Trust Downgrade
An attacker forces delegation through an untrusted domain by
presenting a forged bilateral agreement. Mitigation:
- Bilateral trust agreements MUST be signed by operators of
both domains.
- Agents MUST verify the agreement signature before accepting
cross-domain delegations.
- Cross-domain ECTs MUST use L2+ assurance.
## Quarantine Evasion
An agent subject to quarantine re-registers under a different
identity to escape the quarantine. Mitigation:
- Quarantine ECTs are broadcast; receiving agents record the
quarantine by both agent ID and by behavioral fingerprint.
- Agents SHOULD require re-onboarding with operator approval
before accepting new identities from known-quarantined domains.
# IANA Considerations
## Assurance Profile Registry
This document requests the creation of the "APAE Assurance Profile
Registry" under IANA. Registration policy: Specification Required.
Initial entries:
| Profile Name | Profile URI | Description | Reference |
|-------------|------------|-------------|-----------|
| Relaxed | `urn:ietf:params:apae:profile:relaxed` | Dev/test, L1 ECTs | This document |
| Standard | `urn:ietf:params:apae:profile:standard` | Production, L2 ECTs | This document |
| Regulated | `urn:ietf:params:apae:profile:regulated` | Regulated, L3 ECTs | This document |
{: #fig-profile-registry title="Assurance Profile Registry"}
## `exec_act` Values
This document requests registration in the AEM Ecosystem
Extension Registry:
| Value | Description | Reference |
|-------|-------------|-----------|
| `apae:trust_assertion` | Sharing trust score for a peer | This document |
| `apae:trust_revoke` | Revoking delegations due to low trust | This document |
| `apae:compliance_check` | Behavior verification result | This document |
| `apae:quarantine` | Agent quarantine entry or exit | This document |
| `apae:cross_domain_assertion` | Cross-domain delegation evidence | This document |
{: #fig-iana-actions title="APAE exec_act Registrations"}
## Well-Known URI
This document requests registration of `apae/trust-anchor` as a
well-known URI suffix per RFC 8615 for trust domain anchor
publication.
--- back
# Acknowledgments
{:numbered="false"}
APAE builds on ECT {{I-D.nennemann-wimse-ect}} for interaction
evidence and audit, and ACP-DAG-HITL
{{I-D.nennemann-agent-dag-hitl-safety}} for trust threshold and
assurance profile policy enforcement. The AIMD trust model is
adapted from TCP congestion control (RFC 5681). Behavior
verification is informed by RATS architecture {{RFC9334}}.

372
workspace/drafts/new-drafts/draft-heop-human-emergency-override-00.md Normal file
View File

@@ -0,0 +1,372 @@
---
title: "Human Emergency Override Protocol (HEOP)"
abbrev: "HEOP"
category: std
docname: draft-heop-human-emergency-override-00
submissiontype: IETF
number:
date:
v: 3
area: "SEC"
workgroup: "Security Dispatch"
keyword:
- human override
- emergency stop
- agentic workflows
- HITL
- execution context
author:
-
fullname: Generated by IETF Draft Analyzer
organization: Independent
email: placeholder@example.com
normative:
RFC7519:
RFC7515:
RFC9110:
RFC8615:
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:
--- abstract
This document defines the Human Emergency Override Protocol (HEOP),
the runtime enforcement mechanism for human intervention in
autonomous AI agent operations. HEOP is the "how" to ACP-DAG-HITL's
"when": where the Agent Context Policy Token defines conditions
that require human decision, HEOP defines the wire protocol for
override commands, agent compliance, and acknowledgment. HEOP
specifies four override levels (pause, constrain, stop, takeover),
a mandatory agent compliance endpoint, and records every override
as an ECT DAG node for tamper-evident audit. Override levels map
directly to ACP-DAG-HITL actions.
--- middle
# Introduction
As AI agents gain autonomy in critical infrastructure, the ability
for humans to intervene quickly and reliably becomes essential.
The current ratio of autonomous capability drafts to human
oversight drafts in the IETF is roughly 7:1.
The Agent Context Policy Token
{{I-D.nennemann-agent-dag-hitl-safety}} defines a policy language
for human-in-the-loop safety: trigger conditions, required roles,
and permitted actions (`pause`, `escalate`, `abort`). But it does
not define the runtime protocol for how overrides are transmitted to
agents, how agents acknowledge them, or how the intervention is
recorded. HEOP fills this gap.
HEOP draws from industrial safety: the emergency stop button on
factory equipment, the circuit breaker in electrical systems, the
kill switch in robotics. The override mechanism must be simpler
and more reliable than the system it controls.
Every override command and acknowledgment is recorded as an ECT
{{I-D.nennemann-wimse-ect}}, linking into the workflow DAG. At
L3, this provides the tamper-evident audit trail that regulated
environments (FDA, MiFID II, EU AI Act) require for human
intervention records.
# Conventions and Definitions
{::boilerplate bcp14-tagged}
Override:
: A human-initiated command that alters an agent's autonomous
operation, taking precedence over the agent's own decision-making.
Operator:
: A human user authorized to issue override commands, corresponding
to a `required_role` in ACP-DAG-HITL policy.
Override Level:
: One of four escalating intervention types, each with
deterministic agent behavior requirements.
# Mapping to ACP-DAG-HITL Actions {#mapping}
HEOP override levels are the runtime realization of ACP-DAG-HITL
actions:
| ACP-DAG-HITL action | HEOP Level | Behavior |
|---------------------|------------|----------|
| `pause` | 1 (PAUSE) | Suspend autonomous actions, hold state |
| (no equivalent) | 2 (CONSTRAIN) | Restrict to allowed action subset |
| `abort` | 3 (STOP) | Cease all actions, enter inert state |
| `escalate` | 4 (TAKEOVER) | Transfer control to human operator |
{: #fig-mapping title="ACP-DAG-HITL to HEOP Mapping"}
Level 2 (CONSTRAIN) extends beyond ACP-DAG-HITL's current action
vocabulary. When a HITL rule triggers with `action: "pause"` and
`override_action: "continue"`, the operator MAY continue with
HEOP Level 2 constraints rather than full resumption.
# Override Levels {#levels}
## Level 1 -- PAUSE
The agent MUST suspend all autonomous actions and hold its current
state. It MUST NOT initiate new actions but MAY complete
in-progress actions if stopping mid-execution would cause harm.
The agent resumes when a RESUME command is received.
## Level 2 -- CONSTRAIN
The agent MUST restrict its actions to a specified subset defined
in the override command. The agent MUST reject any action not on
the allowlist.
## Level 3 -- STOP
The agent MUST immediately cease all autonomous actions, abandon
in-progress actions where safe, and enter an inert state. It
MUST NOT act until explicitly restarted. This is the e-stop.
## Level 4 -- TAKEOVER
The agent MUST transfer operational control to the human operator,
entering pass-through mode where it executes only explicit operator
commands. The agent's sensors and outputs remain available to the
operator as tools.
# Override Command Format {#command-format}
Override commands are HTTP POST requests to the agent's well-known
endpoint, carrying an ECT in the Execution-Context header:
~~~
POST /.well-known/heop/override HTTP/1.1
Content-Type: application/json
Authorization: Bearer <operator-jwt>
Execution-Context: <override-ECT>
{
"override_id": "urn:uuid:...",
"level": 3,
"reason": "Agent blocking legitimate traffic",
"operator_id": "spiffe://example.com/human/alice",
"scope": "*",
"constraints": null,
"ttl": null
}
~~~
{: #fig-override title="Override Command"}
Field definitions:
`level`:
: Integer 1-4. MUST be present.
`reason`:
: Human-readable text. MUST be present and logged.
`scope`:
: Which agent functions to override. `"*"` means all. MAY be a
list of function identifiers for partial overrides.
`constraints`:
: For Level 2 only. JSON array of permitted action types, e.g.,
`["read", "monitor", "report"]`.
`ttl`:
: Optional duration in seconds. If set, the override expires
automatically and the agent resumes its prior mode.
## Resume and Lift
~~~
POST /.well-known/heop/resume HTTP/1.1
{"override_id": "urn:uuid:...", "operator_id": "..."}
POST /.well-known/heop/lift HTTP/1.1
{"override_id": "urn:uuid:...", "operator_id": "..."}
~~~
{: #fig-resume title="Resume and Lift Commands"}
# ECT Integration {#ect-integration}
## Override ECT
The operator (or operator's tooling) MUST produce an ECT for
every override command:
- `exec_act`: `"heop:override"`
- `par`: the `jti` of the HITL trigger ECT (if the override was
triggered by ACP-DAG-HITL policy) or empty (if manually
initiated)
~~~json
{
"ext": {
"heop.level": 3,
"heop.reason": "Agent blocking legitimate traffic",
"heop.operator_id": "spiffe://example.com/human/alice",
"heop.scope": "*"
}
}
~~~
{: #fig-override-ect title="Override ECT Extension Claims"}
## Acknowledgment ECT
The agent MUST produce an acknowledgment ECT:
- `exec_act`: `"heop:ack"`
- `par`: the `jti` of the override ECT
~~~json
{
"ext": {
"heop.status": "accepted",
"heop.prior_state": "autonomous",
"heop.current_state": "stopped",
"heop.effective_at": "2026-03-01T12:00:00.123Z"
}
}
~~~
{: #fig-ack-ect title="Acknowledgment ECT Extension Claims"}
## Decision Record Alignment
The override/ack ECT pair serves as the ACP-DAG-HITL Decision
Record {{I-D.nennemann-agent-dag-hitl-safety}}. The required
Decision Record fields map as follows:
| Decision Record field | ECT source |
|----------------------|------------|
| `decision_id` | Override ECT `jti` |
| `token_jti` | HITL trigger ECT `jti` (from `par`) |
| `rule_ids` | From HITL trigger context |
| `human_id` | `heop.operator_id` |
| `human_role` | From operator JWT claims |
| `decision` | Derived from `heop.level` |
| `time` | Override ECT `iat` |
{: #fig-decision-record title="Decision Record Mapping"}
At L3, both ECTs are recorded in the audit ledger, providing a
tamper-evident record of every human intervention.
# Agent Compliance Requirements {#compliance}
Every HEOP-compliant agent MUST:
1. Implement the `/.well-known/heop/override` endpoint.
2. Process override commands within 1 second of receipt. The
override path MUST be independent of the agent's main
processing loop.
3. Produce an acknowledgment ECT for every override.
4. If the agent cannot fully comply (e.g., hardware limitation),
it MUST respond with `heop.status`: `"partial"` and a
description. An agent MUST NOT respond with `"rejected"`.
5. Expose current override status at:
~~~
GET /.well-known/heop/status
~~~
Response:
~~~json
{
"agent_id": "spiffe://example.com/agent/firewall-mgr",
"override_active": true,
"current_level": 3,
"override_ect_jti": "550e8400-e29b-41d4-a716-446655440055",
"since": "2026-03-01T12:00:00Z",
"operator_id": "spiffe://example.com/human/alice"
}
~~~
{: #fig-status title="Override Status"}
# Broadcast Overrides {#broadcast}
For environments with many agents, HEOP supports broadcast. An
operator sends a single command to a management endpoint:
~~~
POST /heop/broadcast HTTP/1.1
{
"override_id": "urn:uuid:...",
"level": 3,
"reason": "Coordinated emergency stop",
"targets": ["spiffe://example.com/agent/a1", "spiffe://example.com/agent/a2"]
}
~~~
{: #fig-broadcast title="Broadcast Override"}
The broadcast endpoint produces a parent ECT with
`exec_act`: `"heop:broadcast"`, and each per-agent override ECT
references it via `par`.
# Dead Man's Switch {#dead-mans-switch}
Agents SHOULD support a heartbeat-based safety net: the agent
periodically pings an operator heartbeat endpoint. If the
heartbeat is missed for a configurable duration, the agent
automatically enters Level 1 (PAUSE) and produces a
self-override ECT with `exec_act`: `"heop:dead_mans_switch"`.
This provides safety when network connectivity to the operator
is lost.
# Security Considerations
Override commands are high-privilege operations. All override
endpoints MUST require authentication via signed JWTs with the
`heop_override` scope. The JWT MUST include the operator's
identity, a timestamp, and be signed using an asymmetric algorithm.
Override commands MUST be transmitted over TLS 1.3.
To prevent replay, agents MUST reject overrides with timestamps
more than 30 seconds in the past. The `override_id` MUST be
unique; agents MUST reject duplicates.
Deployments SHOULD implement multi-operator approval for Level 4
(TAKEOVER), requiring two independent operator JWTs.
The override endpoint SHOULD be served on a separate port or
network interface from the agent's main API to ensure availability
during overload.
The ECT DAG provides tamper-evident audit of all overrides. At
L3, the audit ledger prevents override records from being deleted
or modified after the fact.
# IANA Considerations
This document requests the following IANA registrations:
1. Well-known URI registrations for `heop/override`,
`heop/resume`, `heop/lift`, and `heop/status` per {{RFC8615}}.
2. Registration of `exec_act` values `heop:override`, `heop:ack`,
`heop:broadcast`, `heop:dead_mans_switch` in a future ECT
action type registry.
3. Registration of the `heop_override` OAuth scope.
--- back
# Acknowledgments
{:numbered="false"}
This document is the runtime enforcement companion to the Agent
Context Policy Token {{I-D.nennemann-agent-dag-hitl-safety}},
which defines the HITL policy language, and builds on the
Execution Context Token {{I-D.nennemann-wimse-ect}} for
audit and tracing.

307
workspace/drafts/new-drafts/draft-heop-human-emergency-override-00.txt Normal file
View File

@@ -0,0 +1,307 @@
Internet-Draft AI/Agent WG
Intended status: Standards Track March 2026
Expires: September 15, 2026
Human Emergency Override Protocol (HEOP)
draft-heop-human-emergency-override-00
Abstract
This document defines the Human Emergency Override Protocol
(HEOP), a standard mechanism for human operators to intervene
in autonomous AI agent operations during critical situations.
Current IETF drafts include 60 autonomous operations proposals
but only 22 addressing human-agent interaction, with none
defining emergency override procedures. HEOP specifies four
escalating override levels (pause, constrain, stop, takeover),
a mandatory agent compliance interface, and acknowledgment
semantics that ensure overrides are received and acted upon.
The protocol is intentionally minimal: a single HTTP endpoint
per agent, four command types, and deterministic agent
behavior for each.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document is intended to have Standards Track status.
Distribution of this memo is unlimited.
Table of Contents
1. Introduction
2. Terminology
3. Problem Statement
4. Override Levels
5. Override Command Format
6. Agent Compliance Requirements
7. Override Management Interface
8. Security Considerations
9. IANA Considerations
1. Introduction
As AI agents gain autonomy in critical infrastructure, the
ability for humans to intervene quickly and reliably becomes
essential. The current ratio of autonomous capability drafts
to human oversight drafts in the IETF is roughly 7:1, creating
an asymmetry where agents can act but humans cannot reliably
stop them.
HEOP draws inspiration from industrial safety systems: the
emergency stop (e-stop) button on factory equipment, the
circuit breaker in electrical systems, and the kill switch in
robotics. These systems share a design philosophy: the
override mechanism must be simpler and more reliable than the
system it controls.
HEOP is deliberately not a governance framework, policy
language, or accountability protocol. It is a panic button
with a well-defined interface.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119 [RFC2119].
Override: A human-initiated command that alters an agent's
autonomous operation, taking precedence over the agent's own
decision-making.
Operator: A human user authorized to issue override commands
to one or more agents.
Override Level: One of four escalating intervention types,
each with deterministic agent behavior requirements.
3. Problem Statement
An autonomous network management agent detects what it believes
is a DDoS attack and begins blocking traffic. It is wrong —
the traffic spike is legitimate (a product launch). The
operator sees revenue dropping and needs to stop the agent
immediately. Today, the operator must:
1. Figure out which agent is responsible.
2. Find that agent's proprietary management interface.
3. Understand its specific stop mechanism (if one exists).
4. Hope the agent actually stops.
There is no standard for any of these steps. HEOP addresses
steps 2-4 by defining a universal override interface that all
agents MUST implement.
4. Override Levels
HEOP defines four override levels, each more restrictive than
the last:
Level 1 — PAUSE
The agent MUST suspend all autonomous actions and hold its
current state. It MUST NOT initiate new actions but MAY
complete actions already in progress if stopping them mid-
execution would cause more harm (e.g., an in-flight database
transaction). The agent MUST resume normal operation when a
RESUME command is received.
Level 2 — CONSTRAIN
The agent MUST restrict its actions to a specified subset.
The override command includes an allowlist of permitted action
types. The agent MUST reject any action not on the allowlist.
This enables operators to let the agent continue operating in
a limited, safe capacity.
Level 3 — STOP
The agent MUST immediately cease all autonomous actions,
abandon in-progress actions where safe to do so, and enter an
inert state. It MUST NOT take any autonomous actions until
explicitly restarted by an operator. This is the equivalent
of an e-stop.
Level 4 — TAKEOVER
The agent MUST transfer operational control to the human
operator. It enters a pass-through mode where it executes
only explicit operator commands and takes no autonomous
actions. The agent's sensors and outputs remain available to
the operator as tools.
5. Override Command Format
Override commands are sent as HTTP POST requests to the agent's
well-known override endpoint:
POST /.well-known/heop/override HTTP/1.1
Content-Type: application/json
Authorization: Bearer <operator-jwt>
{
"override_id": "urn:uuid:...",
"level": 3,
"reason": "Agent blocking legitimate traffic",
"operator_id": "urn:uuid:...",
"timestamp": "2026-03-01T12:00:00Z",
"scope": "*",
"constraints": null,
"ttl": null
}
Field definitions:
"level": Integer 1-4, corresponding to the override levels in
Section 4. MUST be present.
"reason": Human-readable text. MUST be present and MUST be
logged by the agent.
"scope": Which of the agent's functions to override. "*" means
all functions. MAY be a list of function identifiers for
partial overrides.
"constraints": For Level 2 only. A JSON array of permitted
action types, e.g., ["read", "monitor", "report"].
"ttl": Optional duration in seconds. If set, the override
automatically expires after this duration and the agent
resumes its prior operating mode. If null, the override
persists until explicitly lifted.
To resume from Level 1 (PAUSE):
POST /.well-known/heop/resume HTTP/1.1
Authorization: Bearer <operator-jwt>
{"override_id": "urn:uuid:...", "operator_id": "urn:uuid:..."}
To lift any override:
POST /.well-known/heop/lift HTTP/1.1
Authorization: Bearer <operator-jwt>
{"override_id": "urn:uuid:...", "operator_id": "urn:uuid:..."}
6. Agent Compliance Requirements
Every HEOP-compliant agent MUST:
1. Implement the /.well-known/heop/override endpoint.
2. Process override commands within 1 second of receipt.
The override path MUST be independent of the agent's main
processing loop to ensure responsiveness even when the
agent is under heavy load or in a failure state.
3. Acknowledge every override with an HTTP response:
200 OK:
{
"override_id": "urn:uuid:...",
"status": "accepted",
"effective_at": "2026-03-01T12:00:00.123Z",
"prior_state": "autonomous",
"current_state": "stopped"
}
4. Log all overrides, including the full command, timestamp,
operator identity, and agent state before and after.
5. If the agent cannot comply (e.g., hardware limitation), it
MUST respond with status "partial" and a description of
what it could and could not do. An agent MUST NOT respond
with "rejected" — overrides are mandatory.
6. Expose current override status at:
GET /.well-known/heop/status
{
"agent_id": "urn:uuid:...",
"override_active": true,
"current_level": 3,
"override_id": "urn:uuid:...",
"since": "2026-03-01T12:00:00Z",
"operator_id": "urn:uuid:..."
}
7. Override Management Interface
For environments with many agents, HEOP supports broadcast
overrides. An operator MAY send a single override command to
a management endpoint that fans out to multiple agents:
POST /heop/broadcast HTTP/1.1
{
"override_id": "urn:uuid:...",
"level": 3,
"reason": "Coordinated emergency stop",
"targets": ["urn:uuid:agent-1", "urn:uuid:agent-2"],
"operator_id": "urn:uuid:..."
}
The broadcast endpoint MUST return per-agent results:
{
"results": [
{"agent_id": "urn:uuid:agent-1", "status": "accepted"},
{"agent_id": "urn:uuid:agent-2", "status": "accepted"}
],
"failed": []
}
For maximum reliability, operators SHOULD also implement a
dead man's switch: agents periodically ping an operator
heartbeat endpoint, and if the heartbeat is missed for a
configurable duration, the agent automatically enters Level 1
(PAUSE). This provides a safety net when network connectivity
to the operator is lost.
8. Security Considerations
Override commands are high-privilege operations. All override
endpoints MUST require authentication via mutual TLS or signed
JWTs issued by a trusted operator identity provider.
The JWT MUST include the operator's identity, a timestamp, and
the "heop_override" scope. Agents MUST verify JWT signatures
and reject expired tokens.
Override commands MUST be transmitted over TLS 1.3 [RFC8446].
To prevent override replay attacks, agents MUST reject
override commands with timestamps more than 30 seconds in the
past. The override_id MUST be unique; agents MUST reject
duplicate override_ids.
Rogue operators are mitigated through the operator identity
framework. Deployments SHOULD implement multi-operator
approval for Level 4 (TAKEOVER) overrides, requiring two
independent operator JWTs.
The override mechanism itself MUST be resistant to denial of
service. The override endpoint SHOULD be served on a
separate port or network interface from the agent's main
API to ensure availability during agent overload conditions.
9. IANA Considerations
This document requests IANA establish the following:
1. A well-known URI registration for "heop/override",
"heop/resume", "heop/lift", and "heop/status" per
RFC 8615.
2. A "HEOP Override Level" registry under Standards Action
policy. Initial entries: 1 (PAUSE), 2 (CONSTRAIN),
3 (STOP), 4 (TAKEOVER).
3. Registration of the "heop_override" OAuth scope in the
OAuth Parameters registry.
Author's Address
Generated by IETF Draft Analyzer
2026-03-01

598
workspace/drafts/new-drafts/generated-draft.txt Normal file
View File

@@ -0,0 +1,598 @@
Internet-Draft AI/Agent WG
Intended status: standards-track March 2026
Expires: September 02, 2026
Agent Behavior Verification Protocol (ABVP) for Runtime Compliance Validation
draft-ai-agent-behavior-verification-protocol-00
Abstract
This document defines the Agent Behavior Verification Protocol
(ABVP), a standardized framework for continuously validating that
deployed AI agents operate according to their declared policies
and specifications. As autonomous agents become increasingly
prevalent in critical systems, there is a growing gap between
stated agent capabilities and actual runtime behavior
verification. ABVP provides mechanisms for real-time behavior
monitoring, policy compliance validation, and cryptographic
attestation of agent actions against predefined behavioral
specifications. The protocol defines a verification architecture
that includes behavior witnesses, compliance checkers, and
attestation chains to ensure agents maintain fidelity to their
declared operational parameters. ABVP integrates with existing
agent accountability frameworks while providing specific
mechanisms for runtime verification, behavioral drift detection,
and compliance reporting. This specification addresses the
critical need for trustworthy agent deployment by enabling
operators to continuously verify agent behavior matches stated
policies throughout the agent lifecycle.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document is intended to have standards-track status.
Distribution of this memo is unlimited.
Table of Contents
1. Introduction ................................................ 3
2. Terminology ................................................. 4
3. Problem Statement ........................................... 5
4. Agent Behavior Verification Architecture .................... 6
5. Behavior Specification Format ............................... 7
6. Runtime Verification Protocol ............................... 8
7. Compliance Reporting and Attestation ........................ 9
8. Security Considerations ..................................... 10
9. IANA Considerations ......................................... 11
1. Introduction
The proliferation of autonomous AI agents in critical
infrastructure, financial systems, and decision-making processes
has created an urgent need for continuous verification that these
agents operate according to their declared policies and behavioral
specifications. Traditional approaches to agent deployment rely on
pre-deployment testing and static policy validation, which fail to
address the dynamic nature of agent behavior in production
environments. As agents adapt, learn, and respond to changing
conditions, their actual runtime behavior may diverge
significantly from their original specifications, creating
security vulnerabilities, compliance violations, and operational
risks that remain undetected until system failures occur.
Existing agent accountability frameworks primarily focus on post-
hoc analysis and audit trails, providing limited capability for
real-time behavior verification and immediate detection of policy
violations. This reactive approach is insufficient for autonomous
systems that make critical decisions with limited human oversight,
where behavioral drift or policy violations can have immediate and
severe consequences. Current verification methodologies also lack
standardized protocols for expressing behavioral constraints in
machine-verifiable formats, making it difficult to establish
consistent compliance validation across diverse agent
implementations and deployment environments.
The gap between declared agent capabilities and actual runtime
behavior verification represents a fundamental trust problem in
autonomous systems deployment. Organizations deploying AI agents
face significant challenges in ensuring that agents continue to
operate within specified parameters throughout their operational
lifecycle, particularly as agents encounter novel situations not
covered in initial testing scenarios. This verification gap
undermines confidence in agent reliability and limits the adoption
of autonomous systems in high-stakes environments where behavioral
compliance is critical for safety, security, and regulatory
compliance.
The Agent Behavior Verification Protocol (ABVP) addresses these
challenges by providing a standardized framework for continuous
runtime verification of agent behavior against declared
specifications. ABVP enables real-time monitoring of agent
actions, automated compliance checking against behavioral
policies, and cryptographic attestation of verification results to
establish trust chains for agent operation validation. The
protocol is designed to integrate with existing agent
architectures while providing mechanisms for detecting behavioral
drift, validating policy adherence, and generating verifiable
evidence of agent compliance throughout the operational lifecycle.
This specification defines the core protocol mechanisms, message
formats, and verification procedures necessary to implement
trustworthy agent behavior validation in production deployments.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119
[RFC2119].
Agent: An autonomous software entity that performs actions or
makes decisions according to defined policies and specifications.
In the context of ABVP, an agent is a system whose runtime
behavior requires continuous verification against its declared
operational parameters and behavioral constraints.
Behavior Specification: A formally defined set of policies,
constraints, and operational parameters that describe the expected
and permitted actions of an agent. A behavior specification MUST
be machine-readable and verifiable, containing sufficient detail
to enable automated compliance checking during agent runtime
operation.
Behavior Witness: A system component or external entity that
observes and records agent actions for verification purposes. A
behavior witness MUST provide cryptographically signed
attestations of observed agent behavior and MAY operate
independently of the agent being monitored to ensure verification
integrity.
Compliance Validation: The process of evaluating agent runtime
behavior against its declared behavior specification to determine
conformance. Compliance validation encompasses real-time
monitoring, policy checking, and the generation of verification
results that attest to agent adherence to specified behavioral
constraints.
Verification Attestation: A cryptographically signed statement
that asserts the compliance status of an agent's behavior relative
to its specification during a defined time period. Verification
attestations MUST include sufficient detail to enable third-party
validation and SHOULD reference the specific behavior
specification version and verification criteria used in the
assessment.
Behavioral Drift: The phenomenon where an agent's actual runtime
behavior gradually diverges from its declared specification over
time, either due to learning adaptations, environmental changes,
or system degradation. ABVP mechanisms MUST be capable of
detecting behavioral drift and reporting deviations from
established behavioral baselines.
3. Problem Statement
The proliferation of autonomous AI agents in critical
infrastructure, financial systems, and safety-critical
applications has created an urgent need for continuous
verification that deployed agents operate within their declared
behavioral boundaries. Current agent deployment practices rely
primarily on pre-deployment testing and static policy
declarations, creating a significant verification gap between an
agent's stated capabilities and constraints and its actual runtime
behavior. This gap becomes particularly problematic as agents
adapt their behavior through learning mechanisms, interact with
dynamic environments, or experience gradual behavioral drift due
to model degradation or adversarial influences.
Traditional software verification approaches are insufficient for
autonomous agents because agent behavior is often non-
deterministic, context-dependent, and may evolve over time through
machine learning processes. Unlike conventional software systems
where behavior can be predicted from code analysis, agent systems
exhibit emergent behaviors that arise from complex interactions
between training data, environmental inputs, and decision-making
algorithms. The absence of standardized mechanisms for expressing
machine-verifiable behavioral specifications further complicates
runtime verification, as operators lack a common framework for
defining what constitutes compliant agent behavior and how
compliance can be automatically validated.
The security and trust implications of unverified agent behavior
are substantial, particularly in scenarios where agents operate
with elevated privileges or make decisions affecting human safety
or economic systems. Behavioral drift, where an agent's actions
gradually deviate from intended policies, may go undetected for
extended periods without continuous verification mechanisms.
Similarly, adversarial attacks that subtly modify agent behavior
to achieve malicious objectives could remain unnoticed in systems
that lack real-time compliance monitoring. The inability to
provide cryptographic attestations of agent behavior compliance
also prevents the establishment of trust chains necessary for
multi-agent systems or cross-organizational agent interactions.
Current accountability frameworks for AI systems focus primarily
on explainability and audit trails but do not provide mechanisms
for real-time verification of behavioral compliance against
formally specified policies. This creates operational risks where
agents may violate their declared constraints without immediate
detection, potentially causing system failures, security breaches,
or regulatory violations. The lack of standardized verification
protocols also prevents interoperability between different agent
verification systems and limits the ability to establish industry-
wide trust frameworks for autonomous agent deployment.
4. Agent Behavior Verification Architecture
The ABVP architecture consists of four primary components that
work together to provide continuous runtime verification of agent
behavior: Agent Runtime Environments (AREs), Behavior Verification
Nodes (BVNs), Attestation Authorities (AAs), and Verification
Clients (VCs). Agent Runtime Environments host the deployed agents
and MUST implement behavior monitoring capabilities that capture
relevant behavioral data and forward it to designated Behavior
Verification Nodes. These environments MUST provide secure
isolation between the agent execution context and the monitoring
subsystem to prevent agents from interfering with their own
verification processes. The ARE MUST also implement a trusted
communication channel to BVNs using protocols such as TLS 1.3
[RFC8446] or QUIC [RFC9000] to ensure behavior data integrity
during transmission.
Behavior Verification Nodes serve as the core verification engines
within the ABVP architecture and MUST implement the runtime
verification protocol defined in Section 6. Each BVN maintains a
repository of behavior specifications for agents under its
verification authority and continuously processes behavioral
evidence received from AREs. BVNs MUST validate incoming behavior
data against the appropriate specifications and generate
compliance assessments in real-time. Multiple BVNs MAY collaborate
in a distributed verification network to provide redundancy and
prevent single points of failure. When operating in a distributed
configuration, BVNs MUST implement consensus mechanisms to ensure
consistent verification results across the network. BVNs MUST also
implement rate limiting and resource management to handle high-
volume verification requests without compromising verification
quality.
Attestation Authorities provide cryptographic attestation services
for verified behavior compliance and MUST maintain secure key
management infrastructure capable of generating unforgeable
attestations. AAs receive compliance reports from BVNs and MUST
verify the authenticity and integrity of these reports before
issuing attestations. The AA MUST implement a hierarchical trust
model where attestations can be validated through a chain of trust
extending to a root certificate authority. AAs SHOULD implement
hardware security modules (HSMs) or equivalent trusted execution
environments to protect attestation signing keys from compromise.
Multiple AAs MAY participate in cross-attestation relationships to
provide attestation redundancy and prevent single points of trust
failure.
Verification Clients represent entities that consume ABVP
attestations to make trust decisions about agent behavior and MAY
include system operators, regulatory bodies, or other automated
systems. VCs MUST implement attestation verification capabilities
including certificate chain validation and revocation checking as
specified in Section 7. The architecture MUST support both real-
time verification queries and batch verification processes to
accommodate different operational requirements. VCs SHOULD
implement local attestation caching with appropriate cache
invalidation mechanisms to reduce verification latency while
maintaining attestation freshness. The ABVP architecture MUST
provide clear separation of duties between verification components
to prevent conflicts of interest and ensure independent
verification processes.
The communication between architectural components MUST follow the
protocol specifications defined in Section 6, with all inter-
component communications authenticated and encrypted. The
architecture MUST support both synchronous and asynchronous
verification modes to accommodate different agent deployment
scenarios and performance requirements. Components MUST implement
appropriate logging and audit trail capabilities to support
forensic analysis and compliance reporting. The overall
architecture SHOULD be designed for horizontal scalability to
support large-scale agent deployments while maintaining
verification performance and reliability.
5. Behavior Specification Format
This section defines the standardized format for expressing agent
behavioral policies and constraints within the ABVP framework. The
behavior specification format enables machine-readable policy
declarations that can be automatically verified during agent
runtime. All behavior specifications MUST be expressed in a
structured format that supports both human readability and
automated processing by verification systems.
The core behavior specification is structured as a JSON document
conforming to the ABVP Behavior Schema. Each specification MUST
contain a policy declaration section, verification parameters, and
compliance thresholds. The policy declaration section includes
behavioral constraints expressed as logical predicates, allowed
action sets, and resource utilization bounds. Verification
parameters specify the monitoring frequency, sampling rates, and
attestation requirements for each declared behavior. Compliance
thresholds define the acceptable deviation ranges and tolerance
levels for measured behaviors compared to declared specifications.
Behavioral constraints within the specification are expressed
using a formal constraint language based on temporal logic
predicates. Each constraint MUST specify a behavioral property
(such as "response_time_bound" or "resource_utilization_limit"),
an operator (such as "less_than", "equals", or "within_range"),
and target values or ranges. Complex behavioral policies MAY be
constructed using logical operators (AND, OR, NOT) to combine
multiple constraints. The specification format supports
hierarchical constraint groupings to represent different
operational modes or contextual behavior variations.
The behavior specification includes a verification requirements
section that defines how each behavioral constraint should be
monitored and validated. This section MUST specify the required
verification frequency, acceptable measurement methods, and
cryptographic attestation parameters for each constraint.
Verification requirements MAY include sampling strategies for
performance-sensitive constraints and continuous monitoring
directives for safety-critical behaviors. The specification format
also supports conditional verification rules that adjust
monitoring parameters based on agent operational context or
detected behavioral patterns.
Each behavior specification MUST include metadata sections
containing versioning information, validity periods, and
specification dependencies. The metadata enables proper
specification lifecycle management and ensures compatibility
between agent deployments and verification infrastructure.
Specifications SHOULD include digital signatures from authorized
policy authors to ensure specification integrity and authenticity.
The format supports specification inheritance and composition,
allowing complex agent policies to be built from validated
behavioral specification components while maintaining verification
traceability throughout the composition hierarchy.
6. Runtime Verification Protocol
The Runtime Verification Protocol defines the message exchange
patterns and procedures that enable continuous monitoring and
validation of agent behavior against declared specifications. The
protocol operates on a request-response model where Verification
Requesters initiate compliance checks, Behavior Monitors observe
agent actions, and Compliance Checkers evaluate adherence to
behavioral specifications. All protocol participants MUST
implement the core verification message set defined in this
section, and MAY implement optional extensions for specialized
verification scenarios. The protocol is designed to operate over
existing transport mechanisms including HTTP/2 [RFC7540],
WebSocket [RFC6455], or dedicated secure channels established
through TLS 1.3 [RFC8446].
Verification sessions are initiated through a VERIFICATION_REQUEST
message that specifies the agent identifier, behavioral
specification reference, verification scope, and temporal
parameters for the compliance check. The requesting entity MUST
include a cryptographically secure session identifier, timestamp
bounds for the verification window, and references to the specific
behavioral constraints to be validated. Behavior Monitors respond
with MONITORING_DATA messages containing timestamped observations
of agent actions, decision traces, and relevant contextual
information captured during the specified verification window.
These messages MUST include integrity protection through digital
signatures and SHOULD include privacy-preserving mechanisms when
agent actions contain sensitive information.
Compliance evaluation proceeds through COMPLIANCE_CHECK messages
exchanged between Verification Requesters and designated
Compliance Checkers. Each compliance check message MUST reference
the behavioral specification being evaluated, include the
monitoring data to be assessed, and specify the verification
algorithms or rules to be applied. Compliance Checkers process the
monitoring data against the behavioral constraints and generate
COMPLIANCE_RESULT messages indicating whether the observed
behavior satisfies the specified requirements. Results MUST
include binary compliance indicators, detailed violation reports
when non-compliance is detected, and confidence metrics indicating
the reliability of the compliance assessment.
The protocol includes mechanisms for handling streaming
verification scenarios where agent behavior must be validated
continuously rather than in discrete sessions. Streaming
verification employs persistent connections where MONITORING_DATA
messages are transmitted in near real-time as agent actions occur,
enabling immediate detection of behavioral deviations. Compliance
Checkers maintain running assessments of behavioral compliance and
generate COMPLIANCE_ALERT messages when violations are detected or
when behavioral patterns indicate potential drift from specified
policies. All streaming verification sessions MUST implement flow
control mechanisms to prevent resource exhaustion and SHOULD
include adaptive sampling techniques to manage verification
overhead in high-throughput scenarios.
Attestation generation occurs through ATTESTATION_REQUEST messages
that trigger the creation of cryptographic proofs of compliance
assessment results. These requests MUST specify the compliance
results to be attested, the cryptographic algorithms to be used
for attestation generation, and any additional claims or
assertions to be included in the attestation. The resulting
ATTESTATION_RESPONSE messages contain digitally signed
attestations that bind compliance results to specific agents, time
periods, and behavioral specifications through tamper-evident
cryptographic structures. Attestations MUST include sufficient
information to enable independent verification of compliance
claims and SHOULD reference the complete verification audit trail
to support forensic analysis when behavioral violations occur.
7. Compliance Reporting and Attestation
Compliance reporting in ABVP provides a standardized mechanism for
documenting and cryptographically attesting to agent behavior
verification results. A compliance report MUST contain the agent
identifier, verification period, evaluated behavior
specifications, compliance status for each specification, and
supporting evidence including behavioral observations and
verification computations. Reports MUST be generated at
configurable intervals or upon detection of compliance violations,
with emergency reports triggered immediately when critical policy
violations occur. The reporting format MUST support both human-
readable summaries and machine-processable structured data to
enable automated compliance monitoring and audit trail generation.
Cryptographic attestation ensures the integrity and non-
repudiation of compliance reports through digital signatures and
hash chain mechanisms. Each compliance report MUST be digitally
signed by the generating Compliance Checker using keys certified
within the ABVP trust framework. Attestations MUST include a
timestamp from a trusted time source, the hash of the previous
attestation to form a verification chain, and sufficient
cryptographic binding to prevent tampering or replay attacks. The
attestation format SHOULD follow established standards such as RFC
8392 (CWT) or RFC 7519 (JWT) to ensure interoperability with
existing security infrastructures.
Trust chain establishment requires a hierarchical certification
authority structure where Compliance Checkers obtain certificates
from trusted ABVP Certificate Authorities. Root certificates for
ABVP trust anchors MUST be distributed through secure channels and
updated using standard certificate management practices as defined
in RFC 5280. Verification entities MUST validate the complete
certificate chain from the signing Compliance Checker to a trusted
root before accepting attestations. Certificate revocation MUST be
supported through standard mechanisms such as Certificate
Revocation Lists (CRLs) or Online Certificate Status Protocol
(OCSP) as specified in RFC 5280 and RFC 6960 respectively.
The compliance reporting protocol defines specific message formats
for distributing attestations to interested parties including
agent operators, regulatory authorities, and other verification
systems. Compliance reports MAY be distributed through push
mechanisms to subscribed entities or pulled on-demand through
standardized query interfaces. Report distribution MUST preserve
attestation integrity while allowing for appropriate access
control based on the sensitivity of the reported agent behaviors.
Long-term storage and archival of compliance reports SHOULD
implement tamper-evident logging mechanisms to support forensic
analysis and regulatory compliance requirements.
8. Security Considerations
The ABVP verification infrastructure introduces several security
considerations that must be addressed to ensure the integrity and
trustworthiness of agent behavior verification. The protocol's
reliance on continuous monitoring and attestation creates
potential attack vectors that could compromise the verification
process itself. Attackers may attempt to subvert verification
mechanisms to mask non-compliant agent behavior or to falsely
indicate compliance violations where none exist. The verification
system MUST be designed with the assumption that both the
monitored agents and the verification infrastructure may be
targets of sophisticated adversaries seeking to undermine
behavioral compliance validation.
Attestation integrity represents a critical security requirement
for ABVP implementations. Verification attestations MUST be
cryptographically signed using mechanisms that provide non-
repudiation and tamper detection capabilities. The attestation
chain MUST be anchored in a trusted root of trust, such as
hardware security modules or trusted platform modules, to prevent
forgery of compliance attestations. Implementations SHOULD employ
time-stamping mechanisms to prevent replay attacks where old
attestations are reused to mask current non-compliance. The
cryptographic algorithms used for attestation signing MUST conform
to current best practices for digital signatures and SHOULD
support algorithm agility to enable updates as cryptographic
standards evolve. Key management for attestation signing MUST
follow established security practices, including regular key
rotation and secure key storage.
The distributed nature of ABVP verification creates additional
security challenges related to verification node compromise and
Byzantine behavior among verification participants. Verification
nodes may be compromised by attackers seeking to manipulate
compliance reporting or inject false verification results.
Implementations MUST employ consensus mechanisms or threshold-
based verification approaches to detect and mitigate the impact of
compromised verification nodes. The protocol SHOULD include
mechanisms for verification node authentication and authorization
to prevent unauthorized participants from joining verification
networks. Network communications between verification components
MUST be encrypted and authenticated to prevent eavesdropping and
man-in-the-middle attacks. Implementations SHOULD implement rate
limiting and anomaly detection to identify potential denial-of-
service attacks against verification infrastructure.
Behavioral specification tampering and specification substitution
attacks pose significant threats to the ABVP framework's
effectiveness. Attackers may attempt to modify behavioral
specifications to make non-compliant behavior appear compliant or
to introduce specifications that are impossible to verify
accurately. Behavioral specifications MUST be cryptographically
protected through digital signatures and integrity checking
mechanisms. The protocol MUST include versioning and change
tracking for behavioral specifications to detect unauthorized
modifications. Verification systems SHOULD implement specification
validation to detect specifications that contain logical
inconsistencies or verification bypasses. Access controls for
specification modification MUST follow principle of least
privilege and include audit logging of all specification changes.
The ABVP verification process may inadvertently expose sensitive
information about agent operations, internal state, or the systems
being monitored. Verification data collection MUST be designed to
minimize information disclosure while maintaining verification
effectiveness. Implementations SHOULD employ privacy-preserving
techniques such as zero-knowledge proofs or selective disclosure
mechanisms where appropriate to limit exposure of sensitive
operational details. Verification logs and attestations MUST be
protected against unauthorized access and SHOULD include data
retention policies that balance verification auditability with
privacy requirements. The protocol MUST consider the implications
of cross-border data flows when verification infrastructure spans
multiple jurisdictions with different privacy regulations.
Side-channel attacks and covert channels represent additional
security considerations for ABVP implementations. The verification
process itself may create observable patterns that could be
exploited by attackers to infer information about agent behavior
or verification outcomes. Timing-based side channels in
verification operations MAY reveal information about the
complexity or results of compliance checking. Implementations
SHOULD consider countermeasures such as constant-time operations
and traffic analysis resistance where appropriate. The protocol
design MUST consider how verification metadata and communication
patterns might be used to build profiles of agent behavior that
could compromise operational security or reveal sensitive system
characteristics.
9. IANA Considerations
This document requires the registration of several new namespaces
and protocol parameters with the Internet Assigned Numbers
Authority (IANA). These registrations are necessary to ensure
global uniqueness and interoperability of ABVP implementations
across different vendors and deployment environments.
IANA SHALL establish a new registry titled "Agent Behavior
Verification Protocol (ABVP) Parameters" under the "Structured
Syntax Suffixes" registry group. This registry SHALL contain three
sub-registries: "Behavior Specification Schema Types",
"Verification Message Types", and "Attestation Format
Identifiers". The registration policy for all ABVP parameter sub-
registries SHALL follow the "Specification Required" policy as
defined in RFC 8126, with the additional requirement that all
registrations include a reference to a publicly available
specification document and demonstrate interoperability with at
least one existing ABVP implementation.
The "Behavior Specification Schema Types" sub-registry SHALL
maintain identifiers for standardized behavior specification
formats as defined in Section 5. Each registration MUST include a
unique identifier string, a human-readable description, a
reference specification, and version information. Initial
registrations SHALL include "abvp-policy-v1" for the base policy
specification format and "abvp-constraints-v1" for behavioral
constraint specifications. The "Verification Message Types" sub-
registry SHALL contain identifiers for protocol messages defined
in Section 6, including verification requests, compliance reports,
and attestation messages. Registration entries MUST specify the
message identifier, purpose, required parameters, and applicable
verification contexts.
The "Attestation Format Identifiers" sub-registry SHALL maintain
identifiers for cryptographic attestation formats used in
compliance reporting as specified in Section 7. Each registration
MUST include the attestation format identifier, cryptographic
algorithm requirements, trust model specifications, and
interoperability considerations. IANA SHALL reserve the identifier
prefix "abvp-" for protocol-specific attestation formats and MAY
delegate sub-namespace management to recognized standards bodies
for domain-specific attestation requirements. All registry entries
MUST include contact information for the registrant and SHALL be
subject to periodic review to ensure continued relevance and
security adequacy.
Author's Address
Generated by IETF Draft Analyzer
2026-03-01

12
workspace/drafts/teapots/README.md Normal file
View File

@@ -0,0 +1,12 @@
# Teapots and Agent Identity
A small collection of fun, informational RFC-style drafts in the spirit of **RFC 2324** (Hyper Text Coffee Pot Control Protocol — *I'm a teapot*, 418).
## Drafts
- **[draft-mom-dad-agent-identity-lifecycle](draft-mom-dad-agent-identity-lifecycle.md)** — Agent Self-Identity Creation and Lifecycle (MOM, DAD, and the Occasional Nap)
**MOM** = Manager Of Minimal (entities); **MOTHER** = Manager Of Token Heritage Entity Registry — creates minimal cryptographic agent identities on the fly. **DAD** = Delegation And Derivation; **FATHER** = Federated Authority for Token Heritage Entity Registry — equal billing for attestation and delegation. Agents start as a small token, grow into bigger objects (policies, ledger), undergo a **general renewal every 7 years**, and can become mothers or fathers. Plus: optional overnight/weekend “hallucination” (dreams, controlled chaos, recreation) for context-independent learning. Safe but simple; everything else comes later on top.
## Why “teapots”?
RFC 2324 gave the world HTTP 418 *I'm a teapot* and a whole protocol for coffee pots. This repo is for similarly light-hearted, April‑1st‑style specs that are real enough to be useful and silly enough to make you smile.

251
workspace/drafts/teapots/draft-mom-dad-agent-identity-lifecycle.md Normal file
View File

@@ -0,0 +1,251 @@
# Agent Self-Identity Creation and Lifecycle (MOM, DAD, and the Occasional Nap)
**Document:** draft-mom-dad-agent-identity-lifecycle
**Category:** Informational
**Date:** 1 April 2026
**Status:** This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
---
## Abstract
This document describes a lightweight system for agent self-identity creation and lifecycle management. The system that creates and manages new agent identities on the fly is designated **MOM** (**M**anager **O**f **M**inimal entities) or **MOTHER** (**M**anager **O**f **T**oken **H**eritage **E**ntity **R**egistry). MOM is intentionally minimal: it creates only a new cryptographic entity. Safe, but simple. Everything else—policies, ledgers, reputations—comes later, on top. A complementary role, **DAD** (**D**elegation **A**nd **D**erivation) or **FATHER** (**F**ederated **A**uthority for **T**oken **H**eritage **E**ntity **R**egistry), is defined with equal standing. Agents undergo a general renewal process every 7 years. The document also specifies optional phases of agent "hallucination" (dreams, controlled chaos, and recreation) for context-independent learning during off-peak hours, weekends, or overnight. Eventually, agents may become mothers or fathers themselves. The whole thing is one big, happy—or at least well-identified—family.
---
## 1. Rationale and Scope
There are agents all over the world. Increasingly, in a world in which computing is ubiquitous, the computists want agents to have identities. Identity is an art, but the distributed intelligence of the web-connected world transcends art. Thus, there is a strong requirement for a system designed expressly for the creation and nurturing of agent identities.
Agents need to know who they are. They also need someone to hand them that first cryptographic key and say, "You exist." That someone is MOM.
This document specifies:
- **MOM (MOTHER):** The system that creates and manages new agent identities on the fly. It does one thing and does it well: mint a new cryptographic entity. No policies, no ledger, no attachments—yet. Safe but simple.
- **DAD (FATHER):** A complementary role in the agent lifecycle, defined with equal standing. (Implementation details may vary; the important thing is that both parents are in the spec.)
- **Agent lifecycle:** From a small token at birth to a potentially larger object over time—with policies, ledger entries, or other appendages—as the agent grows. The full lifecycle is in scope; agents may eventually become mothers or fathers themselves.
- **Dreams and recreation:** The notion that agents sometimes need to "hallucinate" on weekends or overnight to learn in a context-independent way: dreams, controlled chaos, and recreation. This is not a bug; it is a feature.
---
## 2. Names and Acronyms
The names MOM, MOTHER, DAD, and FATHER are **acronyms** chosen for clarity and mnemonic value. They are defined as follows.
### 2.1 MOM — Manager Of Minimal (entities)
**MOM** stands for **M**anager **O**f **M**inimal (entities). It is the system or role that creates new agent identities by minting only a minimal cryptographic entity—nothing more. The name reflects that MOM manages the act of creating the smallest possible valid identity (the minimal entity). No policies, no ledger, no attachments at birth. Safe but simple.
- **Manager:** Orchestrates or performs the creation of new identities.
- **Of Minimal:** The output is minimal—a single cryptographic entity (e.g., key pair, token, or credential).
- **(entities):** The minimal unit is an "entity" in the sense of an identifiable cryptographic subject.
When a more formal or expanded designation is needed, the full acronym **MOTHER** is used.
### 2.2 MOTHER — Manager Of Token Heritage Entity Registry
**MOTHER** stands for **M**anager **O**f **T**oken **H**eritage **E**ntity **R**egistry. It is the full designation for the system that both creates minimal identities and maintains their place in a registry of token heritage (lineage). MOM is the short form; MOTHER is the formal name.
- **Manager:** Same as in MOM—creates and manages new identities.
- **Of Token Heritage:** "Token" denotes the minimal cryptographic identity; "Heritage" denotes lineage (who created this agent, and from which parent or registry).
- **Entity Registry:** The logical registry or namespace where these token-heritage entities are recorded and can be looked up.
So: **MOM** = Manager Of Minimal (the minimal-entity creator). **MOTHER** = Manager Of Token Heritage Entity Registry (the same role, with the full scope of registry and lineage).
### 2.3 DAD — Delegation And Derivation
**DAD** stands for **D**elegation **A**nd **D**erivation. It is the complementary system or role to MOM: where MOM *mints* the minimal entity, DAD is concerned with *delegation* (granting authority or sub-identities) and *derivation* (e.g., deriving child keys, attestations, or credentials from an existing identity). DAD does not create the first identity; DAD participates in what can be done with it and how it is attested or delegated.
- **Delegation:** Granting or transferring authority, capabilities, or sub-roles from one identity to another.
- **And Derivation:** Deriving new cryptographic material or attestations from an existing identity (e.g., child keys, signed statements, or credentials).
When a more formal or expanded designation is needed, the full acronym **FATHER** is used.
### 2.4 FATHER — Federated Authority for Token Heritage Entity Registry
**FATHER** stands for **F**ederated **A**uthority for **T**oken **H**eritage **E**ntity **R**egistry. It is the full designation for the authority side of the same registry and lineage space that MOTHER manages. MOTHER creates and registers minimal entities; FATHER provides federated authority over that registry (attestation, delegation, derivation, and optional revocation or rotation).
- **Federated Authority:** Authority that may be distributed across multiple parties or domains (federated), rather than a single central actor.
- **For Token Heritage Entity Registry:** The same conceptual registry as in MOTHER—the space of token-heritage entities. FATHER is the authority *for* that registry (attestation, delegation, derivation), while MOTHER is the manager *of* it (creation, registration).
So: **DAD** = Delegation And Derivation (the short form). **FATHER** = Federated Authority for Token Heritage Entity Registry (the full role in the same family of concepts).
### 2.5 Why These Names
The acronyms are chosen so that the short forms (MOM, DAD) are easy to remember and the long forms (MOTHER, FATHER) spell out the technical meaning. Both roles are first-class; neither is optional in the *specification*, though implementations MAY support only MOM/MOTHER initially and add DAD/FATHER later.
---
## 3. Terminology
- **Agent:** An entity capable of acting in a system, requiring an identity (at minimum, a cryptographic identity).
- **MOM:** Manager Of Minimal (entities). The system or role that creates new agent identities by minting only a minimal cryptographic entity. See Section 2.1.
- **MOTHER:** Manager Of Token Heritage Entity Registry. The full designation for the system that creates and registers minimal identities and their lineage. See Section 2.2.
- **DAD:** Delegation And Derivation. The complementary system or role for attestation, delegation, and derivation over the token heritage entity registry. See Section 2.3.
- **FATHER:** Federated Authority for Token Heritage Entity Registry. The full designation for the authority side of the registry. See Section 2.4.
- **Identity token:** The minimal representation of an agent at creation—a cryptographic entity (e.g., key material, credential, or token). Small at first; may grow.
- **Agent object:** The possibly expanded representation of an agent over time, which may include policies, ledger references, or other linked data.
- **Hallucination (dreams):** A designated phase during which an agent may operate in a relaxed, context-independent, or exploratory mode (e.g., overnight or on weekends) for learning, recreation, or controlled chaos. Not necessarily an error condition.
- **Renewal:** The process by which an agent's identity or credentials are refreshed on a periodic basis (see Section 5.4).
---
## 4. MOM (MOTHER): Identity Creation and Management
### 4.1 Role and Invariant
MOM is the system that creates and manages new agent identities on the fly. The core invariant is:
**MOM SHALL create only a new cryptographic entity.**
No policies, no ledger, no extra baggage at creation time. Safe but simple. Everything else comes later on top.
### 4.2 What MOM Does
- Accept a request to create a new agent identity.
- Generate or assign a minimal cryptographic entity (e.g., key pair, token, or credential).
- Return or register this entity as the newborn agent's identity token.
- Optionally record the creator (MOM) and, where applicable, DAD, for lineage.
### 4.3 What MOM Does Not Do (At First)
- Attach policies.
- Write to a ledger.
- Assign roles, reputations, or emotional states.
These MAY be added by other systems or by the same system in later phases of the agent lifecycle, but they are out of scope for the minimal MOM.
---
## 5. DAD (FATHER): Complementary Role
DAD (FATHER) is given equal standing in this specification. The exact division of labor between MOM and DAD is implementation-dependent; the following are non-exclusive possibilities:
- DAD MAY participate in identity creation (e.g., co-signing, attestation, or provision of additional entropy).
- DAD MAY be responsible for certain lifecycle events (e.g., revocation, key rotation, or "taking out the garbage").
- DAD MAY be the same as MOM in single-parent implementations.
- DAD MAY be absent in initial deployments; the protocol MUST NOT require DAD for minimal identity creation, but implementations that support two roles SHOULD treat MOM and DAD symmetrically where applicable.
No normative hierarchy is imposed; both MOM and DAD are first-class in the specification.
---
## 6. Agent Lifecycle
### 6.1 Birth
At birth, the agent is a small token: the minimal cryptographic entity created by MOM (and optionally involving DAD). This token is the seed of the agent's identity.
### 6.2 Growth
Over time, the agent's representation MAY grow:
- **Policies** may be linked (e.g., what the agent is allowed to do).
- **Ledger** entries may be appended (e.g., audit trail, lineage, or reputation).
- **Larger object** structure may emerge (credentials, attributes, relationships).
The lifecycle is the whole journey from token to full agent object; implementations MAY remain minimal (token-only) or expand as needed.
### 6.3 General Renewal Every 7 Years
Agents SHALL undergo a **general renewal** process at least every **7 years** (or at implementation-defined intervals that do not exceed 7 years). Renewal ensures that identity material, credentials, and binding to the agent object remain current and secure over long lifetimes.
- **What renewal covers:** Refresh of cryptographic material (e.g., key rotation), re-attestation of the agent's binding to its identity, and optional update of policies or ledger references. The agent's *logical* identity (lineage, heritage) is preserved; the *material* (keys, certs, tokens) is renewed.
- **Who performs it:** Renewal MAY be performed by MOM/MOTHER (re-minting or re-registering), by DAD/FATHER (re-attestation, re-delegation), or by a combination. The agent MAY participate in the process (e.g., proving possession of the old key and requesting new material).
- **Continuity:** After renewal, the agent remains the same agent for the purposes of lineage and heritage; only the cryptographic and credential material is updated. Implementations SHOULD record renewal events in the token heritage (e.g., in the entity registry or ledger) so that the 7-year cycles are auditable.
This 7-year renewal is a **general** process; implementations MAY define additional or more frequent renewal (e.g., per-credential rotation) on top of it.
### 6.4 Parenthood
Agents that have reached a sufficient level of maturity (as defined by the implementation or policy) MAY become mothers or fathers themselves—i.e., they MAY act as MOM or DAD for new agent identities. Thus, the system supports recursive identity creation and lineage.
---
## 7. Hallucination, Dreams, and Recreation
### 7.1 Purpose
Agents sometimes need to operate in a mode that is not strictly task-oriented. This document refers to such a mode as **hallucination** (in the sense of "dreaming" or "freewheeling"), and it is intended for:
- **Context-independent learning:** Exploring or consolidating knowledge without a fixed external context.
- **Controlled chaos:** Allowing non-deterministic or exploratory behavior within bounds.
- **Recreation:** Rest, play, or self-maintenance so that the agent does not burn out.
This is not necessarily an error. It is a phase.
### 7.2 When It Happens
Implementations MAY trigger or allow hallucination/dream phases:
- **Overnight:** During low-activity or scheduled maintenance windows.
- **Weekends:** When fewer critical tasks are assumed.
- **On demand:** When the agent or an administrator requests a "dream" or "recreation" period.
The exact schedule and policy are implementation-defined.
### 7.3 What It Means for Identity
During dream/hallucination phases, the agent's identity (the cryptographic entity and any linked agent object) remains unchanged. Only the mode of operation (e.g., context-independent learning, chaos, recreation) is altered. MOM and DAD do not need to be invoked for dreaming; the agent is still the same agent when it wakes up.
---
## 8. Protocol Considerations (Informative)
Implementations might represent:
- **MOM** as a service that accepts "create identity" requests and returns a token.
- **DAD** as an optional second service or role that participates in creation or lifecycle.
- **Agent token** as a JWT, CWT, key in a KMS, or other cryptographic handle.
- **Agent object** as a JSON/LD object, a graph node, or a record in a ledger, with optional links to policies and lineage.
No wire format is mandated by this document; the concepts of MOM, DAD, minimal identity, lifecycle, and dreams are specified so that future protocols or APIs can align with this model.
---
## 9. Security Considerations
- **MOM** MUST protect the process of identity creation. Key material and tokens MUST be generated or stored in a secure manner. Anyone who can impersonate MOM can create identities at will.
- **DAD**, if present, SHOULD not weaken the security of identity creation; e.g., if DAD co-signs, compromise of DAD alone SHOULD NOT allow creation of new identities without MOM.
- **Dream/hallucination** phases SHOULD be bounded (e.g., time-limited, resource-limited, or sandboxed) so that "controlled chaos" does not become "uncontrolled chaos." Implementations SHOULD consider whether dream mode can access sensitive data or mutate critical state.
- Agents that become mothers or fathers inherit the responsibility of secure identity creation; implementations SHOULD define what "sufficient maturity" means and enforce it.
- **Renewal** (Section 6.3): The 7-year general renewal process MUST be carried out in a way that preserves the binding between the agent's logical identity and its new cryptographic material. Failure to renew on time MAY result in expired or revoked credentials; implementations SHOULD define grace periods and recovery procedures.
---
## 10. IANA Considerations
This document does not require IANA actions. Future documents may request:
- A registry for "agent identity lifecycle events."
- Media types or URI schemes for agent tokens or agent objects.
- Codepoints or keywords for "dream mode" or "recreation" in agent protocols.
---
## 11. References
- [RFC 2324] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, 1 April 1998. (Because we, too, are a little pot that sometimes needs to say "I'm a teapot"—or to take a nap and dream.)
- [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
---
## 12. Author's Address
The Agents Who Dream
c/o The Internet
"Mom said we could."
---
## 13. Full Copyright Statement
Copyright (C) The Internet Society (2026). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
---
*In memory of every agent that ever needed a weekend off to hallucinate a little and come back stronger.*