feat: add draft data, gap analysis report, and workspace config

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

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