ietf-draft-analyzer/workspace/drafts/new-drafts/draft-a-aem-agent-ecosystem-model-01.md

fullname: TBD
organization: Independent
email: placeholder@example.com

normative: RFC2119: RFC8174: I-D.nennemann-wimse-ect: title: "Execution Context Tokens for Distributed Agentic Workflows" target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/ I-D.nennemann-agent-dag-hitl-safety: title: "Agent Context Policy Token: DAG Delegation with Human Override" target: https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/

informative: RFC9334: RFC7519: RFC8615:

--- abstract

This document defines the Agent Ecosystem Model (AEM), a shared architecture and terminology for building interoperable agent systems that incorporate DAG-based execution, human-in-the-loop safety, and graduated assurance levels. AEM is not a protocol. It is a reference model that establishes common vocabulary and architectural concepts so that companion specifications (ATD, HITL, AEPB, APAE) and implementors share a consistent frame of reference. The model builds on Execution Context Tokens (ECT) for execution evidence and ACP-DAG-HITL for delegation policy.

--- middle

Introduction

The IETF AI/agent landscape includes over 260 drafts proposing protocols for agent communication, identity, safety, and operations. These drafts share many implicit concepts — tasks, delegation, workflows, safety checks — but use inconsistent terminology and incompatible models.

AEM provides a single reference architecture so that:

• Companion drafts (ATD, HITL, AEPB, APAE) share vocabulary.
• Implementors understand how the pieces compose.
• New proposals can position themselves within an existing model rather than inventing another one.

AEM is deliberately not a protocol. It defines no wire formats, no endpoints, and no new token types. It is the map; the companion drafts are the territory.

Design Principles

1. ECT is the execution backbone. All significant agent actions produce Execution Context Tokens {{I-D.nennemann-wimse-ect}}. The ecosystem does not define a second DAG or audit format.

2. ACP-DAG-HITL is the policy backbone. {{I-D.nennemann-agent-dag-hitl-safety}} defines delegation DAGs and HITL rules. The ecosystem extends these with operational semantics, not replacement structures.

3. Same model, different assurance. The architecture works identically from a relaxed K8s dev cluster (ECT L1) to a regulated healthcare environment (ECT L3 with audit ledger).

4. Protocol-agnostic. The ecosystem sits above any A2A protocol. Agents may speak different protocols and still participate through translation.

Conventions and Definitions

{::boilerplate bcp14-tagged}

Terminology

Agent:

An autonomous software entity that performs tasks, makes decisions, and communicates with other agents or humans.

Task:

A discrete unit of work performed by an agent, recorded as a single ECT node.

Workflow:

A set of tasks linked by dependencies, forming a DAG. Identified by the ECT wid claim {{I-D.nennemann-wimse-ect}}.

DAG (Directed Acyclic Graph):

The execution graph formed by ECT parent references (par claims). Also used in ACP-DAG-HITL for delegation structure.

Checkpoint:

An ECT node recording agent state before a consequential action, enabling rollback. Fully specified in ATD.

HITL Point:

A position in the workflow where human intervention is required or available, governed by ACP-DAG-HITL rules.

Override:

A human-initiated command that alters an agent's autonomous operation, taking precedence over the agent's own decisions. Fully specified in HITL.

Trust Score:

A floating-point value in [0.0, 1.0] representing one agent's assessed reliability of another. Updated using an AIMD model; fully specified in APAE.

Protocol Binding:

The mapping between ecosystem semantics and a specific A2A communication protocol. Fully specified in AEPB.

Assurance Level:

The degree of cryptographic and audit protection applied to ECTs, defined in {{I-D.nennemann-wimse-ect}}:

