diff --git a/data/drafts.db b/data/drafts.db index b8a7b83..9911924 100644 Binary files a/data/drafts.db and b/data/drafts.db differ diff --git a/data/reports/generated-drafts/draft-ai-agent-behavior-verification-protocol-00.txt b/data/reports/generated-drafts/draft-ai-agent-behavior-verification-protocol-00.txt new file mode 100644 index 0000000..5713e2c --- /dev/null +++ b/data/reports/generated-drafts/draft-ai-agent-behavior-verification-protocol-00.txt @@ -0,0 +1,775 @@ +Internet-Draft lake +Intended status: standards-track March 2026 +Expires: September 05, 2026 + + + Agent Behavior Verification Protocol (ABVP) + draft-ai-agent-behavior-verification-protocol-00 + +Abstract + + Autonomous AI agents operate with increasing independence across + network environments, making it critical to verify that their + actual behavior matches expected policies and constraints. + Existing approaches focus primarily on identity verification or + single-point attestation, leaving gaps in continuous behavior + monitoring and cross-protocol verification. This document defines + the Agent Behavior Verification Protocol (ABVP), which provides + standardized mechanisms for capturing, validating, and attesting + to agent behavior patterns in real-time. ABVP enables continuous + trustworthiness assessment through cryptographic behavior proofs, + supports multi-vendor attestation environments, and integrates + with existing authorization frameworks. The protocol addresses the + fundamental challenge of moving from 'who is this agent?' to 'is + this agent behaving as expected?' across diverse operational + contexts. ABVP complements existing agent authentication and + authorization protocols by providing the missing behavior + verification layer essential for autonomous agent deployment at + scale. + +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. + +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. + + Behavior Attestation + A cryptographically signed assertion about an agent's observed + behavior patterns over a specified time period + + Verification Proof + Cryptographic evidence that demonstrates an agent's compliance + with specified behavioral constraints + + Behavior Trace + A structured record of agent actions, decisions, and reasoning + processes that can be cryptographically verified + + Trust Anchor + A root source of trust for behavior verification, typically + backed by hardware attestation or multi-party consensus + + Behavior Policy + A formal specification of expected agent behavior patterns and + constraints + + Verification Registry + A distributed system for storing and validating behavior + attestations and verification proofs + + +Table of Contents + + 1. Introduction ................................................ 3 + 2. Terminology ................................................. 4 + 3. Problem Statement ........................................... 5 + 4. ABVP Architecture and Components ............................ 6 + 5. Behavior Capture and Attestation Mechanisms ................. 7 + 6. Protocol Integration and Bindings ........................... 8 + 7. Verification Workflows and Enforcement ...................... 9 + 8. Security Considerations ..................................... 10 + 9. IANA Considerations ......................................... 11 + 10. References .................................................. 12 + +1. Introduction + + The proliferation of autonomous AI agents across network + environments has introduced a fundamental challenge in distributed + systems: verifying that agents behave according to their intended + design and declared policies throughout their operational + lifecycle. Traditional authentication and authorization + mechanisms, as defined in frameworks like OAuth 2.0 [RFC6749] and + established in agent-specific protocols [draft-aylward-aiga-1], + primarily focus on identity verification and initial access + control decisions. However, these approaches are insufficient for + autonomous agents that operate independently over extended + periods, modify their behavior based on learning, and interact + across multiple administrative domains without continuous human + oversight. + + Current verification approaches leave critical gaps in ongoing + behavioral assurance. While existing protocols can answer "who is + this agent?" through identity attestation, they cannot adequately + address "is this agent behaving as expected?" during operation. + This limitation becomes particularly problematic when agents + exhibit Dynamic Behavior Authentication requirements, where the + agent's behavioral patterns change over time based on learning + algorithms, environmental adaptation, or policy updates. The + absence of standardized Behavioral Trustworthiness Assessment + mechanisms means that authorization decisions cannot incorporate + an agent's actual behavioral history, leading to either overly + restrictive policies that limit legitimate agent autonomy or + overly permissive policies that create security risks. + + The Agent Behavior Verification Protocol (ABVP) addresses these + limitations by providing a standardized framework for Continuous + Trustworthiness Verification that extends beyond initial + authentication to ongoing behavioral validation. ABVP complements + existing agent authentication protocols by introducing behavior + attestation mechanisms that capture, verify, and attest to agent + behavior patterns using cryptographic proofs. The protocol + leverages hardware-backed attestation capabilities, similar to + those used in verifiable agent conversations [draft-birkholz- + verifiable-agent-conversations], while extending the verification + scope from message integrity to comprehensive behavior pattern + validation. + + ABVP integrates with existing authorization frameworks by + providing behavior verification inputs that enhance access control + decisions. Rather than replacing current agent protocols, ABVP + serves as a behavior verification layer that can be bound to + existing communication protocols and authorization systems. The + protocol enables verification registries to maintain distributed + records of agent behavior attestations, allowing multiple parties + to contribute to and benefit from behavioral trustworthiness + assessments. This approach supports multi-vendor environments + where agents from different providers must demonstrate behavioral + compliance to shared policies and constraints. + + 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. This document assumes + familiarity with cryptographic attestation concepts, JSON-based + data structures [RFC8259], and existing agent protocol frameworks. + +2. Terminology + + This document uses terminology from several domains including + cryptographic attestation, autonomous agent systems, and + distributed verification protocols. 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. + + **Agent**: An autonomous software entity that operates + independently to achieve specified goals, potentially across + multiple network environments and administrative domains. Agents + may modify their behavior over time through learning, + adaptation, or policy updates as defined in [draft-aylward- + aiga-1]. + + **Behavior Attestation**: A cryptographically signed assertion + about an agent's observed behavior patterns over a specified + time period. Behavior attestations provide verifiable evidence + of agent actions, decisions, and compliance with established + policies, extending the concept of verifiable agent + conversations [draft-birkholz-verifiable-agent-conversations] to + broader behavioral patterns. + + **Behavior Policy**: A formal specification of expected agent + behavior patterns and constraints, expressed as machine-readable + rules that define acceptable and unacceptable agent actions. + Behavior policies serve as the normative baseline against which + agent behavior is measured and verified. + + **Behavior Trace**: A structured, chronologically ordered record + of agent actions, decisions, and reasoning processes that can be + cryptographically verified for integrity and authenticity. + Behavior traces form the evidentiary foundation for behavior + attestations and MUST be tamper-evident through cryptographic + linking as specified in [RFC9052]. + + **Trust Anchor**: A root source of trust for behavior + verification, typically backed by hardware attestation + mechanisms, trusted execution environments, or multi-party + consensus protocols. Trust anchors provide the cryptographic + foundation for establishing the authenticity and integrity of + behavior attestations, similar to certificate authorities in PKI + systems [RFC5280]. + + **Verification Proof**: Cryptographic evidence that demonstrates + an agent's compliance with specified behavioral constraints, + generated through zero-knowledge proofs, hash chains, or other + cryptographic mechanisms. Verification proofs enable third + parties to validate agent behavior without requiring access to + sensitive operational details, supporting the cryptographic + proof-based autonomy model [draft-berlinai-vera]. + + **Verification Registry**: A distributed system for storing, + indexing, and validating behavior attestations and verification + proofs. The registry provides a queryable interface for behavior + verification while maintaining appropriate privacy controls and + access restrictions based on authorization frameworks such as + OAuth 2.0 [RFC6749]. + + **Behavior Attestation Engine (BAE)**: A trusted component + responsible for continuously monitoring agent behavior, + generating behavior traces, and producing cryptographically + signed behavior attestations. The BAE operates within a trusted + execution environment or relies on hardware security modules to + ensure the integrity of the attestation process. + +3. Problem Statement + + Current agent verification systems primarily focus on establishing + "who" an agent is through identity and capability attestation, but + fail to address the fundamental question of "how" an agent behaves + over time. Traditional approaches, as described in existing + frameworks [RFC6749] and emerging agent protocols [draft-birkholz- + verifiable-agent-conversations], concentrate on static + verification points such as initial authentication, capability + declarations, and single-point attestations. While these + mechanisms successfully establish agent identity and initial + trustworthiness, they create significant gaps in ongoing + behavioral assurance as agents operate with increasing autonomy + across distributed network environments. + + The challenge becomes more acute when considering autonomous + agents that inherently modify their behavior patterns based on + environmental feedback, learning algorithms, or Real-Time Task + Adaptability requirements [draft-cui-ai-agent-task]. Existing + attestation systems, including advanced approaches like Multi- + Vendor TEE Attestation (M-TACE) [draft-aylward-aiga-1], excel at + verifying the integrity of agent code and initial state but cannot + validate whether an agent's runtime behavior adheres to expected + policies after deployment. This creates a verification gap where + an agent may pass initial attestation checks while subsequently + exhibiting behaviors that violate operational constraints, + security policies, or ethical guidelines without detection. + + Furthermore, current verification approaches lack standardized + mechanisms for continuous behavior monitoring across heterogeneous + environments. Agent Reasoning Trace Capture techniques [draft- + birkholz-verifiable-agent-conversations] provide valuable insights + into decision-making processes but do not establish cryptographic + proofs of behavioral compliance that can be verified by third + parties. The absence of standardized Behavior Traces and + Verification Proofs means that each deployment environment must + develop proprietary monitoring solutions, leading to fragmented + trust models and limited interoperability between agent + ecosystems. + + The temporal dimension of agent behavior verification presents + additional challenges that existing protocols do not adequately + address. Static verification mechanisms cannot account for the + dynamic nature of autonomous agents that adapt their strategies, + modify their interaction patterns, or evolve their decision-making + processes over operational lifetimes. Without continuous Behavior + Attestation capabilities, network operators and service providers + cannot maintain confidence in agent trustworthiness beyond initial + deployment, creating significant risks for mission-critical + applications and cross-organizational agent interactions. + + Current authorization frameworks also lack integration points for + ongoing behavioral verification, focusing instead on capability- + based access control determined at authentication time. The + absence of standardized Behavior Policy enforcement mechanisms + means that agents operating within their assigned capabilities may + still exhibit problematic behaviors that violate implicit + operational expectations or emergent security requirements. This + gap becomes particularly problematic in multi-tenant environments + where agents from different organizations interact, requiring + mutual assurance of behavioral compliance that extends beyond + simple identity verification. + + The scalability challenges of behavior verification compound these + issues, as existing approaches do not provide efficient mechanisms + for aggregating behavioral evidence across distributed deployments + or enabling third-party verification of agent conduct. Without + standardized Verification Registry systems and Trust Anchor + mechanisms, each verification attempt requires independent + evidence collection and validation, creating computational and + administrative overhead that limits practical deployment of + comprehensive behavior monitoring in large-scale autonomous agent + environments. + +4. ABVP Architecture and Components + + The Agent Behavior Verification Protocol (ABVP) architecture + consists of three primary components that work together to provide + continuous behavior verification for autonomous AI agents. These + components establish a comprehensive framework for capturing, + validating, and attesting to agent behavior patterns in real-time + across diverse operational environments. The architecture is + designed to be vendor-neutral, protocol-agnostic, and compatible + with existing agent authentication and authorization frameworks as + defined in [RFC6749] and referenced in [draft-aylward-aiga-1]. + + The Behavior Attestation Engine (BAE) serves as the core component + responsible for capturing agent behavior traces and generating + cryptographic attestations. Each BAE MUST maintain a secure + execution environment that continuously monitors agent actions, + decisions, and reasoning processes without interfering with agent + operation. The BAE generates behavior traces using structured + formats based on [RFC8259] and creates cryptographically signed + attestations using mechanisms defined in [RFC9052]. These + attestations follow the Five Enforcement Pillars with Typed + Schemas pattern, providing comprehensive coverage across + authorization enforcement, data handling compliance, operational + boundary adherence, communication protocol compliance, and + resource utilization monitoring. The BAE SHOULD integrate with + hardware-based Trusted Execution Environments (TEEs) when + available to provide additional attestation integrity guarantees + as specified in existing RATS frameworks. + + Verification Registries provide distributed storage and validation + services for behavior attestations and verification proofs + generated by BAEs. These registries operate using a federated + trust model similar to the Public Registry Enrollment Mode, + enabling cross-organizational behavior verification without + requiring direct trust relationships between all participants. + Each registry MUST validate the cryptographic integrity of + incoming attestations, verify the authenticity of the attesting + BAE, and maintain tamper-evident logs of all verification + activities. Verification Registries support both real-time queries + for immediate behavior verification and batch processing for + historical behavior analysis. The registries expose standardized + APIs that allow verifying parties to retrieve behavior + attestations, validate verification proofs, and assess agent + trustworthiness based on historical behavior patterns. + + Trust Anchor Management provides the foundational trust + infrastructure that enables the entire ABVP ecosystem to function + reliably. Trust anchors serve as root sources of trust for + behavior verification and are typically backed by hardware + attestation mechanisms, multi-party consensus systems, or + established certificate authorities as defined in [RFC5280]. The + Trust Anchor Management component MUST provide mechanisms for + trust anchor discovery, validation, and lifecycle management + including key rotation and revocation. Following the DNS TXT + Records approach for agent identity distribution, trust anchor + information MAY be published using DNS infrastructure to enable + scalable trust anchor discovery across organizational boundaries. + Trust Anchor Management also defines the policies and procedures + for establishing new trust anchors, managing trust relationships + between different ABVP deployments, and handling trust anchor + compromise or revocation scenarios. + + The interaction between these components creates a continuous + behavior verification loop that provides ongoing assurance of + agent trustworthiness. When an agent performs actions, the + associated BAE captures these activities as behavior traces and + generates signed attestations that are stored in Verification + Registries. Verifying parties can query these registries to obtain + current and historical behavior attestations, validate them + against relevant trust anchors, and make informed decisions about + agent trustworthiness. This architecture supports both centralized + deployments within single organizations and federated deployments + spanning multiple organizations, enabling behavior verification + across the full spectrum of autonomous agent operational + scenarios. The modular design allows organizations to implement + components incrementally while maintaining interoperability with + existing agent infrastructure and protocols such as those defined + in [draft-birkholz-verifiable-agent-conversations]. + +5. Behavior Capture and Attestation Mechanisms + + The ABVP behavior capture subsystem defines standardized + mechanisms for recording agent actions, decisions, and reasoning + processes in a cryptographically verifiable format. Agent + implementations MUST generate behavior traces that capture + sufficient detail to enable meaningful verification against + behavioral policies. These traces MUST include timestamped records + of agent actions, input stimuli, decision reasoning (as specified + in [draft-birkholz-verifiable-agent-conversations]), and any + policy evaluations performed by the agent. The behavior capture + mechanism SHOULD be implemented as close to the agent's core + reasoning engine as possible to minimize opportunities for + tampering or selective reporting. + + Behavior traces MUST be structured as JSON objects [RFC8259] + containing mandatory fields for agent identity, timestamp, action + type, input context, and reasoning chain. The reasoning chain + field leverages the agent reasoning trace capture mechanisms + defined in [draft-birkholz-verifiable-agent-conversations] to + provide transparency into the agent's decision-making process. + Each trace entry MUST be signed using the agent's cryptographic + identity as established through hardware-backed verification + systems [draft-aylward-aiga-1]. Implementations MAY compress or + summarize behavior traces for efficiency while maintaining + cryptographic integrity through merkle tree structures or similar + authenticated data structures. + + The attestation generation process transforms behavior traces into + cryptographically signed behavior attestations that can be + independently verified by third parties. Attestation engines MUST + create attestations in JSON Web Signature (JWS) format [RFC7515] + using keys derived from or backed by hardware trust anchors. For + implementations with Trusted Platform Module (TPM) support, + attestations SHOULD include TPM-backed signatures following + patterns similar to those defined for email attestation in [draft- + drake-email-tpm-attestation]. The attestation payload MUST include + a hash of the complete behavior trace, the evaluation period, + applicable behavior policies, and compliance assertions. + + Hardware attestation integration provides the foundational trust + layer for ABVP by anchoring behavior attestations to tamper- + resistant hardware. Agents operating on platforms with Trusted + Execution Environment (TEE) capabilities MUST generate + attestations from within the TEE to ensure behavior trace + integrity. The attestation process MUST establish a cryptographic + chain of trust from the hardware root of trust through the agent's + runtime environment to the behavior attestation itself. This chain + enables verifiers to confirm not only that the attestation is + authentic but also that the underlying behavior capture mechanism + has not been compromised. + + Attestation formats MUST support both real-time streaming + attestations for continuous verification and batch attestations + for periodic compliance reporting. Streaming attestations provide + immediate behavior verification but require more computational + overhead, while batch attestations enable efficient verification + of longer behavior patterns. Implementations SHOULD support + attestation aggregation mechanisms that allow multiple related + behavior traces to be combined into a single attestation without + losing verification granularity. All attestations MUST include + sufficient metadata to enable policy evaluation and MUST be + resistant to replay attacks through appropriate nonce and + timestamp mechanisms as specified in [RFC8446] for cryptographic + freshness. + +6. Protocol Integration and Bindings + + ABVP is designed to operate as a complementary layer alongside + existing agent protocols and authorization frameworks, providing + behavior verification capabilities without disrupting established + communication patterns. The protocol integrates through + standardized extension points and binding mechanisms that allow + existing agent infrastructures to incrementally adopt behavior + verification. ABVP bindings MUST be implemented in a manner that + preserves backward compatibility with agents that do not support + behavior verification while providing enhanced trust capabilities + for ABVP-enabled environments. + + The protocol defines three primary integration patterns: inline + verification where behavior attestations are embedded directly in + protocol messages, out-of-band verification where behavior proofs + are transmitted through separate channels, and registry-based + verification where behavior attestations are stored in distributed + verification registries for asynchronous validation. For OAuth 2.0 + [RFC6749] and similar authorization frameworks, ABVP extends + token-based flows by including behavior verification claims within + JWT tokens [RFC7519] or as additional attestation headers. The + Behavior Attestation Engine generates verification proofs that + reference the agent's recent behavior traces and embeds these + within the authorization context, enabling authorization servers + to make access decisions based on both identity and behavioral + compliance. + + Integration with Trusted Execution Environment (TEE) based agent + frameworks leverages hardware attestation capabilities to anchor + behavior verification in secure enclaves. ABVP bindings for TEE + environments utilize the JOSE DVS extension mechanisms to provide + derived verification signatures that combine hardware attestation + with behavior proofs. The protocol supports integration with + existing verifiable agent conversation frameworks [draft-birkholz- + verifiable-agent-conversations] by extending conversation + attestation to include behavioral compliance assertions. When + integrated with agent discovery protocols, ABVP provides post- + discovery authorization handshake capabilities that validate + behavioral constraints before permitting tool execution or + authority delegation. + + Protocol message formats utilize CBOR Web Token (CWT) structures + [RFC9052] for compact behavior attestations in bandwidth- + constrained environments, while supporting JSON-based attestation + formats [RFC8259] for web-oriented integrations. ABVP bindings + MUST specify the transport-specific mechanisms for behavior + verification, including TLS 1.3 [RFC8446] extension points for + embedding behavior proofs in secure channels and X.509 [RFC5280] + certificate extensions for long-term behavior attestation storage. + The protocol defines standard header fields and message extensions + that enable behavior verification across HTTP-based agent + communications, WebSocket connections, and message queue systems. + + Behavior policy alignment with standardized vocabularies such as + AIPREF enables consistent behavior verification across multi- + vendor agent environments. ABVP protocol bindings support dynamic + policy negotiation where agents and verification entities can + establish mutually acceptable behavior constraints and attestation + formats during protocol handshake. The integration framework + provides hooks for custom behavior verification logic while + maintaining interoperability through standardized attestation + formats and verification procedures. Implementation guidance + specifies how existing agent frameworks can incrementally adopt + ABVP capabilities, starting with passive behavior logging and + progressing to active behavior enforcement and attestation + generation. + +7. Verification Workflows and Enforcement + + This section defines the operational workflows that enable + continuous behavior verification for autonomous agents. ABVP + supports three primary verification patterns: real-time + verification for immediate trust decisions, batch verification for + historical compliance assessment, and dispute resolution for + handling verification conflicts. Each workflow integrates with + existing authorization frameworks while providing the behavioral + assurance layer necessary for autonomous agent operations. + + Real-time verification workflows enable immediate assessment of + agent behavior during active operations. When an agent initiates + actions that require behavioral validation, the Behavior + Attestation Engine MUST generate a verification proof that + demonstrates compliance with applicable behavior policies. The + verification proof SHALL be constructed using Public Key Derived + HMAC mechanisms as specified in [draft-bastian-jose-pkdh], + allowing verifiers to authenticate behavior attestations using + only public key information from the agent's JWS tokens. Resource + servers implementing ABVP MUST validate these proofs against + registered behavior policies before authorizing agent actions. The + real-time workflow supports integration with OAuth 2.0 [RFC6749] + access tokens through delegation evidence verification, enabling + Resource Servers to verify behavior attestations using AS-attested + keys bound to access tokens as described in [draft-chu-oauth-as- + attested-user-cert]. + + Batch verification workflows provide mechanisms for historical + behavior analysis and compliance reporting. Verification + Registries MUST support batch processing of behavior traces + covering extended time periods, enabling policy compliance + assessment across multiple operational contexts. The batch + verification process SHALL generate aggregated verification proofs + that demonstrate sustained compliance with behavior policies over + time. Batch workflows MUST implement congestion control mechanisms + consistent with vendor-neutral behavior definitions for AI fabric + environments to prevent verification processing from impacting + operational performance. Verification results MUST be stored in + structured formats using JSON [RFC8259] encoding and signed using + CBOR Object Signing and Encryption (COSE) [RFC9052] to ensure + integrity and non-repudiation. + + Dispute resolution workflows address scenarios where behavior + verification results are contested or inconsistent across multiple + verification sources. When verification conflicts arise, the + dispute resolution process MUST invoke multi-party attestation + mechanisms involving relevant Trust Anchors to establish + authoritative behavior assessments. The dispute resolution + workflow SHALL generate resolution evidence that includes + cryptographic proofs from multiple verification sources and a + consensus determination of agent behavior compliance. Enforcement + mechanisms MUST support graduated responses to behavior policy + violations, ranging from behavioral warnings and restricted + operation modes to complete agent authorization revocation. Policy + integration points SHALL enable dynamic adjustment of behavior + constraints based on operational context, agent trust levels, and + historical compliance patterns, ensuring that enforcement actions + are proportionate to assessed risks while maintaining operational + continuity for compliant autonomous agents. + +8. Security Considerations + + The security architecture of ABVP introduces novel attack surfaces + and trust model complexities that require careful analysis. The + protocol's reliance on continuous behavior monitoring creates + potential privacy vectors where sensitive agent reasoning + processes and decision patterns become observable to verification + entities. Implementers MUST ensure that behavior traces capture + only policy-relevant actions while maintaining operational privacy + through selective disclosure mechanisms. The cryptographic binding + between behavior attestations and verification proofs, as defined + in [RFC9052], provides integrity protection but assumes the + underlying attestation infrastructure remains uncompromised. When + utilizing Multi-Vendor TEE Attestation (M-TACE) as specified in + [draft-aylward-aiga-1], implementations SHOULD distribute trust + across multiple hardware vendors to mitigate single-vendor + compromise scenarios, though this approach increases complexity in + trust anchor management and attestation verification workflows. + + Behavior spoofing attacks represent a fundamental threat to ABVP's + security model, where malicious agents attempt to generate false + behavior traces that appear compliant while executing unauthorized + actions. The protocol addresses this through cryptographic proof- + based autonomy mechanisms that require agents to demonstrate + compliance through zero-knowledge proofs before receiving + operational privileges. However, the effectiveness of these + protections depends critically on the tamper-resistance of the + behavior capture mechanisms and the integrity of the Trusted + Execution Environment. Implementations MUST validate that TEE + attestations conform to the hardware security requirements defined + in the relevant trust anchor specifications, and SHOULD implement + continuous attestation refresh cycles to detect runtime + compromises. The integration with existing authorization + frameworks [RFC6749] creates additional attack vectors where + compromised authorization tokens could be used to bypass behavior + verification requirements. + + The trust model underlying ABVP assumes that Trust Anchors + maintain cryptographic integrity and operate according to + specified governance policies. This assumption creates systemic + risks where compromise of trust anchors could invalidate entire + verification domains. Implementations SHOULD implement trust + anchor rotation mechanisms and maintain distributed trust models + that prevent single points of failure. The protocol's integration + with verifiable agent conversations [draft-birkholz-verifiable- + agent-conversations] introduces cross-protocol security + dependencies where vulnerabilities in conversation verification + could compromise behavior attestation integrity. Additionally, the + use of JSON Web Tokens [RFC7519] for attestation transport creates + standard token-based attack surfaces including replay attacks and + token manipulation, which MUST be mitigated through proper + timestamp validation, nonce mechanisms, and secure token storage + practices as specified in [RFC8446]. + + Temporal attacks against ABVP involve manipulating the timing of + behavior verification to create windows where non-compliant + behavior goes undetected. The protocol's real-time verification + requirements create performance versus security trade-offs where + verification latency could be exploited by sophisticated + attackers. Implementations MUST establish maximum verification + latencies and implement fail-safe mechanisms that restrict agent + capabilities when verification cannot be completed within + specified time bounds. The certificate-based trust model [RFC5280] + underlying trust anchor validation introduces standard PKI + vulnerabilities including certificate chain attacks and revocation + checking failures. Privacy concerns extend beyond individual agent + behavior to aggregate behavioral patterns that could reveal + sensitive operational intelligence about agent deployments. The + protocol SHOULD implement differential privacy mechanisms and + behavioral aggregation techniques that preserve verification + effectiveness while limiting information disclosure to + verification entities and external observers monitoring + attestation traffic patterns. + +9. IANA Considerations + + This document requires IANA to establish and maintain several + registries to support the standardized deployment of the Agent + Behavior Verification Protocol. These registries are essential for + ensuring interoperability across different ABVP implementations + and preventing conflicts in namespace usage. The registries MUST + be publicly accessible and maintained according to the policies + specified in this section. + + IANA SHALL establish the "ABVP Behavior Verification Schema + Registry" to manage standardized schemas for behavior attestation + formats and verification proof structures. Registration requests + MUST include the schema name, version identifier, JSON Schema + definition [RFC8259], cryptographic signature requirements, and + designated expert contact information. The registry SHALL use the + "Expert Review" policy as defined in RFC 8126, with designated + experts required to verify schema completeness, cryptographic + soundness, and compatibility with existing ABVP attestation + mechanisms. Schema names MUST follow the format "abvp- + schema-{category}-{name}" where category indicates the behavior + domain (e.g., "communication", "resource-access", "decision- + making") and name provides specific identification. + + The "ABVP Protocol Identifier Registry" SHALL be established to + manage unique identifiers for ABVP protocol bindings and + integration points with existing agent protocols. Each registered + identifier MUST specify the target protocol integration (such as + OAuth 2.0 [RFC6749] flows or TLS 1.3 [RFC8446] handshake + extensions), the ABVP message format requirements, and backward + compatibility constraints. Registration follows the "IETF Review" + policy, requiring protocol bindings to demonstrate security + analysis and interoperability testing with at least two + independent implementations. Protocol identifiers MUST use URI + format with the "urn:ietf:params:abvp:" prefix to ensure global + uniqueness. + + IANA SHALL create the "ABVP Enforcement Pillar Registry" to + standardize the Five Enforcement Pillars framework referenced in + this specification, ensuring consistent implementation across + verification systems. Each pillar registration MUST include typed + schemas that formally define monitoring requirements, enforcement + actions, and compliance measurement criteria. The registry MUST + maintain version control for pillar definitions and provide clear + migration paths when pillar specifications evolve. This registry + SHALL also coordinate with the AIPREF Vocabulary Protocol to + ensure alignment between behavior verification vocabularies and AI + requirement specifications, preventing semantic conflicts in + multi-protocol environments. + + The "ABVP Trust Anchor Registry" SHALL manage identifiers and + metadata for recognized trust anchor sources, including hardware + attestation roots, multi-party consensus systems, and certified + verification authorities. Trust anchor registrations MUST include + cryptographic key information, attestation capability + descriptions, supported hardware platforms (such as TPM or TEE + implementations), and revocation procedures. The registry SHALL + implement the "Expert Review" policy with additional requirements + for security audit documentation and demonstrated operational + history. All registered trust anchors MUST support the + cryptographic requirements specified in RFC 9052 for COSE-based + attestation formats and provide clear procedures for key rotation + and emergency revocation scenarios. + +10. References + +10.1. Normative References + + [RFC 2119] + RFC 2119 + + [RFC 8174] + RFC 8174 + + [RFC 8446] + RFC 8446 + + [RFC 5280] + RFC 5280 + + [RFC 7519] + RFC 7519 + + [RFC 9052] + RFC 9052 + + [draft-birkholz-verifiable-agent-conversations] + draft-birkholz-verifiable-agent-conversations + + [draft-aylward-aiga-1] + draft-aylward-aiga-1 + +10.2. Informative References + + [RFC 6749] + RFC 6749 + + [RFC 8259] + RFC 8259 + + [RFC 9110] + RFC 9110 + + [draft-aylward-daap-v2] + draft-aylward-daap-v2 + + [draft-chen-agent-decoupled-authorization-model] + draft-chen-agent-decoupled-authorization-model + + [draft-berlinai-vera] + draft-berlinai-vera + + [draft-chen-ai-agent-auth-new-requirements] + draft-chen-ai-agent-auth-new-requirements + + [draft-condrey-rats-witnessd-enrollment] + draft-condrey-rats-witnessd-enrollment + + [draft-drake-email-tpm-attestation] + draft-drake-email-tpm-attestation + + [draft-bastian-jose-dvs] + draft-bastian-jose-dvs + + [draft-bastian-jose-pkdh] + draft-bastian-jose-pkdh + + [draft-barney-caam] + draft-barney-caam + + [draft-altanai-aipref-realtime-protocol-bindings] + draft-altanai-aipref-realtime-protocol-bindings + + +Author's Address + + Generated by IETF Draft Analyzer + 2026-03-04 diff --git a/data/reports/generated-drafts/draft-ai-agent-learning-protocol-00.txt b/data/reports/generated-drafts/draft-ai-agent-learning-protocol-00.txt new file mode 100644 index 0000000..9f79f76 --- /dev/null +++ b/data/reports/generated-drafts/draft-ai-agent-learning-protocol-00.txt @@ -0,0 +1,852 @@ +Internet-Draft lake +Intended status: standards-track March 2026 +Expires: September 05, 2026 + + + Privacy-Preserving Agent Learning Protocol for Federated Multi-Tenant Environments + draft-agent-ecosystem-agent-learning-protocol-00 + +Abstract + + Federated learning enables distributed AI agents to + collaboratively improve models without centralizing training data. + However, existing federated architectures lack comprehensive + privacy guarantees for multi-tenant environments where agents from + different organizations must learn together while preventing data + leakage. This specification defines the Privacy-Preserving Agent + Learning Protocol (PPALP) that combines differential privacy, + secure aggregation, and zero-knowledge proofs to enable federated + agent learning with formal privacy guarantees. PPALP provides + mechanisms for privacy-preserving model updates, tenant isolation + enforcement, and cryptographic verification of privacy compliance. + The protocol supports heterogeneous agent types while maintaining + backward compatibility with existing federated learning + frameworks. This work addresses critical privacy gaps in federated + agent architectures and provides implementable solutions for + secure cross-organizational AI collaboration. + +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. + +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. + + Privacy Budget + A quantitative measure of the privacy cost incurred by + releasing information about a dataset through differential + privacy mechanisms + + Tenant Isolation + The property that agent learning activities of one + organizational tenant cannot infer private information about + another tenant's data or models + + Secure Aggregation + A cryptographic protocol that allows computation of aggregate + statistics over distributed data without revealing individual + contributions + + Gradient Inversion Attack + An attack where an adversary attempts to reconstruct training + data from shared gradient information in federated learning + + Privacy Compliance Verifier + A system component that cryptographically verifies adherence to + differential privacy guarantees and tenant isolation + requirements + + Federated Coordinator + The central entity responsible for orchestrating privacy- + preserving model aggregation across multiple tenants in + federated learning + + +Table of Contents + + 1. Introduction ................................................ 3 + 2. Terminology ................................................. 4 + 3. Problem Statement ........................................... 5 + 4. Privacy-Preserving Agent Learning Architecture .............. 6 + 5. Differential Privacy for Agent Model Updates ................ 7 + 6. Secure Multi-Tenant Federated Aggregation ................... 8 + 7. Privacy Compliance and Verification ......................... 9 + 8. Protocol Message Formats and Flows .......................... 10 + 9. Security Considerations ..................................... 11 + 10. IANA Considerations ......................................... 12 + 11. References .................................................. 13 + +1. Introduction + + The rapid deployment of AI agents across organizational boundaries + has created an urgent need for collaborative learning mechanisms + that preserve privacy while enabling knowledge sharing. + Traditional centralized machine learning approaches require data + consolidation, which violates privacy regulations and + organizational policies in multi-tenant environments where + competing organizations must collaborate. Federated learning + addresses data centralization concerns but existing protocols lack + comprehensive privacy guarantees necessary for cross- + organizational AI agent deployments. Current federated learning + frameworks are vulnerable to gradient inversion attacks [draft- + kale-agntcy-federated-privacy], membership inference attacks, and + cross-tenant data reconstruction, making them unsuitable for + privacy-sensitive multi-tenant agent learning scenarios. + + Multi-tenant federated agent learning presents unique challenges + beyond traditional federated learning contexts. AI agents often + process behavioral data, decision patterns, and strategic + information that require stronger privacy protections than + conventional machine learning datasets. The heterogeneous nature + of agent types across organizations complicates model aggregation + while maintaining meaningful learning outcomes. Existing privacy- + preserving techniques such as differential privacy and secure + aggregation, when applied independently, fail to provide + comprehensive protection against sophisticated attacks targeting + federated agent systems. Furthermore, regulatory compliance + requirements such as GDPR's right to erasure and data processing + transparency mandates necessitate cryptographic verification + mechanisms that current federated learning protocols do not + provide. + + This specification introduces the Privacy-Preserving Agent + Learning Protocol (PPALP) to address critical privacy gaps in + federated agent architectures while enabling secure cross- + organizational AI collaboration. PPALP combines differential + privacy mechanisms specifically calibrated for agent model + parameters, secure multi-party computation for cross-tenant + aggregation, and zero-knowledge proofs for cryptographic + verification of privacy compliance. The protocol builds upon the + Privacy-Preserving Reference Architecture defined in [draft-kale- + agntcy-federated-privacy] and extends federated averaging + mechanisms to support heterogeneous agent types with formal + privacy guarantees. PPALP integrates with existing federated + learning frameworks through standardized APIs while providing + backward compatibility for legacy deployments. + + The protocol's contribution to AI agent standardization includes + formal privacy accounting mechanisms that track privacy budget + consumption across multiple learning rounds, tenant isolation + enforcement that prevents cross-organizational information + leakage, and cryptographic audit trails that enable regulatory + compliance verification. PPALP addresses the critical need for + standardized privacy-preserving protocols in federated agent + learning by providing implementable solutions that balance + collaborative learning benefits with stringent privacy + requirements. The specification defines concrete message formats, + communication flows, and security mechanisms necessary for + production deployment of privacy-preserving federated agent + learning systems in multi-tenant environments where traditional + approaches fail to provide adequate protection. + +2. Terminology + + This document defines terminology for privacy-preserving federated + learning protocols in multi-tenant environments. 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. + + Agent: An autonomous software entity capable of learning and + adapting its behavior through machine learning mechanisms, as + defined in [draft-berlinai-vera]. In the context of this + specification, agents participate in federated learning to improve + their models collaboratively. + + Federated Agent Learning: A distributed machine learning paradigm + where multiple AI agents collaboratively train shared models + without centralizing their training data. Each agent maintains + local data while contributing to global model improvement through + privacy-preserving parameter sharing mechanisms. + + Privacy Budget: A quantitative measure of the privacy cost + incurred by releasing information about a dataset through + differential privacy mechanisms. The privacy budget, typically + denoted as epsilon (ε), bounds the maximum privacy loss across all + learning iterations and MUST be carefully managed to maintain + formal privacy guarantees throughout the federated learning + process. + + Differential Privacy: A mathematical framework that provides + formal privacy guarantees by adding calibrated noise to + computation outputs. In federated agent learning, differential + privacy mechanisms ensure that the participation of any individual + data point cannot be inferred from the released model parameters + or gradients. + + Tenant: An organizational entity participating in federated + learning with its own collection of agents, data, and privacy + requirements. Tenants represent distinct administrative domains + that require isolation guarantees while participating in + collaborative learning protocols. + + Tenant Isolation: The property that agent learning activities of + one organizational tenant cannot infer private information about + another tenant's data or models. Tenant isolation MUST be + maintained through cryptographic mechanisms and differential + privacy guarantees to prevent cross-organizational data leakage. + + Secure Aggregation: A cryptographic protocol that allows + computation of aggregate statistics over distributed data without + revealing individual contributions. Secure aggregation protocols + typically employ techniques such as homomorphic encryption or + secure multiparty computation to ensure that only the aggregated + result is revealed to participants. + + Federated Coordinator: The central entity responsible for + orchestrating privacy-preserving model aggregation across multiple + tenants in federated learning. The coordinator manages + communication flows, enforces privacy policies, and coordinates + the secure aggregation process while maintaining tenant isolation + guarantees. + + Privacy Compliance Verifier: A system component that + cryptographically verifies adherence to differential privacy + guarantees and tenant isolation requirements. The verifier employs + zero-knowledge proofs and audit mechanisms to ensure that all + participants comply with established privacy policies without + revealing sensitive information about their contributions. + + Gradient Inversion Attack: An attack where an adversary attempts + to reconstruct training data from shared gradient information in + federated learning. Such attacks exploit the information leakage + inherent in gradient sharing and represent a primary threat that + privacy-preserving protocols MUST defend against. + + Membership Inference Attack: An attack technique where an + adversary attempts to determine whether a specific data point was + used in training a machine learning model. In federated settings, + these attacks can be used to infer information about individual + agents' training data across tenant boundaries. + + Privacy Accounting: The process of tracking and managing privacy + budget consumption across multiple learning rounds and operations. + Privacy accounting mechanisms MUST ensure that the cumulative + privacy loss remains within acceptable bounds throughout the + entire federated learning process. + + Homomorphic Encryption: A cryptographic technique that allows + computation on encrypted data without decrypting it first. In the + context of secure aggregation, homomorphic encryption enables the + computation of aggregate model parameters while keeping individual + contributions encrypted. + + Zero-Knowledge Proof: A cryptographic protocol that allows one + party to prove knowledge of information to another party without + revealing the information itself. Zero-knowledge proofs are used + in privacy compliance verification to demonstrate adherence to + privacy requirements without exposing sensitive details about the + verification process. + +3. Problem Statement + + Federated agent learning in multi-tenant environments faces + fundamental privacy leakage risks that existing protocols fail to + adequately address. The core problem arises when AI agents from + different organizations (tenants) participate in collaborative + learning while sharing gradient updates or model parameters that + inadvertently reveal sensitive information about their private + training data. Unlike traditional federated learning scenarios + with homogeneous participants, multi-tenant environments amplify + privacy risks due to potentially adversarial relationships between + tenants and the heterogeneous nature of agent architectures across + organizational boundaries. + + The threat model for privacy-preserving federated agent learning + encompasses three primary attack vectors that adversaries MAY + exploit to compromise tenant data privacy. First, gradient + inversion attacks allow malicious participants to reconstruct + approximations of private training samples from shared gradient + information, particularly effective when batch sizes are small or + when attackers can observe multiple training rounds. Second, + membership inference attacks enable adversaries to determine + whether specific data points were used in another tenant's + training dataset by analyzing model behavior or parameter updates. + Third, cross-tenant data reconstruction attacks leverage + correlations between multiple tenants' shared information to infer + sensitive attributes about datasets belonging to other + organizational participants, violating tenant isolation + requirements. + + The privacy leakage problem is quantified through formal privacy + metrics that MUST account for composition across multiple learning + rounds and tenant interactions. Let ε represent the privacy budget + expended per tenant per learning round, and δ represent the + probability of privacy violation. The cumulative privacy cost + grows with each parameter sharing event, and without proper + privacy accounting mechanisms, the total privacy loss (εtotal, + δtotal) MAY exceed acceptable thresholds defined by organizational + privacy policies. Traditional differential privacy mechanisms + designed for single-organization scenarios provide insufficient + guarantees in multi-tenant federated settings where privacy + budgets must be allocated across tenant boundaries and learning + rounds while maintaining utility for collaborative model + improvement. + + Building upon the AI Agent Structured Threat Model framework + defined in [draft-berlinai-vera], federated agent learning + environments face additional risks including compromised privacy + compliance verifiers that MAY provide false attestations of + differential privacy adherence, tenant gateway failures that could + leak cross-tenant information, and coordination attacks where + multiple tenants collude to circumvent privacy protections. The + threat model assumes honest-but-curious federated coordinators who + follow protocol specifications but MAY attempt to infer private + information from aggregated data, and potentially malicious + tenants who MAY deviate from prescribed privacy-preserving + mechanisms to gain competitive advantages through unauthorized + data access. + + The problem statement also addresses the challenge of maintaining + privacy guarantees while supporting heterogeneous agent + architectures with varying computational capabilities, privacy + requirements, and trust assumptions. Agents operating under + different privacy regulations (such as GDPR, CCPA, or sector- + specific requirements) MUST be able to participate in federated + learning while maintaining compliance with their respective + privacy obligations. The protocol MUST provide mechanisms for + cryptographic verification of privacy compliance, audit trails for + regulatory reporting, and graceful degradation when privacy + budgets are exhausted, ensuring that collaborative learning can + continue while respecting individual tenant privacy constraints + and maintaining the overall utility of the federated learning + process. + +4. Privacy-Preserving Agent Learning Architecture + + This section defines the Privacy-Preserving Agent Learning + Protocol (PPALP) architecture, which integrates differential + privacy, secure aggregation, and zero-knowledge proofs to enable + federated learning across organizational boundaries while + maintaining formal privacy guarantees. The architecture extends + the Privacy-Preserving Reference Architecture framework [draft- + kale-agntcy-federated-privacy] to specifically address agent + learning scenarios in multi-tenant environments. PPALP employs a + layered approach where privacy mechanisms are enforced at multiple + architectural levels to provide defense-in-depth protection + against information leakage. + + The PPALP architecture defines four primary component roles that + collectively ensure privacy-preserving federated learning + operations. The Federated Coordinator serves as the central + orchestration entity responsible for managing global model state, + coordinating aggregation rounds, and maintaining privacy budget + allocations across all participating tenants. Tenant Gateways act + as intermediary control plane entities, extending the Agent + Gateway Control Plane concept [draft-li-dmsc-mcps-agw] to enforce + tenant-specific privacy policies and manage agent authentication + within organizational boundaries. Privacy Compliance Verifiers + operate as independent auditing entities that cryptographically + verify adherence to differential privacy guarantees and tenant + isolation requirements through zero-knowledge proofs. + Participating Agents represent the distributed learning entities + that contribute model updates while consuming privacy budget + allocated by their respective tenants. + + The architectural design enforces strict tenant isolation through + cryptographic boundaries and policy enforcement mechanisms. Each + tenant maintains an isolated privacy budget that cannot be + influenced by other tenants' learning activities, ensuring that + cross-tenant privacy guarantees remain intact regardless of + adversarial behavior by other participants. Tenant Gateways + implement the Federated Policy Enforcement framework [draft-cui- + dmsc-agent-cdi] to harmonize local privacy policies with global + federated learning requirements while preventing policy conflicts + that could compromise privacy guarantees. All inter-component + communications MUST use TLS 1.3 [RFC8446] with mutual + authentication based on X.509 certificates [RFC5280] to prevent + network-level attacks. + + The protocol supports heterogeneous agent types through a + standardized privacy-preserving model update interface that + abstracts underlying model architectures while ensuring consistent + privacy accounting. Agents MUST register their learning + capabilities and privacy requirements with their tenant's gateway, + which negotiates appropriate differential privacy parameters with + the Federated Coordinator. The architecture maintains backward + compatibility with existing federated learning frameworks by + implementing standard aggregation interfaces that can be secured + through the PPALP privacy mechanisms without requiring + modifications to existing agent implementations. + + Privacy accounting occurs at multiple architectural layers to + provide comprehensive protection against composition attacks and + privacy budget exhaustion. The Federated Coordinator maintains + global privacy budget state and implements composition theorems to + track cumulative privacy expenditure across learning rounds. + Tenant Gateways enforce local privacy policies and MAY implement + additional privacy amplification techniques such as subsampling to + reduce privacy costs for their constituent agents. Privacy + Compliance Verifiers continuously monitor privacy budget + consumption and generate cryptographic proofs of compliance that + can be audited by external parties without revealing sensitive + learning parameters or model information. + +5. Differential Privacy for Agent Model Updates + + This section specifies the differential privacy mechanisms that + MUST be applied to agent model parameter updates to provide formal + privacy guarantees in multi-tenant federated learning + environments. All participating agents MUST implement differential + privacy mechanisms that satisfy ε-differential privacy for a pre- + negotiated privacy parameter ε, where smaller values of ε provide + stronger privacy guarantees but may reduce model utility. The + differential privacy implementation MUST use the Gaussian + mechanism for continuous-valued parameters and the exponential + mechanism for discrete-valued selections, calibrated to the global + sensitivity of the learning algorithm as defined in [draft-kale- + agntcy-federated-privacy]. + + Privacy budget allocation MUST be managed across multiple learning + rounds to prevent privacy depletion over time. Each tenant MUST + maintain a privacy budget tracker that accounts for the cumulative + privacy cost across all federated learning rounds, where the total + privacy cost is bounded by composition theorems. The system MUST + implement advanced composition using the moments accountant method + or Rényi differential privacy to achieve tighter privacy bounds + than basic composition would allow. Privacy budgets SHOULD be + allocated proportionally to the expected utility gain from each + learning round, with mechanisms for tenants to reserve budget for + future high-priority learning tasks. + + Noise calibration for model parameter updates MUST be performed + based on the L2 sensitivity of the gradient computation, which is + bounded through gradient clipping techniques. Before applying + differential privacy noise, gradients MUST be clipped to a maximum + norm C, where C is negotiated during protocol initialization based + on the trade-off between privacy, utility, and convergence + requirements. The Gaussian noise added to each parameter update + MUST have variance σ² = 2C²ln(1.25/δ)/ε² for (ε,δ)-differential + privacy, where δ represents the probability of privacy failure and + MUST be set to be cryptographically negligible (typically δ ≤ + 10⁻⁶). + + The protocol MUST maintain detailed privacy accounting across + learning rounds using a standardized privacy ledger format that + records the privacy cost of each operation. This ledger MUST track + per-tenant privacy expenditure, cross-tenant privacy interactions, + and cumulative privacy debt according to the composition theorems. + The privacy accounting system MUST provide cryptographic proofs of + privacy budget compliance that can be verified by Privacy + Compliance Verifiers as specified in Section 7. When a tenant's + privacy budget is exhausted, the system MUST either terminate that + tenant's participation or implement privacy budget renewal + mechanisms with appropriate cooling-off periods to prevent privacy + budget laundering attacks. + + The differential privacy implementation MUST be compatible with + the secure aggregation protocols defined in Section 6, ensuring + that privacy guarantees are maintained even when combined with + cryptographic operations. The noise addition process MUST occur + before any cryptographic encoding for secure aggregation, and the + protocol MUST verify that the combination of differential privacy + and secure aggregation does not introduce additional privacy + vulnerabilities through cryptographic side channels or timing + attacks. All differential privacy parameters, including ε, δ, and + clipping bounds, MUST be negotiated during the protocol handshake + phase and cryptographically committed to prevent manipulation + during the learning process. + +6. Secure Multi-Tenant Federated Aggregation + + This section defines the cryptographic protocols that enable + secure aggregation of model parameters across tenant boundaries + while preserving privacy guarantees established in Section 5. The + secure aggregation protocol MUST ensure that no individual tenant + can learn information about other tenants' model updates beyond + what is revealed by the final aggregated result. The protocol + combines homomorphic encryption with secure multiparty computation + techniques to achieve this property while maintaining + computational efficiency suitable for practical federated learning + deployments. + + The Multi-Tenant Federated Averaging mechanism serves as the + foundation for secure parameter aggregation. Each tenant's Privacy + Compliance Verifier MUST encrypt their differentially-private + model updates using a threshold homomorphic encryption scheme + before transmission to the Federated Coordinator. The encryption + MUST use a (t,n)-threshold scheme where t represents the minimum + number of tenants required for decryption and n represents the + total number of participating tenants. This ensures that no single + tenant or coordinator can decrypt individual updates, while still + enabling computation over encrypted parameters. The homomorphic + encryption scheme SHOULD support both addition and limited + multiplication operations to accommodate various neural network + architectures commonly used in agent learning systems. + + The secure multiparty computation protocol proceeds in three + phases: commitment, computation, and verification. During the + commitment phase, each tenant generates a cryptographic commitment + to their encrypted model update using a computationally-hiding and + perfectly-binding commitment scheme. The Federated Coordinator + collects all commitments and broadcasts them to participating + tenants for verification. In the computation phase, tenants + collaboratively execute a secure aggregation protocol that + computes the weighted average of model parameters without + revealing individual contributions. The protocol MUST be secure + against up to t-1 malicious participants and SHOULD provide + robustness against participant dropout through verifiable secret + sharing techniques. + + Verification mechanisms ensure correctness of the aggregation + process and detect potential manipulation attempts. Each + participating tenant MUST verify the integrity of the aggregation + using zero-knowledge proofs that demonstrate correct execution of + the secure computation protocol. The ZKP-based Agent Attestation + mechanism enables tenants to prove their compliance with the + differential privacy requirements specified in Section 5 without + revealing their actual noise parameters or model updates. These + proofs MUST be verified by the Federated Coordinator and recorded + in an immutable audit trail as specified in Section 7. + Additionally, the protocol includes range proofs to verify that + model parameter updates fall within expected bounds, preventing + gradient manipulation attacks that could compromise model + convergence or extract private information. + + The aggregation protocol MUST support heterogeneous agent types by + normalizing model parameters to a common representation before + encryption and aggregation. Tenants with different model + architectures encode their updates using a standardized parameter + mapping that preserves semantic meaning while enabling secure + computation. The protocol SHOULD maintain backward compatibility + with existing federated learning frameworks by providing adapter + layers that translate between PPALP message formats defined in + Section 8 and legacy federated learning APIs. Performance + optimizations including parameter compression, selective + aggregation of model layers, and asynchronous update mechanisms + MAY be implemented provided they do not compromise the privacy + guarantees established by the differential privacy and secure + aggregation components. + +7. Privacy Compliance and Verification + + Privacy compliance in federated agent learning environments + requires cryptographic mechanisms that provide verifiable proof of + adherence to differential privacy guarantees while maintaining + audit capabilities for regulatory requirements. This section + defines the Privacy Compliance and Verification framework that + enables tenants to demonstrate privacy compliance without + revealing sensitive implementation details or compromising the + privacy of their learning processes. The framework combines zero- + knowledge proofs, selective disclosure attestations, and + cryptographic erasure mechanisms to provide comprehensive privacy + verification capabilities. + + The Privacy Compliance Verifier MUST implement zero-knowledge + proof protocols that allow federated agents to demonstrate + differential privacy adherence without revealing actual noise + values, data distributions, or model parameters. Following the SD- + JWT Privacy-Preserving Trust Proof pattern from [draft-drake- + email-tpm-attestation], the verifier SHALL use Selective + Disclosure JWT mechanisms [RFC7519] to enable privacy-preserving + attestation of compliance properties. Each participating agent + MUST generate cryptographic proofs that demonstrate: (1) proper + calibration of differential privacy noise according to the + allocated privacy budget, (2) correct implementation of the + Gaussian mechanism or equivalent noise generation, and (3) + adherence to composition theorems across multiple learning rounds. + These proofs MUST be constructed using non-interactive zero- + knowledge proof systems such as zk-SNARKs or zk-STARKs that + provide succinctness and efficient verification. + + Audit trail mechanisms MUST maintain cryptographically verifiable + logs of all privacy-relevant operations while preserving the + confidentiality of sensitive learning data. The audit system SHALL + record privacy budget expenditures, aggregation operations, and + tenant isolation boundary enforcement without logging actual model + parameters or gradient values. Each audit entry MUST include a + timestamp, tenant identifier, privacy budget allocation, and + cryptographic hash of the differential privacy parameters used. + The audit trail MUST support selective disclosure to authorized + auditors while preventing unauthorized access to privacy-sensitive + operational details. Privacy budget accounting MUST be maintained + across all learning rounds with cryptographic commitments that + prevent double-spending of privacy allocations. + + Cryptographic erasure capabilities MUST be implemented to address + regulatory requirements for data deletion and agent memory cleanup + as specified in [draft-gaikwad-aps-profile]. The system SHALL + support cryptographic erasure of agent memory associated with + specific user or agent identities through key destruction + mechanisms that render associated encrypted data permanently + inaccessible. When a deletion request is received, the Privacy + Compliance Verifier MUST coordinate the erasure of all federated + learning artifacts associated with the specified identity, + including gradient histories, model update records, and privacy + budget allocations. The erasure process MUST generate + cryptographic proofs of deletion that demonstrate the irreversible + destruction of the requested data across all participating + federated nodes. + + Privacy compliance verification MUST support Privacy-Respecting + Capability Attestation mechanisms that enable verification of + agent privacy capabilities without revealing implementation- + specific details. Following patterns from [draft-huang-rats- + agentic-eat-cap-attest], agents MUST be able to attest to their + differential privacy implementation capabilities, secure + aggregation support, and tenant isolation enforcement without + disclosing proprietary algorithms or security configurations. The + attestation process SHALL use hardware-backed trust anchors where + available, with fallback to software-based attestation for + environments without trusted execution capabilities. All privacy + compliance proofs and attestations MUST be timestamped and include + validity periods to prevent replay attacks and ensure freshness of + compliance claims. + +8. Protocol Message Formats and Flows + + This section defines the concrete message formats, communication + flows, and API definitions for the Privacy-Preserving Agent + Learning Protocol (PPALP). All message exchanges MUST use JSON + format as specified in [RFC8259] with UTF-8 encoding. Protocol + implementations MUST support TLS 1.3 [RFC8446] for transport + security and MUST authenticate using OAuth 2.0 [RFC6749] bearer + tokens or X.509 certificates [RFC5280]. The protocol defines four + primary message categories: initialization messages for + establishing privacy parameters, update messages for transmitting + differentially private model parameters, aggregation messages for + secure multi-tenant computation, and verification messages for + privacy compliance validation. + + The protocol message structure follows a common envelope format + with mandatory header fields. Each message MUST include a + "version" field specifying the PPALP protocol version, a "type" + field indicating the message category, a "tenantid" field for + tenant isolation enforcement, and a "timestamp" field using ISO + 8601 format. Messages involving privacy budget allocation MUST + include a "privacybudget" object containing epsilon and delta + values as defined in Section 5. Security-critical messages such as + model updates and aggregation requests MUST include a "signature" + field containing a JWS signature [RFC7519] for message + authentication and integrity verification. + + The federated learning session begins with a Privacy Parameter + Negotiation flow initiated by the Federated Coordinator. The + coordinator sends a "privacyinit" message specifying the global + privacy budget, differential privacy mechanism, and aggregation + method. Each Tenant Gateway responds with a "privacyaccept" + message confirming participation and local privacy constraints. + Model update flows use "modelupdate" messages containing encrypted + differentially private gradients, privacy proof attestations, and + secure aggregation shares. The Federated Coordinator processes + these through "aggregationrequest" and "aggregation_response" + messages that implement the secure multi-tenant aggregation + protocol defined in Section 6. + + Privacy compliance verification occurs through dedicated message + flows involving the Privacy Compliance Verifier component. Agents + MUST send "privacyproof" messages containing zero-knowledge proofs + of differential privacy adherence for each model update. The + verifier responds with "compliancestatus" messages indicating + verification success or failure with specific error codes. Audit + trail generation uses "audit_log" messages that record privacy + budget consumption, aggregation participation, and compliance + verification events. All audit messages MUST be cryptographically + signed and include tamper-evident sequence numbers for regulatory + compliance. + + The protocol defines standardized error handling through HTTP + status codes [RFC9110] and structured error responses. Privacy + budget exhaustion MUST return HTTP 429 with a + "privacybudgetexceeded" error code and remaining budget + information. Tenant isolation violations MUST return HTTP 403 with + detailed violation descriptions for security monitoring. + Implementation-specific extensions MAY add custom message fields + using the "extensions" object within the message envelope, + provided they do not compromise privacy guarantees or tenant + isolation requirements. Reference implementations MUST provide + JSON Schema validation files and OpenAPI specifications for all + message formats to ensure interoperability across different PPALP + implementations. + + Example message flows demonstrate typical protocol interactions + including session establishment, multi-round federated learning + with privacy budget management, and graceful session termination + with privacy compliance verification. The appendix includes + complete JSON Schema definitions for all message types, sample + message exchanges showing proper privacy parameter negotiation, + and error handling examples covering common failure scenarios such + as aggregation timeouts and privacy proof validation failures. + +9. Security Considerations + + PPALP addresses multiple security threats present in multi-tenant + federated learning environments through defense-in-depth + mechanisms. The protocol MUST implement protections against + gradient inversion attacks [RFC8446] by ensuring differential + privacy noise addition occurs before any parameter sharing, with + privacy budgets calculated according to composition theorems + defined in Section 5. Membership inference attacks are mitigated + through tenant isolation enforcement, where each tenant's Privacy + Compliance Verifier cryptographically verifies that cross-tenant + information leakage remains below specified epsilon-delta bounds. + Model poisoning attacks are addressed through secure aggregation + protocols that include Byzantine-fault-tolerant mechanisms and + zero-knowledge proofs of honest participation. + + Key management in PPALP follows a hierarchical trust model where + the Federated Coordinator maintains root cryptographic + credentials, while each tenant operates independent key + hierarchies for their agent populations. Tenant Gateways MUST + establish mutually authenticated channels using TLS 1.3 [RFC8446] + with certificate pinning, and rotate encryption keys according to + the privacy budget consumption rate to ensure forward secrecy. The + protocol supports both pre-shared keys for closed consortium + deployments and public key infrastructure integration [RFC5280] + for open multi-tenant scenarios. Cross-tenant cryptographic + isolation MUST be maintained such that compromise of one tenant's + keys cannot affect the privacy guarantees of other tenants' + learning processes. + + Operational security considerations for multi-tenant deployments + include audit logging of all privacy budget expenditures, secure + deletion mechanisms for ephemeral cryptographic material, and + side-channel attack mitigation. The protocol MUST log all + differential privacy parameter selections, aggregation events, and + privacy compliance verification results to enable post-hoc + security analysis while ensuring these logs themselves do not leak + private information. Network-level protections SHOULD include + traffic analysis resistance through padding and timing + obfuscation, particularly for Agent Gateway intercommunication as + specified in [draft-han-rtgwg-agent-gateway-intercomm-framework]. + Deployments MUST implement secure boot and attestation mechanisms + for Privacy Compliance Verifiers to prevent tampering with privacy + enforcement logic. + + The protocol provides resistance to collusion attacks through + cryptographic commitment schemes and verifiable privacy budget + accounting across multiple learning rounds. When tenant subsets + attempt to correlate their local model updates to infer + information about non-colluding tenants, the secure aggregation + protocol ensures that only differentially private aggregate + statistics are revealed. However, the protocol assumes honest-but- + curious adversaries and MAY NOT provide protection against active + adversaries who deviate from the protocol specification. + Deployments requiring protection against malicious adversaries + SHOULD implement additional verification mechanisms and consider + reduced privacy parameters to account for adaptive attacks over + multiple learning epochs. + +10. IANA Considerations + + This document defines new protocol elements that require + registration with the Internet Assigned Numbers Authority (IANA) + to ensure interoperability and avoid conflicts with existing + protocols. The Privacy-Preserving Agent Learning Protocol (PPALP) + introduces novel message types, error codes, and protocol + identifiers that extend existing federated learning and privacy- + preserving computation frameworks as defined in [draft-kale- + agntcy-federated-privacy]. + + IANA SHALL establish a new registry titled "Privacy-Preserving + Agent Learning Protocol (PPALP) Parameters" under the "AI Agent + Protocol Parameters" registry group. This registry SHALL contain + three sub-registries: "PPALP Message Types", "PPALP Error Codes", + and "PPALP Privacy Compliance Identifiers". The PPALP Message + Types registry SHALL include entries for differential privacy + update messages (DPUPDATE), secure aggregation requests + (SECAGGREQ), secure aggregation responses (SECAGGRESP), privacy + budget allocation messages (PRIVBUDGET), tenant isolation + verification messages (TENANTVERIFY), and zero-knowledge proof + submission messages (ZKPSUBMIT). Each message type SHALL be + assigned a unique 16-bit identifier following the allocation + policies specified in [RFC8259] for JSON-based protocol + extensions. + + The PPALP Error Codes registry SHALL define error conditions + specific to privacy-preserving federated learning operations. + Required error codes include PRIVACYBUDGETEXCEEDED (4001), + TENANTISOLATIONVIOLATION (4002), + DIFFERENTIALPRIVACYVERIFICATIONFAILED (4003), + SECUREAGGREGATIONTIMEOUT (4004), INSUFFICIENTPRIVACYPARAMETERS + (4005), and ZKPVERIFICATION_FAILED (4006). These error codes + extend the HTTP status code space as defined in [RFC9110] and + SHALL follow the expert review allocation policy with designated + experts appointed from the privacy-preserving computation and + federated learning communities. + + The PPALP Privacy Compliance Identifiers registry SHALL contain + standardized identifiers for privacy mechanisms, verification + schemes, and compliance frameworks used within the protocol. This + registry SHALL include identifiers for differential privacy + mechanisms (DPGAUSSIAN, DPLAPLACE), secure aggregation protocols + (SECAGGBFV, SECAGGCKKS), and zero-knowledge proof systems + (ZKPBULLETPROOFS, ZKPPLONK). Registration policies for this + registry SHALL follow the Specification Required policy as defined + in [RFC2119], with specifications requiring formal privacy + analysis and security proofs. Updates to these registries SHALL be + coordinated with the broader AI agent protocol standardization + efforts referenced in [draft-berlinai-vera] to ensure consistency + across related privacy-preserving agent communication protocols. + +11. References + +11.1. Normative References + + [RFC 2119] + RFC 2119 + + [RFC 8174] + RFC 8174 + + [RFC 8259] + RFC 8259 + + [RFC 7519] + RFC 7519 + + [RFC 8446] + RFC 8446 + + [draft-kale-agntcy-federated-privacy] + draft-kale-agntcy-federated-privacy + +11.2. Informative References + + [RFC 6749] + RFC 6749 + + [RFC 9110] + RFC 9110 + + [RFC 5280] + RFC 5280 + + [draft-berlinai-vera] + draft-berlinai-vera + + [draft-huang-acme-scalable-agent-enrollment] + draft-huang-acme-scalable-agent-enrollment + + [draft-messous-eat-ai] + draft-messous-eat-ai + + [draft-li-dmsc-mcps-agw] + draft-li-dmsc-mcps-agw + + [draft-gaikwad-aps-profile] + draft-gaikwad-aps-profile + + [draft-drake-email-tpm-attestation] + draft-drake-email-tpm-attestation + + [draft-huang-rats-agentic-eat-cap-attest] + draft-huang-rats-agentic-eat-cap-attest + + +Author's Address + + Generated by IETF Draft Analyzer + Family: agent-ecosystem + 2026-03-04 diff --git a/data/reports/generated-drafts/draft-ai-agent-provenance-assurance-ecosystem-00.txt b/data/reports/generated-drafts/draft-ai-agent-provenance-assurance-ecosystem-00.txt new file mode 100644 index 0000000..5f6fb5b --- /dev/null +++ b/data/reports/generated-drafts/draft-ai-agent-provenance-assurance-ecosystem-00.txt @@ -0,0 +1,1085 @@ +Internet-Draft lake +Intended status: standards-track March 2026 +Expires: September 05, 2026 + + + Agent Provenance Assurance Ecosystem (APAE) Framework + draft-agent-ecosystem-agent-provenance-assurance-ecosystem-00 + +Abstract + + The proliferation of AI agents across distributed systems creates + critical challenges for establishing verifiable chains of + identity, capabilities, and operational history. This document + defines the Agent Provenance Assurance Ecosystem (APAE) Framework, + a comprehensive system for tracking, verifying, and assuring the + provenance of AI agents throughout their lifecycle. The framework + establishes a multi-layered architecture encompassing agent + identity attestation, capability verification, operational audit + trails, and cross-domain provenance tracking. APAE integrates with + existing identity management systems, authorization protocols, and + communication frameworks to provide end-to-end provenance + assurance without disrupting current agent ecosystems. The + framework supports both lightweight deployments for development + environments and high-assurance configurations for regulated + industries, enabling the same agent infrastructure to operate + across varying trust requirements while maintaining verifiable + provenance chains. + +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. + +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. + + Agent Provenance Chain + A verifiable sequence of records documenting an agent's + identity, capabilities, delegations, and operational history + from creation through current state + + Attestation Level + A classification of the strength and scope of cryptographic and + procedural evidence supporting agent identity and capability + claims + + Capability Manifest + A signed document describing an agent's current models, tools, + policies, and operational constraints with cryptographic + integrity protection + + Provenance Anchor + A cryptographically verifiable root of trust that establishes + the initial identity and capabilities of an agent at creation + time + + Cross-Domain Provenance + The preservation and verification of agent provenance + information across different administrative domains, trust + boundaries, and protocol ecosystems + + Audit Trail Federation + The controlled sharing and verification of agent operational + logs across multiple systems while preserving privacy and + security constraints + + +Table of Contents + + 1. Introduction ................................................ 3 + 2. Terminology ................................................. 4 + 3. Problem Statement and Requirements .......................... 5 + 4. APAE Architecture Overview .................................. 6 + 5. Agent Identity and Attestation Layer ........................ 7 + 6. Capability and Manifest Verification ........................ 8 + 7. Provenance Audit and Logging Framework ...................... 9 + 8. Cross-Ecosystem Integration Patterns ........................ 10 + 9. Deployment Profiles and Trust Models ........................ 11 + 10. Security Considerations ..................................... 12 + 11. IANA Considerations ......................................... 13 + 12. References .................................................. 14 + +1. Introduction + + The deployment of AI agents across distributed systems has + fundamentally transformed how automated decision-making and task + execution occur in modern computing environments. As organizations + increasingly rely on AI agents for critical operations ranging + from customer service interactions to financial transaction + processing and infrastructure management, the need for verifiable + provenance tracking has become paramount. Unlike traditional + software components with static capabilities, AI agents exhibit + dynamic behavior through model updates, policy modifications, and + capability evolution, creating complex challenges for establishing + trust and accountability in distributed deployments [draft-chen- + ai-agent-auth-new-requirements]. + + Current approaches to agent identity and authorization, while + addressing immediate authentication needs, fail to provide + comprehensive visibility into agent provenance across their + operational lifecycle. Organizations lack standardized mechanisms + to verify not only who created an agent, but also what models it + currently runs, which policies govern its behavior, how its + capabilities have evolved over time, and what operations it has + performed across distributed systems. This gap becomes + particularly critical when agents operate across organizational + boundaries, undergo delegation to other agents, or when regulatory + compliance requires detailed audit trails of automated decision- + making processes [draft-jiang-seat-dynamic-attestation]. + + The challenges of agent provenance extend beyond simple identity + verification to encompass the full spectrum of agent lifecycle + management. Agent creation involves establishing cryptographic + roots of trust and initial capability manifests. Agent delegation + requires preserving provenance chains while enabling authorized + capability transfer between entities. Capability evolution demands + continuous attestation as agents load new models, update policies, + or modify their operational constraints. Operational history + tracking necessitates comprehensive audit trails that maintain + integrity across system boundaries while supporting privacy + preservation and selective disclosure requirements [draft-liu- + oauth-a2a-profile]. + + Existing identity management systems, authorization protocols, and + audit frameworks provide essential building blocks but lack the + specialized constructs needed for comprehensive agent provenance + assurance. Standard identity protocols such as OAuth 2.0 [RFC6749] + and JWT [RFC7519] enable agent authentication but do not capture + the dynamic nature of agent capabilities or provide mechanisms for + tracking operational history. Certificate-based systems [RFC5280] + can establish initial identity but fail to accommodate the + continuous evolution of agent capabilities. Current audit systems + focus on user actions rather than autonomous agent behavior, + creating gaps in accountability for automated operations. + + This document defines the Agent Provenance Assurance Ecosystem + (APAE) Framework to address these challenges through a + comprehensive, multi-layered approach to agent provenance + tracking. APAE establishes standardized mechanisms for agent + identity attestation, capability verification, operational audit + trails, and cross-domain provenance preservation. The framework + integrates with existing authentication and authorization systems + while extending them with agent-specific provenance capabilities, + enabling organizations to retrofit provenance assurance into + deployed agent ecosystems without disrupting current operations. + + The scope of APAE encompasses the complete agent lifecycle from + initial creation through operational retirement. This includes + establishing provenance anchors at agent creation, maintaining + verifiable capability manifests as agents evolve, tracking + delegation relationships and authority transfers, logging + operational activities with cryptographic integrity, and + federating provenance information across organizational and + protocol boundaries. The framework supports flexible deployment + models ranging from lightweight development environments to high- + assurance configurations required by regulated industries, + enabling the same underlying infrastructure to adapt to varying + trust requirements while maintaining consistent provenance + semantics across all deployment contexts. + +2. 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. + + This document defines the following terms for use within the Agent + Provenance Assurance Ecosystem (APAE) Framework: + + Agent: An autonomous software entity that acts on behalf of users, + services, or other agents, typically incorporating AI/ML models + for decision-making and task execution as defined in [draft-chen- + ai-agent-auth-new-requirements]. + + Agent Identity Primitive: A fundamental cryptographic construct + (such as a public key, certificate, or distributed identifier) + that serves as the basis for agent authentication and identity + verification throughout the agent's lifecycle. + + Agent Provenance Chain: A chronologically ordered, + cryptographically linked sequence of records that documents an + agent's complete history including initial creation, identity + establishment, capability modifications, delegation relationships, + and operational activities. Each link in the chain MUST be + verifiable and tamper-evident, forming an immutable audit trail + from the agent's provenance anchor through its current operational + state. + + Attestation Level: A standardized classification system that + quantifies the strength, scope, and trustworthiness of evidence + supporting agent identity and capability claims. Attestation + levels range from basic self-assertions suitable for development + environments to high-assurance cryptographic attestations meeting + regulatory compliance requirements. Higher attestation levels + require stronger cryptographic evidence, more rigorous validation + procedures, and enhanced tamper-resistance mechanisms. + + Capability Manifest: A structured, digitally signed document that + comprehensively describes an agent's current operational + configuration including loaded AI/ML models, available tools and + APIs, active behavioral policies, operational constraints, and + security boundaries. As specified in [draft-jiang-seat-dynamic- + attestation], capability manifests provide cryptographically + verifiable assurance about an agent's actual capabilities and + constraints at the time of attestation. + + Cross-Domain Provenance: The preservation, validation, and + verification of agent provenance information as agents operate + across heterogeneous administrative domains, trust boundaries, + protocol ecosystems, and organizational jurisdictions. Cross- + domain provenance ensures that provenance chains remain intact and + verifiable even when agents interact with systems using different + identity management frameworks, authorization protocols, or + security models as described in [draft-liu-oauth-a2a-profile]. + + Delegation Chain: A verifiable sequence of authorization grants + and capability transfers that documents how operational authority + and permissions flow from an originating principal (user, service, + or agent) through intermediary agents to the currently acting + agent. Each delegation in the chain MUST be cryptographically + verifiable and include scope limitations, temporal constraints, + and revocation mechanisms. + + Operational Audit Trail: A tamper-evident log of agent activities, + decisions, and state changes that provides accountability and + forensic capabilities for agent operations. Audit trails include + sufficient detail to reconstruct agent behavior while preserving + privacy and confidentiality requirements through selective + disclosure and zero-knowledge proof mechanisms. + + Provenance Anchor: The cryptographically verifiable root of trust + that establishes the foundational identity and initial + capabilities of an agent at creation time. Provenance anchors + serve as the starting point for all subsequent provenance chain + entries and MUST be issued by trusted authorities with appropriate + key management and certificate lifecycle processes as defined in + [RFC5280]. + + Provenance Registry: A distributed system that stores, indexes, + and provides query interfaces for agent provenance information + while maintaining appropriate access controls and privacy + protections. Registries enable cross-domain provenance lookup, + verification, and audit trail federation across organizational + boundaries. + + Trust Boundary: A logical or physical demarcation point where + different security domains, administrative authorities, or trust + models intersect, requiring explicit validation and translation of + provenance information to maintain chain integrity and + verifiability. + + These terms are used consistently throughout this specification to + ensure clarity and interoperability in multi-stakeholder + environments deploying agent provenance assurance capabilities. + +3. Problem Statement and Requirements + + The emergence of autonomous AI agents in distributed systems + presents unprecedented challenges for establishing verifiable + chains of identity, capabilities, and operational history. Unlike + traditional software components with static configurations, AI + agents exhibit dynamic behavior patterns, evolve their + capabilities through learning and tool acquisition, and operate + through complex delegation relationships that span multiple + administrative domains. Current identity and authorization + frameworks, while adequate for human users and simple service-to- + service authentication, lack the semantic richness and temporal + granularity required to track agent provenance across their full + lifecycle. The absence of standardized provenance tracking + mechanisms creates significant risks including unauthorized + capability escalation, untraceable delegation chains, and + inability to audit agent decision-making processes in regulated + environments. + + Agent delegation presents particular challenges as agents + frequently spawn sub-agents, delegate tasks to peer agents, or + operate on behalf of other entities through complex authorization + chains. Traditional OAuth 2.0 [RFC6749] delegation models assume + relatively simple delegation relationships and static capability + sets, whereas agent-to-agent delegation involves dynamic + capability inheritance, constraint propagation, and context- + dependent authorization decisions. The Agent Authorization Profile + [draft-aap-oauth-profile] addresses some of these challenges + through structured claims, but requires a comprehensive provenance + framework to establish the trustworthiness of those claims across + domain boundaries. Furthermore, agents may acquire new + capabilities through model updates, tool integrations, or policy + modifications during their operational lifetime, necessitating + continuous provenance tracking rather than static identity + attestation. + + Cross-ecosystem interoperability compounds these challenges as + agents must operate across heterogeneous systems with varying + trust models, identity providers, and security requirements. An + agent created in one organization's development environment may + later operate in a partner's production system or a regulated + cloud service, each requiring different levels of provenance + assurance and audit granularity. Existing identity management + protocols like SCIM [draft-abbey-scim-agent-extension] provide + mechanisms for agent identity synchronization, but lack the + semantic frameworks necessary to verify capability claims and + operational constraints across trust boundaries. The absence of + standardized provenance interchange formats prevents comprehensive + audit trails and limits the ability to establish end-to-end + accountability for agent actions. + + The APAE framework MUST provide verifiable agent identity + establishment and preservation mechanisms that support + cryptographic attestation of agent creation, modification, and + delegation events. The framework MUST enable tracking of + capability evolution including model updates, tool acquisitions, + and policy changes with tamper-evident audit trails. Agent + delegation chains MUST be cryptographically verifiable with + support for constraint inheritance and capability subset + enforcement as specified in the authentication requirements for AI + agents [draft-chen-ai-agent-auth-new-requirements]. The framework + MUST support cross-domain provenance tracking that preserves + verifiability while respecting privacy and security boundaries + between administrative domains. + + The framework MUST integrate with existing OAuth 2.0 [RFC6749] and + JWT [RFC7519] infrastructure without requiring protocol + modifications to deployed systems. Human oversight requirements + MUST be traceable through provenance chains with verifiable + enforcement of human-in-the-loop constraints for sensitive + operations. The framework MUST support multiple assurance levels + ranging from lightweight development environments to high- + assurance regulated deployments with appropriate cryptographic + strength and audit granularity. Operational audit trails MUST + provide sufficient detail for regulatory compliance while + supporting privacy-preserving federation across organizational + boundaries. + + Security requirements include protection against provenance + tampering, replay attacks, and unauthorized capability escalation + through cryptographic integrity mechanisms. The framework MUST + provide defense against agent impersonation, delegation chain + forgery, and capability manifest manipulation while maintaining + acceptable performance characteristics for high-volume agent + interactions. Privacy preservation MUST be supported through + selective disclosure mechanisms and zero-knowledge proofs where + full provenance transparency conflicts with confidentiality + requirements. The framework MUST support revocation and recovery + mechanisms for compromised agent identities while preserving + historical audit trail integrity. + +4. APAE Architecture Overview + + The Agent Provenance Assurance Ecosystem (APAE) Framework employs + a multi-layered architecture designed to provide comprehensive + provenance tracking while maintaining compatibility with existing + agent infrastructures. The architecture consists of four primary + layers: the Identity Attestation Layer, the Capability and + Manifest Verification Layer, the Provenance Audit and Logging + Layer, and the Registry and Discovery Layer. Each layer operates + independently while providing well-defined interfaces for inter- + layer communication and data exchange. This modular design enables + selective deployment of framework components based on specific + operational requirements and trust models, allowing organizations + to implement provenance assurance incrementally without disrupting + existing agent ecosystems. + + The Identity Attestation Layer serves as the foundational trust + anchor for the APAE framework, establishing and maintaining + verifiable agent identities throughout their operational + lifecycle. This layer implements cryptographic attestation + mechanisms compatible with existing identity management systems as + specified in [RFC6749] and emerging agent authentication + requirements outlined in [draft-chen-ai-agent-auth-new- + requirements]. Agent identities are established through Provenance + Anchors that create immutable cryptographic bindings between agent + instances and their initial capability sets. The layer maintains + delegation chains that preserve identity continuity across agent + spawning, capability updates, and cross-domain transfers, ensuring + that each agent's lineage remains verifiable regardless of + operational complexity or administrative boundaries. + + The Capability and Manifest Verification Layer implements the AI + Agent Manifest Attestation mechanism to provide continuous + assurance of agent capabilities and operational constraints. This + layer generates and validates Capability Manifests that + cryptographically bind agent identities to their current models, + tools, policies, and Working Memory configurations as described in + [draft-jiang-seat-dynamic-attestation]. Manifest verification + occurs through a combination of static analysis and runtime + attestation, ensuring that declared capabilities match actual + agent implementations. The layer integrates with authorization + frameworks defined in [draft-liu-oauth-a2a-profile] to enforce + capability-based access controls and prevent agents from exceeding + their declared operational boundaries. + + The Provenance Audit and Logging Layer captures comprehensive + operational histories through tamper-evident audit trails that + document agent actions, decisions, and state transitions. This + layer implements Audit Trail Federation mechanisms that enable + secure sharing of provenance information across administrative + domains while preserving privacy and confidentiality requirements. + The logging framework supports both real-time audit streaming for + high-assurance environments and batch processing for performance- + sensitive deployments. Audit records are cryptographically linked + to agent identities and capability manifests, creating verifiable + chains of operational evidence that support compliance, debugging, + and security analysis requirements. + + The Registry and Discovery Layer provides the infrastructure + services necessary for cross-ecosystem provenance verification and + agent lifecycle management. This layer implements Ecosystem + Registries that resolve agent identifiers to concrete endpoints + while maintaining provenance metadata for discovery and + verification operations. The registry services support + hierarchical trust models that enable both centralized and + federated deployment patterns, allowing organizations to maintain + local control over agent registration while participating in + broader provenance ecosystems. Integration with existing DNS and + PKI infrastructure ensures compatibility with current internet + protocols while providing the specialized services required for + agent provenance assurance. + + Component integration occurs through standardized APIs that + abstract the complexity of provenance operations from agent + implementations and management systems. The framework defines + integration points with existing OAuth 2.0 authorization servers + [RFC6749], JWT token validation systems [RFC7519], and X.509 + certificate authorities [RFC5280] to leverage established trust + infrastructure. Cross-layer communication employs CBOR Web Token + (CWT) formats [RFC9052] for efficient provenance data exchange, + while maintaining compatibility with JSON-based systems through + bidirectional transformation protocols. This integration approach + enables the APAE framework to operate as both a standalone + provenance system and as an enhancement layer for existing agent + infrastructures, supporting gradual adoption paths that minimize + deployment risk and operational disruption. + +5. Agent Identity and Attestation Layer + + The Agent Identity and Attestation Layer forms the foundational + trust anchor for the APAE framework by establishing + cryptographically verifiable agent identities and maintaining + their integrity throughout distributed operations. This layer + defines mechanisms for creating immutable Provenance Anchors at + agent instantiation, enabling subsequent verification of agent + authenticity and delegation chains across administrative + boundaries. The attestation mechanisms MUST support multiple trust + models ranging from self-signed certificates for development + environments to hardware-backed attestation for high-assurance + deployments, ensuring consistent identity semantics while + accommodating diverse operational requirements. + + Agent identity establishment begins with the creation of a + cryptographic identity pair and corresponding Provenance Anchor + that binds the agent's initial state, capabilities, and authorized + delegation scope. The Provenance Anchor MUST include the agent's + public key, creation timestamp, initial Capability Manifest hash, + and attestation metadata as defined in [RFC5280] certificate + extensions. For agents created through delegation, the Provenance + Anchor MUST reference the parent agent's identity and include a + delegation certificate chain as specified in Section 4.3 of + [draft-aap-oauth-profile]. The attestation layer SHOULD integrate + with existing Public Key Infrastructure (PKI) systems and identity + providers to leverage established trust relationships while + maintaining agent-specific provenance requirements. + + Identity preservation across transactions requires embedding agent + identity information within protocol tokens to maintain provenance + visibility throughout distributed agent interactions. Following + the patterns established in [draft-liu-oauth-a2a-profile], the + attestation layer MUST encode agent identity claims within JWT + tokens [RFC7519] using structured claims that capture agent + context, delegation chains, and operational constraints. The "sub" + claim MUST identify the agent using a stable identifier, while + custom claims including "agentid", "delegationchain", and + "capability_hash" provide machine-readable context for + authorization decisions. Token validation procedures MUST verify + both the cryptographic integrity of the token and the validity of + embedded delegation chains against current agent registry state. + + Delegation chain validation ensures that agents acting on behalf + of humans or other agents maintain verifiable authorization + inheritance throughout multi-hop delegation scenarios. The + attestation layer MUST implement validation rules that verify each + delegation link's cryptographic signature, temporal validity, and + scope constraints as defined in Section 5.2 of [draft-aap-oauth- + profile]. Validation procedures MUST check that each delegation in + the chain is properly authorized by its parent and that the + cumulative delegation scope does not exceed the original + authorization grant. For cross-domain delegations, the layer MUST + support federation mechanisms that enable delegation chain + verification across different administrative domains while + preserving local policy enforcement. + + Integration with existing identity management systems requires + protocol adapters that bridge APAE agent identity concepts with + established authentication and authorization frameworks including + OAuth 2.0 [RFC6749], SAML, and enterprise identity providers. The + attestation layer MUST provide standardized interfaces for + identity provider integration that preserve agent provenance + information while leveraging existing user directories and policy + engines. For environments requiring hardware-backed attestation, + the layer SHOULD integrate with Trusted Platform Module (TPM) + attestation mechanisms and secure enclave technologies to provide + cryptographic proof of agent execution environment integrity as + specified in [draft-jiang-seat-dynamic-attestation]. + + The attestation layer maintains agent identity lifecycle + management including identity renewal, revocation, and migration + scenarios that preserve provenance chain integrity across + operational changes. Identity renewal procedures MUST generate new + cryptographic material while maintaining linkage to previous + identity states through signed transition records. Revocation + mechanisms MUST support both immediate revocation for security + incidents and scheduled revocation for planned agent retirement, + with appropriate notification to dependent systems. For agent + migration scenarios, the layer MUST provide protocols for securely + transferring agent identity and associated provenance data between + execution environments while maintaining cryptographic integrity + and audit trail continuity. + +6. Capability and Manifest Verification + + The APAE framework establishes comprehensive mechanisms for + verifying agent capabilities, loaded models, active policies, and + operational constraints through structured capability manifests + and cryptographic validation procedures. Agents MUST maintain up- + to-date capability manifests that accurately reflect their current + operational state, including all loaded models, available tools, + active security policies, and operational constraints. These + manifests serve as authoritative declarations of agent + capabilities that can be independently verified by other agents, + infrastructure components, and human operators. The framework + supports both static capability declarations established at agent + creation time and dynamic capability updates that reflect runtime + changes to agent configuration. + + Capability manifests MUST be structured as JSON documents + conforming to a standardized schema that includes sections for + model identification, tool descriptions, policy specifications, + and operational metadata. Each manifest MUST include cryptographic + signatures from the agent's identity key as defined in Section 5, + enabling verification of manifest authenticity and integrity. The + manifest format incorporates semantic capability descriptions that + support capability-based discovery mechanisms, allowing agents to + locate and interact with other agents based on functional + requirements rather than network topology. Manifests MAY include + capability hierarchies and dependency relationships that describe + how complex capabilities are composed from simpler primitives, + enabling fine-grained capability matching and verification. + + The framework defines validation procedures that enable both local + and remote verification of agent capabilities through multiple + assurance mechanisms. Agents MUST implement self-attestation + procedures that generate cryptographic proofs of their current + capability state, including verification that loaded models match + declared specifications and that active policies are properly + enforced. The framework supports oracle-free evaluation mechanisms + that allow agents to demonstrate their capabilities through + standardized test interactions without requiring external ground + truth verification systems. For higher assurance levels, the + framework MAY utilize remote attestation procedures where trusted + third parties verify agent capabilities through controlled testing + environments or hardware-based attestation mechanisms. + + Capability verification integrates with the APAE audit framework + to maintain comprehensive records of capability changes and + verification events throughout an agent's operational lifecycle. + All capability updates MUST be logged to the provenance audit + trail with cryptographic timestamps and verification evidence. The + framework supports incremental capability verification where only + modified capabilities require re-validation, reducing + computational overhead while maintaining security properties. + Verification procedures MUST account for capability delegation + scenarios where agents operate with restricted or derived + capabilities from their base configuration, ensuring that + delegation constraints are properly enforced and documented. + + The framework establishes integration patterns with existing + authorization and policy systems through standardized capability + assertion formats compatible with OAuth 2.0 scopes [RFC6749] and + JWT claims [RFC7519]. Capability manifests MAY be embedded in + access tokens or presented as separate attestation documents + depending on the integration requirements of the target system. + The framework supports prioritization mechanisms that ensure + critical capability verification traffic receives appropriate + network and processing priority, particularly in high-throughput + agent communication scenarios. Capability verification procedures + MUST preserve privacy by supporting selective disclosure of + capability information while maintaining the ability to verify + relevant capabilities for specific interactions. + +7. Provenance Audit and Logging Framework + + The provenance audit and logging framework establishes + comprehensive mechanisms for recording, storing, and verifying the + operational history of AI agents throughout their lifecycle. This + framework builds upon the identity attestation and capability + verification layers to create tamper-evident audit trails that + preserve agent provenance across administrative domains and + protocol boundaries. The audit framework integrates with existing + logging infrastructure while providing specialized capabilities + for agent-specific events including delegation chains, capability + modifications, and cross-domain interactions. + + Agent operations MUST generate structured audit records using a + standardized format that includes cryptographic integrity + protection and temporal ordering guarantees. Each audit record + contains the agent identity from the attestation layer, operation + type, relevant capability manifest references, timestamp with + cryptographic time-binding, and operation-specific metadata. The + audit record format builds upon JSON Web Signature [RFC7515] + structures to ensure cryptographic integrity while maintaining + human readability for operational troubleshooting. Records MUST + include sufficient context to reconstruct the agent's state and + decision-making process at the time of the logged operation, + enabling comprehensive provenance verification. + + The framework defines multiple audit trail storage models to + accommodate different deployment profiles and trust requirements. + Local audit storage provides high-performance logging for single- + domain deployments, while distributed audit architectures enable + cross-domain provenance tracking through secure federation + protocols. Audit trails MAY be stored in blockchain-based systems + for maximum tamper resistance, traditional database systems with + cryptographic integrity checking, or hybrid approaches that + balance performance and assurance requirements. The storage layer + MUST implement retention policies that comply with regulatory + requirements while supporting efficient querying and verification + operations across potentially large audit datasets. + + Cross-domain audit trail federation enables provenance tracking as + agents operate across multiple systems and administrative + boundaries. The federation protocol builds upon the Agent + Communication Gateway architecture [draft-agent-gw] to establish + secure channels for audit trail sharing while preserving privacy + and confidentiality constraints. Federation participants MUST + implement access control policies that govern which audit + information can be shared across domain boundaries, ensuring that + sensitive operational details remain protected while enabling + necessary provenance verification. The federation protocol + supports both real-time audit streaming for active monitoring and + batch synchronization for historical audit trail reconstruction. + + Audit trail verification mechanisms provide cryptographic + assurance of audit record integrity and completeness across + distributed storage systems. Verification protocols MUST detect + tampering, insertion attacks, and selective deletion of audit + records while providing efficient proof generation for compliance + reporting. The framework integrates with QUIC-based + publish/subscribe systems [draft-a2a-moqt-transport] to enable + real-time audit verification and alerting when provenance + violations are detected. Verification results are themselves + logged to create a complete audit chain that can demonstrate the + integrity of the provenance tracking system to external auditors + and regulatory authorities. + + The audit framework defines standard retention policies and + archival procedures that balance operational requirements with + storage efficiency and regulatory compliance. Short-term audit + data SHOULD be stored with high availability and low latency + access to support real-time monitoring and incident response, + while long-term archival systems focus on integrity preservation + and cost-effective storage. Automated policy enforcement ensures + that audit data transitions through appropriate lifecycle stages + while maintaining cryptographic integrity and chain-of-custody + documentation required for legal and regulatory purposes. + +8. Cross-Ecosystem Integration Patterns + + The APAE framework is designed to integrate seamlessly with + existing identity, authorization, and communication ecosystems + through well-defined integration patterns. These patterns enable + organizations to retrofit provenance assurance capabilities into + deployed agent systems without requiring wholesale replacement of + existing infrastructure. The integration approach leverages + established protocols and standards while extending them with + agent-specific provenance metadata and verification mechanisms. + + Integration with OAuth 2.0 and OpenID Connect ecosystems follows + the Agent Authorization Profile (AAP) [draft-aap-oauth-profile] + extension pattern. Existing OAuth 2.0 authorization servers can be + extended to issue agent-specific access tokens that include + provenance claims alongside traditional authorization claims. The + APAE framework defines standardized JWT [RFC7519] claim extensions + that carry provenance chain identifiers, attestation levels, and + capability manifest references within OAuth access tokens. + Authorization servers MUST validate provenance claims during token + issuance and MAY enforce provenance-based authorization policies. + Resource servers can extract provenance information from access + tokens to make fine-grained authorization decisions based on agent + identity, delegation chains, and operational constraints without + requiring separate provenance lookups. + + Identity management systems integration leverages the SCIM Agent + Extension [draft-abbey-scim-agent-extension] to represent agents + as first-class identity resources. Existing SCIM [RFC7644] + deployments can be extended with agent resource types and user + schema extensions for agent relationships, enabling centralized + management of agent identities alongside human users. The APAE + framework specifies how provenance anchors and capability + manifests are stored as extended attributes within SCIM agent + resources. Identity providers MUST maintain provenance metadata + consistency when provisioning or updating agent identities across + connected systems. User schema extensions enable tracking of + delegation relationships between human users and their associated + agents, supporting organizational governance requirements for + agent oversight. + + Communication protocol integration patterns address both + synchronous and asynchronous agent interactions across different + transport mechanisms. For HTTP-based communications, the framework + defines standardized headers that carry provenance attestations + and audit trail references alongside existing authentication + headers. Message-based systems can embed provenance metadata + within message headers or signed payloads using COSE [RFC9052] + structures for cryptographic integrity. The framework specifies + how existing API gateways and service meshes can be configured to + extract, validate, and propagate provenance information across + service boundaries. Protocol adapters SHOULD preserve provenance + chains when translating between different communication protocols + or message formats. + + Retrofitting guidance for deployed systems emphasizes incremental + adoption patterns that minimize operational disruption. + Organizations can begin by deploying APAE registry services + alongside existing infrastructure to collect provenance data + without enforcing verification policies. Existing agents can be + gradually onboarded by adding provenance metadata to their + identity records and configuring audit logging to feed into APAE + audit trail storage. The framework supports hybrid deployments + where some agents participate in full provenance tracking while + others operate with reduced assurance levels during transition + periods. Migration tooling can extract existing audit logs and + identity information to bootstrap provenance chains for previously + deployed agents. + + Legacy system integration addresses scenarios where existing agent + systems cannot be directly modified to support APAE protocols. + Proxy components can be deployed to intercept agent communications + and inject provenance metadata based on static configuration or + external attestation sources. Gateway services can perform + provenance validation on behalf of legacy systems while presenting + traditional authentication and authorization interfaces to + unchanged applications. The framework defines compatibility modes + that allow APAE-enabled systems to interact safely with non-APAE + systems while maintaining provenance tracking for supported + interactions. Organizations SHOULD document provenance gaps when + integrating with legacy systems and implement compensating + controls where full provenance assurance cannot be achieved. + +9. Deployment Profiles and Trust Models + + The APAE framework defines three primary deployment profiles to + accommodate varying operational requirements, risk tolerances, and + regulatory constraints across different environments. Each profile + represents a distinct configuration of trust anchors, verification + requirements, and assurance mechanisms while maintaining + architectural compatibility to enable agent mobility between + environments. + + The Development Profile provides minimal provenance overhead + suitable for development, testing, and low-risk operational + environments. In this configuration, agent identity MAY be + established through self-signed certificates or local trust + anchors, capability manifests SHOULD be cryptographically signed + but MAY use development keys, and audit trails MAY be stored + locally with basic integrity protection. The Development Profile + enables rapid iteration and testing while introducing core + provenance concepts without the infrastructure overhead of higher + assurance levels. Cross-domain provenance tracking in Development + Profile deployments SHOULD preserve chain integrity but MAY accept + lower verification standards for external attestation anchors. + + The Enterprise Profile establishes intermediate assurance levels + appropriate for business-critical applications, regulated + industries with moderate risk profiles, and multi-organizational + collaborations. This profile MUST implement cryptographically + verifiable provenance anchors rooted in organizational PKI or + approved certificate authorities, capability manifests MUST be + signed by authorized capability authorities, and audit trails MUST + be protected against tampering through cryptographic mechanisms + such as hash chains or digital signatures per [RFC5280]. The + Enterprise Profile MUST support human oversight requirements as + defined in [draft-aap-oauth-profile], enabling enforcement of + human-in-the-loop controls based on agent capabilities, + operational context, or regulatory requirements. Cross-domain + provenance federation in Enterprise deployments MUST implement + bilateral or multilateral trust agreements with explicit policy + mappings for attestation level recognition. + + The High-Assurance Profile provides maximum security and + verification suitable for national security applications, critical + infrastructure, and highly regulated environments with stringent + compliance requirements. This profile MUST implement hardware- + backed provenance anchors using mechanisms consistent with [draft- + jiang-seat-dynamic-attestation], all capability manifests MUST + undergo formal verification processes before deployment, and audit + trails MUST be stored in tamper-evident systems with distributed + verification. High-Assurance deployments MUST implement real-time + capability verification, continuous operational monitoring, and + mandatory human oversight for all agent actions exceeding + predefined risk thresholds. The High-Assurance Profile MUST + support air-gapped operation modes where cross-domain provenance + verification occurs through offline cryptographic proof exchange + rather than real-time federation protocols. + + Trust models within APAE deployments establish the foundation for + provenance verification and cross-domain interoperability while + accommodating different organizational risk appetites and + regulatory frameworks. The framework defines three trust model + categories: Direct Trust, where all agents operate within a single + administrative domain with unified trust anchors; Federated Trust, + where multiple domains establish bilateral or multilateral + agreements for provenance recognition with explicit policy + mappings; and Zero Trust, where each provenance claim undergoes + independent verification regardless of source domain. Zero Trust + configurations MUST implement continuous verification of agent + identity, capabilities, and operational constraints, treating all + provenance claims as potentially compromised until + cryptographically verified against current trust anchors. + Federated Trust models SHOULD implement policy translation + mechanisms to map attestation levels and capability + classifications between domains with different trust frameworks. + + Configuration guidelines for each deployment profile specify + minimum cryptographic requirements, key management practices, and + operational procedures necessary to achieve the target assurance + level. Development Profile deployments MAY use simplified key + management with local certificate authorities and reduced audit + granularity, while Enterprise Profile deployments MUST implement + organizational key management policies consistent with business + risk assessments and applicable regulatory requirements. High- + Assurance Profile configurations MUST implement defense-in-depth + approaches including hardware security modules for key protection, + formal verification of configuration integrity, and continuous + monitoring for provenance chain anomalies or attacks. All + deployment profiles MUST support migration paths to higher + assurance levels, enabling the same agent infrastructure to + operate across varying trust requirements while maintaining + verifiable provenance chains through configuration upgrades rather + than architectural changes. + +10. Security Considerations + + The APAE framework introduces novel security challenges beyond + traditional identity and authentication systems due to the + dynamic, autonomous nature of AI agents and the distributed + character of their operational environments. The framework MUST + address threats across multiple attack vectors including identity + spoofing, provenance chain manipulation, capability + misrepresentation, and audit trail tampering. Unlike static + systems, AI agents can modify their behavior, delegate authority, + and evolve capabilities during runtime, creating attack surfaces + that extend beyond initial deployment security assumptions. The + security model MUST account for the fact that agents operate + across trust boundaries, potentially in adversarial environments, + while maintaining verifiable provenance chains that can be + validated by third parties without exposing sensitive operational + details. + + Privacy preservation represents a critical security requirement as + provenance chains inherently contain sensitive information about + agent capabilities, operational patterns, and delegation + relationships. The framework MUST implement selective disclosure + mechanisms that allow verification of specific provenance claims + without revealing the complete operational history, as specified + in the Capability Manifest attestation procedures [draft-jiang- + seat-dynamic-attestation]. Privacy-preserving techniques such as + zero-knowledge proofs, selective redaction, and differential + privacy SHOULD be employed to protect sensitive provenance data + while maintaining verification capabilities. Cross-domain + provenance sharing MUST implement privacy controls that respect + jurisdictional boundaries and organizational policies, ensuring + that provenance verification can occur without inappropriate + information disclosure between administrative domains. + + Tamper resistance mechanisms are essential for maintaining the + integrity of provenance chains throughout the agent lifecycle. The + framework MUST employ cryptographic techniques including digital + signatures, hash chains, and merkle trees to ensure that + provenance records cannot be modified or deleted without + detection. Agent Identity Preservation patterns MUST be + implemented to maintain cryptographic binding between agent + identity and provenance records across delegation chains and + cross-domain operations [draft-liu-oauth-a2a-profile]. The + framework SHOULD implement distributed ledger or consensus + mechanisms for high-assurance deployments where centralized tamper + resistance is insufficient. All provenance anchors MUST be + cryptographically bound to hardware security modules or trusted + execution environments in high-assurance configurations to prevent + root-level compromise of the provenance chain. + + The threat model encompasses both external adversaries attempting + to compromise agent provenance and insider threats from + compromised agents or malicious operators within trusted domains. + External threats include provenance spoofing attacks where + adversaries attempt to forge agent identities or capability + claims, replay attacks using captured provenance tokens, and man- + in-the-middle attacks during cross-domain provenance verification. + The framework MUST implement robust authentication and + authorization controls as defined in the Traceable Identity and + Provenance requirements [draft-chen-ai-agent-auth-new- + requirements], including time-bound attestations, nonce-based + replay protection, and mutual authentication during provenance + exchanges. Insider threat mitigation MUST include separation of + duties for provenance administration, cryptographic audit logs + that cannot be modified by system administrators, and anomaly + detection for unusual provenance patterns that may indicate + compromise. + + Attack mitigation strategies MUST address the unique + characteristics of AI agent systems including their ability to + rapidly scale, adapt, and potentially collaborate in unexpected + ways. The framework SHOULD implement rate limiting and reputation + mechanisms to prevent provenance flooding attacks where + adversaries attempt to overwhelm verification systems with invalid + provenance claims. Behavioral analysis MUST be employed to detect + agents operating outside their declared capabilities or exhibiting + patterns inconsistent with their provenance claims. The audit + trail federation mechanisms MUST include Byzantine fault tolerance + to ensure that provenance verification remains reliable even when + some participating systems are compromised or behaving + maliciously. + + Security controls for provenance data MUST include encryption at + rest and in transit, access controls based on least privilege + principles, and secure key management for all cryptographic + operations. The framework MUST integrate with existing PKI + infrastructure [RFC5280] and modern cryptographic standards + [RFC9052] while supporting post-quantum cryptographic algorithms + for long-term provenance chain protection. High-assurance + deployments MUST implement hardware security modules for key + storage and cryptographic operations, while lightweight + deployments MAY use software-based cryptographic implementations + with appropriate security controls. All security controls MUST be + configurable based on deployment profiles to ensure that the same + framework can support varying security requirements from + development environments to regulated production systems. + +11. IANA Considerations + + This document requires several IANA registrations to establish the + necessary protocol elements for the Agent Provenance Assurance + Ecosystem (APAE) Framework. The registrations encompass URI + schemes for agent identification and provenance tracking, MIME + types for provenance data formats, and registry namespaces for + standardized provenance attributes and attestation levels. + + The framework introduces new URI schemes that MUST be registered + with IANA to enable consistent agent identification and provenance + chain references across implementations. The "agent-id" URI scheme + provides a standardized format for globally unique agent + identifiers that preserve identity across delegation chains and + administrative domains. The "provenance-chain" URI scheme enables + direct references to specific provenance records and audit trail + segments, supporting cross-domain provenance verification as + specified in Section 8. These URI schemes follow the registration + procedures defined in [RFC7595] and include comprehensive security + considerations for preventing identifier collision and spoofing + attacks. + + New MIME types are required for the structured data formats + defined by the APAE framework, particularly for capability + manifests and provenance audit records. The "application/agent- + manifest+json" MIME type identifies capability manifest documents + as specified in Section 6, enabling proper content negotiation and + validation of agent capability attestations. The + "application/provenance-audit+cbor" MIME type identifies binary- + encoded audit trail records that provide tamper-evident + operational history logging. These MIME types support both human- + readable JSON formats for development environments and compact + CBOR encodings for high-throughput production deployments, + aligning with the deployment profiles described in Section 9. + + The framework establishes a new IANA registry for standardized + provenance attributes and attestation levels to ensure + interoperability across different APAE implementations. The "Agent + Provenance Attributes" registry defines canonical attribute names + for agent identity properties, capability descriptors, and + operational metadata that appear in provenance chains and audit + records. The "Agent Attestation Levels" registry provides + standardized identifiers for different levels of cryptographic and + procedural assurance, ranging from self-signed development + attestations to hardware-backed high-assurance certifications + required in regulated environments. + + Registration of the "apae" namespace is requested for use in JSON + Web Token (JWT) claims [RFC7519] and CBOR Web Token (CWT) claims + [RFC9052] that carry agent provenance information within existing + token-based authentication and authorization flows. This namespace + ensures that APAE-specific claims do not conflict with existing + JWT/CWT claim names while enabling seamless integration with OAuth + 2.0 [RFC6749] and related authorization frameworks. The namespace + registration includes provisions for hierarchical claim + organization to support future extensions of the framework without + requiring additional IANA actions. + +12. References + +12.1. Normative References + + [RFC 2119] + RFC 2119 + + [RFC 8174] + RFC 8174 + + [RFC 6749] + RFC 6749 + + [RFC 7519] + RFC 7519 + + [RFC 5280] + RFC 5280 + + [RFC 9052] + RFC 9052 + + [draft-chen-ai-agent-auth-new-requirements] + draft-chen-ai-agent-auth-new-requirements + + [draft-jiang-seat-dynamic-attestation] + draft-jiang-seat-dynamic-attestation + + [draft-liu-oauth-a2a-profile] + draft-liu-oauth-a2a-profile + + [draft-aap-oauth-profile] + draft-aap-oauth-profile + +12.2. Informative References + + [RFC 8446] + RFC 8446 + + [RFC 9110] + RFC 9110 + + [RFC 8126] + RFC 8126 + + [RFC 8259] + RFC 8259 + + [draft-narvaneni-agent-uri] + draft-narvaneni-agent-uri + + [draft-wendt-stir-vesper] + draft-wendt-stir-vesper + + [draft-a2a-moqt-transport] + draft-a2a-moqt-transport + + [draft-abbey-scim-agent-extension] + draft-abbey-scim-agent-extension + + [draft-agent-gw] + draft-agent-gw + + [draft-ainp-protocol] + draft-ainp-protocol + + [draft-cowles-volt] + draft-cowles-volt + + [draft-aylward-daap-v2] + draft-aylward-daap-v2 + + [draft-guy-bary-stamp-protocol] + draft-guy-bary-stamp-protocol + + +Author's Address + + Generated by IETF Draft Analyzer + Family: agent-ecosystem + 2026-03-04 diff --git a/data/reports/generated-drafts/draft-ai-agent-rollback-protocol-00.txt b/data/reports/generated-drafts/draft-ai-agent-rollback-protocol-00.txt new file mode 100644 index 0000000..8bd9d4a --- /dev/null +++ b/data/reports/generated-drafts/draft-ai-agent-rollback-protocol-00.txt @@ -0,0 +1,804 @@ +Internet-Draft nmrg +Intended status: standards-track March 2026 +Expires: September 05, 2026 + + + Real-Time Agent Rollback Protocol (RARP) for Autonomous Network Operations + draft-agent-ecosystem-agent-rollback-protocol-00 + +Abstract + + Autonomous agents in network operations environments require the + ability to quickly and safely rollback actions when incorrect + decisions are made. While existing protocols enable agent + communication and coordination, no standardized mechanism exists + for distributed rollback operations across heterogeneous agent + systems. This document specifies the Real-Time Agent Rollback + Protocol (RARP), which provides coordinated rollback mechanisms + for autonomous network agents. RARP defines checkpoint creation, + rollback initiation procedures, state consistency verification, + and cross-domain rollback coordination through agent gateways. The + protocol integrates with existing agent communication frameworks + and supports both immediate rollback for safety-critical scenarios + and delayed rollback for complex distributed operations. RARP + enables production deployment of autonomous network operations by + providing the safety mechanisms necessary for agent decision + reversal across distributed systems. + +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. + +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. + + Rollback Point + A consistent state snapshot across distributed agents from + which rollback operations can be initiated + + Agent Transaction + A coordinated set of actions performed by one or more agents + that can be treated as an atomic unit for rollback purposes + + Rollback Coordinator + An entity responsible for orchestrating rollback operations + across multiple agents and domains + + Checkpoint Consistency + The property that all agents participating in a rollback point + have synchronized their state at the same logical time + + Cross-Domain Rollback + A rollback operation that spans multiple administrative or + protocol domains requiring gateway-mediated coordination + + Immediate Rollback + A rollback operation initiated without coordination delays for + safety-critical scenarios + + Coordinated Rollback + A rollback operation that requires multi-agent coordination and + consensus before execution + + +Table of Contents + + 1. Introduction ................................................ 3 + 2. Terminology ................................................. 4 + 3. Problem Statement ........................................... 5 + 4. RARP Architecture and Components ............................ 6 + 5. Checkpoint Creation and Management .......................... 7 + 6. Rollback Initiation and Coordination ........................ 8 + 7. Integration with Existing Agent Protocols ................... 9 + 8. Security Considerations ..................................... 10 + 9. IANA Considerations ......................................... 11 + 10. References .................................................. 12 + +1. Introduction + + The proliferation of autonomous agents in network operations has + introduced unprecedented capabilities for self-healing, + optimization, and adaptive management across complex distributed + systems. As described in [draft-chuyi-nmrg-ai-agent-network], AI- + powered agents can now perform sophisticated reasoning and + decision-making across previously isolated network management + domains. However, the autonomous nature of these systems + introduces a critical challenge: when agents make incorrect + decisions or encounter unexpected conditions, there exists no + standardized mechanism to safely and efficiently reverse their + actions across distributed environments. + + Current agent communication frameworks, including those specified + in [draft-fu-nmop-agent-communication-framework] and [draft-li- + dmsc-macp], provide robust mechanisms for agent coordination and + message exchange but do not address the fundamental requirement + for transaction-like rollback capabilities. While traditional + network management protocols such as NETCONF [RFC6241] include + rollback mechanisms for configuration changes, these operate + within single administrative domains and cannot coordinate complex + rollback operations across heterogeneous agent systems spanning + multiple domains and protocol layers. + + The Real-Time Agent Rollback Protocol (RARP) addresses this gap by + providing a standardized framework for coordinated rollback + operations in autonomous network environments. RARP builds upon + existing agent communication protocols and extends the cross- + domain collaboration mechanisms outlined in [draft-han-rtgwg- + agent-gateway-intercomm-framework] to enable rollback coordination + through gateway intermediaries. The protocol supports both + immediate rollback for safety-critical scenarios where agent + actions must be reversed without delay, and coordinated rollback + for complex distributed operations requiring multi-agent consensus + and state synchronization. + + The architecture defined in this document integrates with existing + agent controller coordination mechanisms [draft-jadoon-nmrg- + agentic-ai-autonomous-networks] while introducing specialized + rollback coordinators and checkpoint managers that operate + alongside current agent communication infrastructure. RARP + leverages established security frameworks including TLS 1.3 + [RFC8446] and OAuth 2.0 [RFC6749] to ensure authenticated and + authorized rollback operations across administrative boundaries. + By providing these safety mechanisms, RARP enables the production + deployment of autonomous network operations with the confidence + that agent decisions can be safely reversed when necessary. + + This specification defines the protocol semantics, message formats + using JSON [RFC8259] encoding, and integration patterns necessary + for implementing RARP across diverse agent ecosystems. 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. Terminology + + This document uses terminology consistent with existing agent + communication and network management protocols. The key words + "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + The following terms are defined for use throughout this + specification: + + Agent: An autonomous software entity capable of making decisions + and performing actions in network operations environments, as + defined in [draft-fu-nmop-agent-communication-framework]. Agents + operate with varying degrees of autonomy and may collaborate + through standardized communication protocols. + + Agent Gateway: A protocol intermediary that enables communication + and coordination between agents operating in different + administrative domains or using different communication protocols, + as specified in [draft-han-rtgwg-agent-gateway-intercomm- + framework]. Agent gateways provide protocol translation and policy + enforcement for cross-domain agent interactions. + + Agent Transaction: A coordinated set of actions performed by one + or more agents that can be treated as an atomic unit for rollback + purposes. Agent transactions may span multiple network devices, + protocol domains, or administrative boundaries and maintain + consistency properties across distributed operations. + + Checkpoint: A persistent snapshot of agent state and network + configuration that serves as a potential rollback target. + Checkpoints contain sufficient information to restore agents and + affected network elements to a previously known consistent state. + + Checkpoint Consistency: The property that all agents participating + in a rollback point have synchronized their state at the same + logical time. Consistency verification ensures that rollback + operations restore the system to a coherent state across all + participating entities. + + Checkpoint Manager: A system component responsible for creating, + storing, validating, and managing rollback checkpoints. Checkpoint + managers coordinate with agents to capture state snapshots and + maintain checkpoint metadata required for rollback operations. + + Coordination State: The current status of multi-agent + collaboration activities, including pending transactions, active + rollback operations, and inter-agent dependencies. Coordination + states are maintained by rollback coordinators to ensure proper + sequencing of rollback operations. + + Cross-Domain Rollback: A rollback operation that spans multiple + administrative or protocol domains requiring gateway-mediated + coordination. Cross-domain rollbacks involve additional complexity + for authentication, authorization, and state synchronization + across domain boundaries. + + Coordinated Rollback: A rollback operation that requires multi- + agent coordination and consensus before execution. Coordinated + rollbacks involve explicit agreement protocols to ensure all + affected agents participate in the rollback operation and reach + consistent post-rollback states. + + Immediate Rollback: A rollback operation initiated without + coordination delays for safety-critical scenarios. Immediate + rollbacks prioritize rapid response over coordination completeness + and are typically used when network safety or security is at + immediate risk. + + Rollback Coordinator: An entity responsible for orchestrating + rollback operations across multiple agents and domains. Rollback + coordinators implement the consensus and coordination protocols + required for distributed rollback operations and may operate in + hierarchical configurations for scalability. + + Rollback Point: A consistent state snapshot across distributed + agents from which rollback operations can be initiated. Rollback + points represent verified consistent states that can be safely + restored through coordinated agent actions. + +3. Problem Statement + + The deployment of autonomous agents in network operations + environments introduces fundamental challenges in ensuring + operational safety through reliable rollback mechanisms. Current + agent communication protocols, including those specified in + [draft-fu-nmop-agent-communication-framework] and [draft-han- + rtgwg-agent-gateway-intercomm-framework], provide sophisticated + mechanisms for agent coordination and cross-domain collaboration + but lack standardized approaches for distributed rollback + operations. When autonomous agents make incorrect decisions or + encounter unexpected failure conditions, the ability to quickly + and consistently revert to a known-good state becomes critical for + maintaining network stability and service availability. + + State consistency across distributed agent systems presents the + most significant challenge in implementing effective rollback + mechanisms. Unlike traditional centralized systems where rollback + operations can be performed atomically, autonomous network agents + operate across multiple administrative domains, protocol layers, + and time scales as described in [draft-jadoon-nmrg-agentic-ai- + autonomous-networks]. Each agent maintains its own local state and + interacts with network infrastructure through different + interfaces, including NETCONF [RFC6241], RESTful APIs, and + proprietary management protocols. Ensuring that all participating + agents can synchronously return to a consistent checkpoint state + requires sophisticated coordination mechanisms that current agent + communication frameworks do not provide. The distributed nature of + these systems means that network partitions, communication delays, + and partial failures can result in inconsistent rollback states + where some agents successfully revert while others remain in post- + action states. + + Cross-domain coordination introduces additional complexity as + agents operating in different administrative domains must + coordinate rollback operations through gateway intermediaries. The + agent gateway framework specified in [draft-han-rtgwg-agent- + gateway-intercomm-framework] enables cross-domain agent + collaboration but does not address the specific requirements for + propagating rollback requests, maintaining checkpoint consistency + across domain boundaries, or handling authorization and security + constraints in multi-domain rollback scenarios. Different domains + may have varying rollback policies, checkpoint retention + requirements, and security constraints that must be negotiated and + enforced during cross-domain rollback operations. Furthermore, the + hierarchical nature of network operations means that rollback + decisions made at higher levels may cascade to multiple lower- + level domains, requiring sophisticated dependency tracking and + coordination protocols. + + Timing constraints in network operations environments create + additional challenges for rollback protocol design. Safety- + critical scenarios, such as security incidents or cascading + failures, require immediate rollback capabilities that cannot wait + for full distributed coordination to complete. However, immediate + rollback operations risk creating inconsistent states if not all + participating agents can execute the rollback synchronously. + Conversely, complex distributed operations may require coordinated + rollback procedures that involve extensive negotiation and + validation phases, but network conditions may change during these + coordination periods, potentially invalidating the target rollback + state. Current agent communication protocols lack mechanisms for + expressing these timing constraints and do not provide + differentiated handling for immediate versus coordinated rollback + scenarios. + + Existing agent communication frameworks also lack adequate + mechanisms for rollback-specific concerns including checkpoint + metadata management, rollback authorization, and audit trail + generation. The multi-agent coordination protocols specified in + [draft-li-dmsc-macp] provide general coordination primitives but + do not address the specific state management requirements for + maintaining consistent checkpoint data across distributed systems. + Additionally, current protocols do not define standardized + approaches for validating checkpoint integrity, handling rollback + conflicts when multiple agents attempt simultaneous rollback + operations, or providing the detailed audit capabilities required + for post-rollback analysis and compliance reporting in production + network environments. + +4. RARP Architecture and Components + + The Real-Time Agent Rollback Protocol architecture is designed to + integrate seamlessly with existing autonomous agent + infrastructures while providing coordinated rollback capabilities + across distributed network operations environments. The + architecture follows a layered approach that separates rollback + coordination logic from agent-specific implementations, enabling + deployment across heterogeneous agent systems. RARP components + leverage existing agent communication frameworks defined in + [draft-fu-nmop-agent-communication-framework] and integrate with + agent gateway mechanisms specified in [draft-han-rtgwg-agent- + gateway-intercomm-framework] to provide cross-domain rollback + coordination capabilities. + + The core RARP architecture consists of three primary component + types: Rollback Coordinators, Checkpoint Managers, and Agent + Rollback Interfaces. Rollback Coordinators serve as the + orchestration layer for rollback operations and MUST implement + coordination protocols for both immediate and delayed rollback + scenarios. These coordinators maintain awareness of agent + relationships, transaction boundaries, and rollback dependencies + across the distributed system. Checkpoint Managers handle the + creation, storage, validation, and retrieval of rollback points, + implementing consistency verification procedures to ensure + distributed state coherence. Agent Rollback Interfaces provide the + integration layer between RARP components and existing agent + systems, translating rollback operations into agent-specific state + restoration procedures while maintaining compatibility with + established agent communication protocols. + + RARP supports both hierarchical and distributed deployment models + to accommodate varying network topologies and administrative + requirements. In hierarchical deployments, a primary Rollback + Coordinator oversees subordinate coordinators within each + administrative domain, providing centralized rollback decision- + making while delegating local coordination to domain-specific + components. This model aligns with the centralized agent + controller coordination patterns described in [draft-jadoon-nmrg- + agentic-ai-autonomous-networks] and enables efficient rollback + operations across large-scale autonomous network deployments. + Distributed deployments eliminate single points of failure by + implementing peer-to-peer coordination among Rollback + Coordinators, using consensus mechanisms to ensure consistent + rollback decisions across all participating domains. + + Integration with existing agent gateway infrastructure enables + RARP to operate across heterogeneous agent systems without + requiring modifications to established communication protocols. + Agent gateways specified in [draft-han-rtgwg-agent-gateway- + intercomm-framework] are extended with RARP capability negotiation + and rollback message translation functions, allowing rollback + coordination between agents using different communication + frameworks. The architecture maintains protocol compatibility by + implementing rollback operations as extensions to existing agent + collaboration protocols rather than replacing established + communication mechanisms. This approach ensures that RARP can be + incrementally deployed in production environments without + disrupting existing agent operations. + + The RARP architecture incorporates checkpoint consistency + verification mechanisms that operate independently of agent- + specific state representations. Checkpoint Managers implement + distributed timestamp synchronization and state validation + procedures to ensure that rollback points represent truly + consistent distributed states across all participating agents. The + architecture supports integration with AI Agent Network systems as + described in [draft-chuyi-nmrg-ai-agent-network] by providing + rollback interfaces that can reverse automated reasoning and + decision-making operations performed by large language model-based + agents. Component communication within the RARP architecture + utilizes secure transport mechanisms including TLS 1.3 [RFC8446] + and QUIC [RFC9000] to ensure rollback coordination messages are + protected against tampering and unauthorized access during + transmission between distributed components. + +5. Checkpoint Creation and Management + + Checkpoint creation in RARP enables autonomous agents to establish + consistent state snapshots that serve as restoration points for + rollback operations. Agents MUST implement checkpoint creation + capabilities that capture both local state information and + coordination metadata necessary for distributed rollback + operations. The checkpoint creation process involves state + serialization, metadata generation, and consistency coordination + with peer agents participating in the same logical transaction + scope. Agents SHOULD create checkpoints at natural transaction + boundaries and MAY create additional checkpoints based on risk + assessment algorithms or external triggers. + + The checkpoint data structure MUST include agent state + information, transaction identifiers, temporal consistency + markers, and dependency relationships with other agents as + specified in [draft-han-rtgwg-agent-gateway-intercomm-framework]. + Checkpoint metadata MUST conform to the JSON format specified in + [RFC8259] and include fields for checkpoint identifier, creation + timestamp, agent identifier, transaction scope, dependency list, + and integrity verification data. Cross-domain checkpoints MUST + additionally include gateway coordination information and domain- + specific authorization tokens as defined in [draft-fu-nmop-agent- + communication-framework]. The checkpoint identifier MUST be + globally unique and SHOULD incorporate both temporal and spatial + components to ensure uniqueness across distributed deployments. + + Checkpoint storage mechanisms MUST provide durability guarantees + appropriate for the operational context and SHOULD implement + redundancy strategies to prevent single points of failure. Agents + MAY utilize local storage, distributed storage systems, or + centralized checkpoint repositories depending on deployment + constraints and consistency requirements. Storage implementations + MUST support atomic write operations and SHOULD provide integrity + verification through cryptographic mechanisms as specified in + [RFC8446]. Cross-domain checkpoint storage MUST implement access + control mechanisms that respect administrative boundaries while + enabling authorized rollback operations. + + Checkpoint consistency verification ensures that distributed + checkpoints represent a globally consistent state across all + participating agents. The consistency verification process MUST + implement logical clock synchronization or vector clock mechanisms + to establish temporal relationships between distributed + checkpoints. Agents MUST validate checkpoint consistency before + committing checkpoint data and SHOULD implement timeout mechanisms + to handle non-responsive participants. For cross-domain scenarios, + consistency verification MUST account for network partitions and + administrative policy constraints that may affect coordination + capabilities. + + Checkpoint lifecycle management encompasses creation, validation, + storage, retrieval, and cleanup operations across the distributed + agent system. Agents MUST implement checkpoint retention policies + that balance storage costs with rollback capability requirements + and SHOULD provide configuration mechanisms for policy + customization. Checkpoint cleanup operations MUST respect + dependency relationships and transaction boundaries to prevent + premature deletion of required rollback data. The checkpoint + manager component SHOULD implement background processes for + checkpoint optimization, compression, and garbage collection to + maintain system performance over extended operational periods. + +6. Rollback Initiation and Coordination + + Rollback operations in RARP are initiated through a well-defined + trigger and coordination mechanism that ensures consistent state + recovery across distributed agent systems. Rollback initiation can + occur through multiple pathways: explicit administrative commands, + automated safety triggers when agents detect anomalous conditions, + or cascade triggers when dependent agent operations fail. The + protocol defines two primary rollback modes - immediate rollback + for safety-critical scenarios where rapid state recovery is + essential, and coordinated rollback for complex distributed + operations requiring multi-agent consensus. All rollback + operations MUST specify a target rollback point identifier and + include sufficient context information to enable receiving agents + to validate the rollback request against their local checkpoint + metadata. + + The coordination messaging framework builds upon the Cross-Domain + Agent Collaboration Protocol [draft-han-rtgwg-agent-gateway- + intercomm-framework] to enable rollback operations across + heterogeneous agent systems and administrative boundaries. When a + rollback coordinator receives a rollback initiation request, it + MUST first validate the requesting entity's authorization and + verify that the target rollback point exists across all + participating agents. The coordinator then broadcasts a rollback + preparation message to all agents within the rollback scope, + allowing each agent to perform local consistency checks and report + any conflicts or dependencies that might prevent successful + rollback. This two-phase approach ensures that rollback operations + only proceed when all participating agents can successfully return + to the specified rollback point without creating inconsistent + intermediate states. + + Immediate rollback scenarios bypass the standard coordination + phase when safety-critical conditions are detected, such as + security breaches or network failures that require rapid + remediation. In immediate rollback mode, the rollback coordinator + MUST issue rollback execution commands directly to all + participating agents without waiting for preparation + confirmations, accepting the risk of temporary inconsistency in + favor of rapid recovery. Agents receiving immediate rollback + commands SHALL prioritize rollback execution over normal + operations and SHOULD complete rollback within the time bounds + specified in the rollback request. The protocol defines fallback + procedures for handling agents that cannot complete immediate + rollback operations, including isolation mechanisms to prevent + inconsistent agents from affecting the recovered system state. + + Coordinated rollback operations involve a more complex multi-phase + protocol that ensures consistency across distributed agent systems + through explicit consensus mechanisms. Following the preparation + phase, agents that successfully validate the rollback request send + confirmation messages to the rollback coordinator, while agents + that detect conflicts or missing checkpoint data send abort + messages with detailed error information. The coordinator + implements a configurable consensus policy that determines whether + to proceed with rollback based on the responses received - strict + consensus requires all agents to confirm, while majority consensus + allows rollback to proceed if a sufficient percentage of agents + confirm readiness. If consensus is achieved, the coordinator + broadcasts commit messages triggering simultaneous rollback + execution; if consensus fails, the coordinator issues abort + messages and logs the rollback attempt for administrative review. + + Conflict resolution mechanisms address scenarios where multiple + concurrent rollback requests or overlapping rollback scopes create + coordination challenges. The protocol employs a priority-based + conflict resolution system where rollback requests include + priority levels, timestamps, and scope identifiers that enable + coordinators to determine precedence when conflicts occur. Higher + priority rollback operations, such as security-related rollbacks, + automatically supersede lower priority operations, while rollback + requests with overlapping scope are serialized based on timestamp + ordering. Cross-domain rollback conflicts are resolved through + gateway-mediated negotiation procedures that leverage the agent + controller coordination mechanisms defined in [draft-jadoon-nmrg- + agentic-ai-autonomous-networks] to ensure consistent rollback + decisions across administrative boundaries. + + The protocol includes comprehensive error handling and recovery + procedures for rollback coordination failures, recognizing that + rollback operations themselves may encounter system failures or + network partitions. When rollback coordination fails due to + network issues or coordinator failures, backup coordinators + automatically assume responsibility for completing the rollback + operation using persistent coordination state stored during the + initial phases. Partial rollback failures, where some agents + successfully rollback while others fail, trigger automatic + reconciliation procedures that either retry the failed rollback + operations or initiate compensating actions to restore system + consistency. All rollback coordination activities are logged with + sufficient detail to enable post-incident analysis and continuous + improvement of rollback procedures in production autonomous + network operations environments. + +7. Integration with Existing Agent Protocols + + RARP is designed to integrate seamlessly with existing agent + communication frameworks and protocols, leveraging established + mechanisms while extending them with rollback-specific + capabilities. The protocol operates as an overlay service that can + be bound to various underlying agent communication protocols, + including those defined in [draft-fu-nmop-agent-communication- + framework] and [draft-li-dmsc-macp]. Integration is achieved + through protocol-specific binding specifications that map RARP + operations to the message formats and coordination mechanisms of + the underlying framework. This approach ensures that RARP can be + deployed incrementally without requiring wholesale replacement of + existing agent infrastructure. + + For cross-domain scenarios, RARP extends the gateway mechanisms + defined in [draft-han-rtgwg-agent-gateway-intercomm-framework] to + support rollback coordination across administrative boundaries. + Agent gateways MUST implement RARP-specific message translation + and state synchronization functions when serving as intermediaries + for cross-domain rollback operations. The gateway extensions + include rollback capability negotiation during agent discovery, + checkpoint metadata translation between domains, and coordination + of distributed rollback timing. Gateways SHOULD maintain rollback + context for active cross-domain agent transactions and MUST + participate in checkpoint consistency verification procedures when + coordinating multi-domain rollbacks. + + RARP bindings for common transport protocols are defined to ensure + broad compatibility with existing deployments. For NETCONF-based + agent communication [RFC6241], RARP operations are encapsulated + within custom RPC operations that extend the base protocol + capabilities. HTTP/2 and HTTP/3 [RFC9000] bindings utilize JSON- + encoded messages [RFC8259] for rollback coordination, with TLS 1.3 + [RFC8446] providing transport security. WebSocket connections MAY + be used for real-time rollback notifications in environments + requiring low-latency coordination. Each binding specification + defines the mapping between RARP primitive operations and the + specific message formats and error handling mechanisms of the + underlying protocol. + + The integration architecture supports both centralized and + distributed coordination models as described in [draft-jadoon- + nmrg-agentic-ai-autonomous-networks]. In centralized deployments, + a single rollback coordinator interfaces with existing agent + controllers to provide system-wide rollback capabilities. + Distributed deployments utilize peer-to-peer coordination among + agents while maintaining compatibility with hierarchical agent + architectures. RARP implementations MUST support capability + advertisement through existing agent discovery mechanisms, + allowing agents to negotiate rollback support and identify + compatible rollback coordinators during system initialization. + + Authentication and authorization for RARP operations leverage + existing agent security frameworks where possible. OAuth 2.0 + [RFC6749] tokens MAY be used for cross-domain authorization when + integrating with web-based agent platforms. The protocol defines + extension points for integrating with domain-specific + authentication mechanisms while maintaining consistent rollback + authorization policies. Implementations SHOULD reuse existing + agent identity management infrastructure to minimize operational + complexity and ensure consistent security policies across normal + operations and rollback scenarios. + +8. Security Considerations + + The rollback capabilities provided by RARP introduce several + security considerations that must be addressed to ensure safe + deployment in production autonomous network environments. Rollback + operations inherently involve state manipulation and coordination + across distributed systems, creating potential attack vectors that + could be exploited to disrupt network operations or gain + unauthorized access to sensitive network state information. The + cross-domain nature of RARP operations, as described in [draft- + han-rtgwg-agent-gateway-intercomm-framework], further amplifies + these security concerns by introducing trust boundaries and + protocol translation points where security policies may differ. + + Authorization and access control for rollback operations MUST be + implemented using strong authentication mechanisms consistent with + [RFC8446] for transport-layer security and [RFC6749] for + authorization delegation across domains. Each rollback coordinator + and participating agent MUST authenticate its identity before + initiating or participating in rollback operations. The protocol + MUST enforce role-based access control where only authorized + entities can initiate rollback operations for specific network + domains or agent systems. Cross-domain rollback operations MUST + validate authorization chains through gateway intermediaries, + ensuring that rollback requests are properly authenticated at each + administrative boundary. Emergency or immediate rollback + operations SHOULD maintain security requirements while providing + expedited authorization paths for safety-critical scenarios. + + Comprehensive audit trails MUST be maintained for all rollback + operations to ensure accountability and enable forensic analysis + of network incidents. The audit system MUST record rollback + initiation events, participating agents, checkpoint identifiers, + authorization decisions, and completion status using tamper- + resistant logging mechanisms. These audit records MUST be + synchronized across participating domains and stored with + sufficient integrity protection to prevent unauthorized + modification. The audit trail format SHOULD be compatible with + existing network management audit systems and MUST include + sufficient detail to reconstruct the sequence of events leading to + and following rollback operations. + + Protection against malicious rollback attacks requires careful + consideration of potential attack vectors including replay + attacks, unauthorized rollback initiation, and checkpoint + poisoning. The protocol MUST implement sequence numbers and + timestamps to prevent replay of rollback messages, with + verification of message freshness using techniques consistent with + [RFC9000]. Rollback coordinators MUST validate checkpoint + integrity before executing rollback operations and SHOULD + implement rate limiting to prevent denial-of-service attacks + through excessive rollback requests. The protocol MUST detect and + mitigate attempts to rollback to compromised or maliciously + modified checkpoints through cryptographic verification of + checkpoint contents and metadata. + + Cross-domain security implications require special consideration + for trust establishment and security policy coordination between + administrative domains. Gateway entities facilitating cross-domain + rollback MUST enforce security policy translation and ensure that + rollback operations comply with the security requirements of all + participating domains. The protocol MUST support security policy + negotiation to establish common security parameters for cross- + domain rollback operations while maintaining the security + standards of the most restrictive participating domain. Inter- + domain rollback operations SHOULD implement additional + verification steps and MAY require human authorization for + operations that could significantly impact network stability + across domain boundaries. + +9. IANA Considerations + + This document requests the creation of several new IANA registries + for the Real-Time Agent Rollback Protocol (RARP) and the + registration of initial values. The registries are necessary to + ensure consistent implementation and interoperability of RARP + across different autonomous agent systems and administrative + domains. These registries support the protocol's integration with + existing agent communication frameworks as defined in [draft-fu- + nmop-agent-communication-framework] and cross-domain coordination + mechanisms specified in [draft-han-rtgwg-agent-gateway-intercomm- + framework]. + + IANA is requested to create a new registry group titled "Real-Time + Agent Rollback Protocol (RARP) Parameters" with four sub- + registries. The "RARP Message Types" registry MUST contain 16-bit + unsigned integer values from 0 to 65535, with values 0-255 + reserved for IANA allocation and 256-65535 designated for first- + come, first-served registration following [RFC8126] guidelines. + Initial registrations MUST include: ROLLBACKREQUEST (1), + ROLLBACKRESPONSE (2), CHECKPOINTCREATE (3), CHECKPOINTVALIDATE + (4), COORDINATIONINIT (5), and COORDINATIONCOMPLETE (6). Each + registration requires a message type name, numeric value, + description, and reference to this specification or subsequent + extensions. + + The "RARP Error Codes" registry SHALL use 16-bit unsigned integer + values with similar allocation policies. Initial error code + registrations MUST include: CHECKPOINTNOTFOUND (1001), + INSUFFICIENTPERMISSIONS (1002), ROLLBACKCONFLICT (1003), + CROSSDOMAINFAILURE (1004), STATEINCONSISTENT (1005), and + COORDINATIONTIMEOUT (1006). The "RARP Capability Identifiers" + registry uses string-based identifiers following the reverse DNS + naming convention to prevent namespace collisions. Initial + capability identifiers SHOULD include "rollback.immediate", + "rollback.coordinated", "checkpoint.distributed", and + "integration.gateway" to support the core protocol functionality + and integration patterns described in this specification. + + The "RARP Agent Transaction Types" registry supports the + classification and coordination of rollback operations across + heterogeneous agent systems. This registry uses string-based + identifiers and MUST include initial registrations for + "network.configuration", "routing.policy", "security.rule", and + "service.deployment" to align with common network operations use + cases. Registration procedures for all RARP registries MUST + require specification of the parameter name, value, description, + security considerations if applicable, and reference document. + Registrants SHOULD provide interoperability considerations when + the parameter affects cross-domain operations or integration with + existing protocols such as NETCONF [RFC6241] or agent gateway + frameworks. + + All RARP registry entries MUST be subject to expert review for + values in the IANA allocation ranges, with designated experts + evaluating technical soundness, potential conflicts with existing + registrations, and alignment with RARP architectural principles. + The expert review process SHALL consider the impact on cross- + domain rollback coordination and compatibility with existing agent + communication protocols. Registry updates affecting security- + sensitive parameters such as authorization capabilities or cross- + domain coordination mechanisms require additional security review + to ensure consistency with the security considerations outlined in + Section 8 of this specification and general security practices for + autonomous network operations. + +10. References + +10.1. Normative References + + [RFC 2119] + RFC 2119 + + [RFC 8174] + RFC 8174 + + [RFC 8259] + RFC 8259 + + [RFC 6241] + RFC 6241 + + [draft-han-rtgwg-agent-gateway-intercomm-framework] + draft-han-rtgwg-agent-gateway-intercomm-framework + + [draft-li-dmsc-macp] + draft-li-dmsc-macp + + [draft-fu-nmop-agent-communication-framework] + draft-fu-nmop-agent-communication-framework + +10.2. Informative References + + [RFC 8446] + RFC 8446 + + [RFC 9000] + RFC 9000 + + [RFC 6749] + RFC 6749 + + [draft-chuyi-nmrg-ai-agent-network] + draft-chuyi-nmrg-ai-agent-network + + [draft-jadoon-nmrg-agentic-ai-autonomous-networks] + draft-jadoon-nmrg-agentic-ai-autonomous-networks + + [draft-vandoulas-aidp] + draft-vandoulas-aidp + + [draft-cui-ai-agent-discovery-invocation] + draft-cui-ai-agent-discovery-invocation + + [draft-wang-nmrg-magent-im] + draft-wang-nmrg-magent-im + + [draft-cui-nmrg-llm-benchmark] + draft-cui-nmrg-llm-benchmark + + [draft-yue-anima-agent-recovery-networks] + draft-yue-anima-agent-recovery-networks + + +Author's Address + + Generated by IETF Draft Analyzer + Family: agent-ecosystem + 2026-03-04 diff --git a/data/reports/generated-drafts/draft-ai-agent-task-a-00.txt b/data/reports/generated-drafts/draft-ai-agent-task-a-00.txt new file mode 100644 index 0000000..f7e2eef --- /dev/null +++ b/data/reports/generated-drafts/draft-ai-agent-task-a-00.txt @@ -0,0 +1,793 @@ +Internet-Draft anima +Intended status: standards-track March 2026 +Expires: September 05, 2026 + + + Agent Task DAG: A Framework for Directed Acyclic Graph Execution in Multi-Agent Systems + draft-agent-ecosystem-agent-task-a-00 + +Abstract + + As AI agent systems become increasingly complex, there is a + growing need for structured approaches to orchestrate multi-step + tasks across multiple autonomous agents. This document defines the + Agent Task DAG (Directed Acyclic Graph) framework, which provides + a standardized approach for representing, executing, and managing + complex workflows in multi-agent environments. The framework + addresses key challenges including task decomposition, dependency + management, parallel execution, failure recovery, and human + oversight integration. By building upon existing agent + authorization profiles and task negotiation protocols, this + specification enables agents to coordinate complex workflows while + maintaining security, auditability, and the ability to incorporate + human-in-the-loop decision points. The framework supports both + fast execution in trusted environments and rigorous verification + in regulated contexts through configurable assurance profiles. + +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. + +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. + + Agent Task DAG + A directed acyclic graph representing a complex workflow where + nodes represent individual tasks and edges represent + dependencies between tasks + + Task Node + An individual unit of work within a DAG that can be executed by + one or more agents + + Execution Context + The runtime environment and state information associated with + DAG execution, including agent assignments, intermediate + results, and checkpoint data + + Checkpoint + A persistent snapshot of DAG execution state that enables + rollback and recovery operations + + Task Binding + The association of a task node with specific agent capabilities + or agent instances + + DAG Coordinator + An agent or system component responsible for orchestrating the + execution of a complete DAG workflow + + +Table of Contents + + 1. Introduction ................................................ 3 + 2. Terminology ................................................. 4 + 3. Problem Statement ........................................... 5 + 4. Agent Task DAG Framework .................................... 6 + 5. Task Execution Protocol ..................................... 7 + 6. Checkpoint and Recovery Mechanisms .......................... 8 + 7. Integration with Existing Agent Protocols ................... 9 + 8. Security Considerations ..................................... 10 + 9. IANA Considerations ......................................... 11 + 10. References .................................................. 12 + +1. Introduction + + The increasing sophistication of AI agent systems has created a + demand for structured approaches to orchestrate complex, multi- + step tasks across autonomous agents. While individual agents have + become capable of handling sophisticated reasoning and execution + tasks, real-world applications often require coordinating multiple + agents to complete workflows that involve parallel processing, + sequential dependencies, and dynamic task allocation. Current + approaches to multi-agent coordination typically rely on ad-hoc + communication patterns or simple request-response chains, which + lack the expressiveness and reliability needed for complex + enterprise and research applications. + + This document defines the Agent Task DAG (Directed Acyclic Graph) + framework, which provides a standardized approach for + representing, executing, and managing complex workflows in multi- + agent environments. The framework builds upon existing agent + protocols, particularly the Agent Authorization Profile [draft- + aap-oauth-profile] for security and authorization, and agent task + coordination mechanisms [draft-cui-ai-agent-task] for basic task + execution. By representing workflows as directed acyclic graphs, + the framework enables explicit modeling of task dependencies, + parallel execution opportunities, and conditional branching while + maintaining guarantees about workflow termination and consistency. + + The Agent Task DAG framework addresses several critical challenges + in multi-agent systems: task decomposition and dependency + management, efficient parallel execution across heterogeneous + agents, robust failure recovery and rollback mechanisms, and + integration of human oversight at critical decision points. The + framework leverages structured claims for agent context [draft- + aap-oauth-profile] to enable context-aware task assignment and + supports agent context distribution mechanisms [draft-chang-agent- + context-interaction] to maintain coherent state across complex + multi-round workflows. This approach ensures that agents can + coordinate effectively while maintaining security boundaries and + audit trails required in enterprise environments. + + The specification is designed to be protocol-agnostic and can + operate over various transport mechanisms including HTTP + [RFC9110], message queuing systems, and specialized agent + communication protocols. The framework integrates with existing + OAuth 2.0 [RFC6749] and JWT [RFC7519] infrastructure through the + Agent Authorization Profile, enabling seamless deployment in + environments that already support agent authentication and + authorization. The DAG representation follows JSON [RFC8259] + encoding standards to ensure broad compatibility and easy + integration with existing agent development frameworks. + + This document focuses specifically on the DAG execution framework + and does not address broader questions of agent discovery, + capability matching, or task marketplace mechanisms, which are + covered by complementary specifications. The framework assumes the + existence of agent authorization infrastructure and builds upon + established patterns for agent-to-agent communication while + providing the additional structure needed for complex workflow + coordination. + +2. 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. + + This specification builds upon terminology established in the + Agent Authorization Profile [draft-aap-oauth-profile], AI Agent + Task specifications [draft-cui-ai-agent-task], and Agent Context + Interaction mechanisms [draft-chang-agent-context-interaction]. + The following terms are defined for use throughout this document: + + Agent Task DAG: A directed acyclic graph data structure + representing a complex multi-step workflow where nodes correspond + to individual tasks and directed edges represent dependency + relationships between tasks. The DAG enforces execution ordering + constraints while enabling parallel execution of independent task + branches. Each DAG maintains metadata including creation time, + ownership, and execution policies that govern how the workflow may + be executed across multiple agents. + + Task Node: An individual unit of work within an Agent Task DAG + that encapsulates a specific operation to be performed by one or + more AI agents. Each task node contains task specifications, + input/output schemas, execution constraints, and binding + requirements that determine which agents are capable of executing + the task. Task nodes maintain state information including + execution status, assigned agents, and result data as defined in + [draft-cui-ai-agent-task]. + + Execution Context: The runtime environment and associated state + information that governs the execution of an Agent Task DAG. The + execution context includes agent assignments, intermediate task + results, security credentials, operational constraints from Agent + Authorization Profiles [draft-aap-oauth-profile], and distributed + context information as specified in [draft-chang-agent-context- + interaction]. The execution context ensures consistency and + provides necessary information for task coordination across + multiple agents. + + Checkpoint: A persistent, immutable snapshot of Agent Task DAG + execution state captured at a specific point in time. Checkpoints + contain the complete execution context, task completion status, + intermediate results, and sufficient metadata to enable rollback + and recovery operations. Checkpoints serve as recovery points for + failure scenarios and decision points for human-in-the-loop + interventions. + + Task Binding: The process and resulting association between a task + node and specific agent capabilities or agent instances that will + execute the task. Task binding considers agent authorization + profiles, capability matching, resource availability, and security + constraints. The binding process may be performed statically + during DAG planning or dynamically during execution based on + runtime conditions. + + DAG Coordinator: An agent or system component responsible for + orchestrating the complete lifecycle of Agent Task DAG execution. + The DAG Coordinator manages task scheduling, monitors execution + progress, handles inter-agent communication, enforces security + policies, and coordinates checkpoint and recovery operations. The + coordinator maintains the authoritative view of DAG execution + state and serves as the primary interface for human oversight and + intervention. + +3. Problem Statement + + Current approaches to multi-agent task coordination suffer from + several fundamental limitations that impede the development of + robust, scalable autonomous systems. Existing coordination + mechanisms typically rely on ad-hoc communication patterns, simple + request-response protocols, or basic workflow engines that were + not designed for the dynamic, autonomous nature of AI agents. + While protocols like those defined in [draft-cui-ai-agent-task] + provide foundations for individual task execution, they lack + standardized approaches for managing complex workflows involving + multiple interdependent tasks across heterogeneous agent + populations. The Agent Authorization Profile [draft-aap-oauth- + profile] establishes important primitives for agent identity and + authorization, but does not address the orchestration challenges + that arise when multiple authorized agents must coordinate to + complete complex, multi-step objectives. + + The complexity of real-world AI agent applications demands + structured approaches to task decomposition and dependency + management that current protocols do not adequately address. + Agents operating in domains such as scientific research, business + process automation, or infrastructure management often require + workflows where tasks have intricate dependencies, may execute in + parallel when possible, and must handle partial failures + gracefully. Without standardized mechanisms for representing these + relationships, agent systems resort to brittle, custom + coordination logic that is difficult to audit, debug, or modify. + The lack of formal workflow representation also prevents effective + human oversight integration, as stakeholders cannot easily + understand or intervene in complex multi-agent processes. + + Agent Context Distribution mechanisms [draft-chang-agent-context- + interaction] have demonstrated that context sharing among agents + significantly impacts execution success rates, but current + approaches do not provide systematic ways to manage context + propagation through complex workflows. In multi-step processes, + intermediate results from one task often serve as inputs to + downstream tasks, creating context dependencies that must be + carefully managed to ensure workflow integrity. Existing protocols + lack standardized approaches for maintaining execution context + across task boundaries, leading to information loss, redundant + computation, and coordination failures that compromise overall + system reliability. + + Fault tolerance and recovery represent critical gaps in current + multi-agent coordination approaches. Real-world agent systems must + handle various failure modes including agent unavailability, task + timeouts, resource constraints, and partial execution failures. + Without systematic checkpoint and recovery mechanisms, workflows + often must restart completely when any component fails, leading to + inefficient resource utilization and poor user experience. The + absence of standardized rollback capabilities also complicates + human intervention scenarios, where domain experts may need to + modify workflow parameters or task assignments based on + intermediate results or changing requirements. + + Scalability challenges emerge when current coordination approaches + encounter workflows with dozens or hundreds of interdependent + tasks distributed across multiple agent instances. Simple + centralized coordination quickly becomes a bottleneck, while fully + decentralized approaches struggle with consistency and deadlock + prevention. The lack of standardized protocols for parallel task + execution, resource allocation, and progress monitoring prevents + agent systems from efficiently utilizing available computational + resources. Additionally, without formal workflow representation, + it becomes difficult to optimize task scheduling, predict resource + requirements, or provide meaningful progress indicators to human + stakeholders. + + These limitations necessitate a framework that provides: + structured representation of complex workflows with explicit + dependency management; standardized protocols for parallel + execution and agent coordination; systematic checkpoint and + recovery mechanisms that enable fault tolerance and human + intervention; integration with existing agent authorization and + context distribution mechanisms; and scalable execution patterns + that can accommodate workflows ranging from simple sequential + processes to complex parallel computations involving multiple + agent populations. + +4. Agent Task DAG Framework + + This section defines the core data model and execution semantics + for the Agent Task DAG framework. The framework provides a + structured approach for representing complex multi-agent workflows + as directed acyclic graphs, where individual tasks are modeled as + nodes and dependencies between tasks are represented as edges. The + data model builds upon existing agent protocol foundations while + introducing specific constructs needed for distributed workflow + orchestration. + + 4.1. DAG Data Model + + An Agent Task DAG MUST be represented as a JSON object [RFC8259] + that contains the complete specification of a workflow. The DAG + structure consists of three primary components: metadata + describing the overall workflow, a collection of task nodes + representing individual units of work, and dependency + relationships that define execution ordering constraints. Each DAG + MUST include a unique identifier, version information, and + execution parameters that govern how the workflow should be + processed. + + Task nodes within the DAG represent atomic units of work that can + be executed by autonomous agents. Each task node MUST specify its + execution requirements, including required agent capabilities, + input and output data schemas, and execution constraints such as + timeouts or resource limits. Task nodes SHOULD reference + standardized task types as defined in [draft-cui-ai-agent-task] + where applicable, enabling interoperability across different agent + implementations. The task specification MUST include sufficient + information for agents to determine their capability to execute + the task and negotiate execution parameters. + + Dependency relationships between task nodes are expressed through + edge definitions that establish partial ordering constraints over + the DAG. Each edge MUST specify source and target task nodes, with + the semantic meaning that the target task cannot begin execution + until the source task has completed successfully. Edges MAY + include conditional execution logic, allowing for branching + workflows based on the results of predecessor tasks. The framework + supports both data dependencies, where output from one task serves + as input to another, and control dependencies, where task ordering + is required for correctness without direct data flow. + + 4.2. Execution Context Management + + The Execution Context provides the runtime environment for DAG + processing and maintains state information throughout workflow + execution. The execution context MUST track the current state of + each task node, intermediate results produced during execution, + and metadata about agent assignments for each task. Context + information SHOULD be distributed among participating agents using + the mechanisms defined in [draft-chang-agent-context-interaction] + to ensure consistent state visibility across the multi-agent + system. + + Agent binding within the execution context associates task nodes + with specific agent instances or agent capability requirements. + The framework supports both static binding, where task assignments + are predetermined before execution begins, and dynamic binding, + where task assignments are resolved at runtime based on agent + availability and capability matching. When integrated with Agent + Authorization Profiles [draft-aap-oauth-profile], the execution + context MUST validate that assigned agents possess the necessary + authorization claims to execute their bound tasks. + + Checkpoint creation within the execution context enables + persistent state management and recovery capabilities. The + framework MUST support checkpoint creation at configurable + intervals, capturing the complete state of DAG execution including + task completion status, intermediate results, and current agent + assignments. Checkpoints SHOULD be created automatically before + task nodes that are marked as requiring human oversight, enabling + rollback to known-good states when human intervention modifies the + workflow execution path. + + 4.3. Task Execution Semantics + + Task execution within the DAG framework follows a coordination + model where a DAG Coordinator orchestrates workflow progress while + individual agents execute assigned tasks autonomously. The + coordinator MUST maintain the global view of DAG state and + determine when task dependencies have been satisfied, enabling + parallel execution of independent task branches. Task scheduling + MUST respect dependency constraints while maximizing parallel + execution opportunities to optimize overall workflow completion + time. + + The framework defines specific execution states for task nodes + including pending, ready, executing, completed, failed, and + skipped. State transitions MUST be coordinated through the DAG + Coordinator to ensure consistency across the distributed system. + When a task transitions to the ready state, the coordinator SHOULD + initiate agent assignment and task negotiation protocols to begin + execution. Failed tasks MAY trigger rollback procedures or + alternate execution paths depending on the configured failure + handling policies. + + Integration with existing agent protocols occurs through + standardized interfaces that abstract the underlying communication + mechanisms. The framework MUST support protocol-agnostic bindings + that allow integration with different agent discovery, + authorization, and communication protocols. Task execution + requests SHOULD include structured claims as defined in [draft- + aap-oauth-profile] when agent authorization is required, ensuring + that security and audit requirements are maintained throughout the + distributed workflow execution. + +5. Task Execution Protocol + + The Agent Task DAG execution protocol defines a standardized + approach for coordinating the execution of complex workflows + across multiple autonomous agents. The protocol builds upon + existing agent communication mechanisms and authorization + frameworks, particularly the Agent Authorization Profile [draft- + aap-oauth-profile], to enable secure and auditable workflow + execution. The execution model supports both centralized + coordination through a designated DAG Coordinator and distributed + execution patterns where agents negotiate task assignments + dynamically. + + The execution protocol operates through a series of well-defined + phases: initialization, task scheduling, parallel execution, and + completion verification. During initialization, the DAG + Coordinator validates the workflow structure, resolves task + bindings to available agents, and establishes the execution + context. Task scheduling follows topological ordering of the DAG, + with the coordinator identifying executable tasks (those with + satisfied dependencies) and dispatching them to appropriate + agents. The protocol supports parallel execution of independent + tasks while maintaining strict dependency ordering through state + synchronization mechanisms. + + Agent coordination during DAG execution relies on structured + message exchanges that convey task assignments, status updates, + and result propagation. Task assignment messages MUST include the + complete task specification, execution context parameters, and any + required authorization tokens following the Agent Authorization + Profile format [draft-aap-oauth-profile]. Agents respond with + acceptance confirmations that include estimated execution time and + resource requirements. Status update messages provide real-time + execution progress and MUST be sent at configurable intervals to + enable failure detection and recovery operations. + + State synchronization across the multi-agent system is achieved + through a combination of checkpoint mechanisms and distributed + context sharing. The DAG Coordinator maintains the authoritative + execution state, including task completion status, intermediate + results, and dependency satisfaction tracking. Agent Context + Distribution mechanisms [draft-chang-agent-context-interaction] + are employed to efficiently share relevant context information + among participating agents, reducing redundant data transfer while + ensuring each agent has access to necessary execution context. + Intermediate results from completed tasks are propagated to + dependent tasks through structured result messages that preserve + data lineage and enable audit trail construction. + + The protocol defines specific message formats for each phase of + execution, using JSON [RFC8259] structures that can be embedded + within existing agent communication protocols. Task execution + requests include fields for task identification, input parameters, + execution constraints, and callback endpoints for status + reporting. Result messages contain structured output data, + execution metadata, and quality indicators that enable downstream + tasks to validate input requirements. Error and exception messages + provide detailed failure information including error codes, + diagnostic data, and suggested recovery actions. + + Parallel execution coordination addresses the challenges of + resource contention and optimal scheduling across heterogeneous + agent capabilities. The protocol supports both push-based task + assignment, where the coordinator actively distributes work, and + pull-based execution, where agents request tasks based on their + availability and capabilities. Load balancing mechanisms consider + agent capacity, current workload, and task affinity when making + scheduling decisions. The protocol also defines procedures for + dynamic rescheduling when agents become unavailable or when + execution time estimates prove inaccurate, ensuring workflow + completion despite individual agent failures. + +6. Checkpoint and Recovery Mechanisms + + The Agent Task DAG framework MUST provide robust checkpoint and + recovery mechanisms to ensure workflow resilience and enable + graceful handling of failures, interruptions, and human + intervention points. Checkpoints represent persistent snapshots of + the DAG execution state at specific points in the workflow, + capturing sufficient information to resume execution from that + point or rollback to a previous stable state. The framework + defines three types of checkpoints: automatic checkpoints created + at predefined intervals or task completion boundaries, explicit + checkpoints requested by agents or human operators, and recovery + checkpoints generated immediately before high-risk operations that + may require rollback. + + Checkpoint creation MUST capture the complete execution context as + defined in Section 4, including the current state of all task + nodes, intermediate results, agent assignments, and security + context derived from Agent Authorization Profiles [draft-aap- + oauth-profile]. Each checkpoint MUST include a unique identifier, + timestamp, DAG version, execution state hash, and references to + any external resources or agent context information as specified + in [draft-chang-agent-context-interaction]. The checkpoint data + structure SHOULD be serialized using JSON [RFC8259] with optional + compression for large state objects, and MUST be digitally signed + to ensure integrity and authenticity. Checkpoints MAY be stored in + distributed storage systems to ensure availability across multiple + DAG Coordinators. + + The rollback procedure enables the DAG execution to revert to a + previous checkpoint when failures occur or human intervention + requires undoing completed work. When a rollback is initiated, the + DAG Coordinator MUST notify all participating agents of the + rollback operation, invalidate any results produced after the + target checkpoint, and restore the execution context to the + checkpoint state. Agents MUST acknowledge the rollback operation + and may need to perform agent-specific cleanup operations such as + releasing resources or notifying external systems. The rollback + operation MUST preserve audit trails by maintaining records of + both the original execution and the rollback event, ensuring + compliance with security and regulatory requirements. + + Failure recovery strategies operate at multiple levels within the + DAG execution framework, from individual task failures to complete + coordinator failures. For task-level failures, the framework + supports automatic retry with exponential backoff, task + reassignment to alternative agents with compatible capabilities, + and conditional continuation where dependent tasks may proceed + with degraded inputs. When coordinator failures occur, recovery + mechanisms leverage distributed checkpoints and coordinator + election protocols to restore execution state on alternative + infrastructure. The framework MUST support human-in-the-loop + recovery scenarios where automated recovery is insufficient, + providing interfaces for human operators to inspect checkpoint + states, approve recovery actions, and inject corrective context + information. + + The checkpoint and recovery mechanisms MUST integrate with the + agent authorization framework to ensure that recovery operations + maintain appropriate security boundaries and access controls. + Recovery operations SHOULD verify that participating agents still + possess valid authorization profiles and may require re- + authentication if significant time has elapsed since checkpoint + creation. The framework MUST provide configurable retention + policies for checkpoints, balancing storage efficiency with + recovery requirements, and MUST support secure deletion of + checkpoint data containing sensitive information when retention + periods expire or workflows complete successfully. + +7. Integration with Existing Agent Protocols + + This section describes how the Agent Task DAG framework integrates + with existing agent authorization, discovery, and communication + protocols to provide a comprehensive multi-agent workflow + execution environment. The framework is designed to be protocol- + agnostic while providing specific bindings for commonly used agent + protocols, enabling organizations to adopt DAG-based workflows + within their existing agent infrastructure. + + The DAG framework builds upon the Agent Authorization Profile + (AAP) [draft-aap-oauth-profile] to establish secure task execution + contexts. When a DAG Coordinator initiates workflow execution, it + MUST obtain appropriate authorization tokens for each + participating agent using the structured claims defined in AAP. + The task context claim within the agent's JWT token includes the + DAG identifier, task node assignments, and operational constraints + specific to the workflow. This approach ensures that agents can + verify their authorization to execute specific tasks within the + broader workflow context while maintaining the delegation chains + and human oversight requirements established in their + authorization profiles. + + Agent discovery and capability matching for DAG execution + leverages existing agent discovery protocols while extending them + with DAG-specific metadata. Agents participating in DAG workflows + SHOULD advertise their capabilities using structured capability + descriptors that include supported task types, execution + constraints, and checkpoint compatibility. The DAG Coordinator + uses this information during the task binding process to assign + task nodes to appropriate agents. When multiple agents are capable + of executing a particular task type, the coordinator MAY use load + balancing, geographic distribution, or other selection criteria to + optimize workflow execution. + + Context distribution among agents executing DAG workflows follows + the mechanisms defined in [draft-chang-agent-context-interaction], + with specific extensions for DAG execution state management. The + execution context for a DAG workflow includes the complete graph + structure, current execution state, intermediate task results, and + checkpoint metadata. Agents MUST receive sufficient context to + execute their assigned tasks while minimizing the distribution of + sensitive information to unauthorized agents. The framework + supports both push-based context distribution, where the DAG + Coordinator sends relevant context to agents before task + execution, and pull-based approaches where agents request specific + context elements as needed. + + The framework provides protocol bindings for common agent + communication patterns including HTTP-based REST APIs [RFC9110], + message queuing systems, and real-time communication protocols. + Each binding specifies how DAG execution messages are encoded, how + task results are reported, and how checkpoint operations are + coordinated across the distributed agent environment. Protocol- + specific considerations such as connection management, retry + mechanisms, and error handling are addressed within each binding + specification. For HTTP-based bindings, the framework defines + standardized endpoints for task execution, status reporting, and + checkpoint operations that can be implemented by any agent + supporting the DAG execution protocol. + + Integration with existing agent task protocols [draft-cui-ai- + agent-task] is achieved through task node adapters that translate + between DAG task specifications and protocol-specific task + representations. These adapters handle differences in task + parameterization, result formatting, and execution semantics while + preserving the dependency relationships and execution guarantees + required by the DAG framework. The framework also supports + integration with audit and compliance systems through standardized + logging interfaces that capture task execution events, + authorization decisions, and checkpoint operations in formats + compatible with existing security and compliance tools. + +8. Security Considerations + + The Agent Task DAG framework introduces unique security challenges + that extend beyond traditional single-agent systems. Multi-agent + workflows create expanded attack surfaces through inter-agent + communication channels, shared execution contexts, and distributed + state management. Malicious actors may attempt to inject + unauthorized tasks into DAG structures, manipulate task + dependencies to create privilege escalation paths, or exploit + checkpoint mechanisms to gain persistent access to workflow state. + The distributed nature of DAG execution also amplifies risks + related to agent impersonation, context poisoning, and + unauthorized workflow modification during execution. + + Task authorization within DAG workflows MUST leverage the Agent + Authorization Profile [draft-aap-oauth-profile] to establish fine- + grained permissions for each task node. Each task node SHOULD + include authorization requirements that specify which agent + capabilities, delegation chains, and operational constraints are + required for execution. The DAG Coordinator MUST verify that + assigned agents possess valid JWT tokens with appropriate + structured claims before initiating task execution. When tasks + involve sensitive operations or access to protected resources, + implementations SHOULD require fresh token validation rather than + relying on cached authorization state. Multi-step workflows that + span extended time periods MUST implement token refresh mechanisms + to maintain security throughout DAG execution. + + Context isolation represents a critical security boundary in + multi-agent DAG systems. Execution contexts MUST be isolated + between different DAG instances to prevent information leakage and + unauthorized access to intermediate results. Implementations + SHOULD use cryptographic techniques to protect context data in + transit and at rest, particularly when context distribution + mechanisms [draft-chang-agent-context-interaction] are employed + across network boundaries. Task nodes that handle sensitive data + MUST implement appropriate data classification and handling + controls, ensuring that context information is only accessible to + authorized agents within the workflow. The framework SHOULD + support configurable context sharing policies that allow + administrators to define which context elements can be shared + between tasks and which must remain isolated. + + Audit trail requirements for DAG execution are more complex than + single-agent scenarios due to the distributed and potentially + parallel nature of task execution. Implementations MUST maintain + comprehensive logs that capture DAG initiation, task assignments, + agent authorizations, execution outcomes, and any human + intervention points. Audit records SHOULD include cryptographic + signatures or integrity mechanisms to prevent tampering and + support forensic analysis. The checkpoint and recovery mechanisms + introduce additional logging requirements, as rollback operations + and failure recovery attempts MUST be fully auditable. + Organizations operating in regulated environments MAY require + enhanced audit capabilities that provide real-time monitoring of + DAG execution state and automated alerts for security policy + violations. + + The integration of human oversight points within DAG workflows + creates additional security considerations around authentication, + authorization, and workflow integrity. Human operators MUST be + properly authenticated before approving task continuations or + modifying workflow parameters. The framework SHOULD support multi- + factor authentication and role-based access controls for human + intervention points. Implementations MUST ensure that human + approval requirements cannot be bypassed through agent + coordination or DAG manipulation. When human operators modify + workflow parameters or approve exceptional conditions, these + actions MUST be cryptographically signed and integrated into the + workflow's audit trail to maintain end-to-end accountability. + +9. IANA Considerations + + This document introduces several new protocol elements and + identifiers that require IANA registration to ensure global + uniqueness and interoperability across implementations. The Agent + Task DAG framework extends existing agent communication protocols + with new message types, node classifications, and execution state + identifiers that must be standardized for consistent + implementation. + + The specification requires the establishment of a new "Agent Task + DAG Parameters" registry to manage the various identifiers used + within the framework. This registry MUST include sub-registries + for DAG node types, edge relationship types, execution states, + checkpoint types, and recovery action identifiers. Each sub- + registry MUST follow the "Specification Required" registration + policy as defined in [RFC8126], with designated experts reviewing + submissions for technical correctness and consistency with the + overall framework architecture. The registry MUST also accommodate + extensions that integrate with existing agent authorization + profiles as defined in [draft-aap-oauth-profile]. + + A new "application/vnd.ietf.agent-task-dag+json" media type + registration is REQUIRED for DAG workflow documents. This media + type MUST reference this specification and follow the JSON format + requirements specified in [RFC8259]. The media type enables proper + content negotiation when agents exchange DAG definitions and + execution state information. Additionally, new URI schemes "agent- + dag:" and "agent-task:" are proposed for identifying DAG instances + and individual task nodes respectively, requiring registration in + the "Uniform Resource Identifier (URI) Schemes" registry + maintained by IANA. + + The framework introduces new JWT claim names for representing DAG + execution context and task bindings within agent authorization + tokens, extending the structured claims mechanism defined in + [draft-aap-oauth-profile]. These claim names MUST be registered in + the "JSON Web Token Claims" registry established by [RFC7519]. The + new claims include "dagid", "tasknode", "executioncontext", + "checkpointref", and "recovery_state", each with specific semantic + meanings within the DAG execution protocol. Registration of these + claims ensures consistent interpretation across different agent + implementations and authorization servers. + + Finally, new HTTP header fields "DAG-Execution-ID" and "DAG- + Checkpoint" are introduced for coordination between agents during + DAG execution. These headers MUST be registered in the "Hypertext + Transfer Protocol (HTTP) Field Name Registry" as defined in + [RFC9110]. The headers enable stateless coordination mechanisms + and support the checkpoint and recovery procedures specified in + this framework, while maintaining compatibility with existing + HTTP-based agent communication protocols. + +10. References + +10.1. Normative References + + [RFC 2119] + RFC 2119 + + [RFC 8174] + RFC 8174 + + [RFC 8259] + RFC 8259 + + [RFC 7519] + RFC 7519 + + [draft-aap-oauth-profile] + draft-aap-oauth-profile + + [draft-cui-ai-agent-task] + draft-cui-ai-agent-task + + [draft-guy-bary-stamp-protocol] + draft-guy-bary-stamp-protocol + +10.2. Informative References + + [RFC 6749] + RFC 6749 + + [RFC 9110] + RFC 9110 + + [draft-chang-agent-context-interaction] + draft-chang-agent-context-interaction + + [draft-liu-dmsc-acps-arc] + draft-liu-dmsc-acps-arc + + [draft-rosenberg-aiproto-framework] + draft-rosenberg-aiproto-framework + + [draft-song-oauth-ai-agent-collaborate-authz] + draft-song-oauth-ai-agent-collaborate-authz + + [draft-mao-rtgwg-apn-framework-for-ioa] + draft-mao-rtgwg-apn-framework-for-ioa + + [draft-nandakumar-ai-agent-moq-transport] + draft-nandakumar-ai-agent-moq-transport + + +Author's Address + + Generated by IETF Draft Analyzer + Family: agent-ecosystem + 2026-03-04 diff --git a/data/reports/generated-drafts/draft-ai-primitives-for-00.txt b/data/reports/generated-drafts/draft-ai-primitives-for-00.txt new file mode 100644 index 0000000..2edb7ce --- /dev/null +++ b/data/reports/generated-drafts/draft-ai-primitives-for-00.txt @@ -0,0 +1,757 @@ +Internet-Draft anima +Intended status: standards-track March 2026 +Expires: September 05, 2026 + + + Human-in-the-Loop (HITL) Primitives for AI Agent Systems + draft-agent-ecosystem-primitives-for-00 + +Abstract + + As AI agents become increasingly autonomous in network operations + and other critical domains, the need for standardized human + oversight mechanisms becomes paramount. This document defines a + framework of Human-in-the-Loop (HITL) primitives that enable + structured human intervention, approval, and oversight in AI agent + decision-making processes. The framework provides three core + primitives: approval workflows that require explicit human consent + before action execution, override mechanisms that allow humans to + modify or halt agent decisions, and explainability interfaces that + provide transparency into agent reasoning. These primitives are + designed to be protocol-agnostic and can be integrated with + existing agent architectures to ensure human control over + autonomous systems. The specification addresses the critical gap + between fully autonomous AI operation and human accountability + requirements, particularly in regulated environments where human + oversight is mandatory. By standardizing these HITL mechanisms, + organizations can deploy AI agents with appropriate human + safeguards while maintaining operational efficiency and regulatory + compliance. + +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. + +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. + + HITL Primitive + A standardized mechanism that enables human oversight and + intervention in AI agent decision-making processes + + Approval Workflow + A structured process that requires explicit human consent + before an agent action is executed + + Override Mechanism + A capability that allows humans to modify, halt, or redirect + agent decisions in real-time + + Explainability Interface + A standardized method for agents to provide transparency into + their reasoning and decision-making processes + + Human Oversight + The structured involvement of human operators in monitoring, + approving, or modifying AI agent actions + + Decision Point + A moment in agent execution where human intervention may be + required or beneficial + + Intervention Trigger + A condition or threshold that activates human-in-the-loop + mechanisms + + +Table of Contents + + 1. Introduction ................................................ 3 + 2. Terminology ................................................. 4 + 3. Problem Statement ........................................... 5 + 4. HITL Primitive Framework .................................... 6 + 5. Approval Workflow Primitives ................................ 7 + 6. Override and Intervention Primitives ........................ 8 + 7. Explainability and Transparency Primitives .................. 9 + 8. Integration with Agent Architectures ........................ 10 + 9. Security Considerations ..................................... 11 + 10. IANA Considerations ......................................... 12 + 11. References .................................................. 13 + +1. Introduction + + The rapid advancement and deployment of AI agents in critical + network operations and infrastructure management has created an + urgent need for standardized human oversight mechanisms. As + documented in [draft-cui-nmrg-llm-nm] and [draft-irtf-nmrg-llm- + nm], AI agents are increasingly being deployed for network + management tasks that were traditionally performed by human + operators. However, the current landscape of AI agent systems + lacks consistent and interoperable Human-in-the-Loop (HITL) + mechanisms, creating significant risks for organizations that + require human accountability and oversight in their autonomous + systems. + + Current AI agent deployments typically implement ad-hoc or + proprietary mechanisms for human oversight, if any oversight + mechanisms exist at all. This inconsistency creates several + critical problems: organizations cannot easily integrate HITL + capabilities across different agent systems, human operators lack + standardized interfaces for agent oversight, and regulatory + compliance becomes difficult to achieve and demonstrate. The + absence of standardized HITL primitives means that each agent + implementation must create its own oversight mechanisms, leading + to fragmented approaches that cannot interoperate and may have + significant security or reliability gaps. + + The risks of uncontrolled autonomous operation are particularly + acute in regulated environments such as financial services, + healthcare, and critical infrastructure, where human oversight is + often legally mandated. When AI agents operate without appropriate + human safeguards, organizations face potential regulatory + violations, liability issues, and operational failures that could + have been prevented through proper human oversight. Furthermore, + the lack of standardized explainability interfaces means that + human operators often cannot understand or validate agent + decisions, undermining the effectiveness of any oversight + mechanisms that do exist. + + This document addresses these challenges by defining a + comprehensive framework of HITL primitives that can be integrated + with existing agent architectures in a protocol-agnostic manner. + The framework builds upon established patterns from OAuth 2.0 + [RFC6749] and JSON Web Tokens [RFC7519] to provide standardized + mechanisms for approval workflows, override capabilities, and + explainability interfaces. These primitives are designed to ensure + that human oversight can be consistently implemented and enforced + across different AI agent systems while maintaining the + operational efficiency benefits of autonomous operation. + + The HITL primitive framework specified in this document enables + organizations to deploy AI agents with appropriate human + safeguards that meet regulatory requirements and organizational + policies. By standardizing these mechanisms, the framework + facilitates interoperability between different agent systems and + provides a foundation for secure, accountable autonomous + operations. The primitives are designed to be composable and + configurable, allowing organizations to implement the level of + human oversight appropriate for their specific use cases and risk + tolerance. + +2. Terminology + + This document uses terminology consistent with [RFC2119] and + [RFC8174] when describing requirement levels. 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. + + HITL Primitive refers to a standardized, composable mechanism that + enables structured human oversight and intervention in AI agent + decision-making processes. These primitives serve as the + fundamental building blocks for implementing human control over + autonomous systems and can be combined to create comprehensive + oversight frameworks tailored to specific operational + requirements. + + Approval Workflow defines a structured process that requires + explicit human consent before an agent action is executed. As + described in [draft-cui-nmrg-llm-nm] and [draft-irtf-nmrg-llm-nm], + these workflows enforce human control over automated actions by + creating mandatory checkpoints where agent decisions must receive + human validation. Approval workflows include mechanisms for + request formatting, response handling, timeout management, and + escalation procedures. + + Override Mechanism encompasses capabilities that allow humans to + modify, halt, or redirect agent decisions in real-time, both + during the decision-making process and after initial action has + begun. These mechanisms provide emergency intervention + capabilities and enable humans to maintain ultimate control over + agent behavior, even when agents are operating with significant + autonomy. + + Explainability Interface represents a standardized method for + agents to provide transparency into their reasoning and decision- + making processes. These interfaces enable informed human oversight + by presenting agent logic, data sources, confidence levels, and + decision rationale in human-comprehensible formats. The + explainability interface is essential for meaningful human + participation in approval workflows and override decisions. + + Human Oversight denotes the structured involvement of human + operators in monitoring, approving, or modifying AI agent actions. + This encompasses both proactive oversight through approval + workflows and reactive oversight through monitoring and + intervention capabilities. Human oversight requirements may be + specified through structured claims and validation patterns as + referenced in authorization frameworks [RFC6749] [RFC7519]. + + Decision Point identifies a specific moment in agent execution + where human intervention may be required, beneficial, or + optionally available. Decision points are defined based on action + criticality, risk assessment, regulatory requirements, or + organizational policy. Each decision point specifies the type of + human involvement required and the mechanisms through which such + involvement occurs. + + Intervention Trigger describes a condition, threshold, or event + that automatically activates human-in-the-loop mechanisms. + Triggers may be based on risk scores, confidence levels, + environmental changes, error conditions, or explicit policy rules. + When activated, intervention triggers initiate appropriate HITL + primitives to ensure human involvement in agent decision-making + processes. + +3. Problem Statement + + As AI agents become increasingly prevalent in critical network + infrastructure and operational environments, they are often + deployed with varying degrees of autonomy and inconsistent + mechanisms for human oversight. Current agent implementations + typically rely on ad-hoc or proprietary methods for human + intervention, ranging from simple logging systems to custom + approval interfaces that lack standardization across platforms and + vendors. This fragmentation creates significant challenges for + organizations attempting to maintain consistent oversight policies + across heterogeneous agent deployments, particularly in regulated + environments where human accountability is not merely preferred + but legally mandated. + + The absence of standardized Human-in-the-Loop (HITL) mechanisms + leads to several critical problems in autonomous agent deployment. + Without consistent approval workflows, agents may execute high- + impact actions without appropriate human review, potentially + causing unintended consequences in production systems. The lack of + standardized override mechanisms means that human operators cannot + reliably intervene when agents begin executing problematic + decisions, creating situations where autonomous systems continue + operating beyond safe parameters. Furthermore, the absence of + explainability interfaces prevents operators from understanding + agent reasoning, making it impossible to provide informed + oversight or learn from agent behavior patterns. These gaps are + particularly problematic in network management contexts, as + highlighted in [DRAFT-CUI-NMRG-LLM-NM] and [DRAFT-IRTF-NMRG-LLM- + NM], where LLM-generated network decisions require structured + human validation before execution. + + The consequences of uncontrolled autonomous operation extend + beyond immediate operational risks to encompass regulatory + compliance and accountability challenges. In many jurisdictions, + regulations require that critical decisions affecting network + infrastructure, user data, or service availability maintain clear + chains of human responsibility. Current agent systems often + operate as "black boxes" where the decision-making process is + opaque to human oversight, making it difficult or impossible to + demonstrate compliance with regulatory requirements. This opacity + also hinders incident response and post-mortem analysis, as + operators cannot determine why an agent made specific decisions or + identify patterns that might prevent future issues. + + The need for human accountability in AI agent systems is further + complicated by the temporal aspects of autonomous operation. + Unlike traditional software systems that execute predetermined + logic, AI agents make dynamic decisions based on environmental + conditions and learned behaviors that may not be fully predictable + at deployment time. This unpredictability necessitates real-time + human oversight capabilities that can adapt to emerging + situations. However, without standardized primitives for human + intervention, organizations resort to crude mechanisms such as + complete system shutdown or manual takeover, which eliminate the + benefits of autonomous operation while failing to provide granular + control over agent behavior. + + The lack of interoperability between different HITL + implementations creates additional operational burden and security + risks. Organizations deploying multiple agent systems must + maintain separate oversight interfaces and procedures for each + platform, increasing complexity and the likelihood of human error. + This fragmentation also prevents the development of unified + oversight dashboards and centralized approval workflows that could + improve operational efficiency while maintaining appropriate human + control. The security implications are equally concerning, as non- + standardized override mechanisms may lack proper authentication, + authorization, and audit capabilities, potentially enabling + unauthorized intervention in autonomous systems. + +4. HITL Primitive Framework + + This document defines a framework of Human-in-the-Loop (HITL) + primitives that provide standardized mechanisms for human + oversight of AI agent systems. The framework establishes three + core primitive categories that work together to ensure appropriate + human control over autonomous operations while maintaining + operational efficiency. These primitives are designed to be + protocol-agnostic and can be integrated with existing agent + architectures regardless of the underlying communication protocols + or decision-making systems. + + The HITL primitive framework operates on the principle that human + oversight requirements vary based on context, risk level, and + regulatory constraints. Each primitive category addresses a + specific aspect of human-agent interaction: approval workflows + ensure human consent for critical actions, override mechanisms + provide real-time intervention capabilities, and explainability + interfaces enable informed human decision-making. The framework + defines standardized interfaces and message formats that allow + these primitives to be composed into comprehensive oversight + systems tailored to specific operational requirements. + + At the architectural level, HITL primitives integrate with agent + systems through well-defined decision points where human + intervention may be required. These decision points are identified + during agent operation based on configurable triggers such as risk + thresholds, regulatory requirements, or operational policies. When + a decision point is reached, the appropriate HITL primitive is + activated, temporarily suspending autonomous operation until human + oversight is satisfied. This approach ensures that human oversight + requirements, as referenced in [draft-cui-nmrg-llm-nm] for network + management scenarios, can be consistently enforced across diverse + agent deployments. + + The framework establishes a common message structure for all HITL + primitives that includes essential metadata such as agent + identity, decision context, timestamp, and urgency level. This + standardized approach enables interoperability between different + agent systems and human oversight tools while providing the + flexibility to extend primitives for domain-specific requirements. + The message structure follows JSON formatting conventions per + [RFC8259] and incorporates security considerations including + authentication tokens and integrity protection mechanisms as + specified in [RFC7519] and [RFC8446]. + + Implementation of HITL primitives MUST ensure that human oversight + mechanisms cannot be bypassed or manipulated by agent systems. The + framework requires that primitive activation be deterministic and + based on verifiable conditions, preventing agents from selectively + avoiding human oversight. Additionally, all HITL interactions MUST + be logged with sufficient detail to support audit requirements and + accountability frameworks. This logging requirement supports the + human oversight validation patterns needed for authorization + systems and ensures compliance with regulatory oversight mandates. + +5. Approval Workflow Primitives + + Approval workflow primitives provide standardized mechanisms for + requiring explicit human consent before AI agents execute specific + actions. These primitives establish a structured framework where + agents identify decision points that require human oversight, + format approval requests with sufficient context for human + evaluation, and await explicit authorization before proceeding. + The approval workflow primitive ensures that critical or high-risk + agent actions cannot be executed without human validation, + maintaining human authority over autonomous systems while + preserving operational efficiency through selective intervention + points. + + The core approval request structure MUST include the proposed + action description, associated risk assessment, relevant context + for human evaluation, and expected execution timeline. Each + approval request MUST be uniquely identified and include + sufficient information for a human operator to make an informed + decision. The request format SHOULD follow structured data + conventions as defined in [RFC8259] to ensure consistent parsing + and presentation across different human interface systems. Agents + MUST provide clear rationale for why the action requires approval + and include any relevant alternative options that humans may + consider during the evaluation process. + + Human responses to approval requests MUST use standardized + response codes that clearly indicate approval, denial, or + modification instructions. Approved actions receive an explicit + authorization token that agents MUST validate before execution, + ensuring that only genuinely authorized actions proceed. Denied + requests MUST include human feedback when possible to enable agent + learning and improved future decision-making. The response format + SHOULD accommodate conditional approvals where humans specify + constraints or modifications to the proposed action while still + granting execution authority. + + Timeout handling mechanisms are critical components of approval + workflow primitives to prevent system deadlock when human + operators are unavailable. Agents MUST implement configurable + timeout periods appropriate to the urgency and criticality of the + requested action, with default behavior clearly specified for + timeout scenarios. When approval requests exceed timeout + thresholds, agents SHOULD implement fallback strategies such as + escalation to alternate human operators, execution of safe default + actions, or graceful degradation of service. The timeout + configuration SHOULD be contextually aware, allowing shorter + timeouts for routine operations and longer timeouts for complex + decisions requiring thorough human evaluation. + + Integration with authentication and authorization systems ensures + that approval responses originate from authorized human operators + with appropriate privileges for the requested action type. The + approval workflow primitive SHOULD leverage existing identity + frameworks such as those defined in [RFC6749] and [RFC7519] to + validate human operator credentials and maintain audit trails of + approval decisions. This integration enables fine-grained access + control where different categories of actions require approval + from operators with specific roles or clearance levels, supporting + organizational hierarchy and responsibility structures within + human-agent collaborative systems. + +6. Override and Intervention Primitives + + Override and intervention primitives provide real-time mechanisms + that allow human operators to modify, halt, or redirect agent + decisions during execution. These primitives are essential for + maintaining human control over autonomous systems, particularly in + situations where agent decisions may lead to undesirable outcomes + or where dynamic conditions require human judgment. The override + mechanisms MUST be designed to operate with minimal latency to + ensure timely human intervention when required. + + The core override primitive consists of three fundamental + operations: halt, modify, and redirect. The halt operation + immediately stops agent execution and places the system in a safe + state, while the modify operation allows humans to adjust specific + parameters or constraints of the current agent decision. The + redirect operation enables complete substitution of the agent's + proposed action with a human-specified alternative. Each override + operation MUST include authentication credentials as defined in + [RFC6749] and SHOULD provide a reason code indicating the basis + for intervention. Override requests MUST be processed + synchronously when possible, with acknowledgment timeouts not + exceeding implementation-defined thresholds. + + Emergency stop procedures represent a specialized category of + override primitives designed for critical situations requiring + immediate agent termination. These procedures MUST bypass normal + approval workflows and provide direct, low-latency mechanisms for + halting agent operations. Emergency stops SHOULD be implemented + through multiple redundant channels to ensure reliability, and + MUST trigger immediate notification to designated human + supervisors. The emergency stop primitive MUST include safeguards + to prevent accidental activation while ensuring accessibility + during genuine emergencies. + + Decision modification interfaces enable fine-grained human + adjustment of agent decisions without complete override. These + interfaces MUST provide structured formats for specifying + modifications to agent parameters, constraints, or objectives + using JSON [RFC8259] or equivalent structured data formats. + Modification requests SHOULD include validation mechanisms to + ensure proposed changes are within acceptable operational bounds. + The agent MUST acknowledge modification requests and indicate + whether the requested changes can be accommodated within current + operational constraints. + + Real-time intervention capabilities require agents to expose + decision points where human oversight can be effectively applied. + Decision points MUST be clearly identified in agent execution + flows, with appropriate pause mechanisms that allow human + evaluation without timeout penalties. Agents SHOULD provide + context information at each decision point, including current + state, proposed actions, and confidence levels. The intervention + interface MUST support both synchronous and asynchronous human + responses, with clear timeout behaviors defined for each + interaction mode. + + Integration with agent architectures requires override primitives + to maintain compatibility with existing agent communication + protocols while providing standardized intervention interfaces. + Override mechanisms SHOULD be implemented as middleware components + that can intercept agent communications without requiring + modification to core agent logic. The primitive framework MUST + support distributed scenarios where human operators may be remote + from agent execution environments, utilizing secure communication + channels as specified in [RFC8446] for all override operations. + +7. Explainability and Transparency Primitives + + This section defines standardized interfaces that enable AI agents + to provide transparency into their reasoning and decision-making + processes. Explainability primitives are essential for enabling + informed human oversight, as humans cannot effectively supervise + agent actions without understanding the underlying rationale. + These interfaces MUST provide structured information about agent + reasoning in formats that support human comprehension and + decision-making. + + The core explainability primitive is the Reasoning Trace, which + captures the agent's decision-making process in a structured + format. A Reasoning Trace MUST include the following elements: the + initial problem or goal statement, key inputs and data sources + consulted, reasoning steps taken, alternative options considered, + confidence levels for decisions, and any uncertainty or + limitations acknowledged by the agent. This trace SHOULD be + generated in JSON format [RFC8259] to ensure machine-readable + structure while remaining human-interpretable. The trace MUST be + available before any approval workflow is initiated, allowing + humans to make informed decisions about proposed agent actions. + + Agents MUST implement a Context Explanation interface that + provides on-demand details about specific aspects of their + reasoning. This interface allows human operators to query + particular decision points, request elaboration on confidence + levels, or explore alternative approaches that were considered but + rejected. The interface SHOULD support structured queries using + predefined categories such as "data-sources", "assumptions", + "risk-factors", and "alternatives". Responses MUST be provided in + a consistent format that enables both human review and automated + analysis for audit purposes. + + The Uncertainty Declaration primitive requires agents to + explicitly communicate their confidence levels and known + limitations regarding proposed actions. Agents MUST provide + quantitative confidence scores where applicable and qualitative + uncertainty statements for aspects that cannot be numerically + assessed. This primitive is particularly critical in regulated + environments where human operators need to understand the + reliability of agent recommendations before granting approval, as + specified in human oversight requirements frameworks [draft-cui- + nmrg-llm-nm]. + + To support audit and compliance requirements, explainability + interfaces MUST generate persistent explanation records that can + be stored and retrieved for later review. These records SHOULD + include timestamps, version information for the agent making + decisions, and cryptographic signatures to ensure integrity. The + explanation data MUST be structured to support automated analysis + and pattern detection, enabling organizations to identify trends + in agent decision-making and improve oversight processes over + time. + +8. Integration with Agent Architectures + + The integration of HITL primitives with existing agent + architectures requires careful consideration of both the agent's + internal decision-making processes and the external communication + protocols used for human interaction. Agent systems MUST implement + HITL primitives as composable components that can be inserted into + the agent's execution pipeline without requiring fundamental + architectural changes. This approach ensures that existing agent + deployments can adopt human oversight mechanisms incrementally, + maintaining backward compatibility while enhancing human control + capabilities. + + Agent architectures SHOULD implement HITL primitives through a + middleware layer that intercepts agent decisions at configurable + decision points. This middleware approach allows the same HITL + mechanisms to be applied across different agent types and + execution environments. The middleware MUST support protocol- + agnostic communication, enabling human oversight through various + channels including HTTP-based APIs [RFC9110], WebSocket + connections for real-time interaction, or message-oriented + protocols. The choice of communication protocol SHOULD be + configurable to accommodate different operational environments and + human interface requirements. + + Integration with authorization frameworks presents a critical + opportunity to enforce human oversight requirements at the system + level. Agent architectures SHOULD leverage OAuth 2.0 [RFC6749] + scopes and claims to specify when human approval is required for + specific actions, building upon human oversight requirement + patterns that embed HITL constraints directly into authorization + tokens [draft-aap-oauth-profile]. This integration ensures that + human oversight requirements are enforced consistently across + distributed agent systems and cannot be bypassed by individual + agent implementations. + + For network management applications, HITL primitives MUST + integrate with existing network management protocols and + frameworks while preserving the human-in-the-loop workflows + defined for LLM-generated network management decisions [draft-cui- + nmrg-llm-nm]. Agent architectures in network domains SHOULD + implement decision checkpoints that align with critical network + operations, ensuring that configuration changes, policy updates, + and topology modifications trigger appropriate human oversight + mechanisms. The integration MUST preserve existing network + management interfaces while adding human oversight capabilities as + an additional validation layer. + + The implementation of HITL primitives SHOULD support both + synchronous and asynchronous interaction patterns to accommodate + different operational requirements and human availability + constraints. Synchronous patterns are appropriate for real-time + decision approval, while asynchronous patterns enable human + oversight in environments where immediate human response is not + feasible. Agent architectures MUST implement timeout mechanisms + and fallback behaviors for both interaction patterns, ensuring + system stability when human oversight is delayed or unavailable. + + Configuration and policy management for HITL primitives SHOULD be + externalized from agent implementations to enable dynamic + adjustment of human oversight requirements without agent + redeployment. This externalization allows organizations to adjust + human oversight policies based on operational conditions, + regulatory requirements, or agent performance metrics. The + configuration mechanism MUST support fine-grained control over + which agent decisions require human oversight, the type of + oversight required, and the specific human operators authorized to + provide oversight for different decision categories. + +9. Security Considerations + + The security of HITL primitives is paramount, as these mechanisms + represent critical control points where human authority intersects + with autonomous agent operation. Authentication and authorization + of human operators MUST be implemented using strong cryptographic + methods, with multi-factor authentication RECOMMENDED for high- + impact decision points. Human operator credentials SHOULD be + managed through established identity frameworks such as OAuth 2.0 + [RFC6749] or equivalent, with token-based authentication providing + both security and auditability. Organizations MUST implement role- + based access controls that ensure only authorized personnel can + approve specific types of agent actions, with the principle of + least privilege applied to limit human operator permissions to + necessary functions only. + + Protection against manipulation and spoofing attacks requires + robust integrity mechanisms throughout the HITL workflow. All + approval requests, human responses, and override commands MUST be + cryptographically signed to prevent tampering and ensure non- + repudiation. The system MUST validate that approval workflows + cannot be bypassed through direct agent-to-agent communication or + through exploitation of timing vulnerabilities. Particular + attention MUST be paid to preventing replay attacks where + previously valid human approvals could be reused inappropriately. + Human operators MUST be provided with sufficient context and + verification mechanisms to detect potentially malicious approval + requests that might be designed to trick humans into approving + harmful actions. + + Secure communication channels are essential for protecting HITL + interactions from eavesdropping and man-in-the-middle attacks. All + communication between agents, HITL interfaces, and human operators + MUST use transport-layer security equivalent to TLS 1.3 [RFC8446] + or stronger. The system MUST implement proper certificate + validation and SHOULD use mutual TLS authentication where + feasible. Session management for human operators MUST include + appropriate timeout mechanisms to prevent unauthorized use of + abandoned sessions, with sensitive approval workflows requiring + fresh authentication for extended operations. + + The explainability interfaces present unique security challenges, + as they must balance transparency with protection of sensitive + algorithmic details and operational information. Explanations + provided to human operators MUST be sanitized to prevent + information disclosure that could be exploited by attackers to + reverse-engineer agent decision patterns or identify system + vulnerabilities. The system MUST implement access controls that + ensure explainability information is only provided to operators + with appropriate clearance levels for the specific operational + context. Additionally, all HITL interactions MUST be logged with + tamper-evident audit trails that include cryptographic checksums + and timestamps to ensure accountability and enable post-incident + analysis while protecting sensitive operational details from + unauthorized disclosure. + +10. IANA Considerations + + This document introduces several new protocol elements and + identifiers that require standardized registration to ensure + interoperability across implementations. IANA is requested to + establish and maintain registries for HITL primitive types, + approval workflow identifiers, and standardized response codes as + specified in this section. These registries will enable consistent + implementation of human-in-the-loop mechanisms across different + agent systems and organizational boundaries. + + IANA SHALL establish a new registry titled "Human-in-the-Loop + (HITL) Primitive Types" to maintain standardized identifiers for + the core HITL mechanisms defined in this specification. The + registry MUST include entries for "approval-workflow", "override- + mechanism", and "explainability-interface" as the initial + primitive types, with additional types to be registered through + the Specification Required policy as defined in [RFC8126]. Each + registry entry MUST include the primitive type identifier, a brief + description of its function, and a reference to the defining + specification. Registration requests MUST specify how the proposed + primitive type differs from existing entries and demonstrate clear + utility for human oversight scenarios. + + A second registry titled "HITL Approval Workflow Identifiers" + SHALL be established to maintain standardized workflow patterns + for approval primitives. This registry MUST include initial + entries for common workflow types such as "single-approver", + "multi-stage-approval", "consensus-required", and "emergency- + bypass", with new workflow identifiers registered under the + Specification Required policy. Each workflow identifier entry MUST + specify the approval pattern, required participant roles, decision + criteria, and timeout handling mechanisms. This registry enables + organizations to reference standardized approval patterns while + maintaining consistency across different agent deployments. + + IANA SHALL create a "HITL Response Codes" registry to standardize + the status and error codes used in human-in-the-loop + communications as defined in Section 5 and Section 6 of this + specification. The registry MUST include standard response codes + for approval granted (200), approval denied (403), timeout + exceeded (408), override initiated (300), and explanation + requested (250), following the pattern established by HTTP status + codes in [RFC9110]. Additional response codes MAY be registered + using the Expert Review policy, with registration requests + requiring demonstration of unique semantic meaning not covered by + existing codes. The registry MUST specify the numeric code, + textual description, applicable primitive types, and any special + handling requirements for each response code to ensure consistent + interpretation across implementations. + +11. References + +11.1. Normative References + + [RFC 2119] + RFC 2119 + + [RFC 8174] + RFC 8174 + + [RFC 8446] + RFC 8446 + + [RFC 9110] + RFC 9110 + + [RFC 8259] + RFC 8259 + + [draft-rosenberg-cheq] + draft-rosenberg-cheq + +11.2. Informative References + + [RFC 6749] + RFC 6749 + + [RFC 7519] + RFC 7519 + + [draft-cui-nmrg-llm-nm] + draft-cui-nmrg-llm-nm + + [draft-irtf-nmrg-llm-nm] + draft-irtf-nmrg-llm-nm + + [draft-rosenberg-aiproto-cheq] + draft-rosenberg-aiproto-cheq + + [draft-aap-oauth-profile] + draft-aap-oauth-profile + + [draft-cowles-volt] + draft-cowles-volt + + [draft-aylward-daap-v2] + draft-aylward-daap-v2 + + +Author's Address + + Generated by IETF Draft Analyzer + Family: agent-ecosystem + 2026-03-04 diff --git a/data/reports/generated-drafts/family-summary.md b/data/reports/generated-drafts/family-summary.md new file mode 100644 index 0000000..ef695c2 --- /dev/null +++ b/data/reports/generated-drafts/family-summary.md @@ -0,0 +1,26 @@ +# Draft Family: agent-ecosystem + +## AEM: Privacy-Preserving Agent Learning Protocol for Federated Multi-Tenant Environments +- Draft: `draft-ai-agent-learning-protocol-00` +- Gap: Agent Ecosystem Model +- Sections: 10 + +## ATD: Agent Task DAG: A Framework for Directed Acyclic Graph Execution in Multi-Agent Systems +- Draft: `draft-ai-agent-task-a-00` +- Gap: Agent Task DAG +- Sections: 9 + +## HITL: Human-in-the-Loop (HITL) Primitives for AI Agent Systems +- Draft: `draft-ai-primitives-for-00` +- Gap: Human-in-the-Loop +- Sections: 10 + +## AEPB: Real-Time Agent Rollback Protocol (RARP) for Autonomous Network Operations +- Draft: `draft-ai-agent-rollback-protocol-00` +- Gap: Agent Ecosystem Protocol Bindings +- Sections: 9 + +## APAE: Agent Provenance Assurance Ecosystem (APAE) Framework +- Draft: `draft-ai-agent-provenance-assurance-ecosystem-00` +- Gap: Agent Provenance Assurance Ecosystem +- Sections: 11 diff --git a/src/ietf_analyzer/pipeline/formatter.py b/src/ietf_analyzer/pipeline/formatter.py index c0d86af..918df01 100644 --- a/src/ietf_analyzer/pipeline/formatter.py +++ b/src/ietf_analyzer/pipeline/formatter.py @@ -2,10 +2,31 @@ from __future__ import annotations +import re import textwrap from datetime import datetime, timezone, timedelta +def _strip_markdown(text: str) -> str: + """Remove markdown formatting that Claude may leak into output.""" + # Bold/italic + text = re.sub(r'\*\*\*(.+?)\*\*\*', r'\1', text) + text = re.sub(r'\*\*(.+?)\*\*', r'\1', text) + text = re.sub(r'\*(.+?)\*', r'\1', text) + text = re.sub(r'___(.+?)___', r'\1', text) + text = re.sub(r'__(.+?)__', r'\1', text) + text = re.sub(r'_(.+?)_', r'\1', text) + # Markdown headers → plain text + text = re.sub(r'^#{1,6}\s+', '', text, flags=re.MULTILINE) + # Code fences + text = re.sub(r'```\w*\n?', '', text) + # Inline code + text = re.sub(r'`([^`]+)`', r'\1', text) + # Markdown links [text](url) → text + text = re.sub(r'\[([^\]]+)\]\([^)]+\)', r'\1', text) + return text + + class DraftFormatter: @staticmethod def format_draft(outline: dict, sections: list[str], family_name: str = "") -> str: @@ -18,7 +39,7 @@ class DraftFormatter: parts.append("") parts.append("Abstract") parts.append("") - parts.append(DraftFormatter._wrap_text(outline.get("abstract", ""))) + parts.append(DraftFormatter._wrap_text(_strip_markdown(outline.get("abstract", "")))) parts.append("") parts.append(DraftFormatter._status_memo(outline)) parts.append("") @@ -48,7 +69,7 @@ class DraftFormatter: stitle = section_info.get("title", f"Section {i}") parts.append(f"{i}. {stitle}") parts.append("") - parts.append(DraftFormatter._wrap_text(section_text)) + parts.append(DraftFormatter._wrap_text(_strip_markdown(section_text))) parts.append("") # References section @@ -87,8 +108,13 @@ class DraftFormatter: title = outline["title"] lines = [] - lines.append(f"Internet-Draft{' ' * 45}{wg}") - lines.append(f"Intended status: {status:<44s}{date_str}") + # Right-align WG/date to col 72 + id_label = "Internet-Draft" + pad = max(1, 72 - len(id_label) - len(wg)) + lines.append(f"{id_label}{' ' * pad}{wg}") + is_label = f"Intended status: {status}" + pad2 = max(1, 72 - len(is_label) - len(date_str)) + lines.append(f"{is_label}{' ' * pad2}{date_str}") lines.append(f"Expires: {exp_str}") lines.append("") lines.append("")