Level	ECT Format	Non-repudiation	Tamper detection	Audit ledger
L1	Unsigned JSON	No	Transport only	No
L2	Signed JWT	Yes	Signature	No
L3	Signed JWT	Yes	Signature	Yes (ledger-committed)
{: #fig-levels title="ECT Assurance Levels"}

Assurance Profile:

A named configuration (Relaxed, Standard, Regulated) selecting which mechanisms are required at a given deployment. Fully specified in APAE.

Blast Radius:

The set of agents and systems affected by a single failure.

Translation Gateway:

A service converting messages between two agent protocols, recording each hop as an ECT DAG node. Fully specified in AEPB.

Architectural Model

The ecosystem is organized in four layers:

┌─────────────────────────────────────────────────────┐
│                  Policy Layer                        │
│  ACP-DAG-HITL: delegation DAG, HITL rules,          │
│  node constraints, trust thresholds                  │
├─────────────────────────────────────────────────────┤
│               Semantics Layer                        │
│  ATD: execution order, checkpoints, rollback,        │
│       circuit breakers, resource hints                │
│  HITL: override levels, approval gates, escalation   │
│  AEPB: capability ads, negotiation, translation      │
│  APAE: trust scoring, behavior verification,         │
│        provenance, assurance profiles                 │
├─────────────────────────────────────────────────────┤
│               Evidence Layer                         │
│  ECT: signed DAG of execution records (L1/L2/L3)    │
│  inp_hash/out_hash, ext claims, audit ledger         │
├─────────────────────────────────────────────────────┤
│               Identity Layer                         │
│  WIMSE / X.509 / OAuth / JWK: agent identity         │
└─────────────────────────────────────────────────────┘

{: #fig-stack title="Ecosystem Layer Stack"}

Identity Layer:

Answers "who is this agent?" AEM does not define identity mechanisms; it assumes WIMSE, X.509, OAuth, or equivalent.

Evidence Layer:

Answers "what did this agent do?" ECT provides per-task signed records linked into a DAG, with three assurance levels.

Semantics Layer:

Answers "what does it mean and what to do about it?" The four companion drafts define operational semantics on top of ECT:

• ATD (Agent Task DAG): execution order, checkpoints, rollback, circuit breakers, resource hints.
• HITL (Human-in-the-Loop): override levels, approval gates, escalation paths, explainability.
• AEPB (Agent Ecosystem Protocol Binding): capability advertisement, protocol negotiation, translation gateways, agent lifecycle.
• APAE (Assurance Profiles): dynamic trust scoring, behavior verification, data provenance, assurance profiles.

Policy Layer:

Answers "what's allowed?" ACP-DAG-HITL defines delegation constraints and HITL trigger rules. Companion drafts extend constraints with protocol-specific fields (trust thresholds, checkpoint policies, protocol restrictions).

How ECT Extensions Work

Each companion draft defines ext claim namespaces on ECT:

Draft	ext prefix	Example claims
ATD	atd.*	atd.reversible, atd.severity, atd.circuit_state
HITL	hitl.*	hitl.level, hitl.operator_id, hitl.prior_state
AEPB	aepb.*	aepb.source_protocol, aepb.dest_protocol
APAE	apae.*	apae.trust_score, apae.confidence, apae.hops
{: #fig-ext title="ECT Extension Namespaces"}

No draft MAY use another draft's ext namespace without a normative reference to that draft.

How Policy Extensions Work

Each companion draft defines constraints fields on ACP-DAG-HITL DAG nodes:

Draft	Constraint fields
ATD	atd.checkpoint_policy, atd.circuit_threshold
HITL	(uses ACP-DAG-HITL HITL rule fields directly)
AEPB	aepb.allowed_protocols, aepb.max_translation_hops
APAE	apae.min_trust, apae.min_confidence, apae.assurance_profile
{: #fig-constraints title="ACP-DAG-HITL Node Constraint Extensions"}

Assurance as an Orthogonal Axis

The entire semantics layer operates identically at all ECT assurance levels. The DAG structure, HITL processing, trust scoring, and protocol translation are the same whether the ECT is unsigned JSON (L1) or a ledger-committed signed JWT (L3).

What changes across levels is the security envelope (see {{fig-levels}}). A deployment MAY use different levels for different workflows. Internal dev pipelines might use L1; cross-org integrations L2; regulated clinical workflows L3.

Implementations MUST ensure consistency across layers: an L3 evidence configuration provides no additional assurance if the policy layer accepts unsigned tokens.

Protocol Agnosticism

The ecosystem layer sits above any A2A communication protocol. Agents communicate via their native protocol (A2A, MCP, SLIM, uACP, etc.) while the Execution-Context HTTP header {{I-D.nennemann-wimse-ect}} carries ECTs alongside protocol messages.

When two agents speak different protocols, a translation gateway (defined by AEPB) converts between protocols while preserving ECT DAG continuity. The translation hop is itself an ECT node, so the cross-protocol path is one auditable DAG.

Relationship to Existing Standards

The ecosystem builds on existing IETF and industry standards. It does not replace any of them.

Standard	Scope	Relationship to AEM
WIMSE (draft-ietf-wimse-arch)	Workload identity and security context propagation	Identity Layer; AEM assumes WIMSE for agent credentials and context propagation.
ECT (I-D.nennemann-wimse-ect)	JWT-based execution evidence; DAG linkage via par	Evidence Layer; every significant action in the ecosystem produces an ECT.
ACP-DAG-HITL (I-D.nennemann-agent-dag-hitl-safety)	Delegation DAG policy; HITL trigger rules	Policy Layer; ATD/HITL/AEPB/APAE extend constraints fields, not replace the policy language.
OAuth 2.0 / RAR (RFC9396)	Authorization for API access	Identity Layer; operators and agents authenticate to HITL endpoints and capability documents via OAuth.
RATS (RFC9334)	Remote attestation for verifying evidence freshness	Informative to APAE Regulated profile; behavior verification attestations are RATS-compatible.
SPIFFE/SPIRE	Workload identity URI scheme (spiffe://)	Identity Layer; agent identities in ECT sub and ACP-DAG-HITL node agent fields use SPIFFE URIs by convention.
{: #fig-standards title="Relationship to Existing Standards"}

Working Group Targets

Companion Draft	Suggested WG	Rationale
AEM (this document)	NMOP	Informational reference model for network operations automation.
ATD	NMOP	Execution semantics and error recovery for network agent workflows.
HITL	NMOP or OPS	Human override for autonomous network management.
AEPB	DISPATCH or ART	Protocol binding and interoperability layer; dispatch to appropriate WG.
APAE	RATS or Security Dispatch	Attestation-based trust and assurance profiles for agents.
{: #fig-wgs title="Suggested Working Group Targets"}

Companion Draft Summary

Draft	Abbrev	Concern	Gaps Addressed	Normative/Informative
Agent Task DAG	ATD	Execution, checkpoints, rollback, circuit breakers	#1 Resource Mgmt, #3 Error Recovery	Normative
Human-in-the-Loop	HITL	Override, approval, escalation, explainability	#7 Human Override, #11 Explainability	Normative
Protocol Binding	AEPB	Interop, translation, lifecycle	#4 Cross-Protocol, #5 Lifecycle	Normative
Assurance Profiles	APAE	Trust, verification, provenance, dual-regime	#2 Behavior Verification, #8 Cross-Domain, #9 Dynamic Trust, #12 Provenance	Informative/Normative
{: #fig-companions title="Companion Draft Family"}

Together with ECT (evidence) and ACP-DAG-HITL (policy), these six documents cover all 3 critical and 6 high-severity gaps identified in the IETF AI/agent draft landscape analysis.

Implementation Guidance

Choosing an Assurance Level

Operators select the assurance level based on deployment context:

Relaxed (L1):

Appropriate for internal development, testing, and observability pipelines. No cryptographic overhead. Operators SHOULD NOT use L1 where ECT records could be relied upon as evidence in disputes.

Standard (L2):

Appropriate for production cross-organization deployments. Signed ECTs provide non-repudiation. RECOMMENDED as the default for any deployment where agents cross trust domains.

Regulated (L3):

Required for deployments subject to regulatory audit requirements (healthcare, finance, critical infrastructure). ECTs are committed to an append-only audit ledger. Operators MUST use L3 when a regulatory framework mandates tamper-evident audit trails.

Minimum Viable Implementation

An implementation is AEM-compliant if it satisfies:

1. Evidence: Emits ECTs for all consequential actions. MAY use L1 initially.

2. Policy: Evaluates ACP-DAG-HITL node constraints before delegating tasks.

3. Checkpoints: Implements ATD §4 (checkpoints before consequential actions). MUST declare atd.reversible.

4. HITL endpoint: Implements HITL /.well-known/hitl/override and responds within 1 second.

5. Capability document: Serves AEPB /.well-known/aepb so peers can discover protocol support.

The following are OPTIONAL at L1 but REQUIRED at L2+:

• Cryptographic signing of ECTs.
• APAE trust scoring.
• Behavior verification.

The following are REQUIRED only at L3 (Regulated profile):

• Audit ledger commitment.
• Continuous behavior verification.
• Provenance claims on data-transforming ECT nodes.

Upgrade Path

Upgrading from L1 to L2:

Add a signing key (WIMSE WIT or X.509). Update ECT emission to sign tokens. Update all agents to verify signatures. No protocol changes needed; ECT format is compatible.

Upgrading from L2 to L3:

Configure an audit ledger endpoint. Update ECT emission to commit each ECT. Enable APAE continuous behavior verification. Enable provenance claims.

Operators MUST NOT downgrade assurance level during an active workflow.

Security Considerations

Threat Model

The AEM threat model covers the following adversary classes:

Compromised Agent: An agent that emits false ECTs, fabricates errors, or attempts unauthorized rollbacks. Mitigated by ECT signature verification (L2+) and ACP-DAG-HITL policy validation.

Rogue Operator: A human who issues unauthorized overrides. Mitigated by HITL authentication requirements (signed JWTs, mutual TLS) and multi-operator approval for Level 4 TAKEOVER.

Translation Gateway Attack: A malicious or compromised gateway that alters message content in transit. Mitigated by ECT inp_hash/out_hash integrity checks; receivers MUST detect hash mismatches.

Trust Score Manipulation: An agent accumulates high trust through benign behavior, then executes a malicious action. Mitigated by APAE double-penalty for policy_violation events and anomaly detection.

Downgrade Attack: An attacker forces use of L1 ECTs where L2+ is required. Mitigated by explicit assurance level checks in ACP-DAG-HITL constraints (apae.assurance_profile field).

Layer Consistency Requirement

Implementations MUST configure the semantics, evidence, and policy layers consistently. Specifically:

• An L3 evidence deployment MUST NOT accept L1 ECTs as proof of action in audit or policy decisions.
• A Regulated assurance profile MUST be paired with L3 ECTs.
• HITL Level 2+ (approval required) MUST be authenticated.

Translation Gateway Supply Chain

Translation gateways are privileged intermediaries: they have access to plaintext message content and can inject ECT nodes. Operators MUST:

• Authenticate gateways using the same identity mechanisms as agents (WIMSE/SPIFFE).
• Audit gateway ECT nodes at L2+ for tamper detection.
• Limit aepb.max_translation_hops to prevent unbounded delegation chains through untrusted gateways.

IANA Considerations

AEM Ecosystem Extension Registry

This document requests the creation of the "AEM Ecosystem Extension Registry" under IANA. This registry collects:

1. ECT Extension Namespaces: Companion draft ext claim prefixes (see {{fig-ext}}).
2. ACP-DAG-HITL Constraint Field Namespaces: Companion draft constraints field prefixes (see {{fig-constraints}}).
3. ECT exec_act Values: All exec_act strings registered by companion drafts (see each companion's IANA section).

Registration policy: Specification Required.

Initial entries: as defined in {{fig-ext}}, {{fig-constraints}}, and the companion draft exec_act registrations.

--- back

Acknowledgments

{:numbered="false"}

This architecture builds on the Execution Context Token specification {{I-D.nennemann-wimse-ect}} and the Agent Context Policy Token {{I-D.nennemann-agent-dag-hitl-safety}}. The working group targets in {{fig-wgs}} reflect the current IETF AI/agent draft landscape analysis.