---
title: "Cross-Domain Execution Audit Tokens"
abbrev: "Execution Audit Tokens"
category: std
docname: draft-nennemann-exec-audit-00
submissiontype: IETF
number:
date:
v: 3
area: "SEC"
workgroup: "Individual"
keyword:
  - execution context
  - audit trail
  - agentic workflows
  - cross-domain
  - regulatory compliance
  - assurance levels

author:
  -
    fullname: Christian Nennemann
    organization: Independent Researcher
    email: ietf@nennemann.de

normative:
  RFC7515:
  RFC7517:
  RFC7518:
  RFC7519:
  RFC9449:
  RFC9562:
  RFC9110:

informative:
  RFC6838:
  RFC8693:
  RFC8725:
  RFC9334:
  I-D.ietf-scitt-architecture:
  I-D.ietf-oauth-transaction-tokens:
  I-D.ietf-wimse-arch:
  I-D.ietf-wimse-s2s-protocol:
  OPENTELEMETRY:
    title: "OpenTelemetry Specification"
    target: https://opentelemetry.io/docs/specs/otel/
    date: false
    author:
      - org: Cloud Native Computing Foundation
  SPIFFE:
    title: "SPIFFE ID"
    target: https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/
    date: false
  SD-JWT:
    title: "Selective Disclosure for JWTs (SD-JWT)"
    target: https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/
    seriesinfo:
      Internet-Draft: draft-ietf-oauth-selective-disclosure-jwt
    date: 2024
  CERTIFICATE-TRANSPARENCY:
    title: "Certificate Transparency"
    target: https://datatracker.ietf.org/doc/html/rfc9162
    seriesinfo:
      RFC: 9162
    date: 2021
  EU-AI-ACT:
    title: "Regulation (EU) 2024/1689 (AI Act)"
    target: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
    date: 2024
    author:
      - org: European Parliament and Council
  EU-DORA:
    title: "Regulation (EU) 2022/2554 (DORA)"
    target: https://eur-lex.europa.eu/eli/reg/2022/2554/oj
    date: 2022
    author:
      - org: European Parliament and Council

--- abstract

This document defines Execution Audit Tokens (EATs), a JWT-based
mechanism for recording task execution across distributed agent
workflows that span multiple administrative domains, identity
frameworks, and regulatory jurisdictions.  Each EAT captures a
single task, linked to predecessor tasks through a directed acyclic
graph (DAG).

EATs are identity-framework agnostic and operate with any asymmetric
key infrastructure including X.509 certificates, OAuth-based
credentials, SPIFFE/WIMSE identities, DID-based systems, or plain
JWK sets.

EATs support three assurance levels — Level 1 (unsigned JSON),
Level 2 (JOSE asymmetric signing), and Level 3 (JOSE signing with
audit ledger) — allowing deployments to choose the appropriate
trade-off between simplicity and regulatory compliance.

For cross-domain workflows, EATs introduce regulatory profile
metadata, federated audit ledger anchoring, selective disclosure
at domain boundaries, and machine-readable audit evidence profiles
to satisfy divergent compliance requirements across jurisdictions
simultaneously.

--- middle

# Introduction

Distributed agent workflows increasingly span multiple
administrative domains, identity ecosystems, and regulatory
jurisdictions.  An investment bank's agent in Frankfurt may
coordinate with a credit rating agency's agent in New York; a
healthcare agent processing patient data under HIPAA may hand off
results to a research agent operating under GDPR.  In each case,
the agents must maintain auditable execution records that satisfy
the compliance requirements of every jurisdiction through which the
workflow passes.

Existing identity frameworks authenticate agents and propagate
authorization context, but they do not record what those agents
actually did.  Distributed tracing systems (e.g., OpenTelemetry)
provide observability but lack cryptographic integrity, are
controlled by the platform operator, and do not satisfy regulatory
audit requirements.  Authorization tokens (e.g., OAuth Transaction
Tokens) propagate delegation chains but cannot represent the
branching and convergence patterns of real workflows.

This document defines Execution Audit Tokens (EATs), a JWT-based
mechanism that fills the gap between agent identity and execution
accountability.  Each EAT captures a single task, linked to
predecessor tasks through a directed acyclic graph (DAG).  EATs
are designed to operate with any identity framework that provides
asymmetric key pairs with verifiable binding to agent identity.

The key design goals are:

- Identity-framework independence: EATs work with X.509, OAuth,
  SPIFFE/WIMSE, DID, or plain JWK sets
- Cross-domain interoperability: A single DAG can span agents
  using different identity frameworks
- Regulatory flexibility: Machine-readable regulatory profiles
  allow different segments of a workflow to satisfy different
  compliance requirements
- Federated audit: Each domain operates its own audit ledger;
  cross-ledger anchoring enables end-to-end verification
- Privacy at boundaries: Selective disclosure allows verification
  of DAG structure without exposing regulated data across
  jurisdictions

## Scope and Applicability

This document defines:

- The Execution Audit Token (EAT) format ({{eat-format}})
- Three assurance levels for EAT production and verification
  ({{level-1}}, {{level-2}}, {{level-3}})
- DAG structure for task dependency ordering ({{dag-validation}})
- An HTTP header for EAT transport ({{http-header}})
- Cross-domain audit model including regulatory profiles,
  federated ledger anchoring, and selective disclosure
  ({{cross-domain}})
- Audit ledger interface requirements ({{ledger-interface}})

The following are out of scope and are handled by the deployment's
identity framework:

- Agent authentication and identity provisioning
- Key distribution and management
- Trust domain establishment and management
- Credential lifecycle management

## Assurance Levels and Applicability {#assurance-levels}

EATs support three assurance levels that govern how tokens are
produced, transported, and verified.  Each level builds on the
payload structure defined in {{eat-payload}}.

Level 1 (L1) — Unsigned JSON:
: EATs are plain JSON objects with no cryptographic signature.
  Integrity depends on transport security (TLS).  L1 is intended
  for internal deployments within a single trust domain where
  non-repudiation is not required, such as development
  environments or internal microservice meshes.

Level 2 (L2) — JOSE Asymmetric Signing:
: EATs are signed as JWS Compact Serialization tokens using
  asymmetric keys bound to the agent's identity credential.
  L2 provides non-repudiation and tamper detection.  This is
  the baseline assurance level for cross-organization and
  peer-to-peer deployments.

Level 3 (L3) — JOSE Signing with Audit Ledger:
: L3 extends L2 by requiring that every EAT be recorded in an
  audit ledger with cryptographic commitment (hash chain, Merkle
  tree, or equivalent).  L3 is intended for regulated environments
  that require hash-committed audit trails with tamper-evident
  history.

Assurance level selection is orthogonal to human-in-the-loop
(HITL) policy: any level may be combined with HITL requirements.
Level selection guidance is provided in {{level-selection}}.

# Conventions and Definitions

{::boilerplate bcp14-tagged}

The following terms are used in this document:

Agent:
: An autonomous workload that executes tasks within a workflow.

Task:
: A discrete unit of agent work that consumes inputs and produces
  outputs.

Directed Acyclic Graph (DAG):
: A graph structure representing task dependency ordering where
  edges are directed and no cycles exist.

Execution Audit Token (EAT):
: A token defined by this specification that records task execution
  details.  At Level 2 and Level 3, an EAT is a signed JSON Web
  Token {{RFC7519}}.  At Level 1, an EAT is an unsigned JSON
  object with the same payload structure.

Identity Credential:
: A credential that proves an agent's identity, such as an X.509
  certificate, an OAuth client credential, a SPIFFE Workload
  Identity Token, a DID document, or a JWK with out-of-band
  binding.  See {{identity-binding}}.

Assurance Level:
: One of three tiers (L1, L2, L3) governing how an EAT is
  produced, transported, and verified.  See {{assurance-levels}}.

Audit Ledger:
: An append-only, immutable log of all EATs within a workflow or
  set of workflows, used for audit and verification.

Trust Domain:
: An administrative boundary within which agents share a common
  identity authority.

Domain Boundary:
: The point at which a workflow crosses from one trust domain to
  another, potentially involving different identity frameworks,
  regulatory regimes, or audit requirements.

Regulatory Profile:
: A machine-readable identifier specifying the regulatory
  framework governing an EAT, determining required claims,
  retention periods, and audit properties.  See
  {{regulatory-profiles}}.

Ledger Anchor:
: A signed receipt from one domain's audit ledger that can be
  verified by another domain's ledger, enabling cross-domain
  audit chain verification.  See {{federated-ledger}}.

Actor Type:
: A classification of the entity that performed the task:
  "agent" (autonomous workload), "human" (human operator), or
  "system" (infrastructure component).  See {{actor-type-claim}}.

# Execution Audit Token Format {#eat-format}

An Execution Audit Token records a single task in a distributed
workflow.  The EAT payload structure is common across all assurance
levels; only the envelope and verification requirements differ.

## EAT Payload Structure {#eat-payload}

The EAT payload is a JSON object containing the claims defined in
this section.

### Standard Claims

The following standard JWT claims {{RFC7519}} are defined for EATs:

iss:
: OPTIONAL at L1; REQUIRED at L2 and L3.  StringOrURI.  A URI
  identifying the issuer of the EAT.  The value MUST correspond
  to the agent's identity as asserted by its identity credential
  (see {{identity-binding}}).  Deployments MAY use HTTPS URLs,
  URN:UUID identifiers, SPIFFE IDs, DID URIs, or other URI schemes
  appropriate to the identity framework in use.  L1 deployments
  are encouraged to include "iss" for consistency but it is not
  required.  See {{l2-verification}} and {{l3-verification}} for
  the L2/L3 verification requirements.

aud:
: RECOMMENDED.  StringOrURI or array of StringOrURI.  The intended
  recipient(s) of the EAT.  The "aud" claim SHOULD contain the
  identifiers of all entities that will verify the EAT.  When
  an EAT is to be verified by both the next agent and the audit
  ledger independently, "aud" MUST be an array containing both
  identifiers.  Each verifier checks that its own identity
  appears in "aud".  The "aud" claim is REQUIRED for L2 and L3
  deployments (see {{l2-verification}} and {{l3-verification}}).

iat:
: REQUIRED.  NumericDate.  The time at which the EAT was issued.

exp:
: REQUIRED.  NumericDate.  The expiration time of the EAT.
  Implementations SHOULD set this to 5 to 15 minutes after "iat".

jti:
: REQUIRED.  String.  A unique identifier for both the EAT and
  the task it records, in UUID format {{RFC9562}}.  The "jti"
  serves as both the token identifier (for replay detection) and
  the task identifier (for DAG parent references in "pred").
  Receivers MUST reject EATs whose "jti" has already been seen
  within the expiration window.  When "wid" is present,
  uniqueness is scoped to the workflow; when "wid" is absent,
  uniqueness MUST be enforced globally across the EAT store.

### Execution Context Claims {#exec-claims}

The following claims are defined by this specification:

wid:
: OPTIONAL.  String.  A workflow identifier that groups related
  EATs into a single workflow.  When present, MUST be a UUID
  {{RFC9562}}.

exec_act:
: REQUIRED.  String.  The action or task type identifier describing
  what the agent performed (e.g., "process_payment",
  "validate_safety").  This claim name avoids collision with the
  "act" (Actor) claim registered by {{RFC8693}}.

pred:
: REQUIRED.  Array of strings.  Predecessor task identifiers
  representing DAG dependencies.  Each element MUST be the "jti"
  value of a previously verified EAT.  An empty array indicates
  a root task with no dependencies.  A workflow MAY contain
  multiple root tasks.  The "pred" claim is always required
  (rather than optional with absence meaning "root task") to
  simplify validation logic and eliminate ambiguity between a
  root task and a claim accidentally omitted.

### Actor Type Claim {#actor-type-claim}

actor_type:
: OPTIONAL.  String.  Identifies the type of entity that
  performed the task.  Values are drawn from a controlled
  vocabulary:

  - "agent": An autonomous software workload (default if omitted)
  - "human": A human operator who performed a manual step,
    such as an approval or review
  - "system": An infrastructure component acting automatically,
    such as a load balancer, gateway, or scheduler

  When "actor_type" is "human", the "iss" claim SHOULD identify
  the human's organizational identity (e.g., an email-based URI
  or employee identifier URI) rather than a workload identity.
  Human-performed tasks are typically approval or review steps
  in human-in-the-loop (HITL) workflows.

  At L2 and L3, EATs with "actor_type" of "human" MUST still be
  signed with an asymmetric key.  The signing key MAY belong to
  the human's personal credential or to the system through which
  the human performed the action (e.g., an approval gateway),
  with the "iss" claim identifying the human and the signing
  system documented in "eat_ext".

### Data Integrity Claims {#data-integrity-claims}

The following claims provide integrity verification for task
inputs and outputs without revealing the data itself:

inp_hash:
: OPTIONAL.  String.  The base64url encoding (without padding) of
  the SHA-256 hash of the input data, computed over the raw octets
  of the input.  SHA-256 is the mandatory algorithm with no
  algorithm prefix in the value, consistent with {{RFC9449}}.

out_hash:
: OPTIONAL.  String.  The base64url encoding (without padding) of
  the SHA-256 hash of the output data, using the same format as
  "inp_hash".

### Domain Metadata Claims {#domain-claims}

The following claims support cross-domain workflows:

domain:
: OPTIONAL.  String.  The trust domain in which the agent
  operates.  This is a DNS-compatible identifier (e.g.,
  "bank.example.com", "hospital.example.org").  When present,
  enables auditors to determine which regulatory regime governs
  this segment of the DAG.

eat_reg:
: OPTIONAL.  Object.  Regulatory profile metadata for this EAT.
  See {{regulatory-profiles}} for the structure and semantics.

ledger_receipt:
: OPTIONAL.  Object.  A signed receipt from the domain's audit
  ledger, enabling cross-domain verification.  See
  {{federated-ledger}} for the structure and semantics.  This
  claim is populated by the ledger upon recording, not by the
  producing agent.

### Extension Claims {#extension-claims}

eat_ext:
: OPTIONAL.  Object.  A general-purpose extension object for
  domain-specific claims not defined by this specification.
  Implementations that do not understand extension claims MUST
  ignore them.  Extension key names SHOULD use reverse domain
  notation (e.g., "com.example.custom_field") to avoid
  collisions.  The serialized "eat_ext" object MUST NOT exceed
  4096 bytes and MUST NOT exceed a nesting depth of 5 levels.
  Receivers MUST reject EATs whose "eat_ext" object exceeds these
  limits.

## Complete EAT Payload Example

The following is a complete EAT payload example showing a
cross-domain task with regulatory metadata.  This payload
structure is the same at all assurance levels; only the transport
envelope differs.

~~~json
{
  "iss": "https://agents.bank.example.com/compliance-agent",
  "aud": ["https://agents.partner.example.com/rating-agent",
          "https://ledger.bank.example.com"],
  "iat": 1772064150,
  "exp": 1772064750,
  "jti": "550e8400-e29b-41d4-a716-446655440001",

  "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
  "exec_act": "verify_trade_compliance",
  "pred": ["550e8400-e29b-41d4-a716-446655440000"],
  "actor_type": "agent",

  "domain": "bank.example.com",
  "eat_reg": {
    "profiles": ["urn:ietf:eat:reg:eu-dora",
                  "urn:ietf:eat:reg:eu-ai-act"],
    "retention_days": 2555,
    "jurisdiction": "EU"
  },

  "inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
  "out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",

  "eat_ext": {
    "com.example.trace_id": "abc123"
  }
}
~~~
{: #fig-full-eat title="Complete EAT Payload Example"}

## Level 1: Unsigned JSON {#level-1}

At Level 1, an EAT is a plain JSON object carrying the payload
defined in {{eat-payload}}.  No cryptographic signature is applied.

### L1 Transport {#l1-transport}

L1 EATs are transported as base64url-encoded JSON (without
padding).  Two mechanisms are defined:

HTTP Header:
: The Execution-Context header field ({{http-header}}) carries
  the base64url-encoded JSON payload (without padding).  The
  header value is NOT raw JSON; the receiver MUST base64url-decode
  the value before parsing.

HTTP Body:
: When the EAT is the primary request payload, the EAT MAY be
  carried in the HTTP request body with Content-Type
  `application/json`.

L1 EATs MUST be transmitted over TLS or mTLS connections.
Transport security is the sole integrity mechanism at this level.

### L1 Verification {#l1-verification}

When an agent receives an L1 EAT, it MUST perform the following
verification steps:

1.  Parse the JSON object.

2.  Verify that all required claims ("jti", "iat", "exp",
    "exec_act", "pred") are present and well-formed.

3.  Verify that the "jti" has not been previously seen within the
    expiration window, consistent with the replay detection
    requirement in {{exec-claims}}.

4.  Verify the "exp" claim indicates the EAT has not expired.

5.  Verify the "iat" claim is not unreasonably far in the past
    (RECOMMENDED maximum: 15 minutes) and is not unreasonably
    far in the future (RECOMMENDED: no more than 30 seconds
    ahead of the verifier's current time).

6.  Perform DAG validation per {{dag-validation}}.

If any verification step fails, the EAT MUST be rejected and the
failure MUST be logged.

### L1 Security Properties and Applicability {#l1-security}

L1 provides the following security properties:

- Structural integrity via JSON schema validation
- Temporal ordering via "iat" and "exp" claims
- DAG integrity via parent reference validation
- Transport integrity via TLS

L1 does NOT provide:

- Non-repudiation (no signature binds the EAT to its issuer)
- Tamper detection after delivery (the recipient cannot prove
  the EAT was not modified after receipt)
- Issuer authentication at the EAT layer (identity depends
  entirely on the transport layer)

Note: At L1, without a deployed audit ledger, DAG parent
existence validation ({{dag-validation}} step 2) is limited to
parent EATs received inline with the current request.  Parents
from prior requests that were not forwarded inline cannot be
verified.

L1 MUST NOT be used across trust domain boundaries.
Deployments using L1 SHOULD restrict it to internal environments
where all agents are operated by the same organization and
transport security is considered sufficient.

## Level 2: JOSE Asymmetric Signing {#level-2}

At Level 2, an EAT is a JSON Web Token (JWT) {{RFC7519}} signed
as a JSON Web Signature (JWS) {{RFC7515}}.

EATs MUST use JWS Compact Serialization (the base64url-encoded
`header.payload.signature` format) so that they can be carried in
a single HTTP header value.

The EAT MUST be signed with a private key that is verifiably
bound to the agent's identity credential (see
{{identity-binding}}).  The JOSE header "kid" parameter MUST
reference the public key identifier from the agent's identity
credential, and the "alg" parameter MUST match the algorithm
associated with that credential.

### L2 JOSE Header {#jose-header}

The EAT JOSE header MUST contain the following parameters:

~~~json
{
  "alg": "ES256",
  "typ": "eat+jwt",
  "kid": "agent-a-key-id-123"
}
~~~
{: #fig-header title="EAT JOSE Header Example"}

alg:
: REQUIRED.  The digital signature algorithm used to sign the EAT.
  MUST match the algorithm associated with the agent's identity
  credential.  Implementations MUST support ES256 {{RFC7518}}.
  The "alg" value MUST NOT be "none".  Symmetric algorithms
  (e.g., HS256, HS384, HS512) MUST NOT be used, as EATs require
  asymmetric signatures for non-repudiation.  To support algorithm
  agility, deployments SHOULD maintain an allowlist of accepted
  signing algorithms and SHOULD plan for migration to stronger
  algorithms as cryptographic requirements evolve.

typ:
: REQUIRED.  MUST be set to "eat+jwt" to distinguish EATs from
  other JWT types.

kid:
: REQUIRED.  The key identifier referencing the public key from
  the agent's identity credential {{RFC7517}}.  Used by verifiers
  to look up the correct public key for signature verification.

### L2 Transport {#l2-transport}

L2 EATs are transported in the Execution-Context HTTP header
field ({{http-header}}) as JWS Compact Serialization.  The header
field value consists of three Base64url-encoded parts separated by
period (".") characters.

L2 EATs MUST be transmitted over TLS or mTLS connections.

### L2 Verification {#l2-verification}

When an agent receives an L2 EAT, it MUST perform the following
verification steps in order:

1.  Parse the JWS Compact Serialization to extract the JOSE header,
    payload, and signature components per {{RFC7515}}.

2.  Verify that the "typ" header parameter is "eat+jwt".

3.  Verify that the "alg" header parameter appears in the
    verifier's configured allowlist of accepted signing algorithms.
    The allowlist MUST NOT include "none" or any symmetric
    algorithm (e.g., HS256, HS384, HS512).  Implementations MUST
    include ES256 in the allowlist; additional asymmetric algorithms
    MAY be included per deployment policy.

4.  Verify the "kid" header parameter references a known, valid
    public key from an identity credential within the trust domain
    or a federated trust domain (see {{identity-binding}}).

5.  Retrieve the public key identified by "kid" and verify the JWS
    signature per {{RFC7515}} Section 5.2.

6.  Verify that the signing key identified by "kid" has not been
    revoked within the trust domain.  Implementations MUST check
    the key's revocation status using the identity framework's key
    lifecycle mechanism (e.g., certificate revocation list, OCSP,
    SPIFFE trust bundle updates, JWK set rotation, or DID document
    deactivation).

7.  Verify the "alg" header parameter matches the algorithm
    associated with the agent's identity credential.

8.  Verify the "iss" claim is present and matches the agent
    identity asserted by the identity credential associated with
    the "kid" public key (see {{identity-binding}}).

9.  Verify the "aud" claim is present and contains the verifier's
    own identity.  When "aud" is an array, it is sufficient that
    the verifier's identity appears as one element; the presence
    of other audience values does not cause verification failure.
    When the verifier is the audit ledger, the ledger's own
    identity MUST appear in "aud".

10. Verify the "exp" claim indicates the EAT has not expired.

11. Verify the "iat" claim is not unreasonably far in the past
    (implementation-specific threshold, RECOMMENDED maximum of
    15 minutes) and is not unreasonably far in the future
    (RECOMMENDED: no more than 30 seconds ahead of the
    verifier's current time, to account for clock skew).

12. Verify all required claims ("jti", "exec_act", "pred") are
    present and well-formed.

13. If "actor_type" is present, verify it contains a recognized
    value ("agent", "human", or "system").

14. If "eat_reg" is present, verify the regulatory profile
    structure per {{regulatory-profiles}}.

15. Perform DAG validation per {{dag-validation}}.

16. If all checks pass and an audit ledger is deployed, the EAT
    SHOULD be appended to the ledger.

If any verification step fails, the EAT MUST be rejected and the
failure MUST be logged for audit purposes.  Error messages
SHOULD NOT reveal whether specific parent task IDs exist in the
EAT store, to prevent information disclosure.

### L2 Security Properties and Applicability {#l2-security}

L2 provides the following security properties:

- Non-repudiation (the EAT is cryptographically bound to the
  issuing agent via asymmetric signature)
- Tamper detection (any modification invalidates the signature)
- Issuer authentication (the "kid" links to the agent's identity
  credential)
- Audience restriction (the "aud" claim limits valid verifiers)
- All L1 properties (structural, temporal, DAG, transport
  integrity)

L2 is suitable for cross-organization deployments, peer-to-peer
agent communication, and any deployment requiring cryptographic
non-repudiation.  L2 is the RECOMMENDED default for production
deployments.

## Level 3: JOSE Signing with Audit Ledger {#level-3}

Level 3 extends Level 2 by requiring that every EAT be recorded
in an audit ledger that provides cryptographic commitment.  L3
transport and JWS signing are identical to L2; the additional
requirements apply to ledger recording and verification.

### L3 Transport {#l3-transport}

L3 EATs use the same JWS Compact Serialization transport as L2
(see {{l2-transport}}).

### L3 Audit Ledger Requirements {#l3-ledger}

At Level 3, the audit ledger MUST satisfy the baseline
requirements defined in {{ledger-interface}} and the following
additional requirements:

1.  Hash Chain: Each ledger entry MUST include a cryptographic
    hash of the previous entry, forming a hash chain.  The hash
    algorithm MUST be SHA-256 or stronger.

2.  Cryptographic Commitment: The ledger MUST provide a
    mechanism for verifiable cryptographic commitment over its
    entries, such as Merkle tree proofs, hash chains with signed
    roots, or equivalent constructions.  The commitment MUST
    allow a verifier to confirm that a specific EAT is included
    in the ledger at a specific position without trusting the
    ledger operator.

3.  Receipts: Upon successful append, the ledger MUST return a
    receipt to the submitting agent.  The receipt MUST contain
    the ledger sequence number, the hash of the appended EAT
    entry, and the cryptographic commitment proof (e.g., Merkle
    inclusion proof) at the time of recording.

4.  Availability: The ledger MUST be accessible for verification
    queries by authorized entities within the trust domain.

### L3 Recording Semantics {#l3-recording}

An agent producing an L3 EAT MUST attempt to record the EAT in
the audit ledger.  Two recording modes are defined:

Synchronous Recording:
: The agent submits the EAT to the ledger and waits for a receipt
  before transmitting the EAT to the next agent.  Synchronous
  recording provides the strongest guarantee: the EAT is
  committed to the ledger before any downstream processing
  occurs.

Asynchronous Recording:
: The agent submits the EAT to the ledger and transmits the EAT
  to the next agent without waiting for a receipt.  The agent
  MUST subsequently verify that the ledger accepted the EAT and
  MUST retain the receipt.  If the ledger rejects the EAT, the
  agent MUST alert the workflow coordinator or log a critical
  error.  If asynchronous ledger recording fails, the producing
  agent MUST notify downstream agents that the EAT's L3 status
  is unconfirmed.  Downstream agents SHOULD treat such an EAT as
  L2-verified (not L3-verified) until ledger confirmation is
  independently obtainable.

Deployments SHOULD use synchronous recording unless latency
constraints make it impractical.  The recording mode SHOULD be
documented in the deployment's security policy.

### L3 Verification {#l3-verification}

L3 verification consists of L2 verification ({{l2-verification}})
followed by ledger verification:

Note: The "iss" and "aud" claims, which are RECOMMENDED at L1
and verified at L2 (steps 8-9 of {{l2-verification}}), are
REQUIRED at L3.

1.  Perform all L2 verification steps (steps 1 through 16 of
    {{l2-verification}}).

2.  Verify that the EAT has been recorded in the audit ledger by
    querying the ledger for the EAT's "jti".  If the EAT is
    found, verify that the ledger entry's receipt contains a
    valid sequence number, EAT hash, and cryptographic commitment
    proof.  Note: the producing agent is responsible for recording
    the EAT per {{l3-recording}}; the verifier checks that
    recording has occurred.

3.  If the EAT is not yet present in the ledger (e.g., due to
    asynchronous recording), the verifier MAY retry after a
    short delay.  If the ledger does not contain the EAT within
    the configured timeout, the verifier MUST either reject the
    EAT or downgrade to L2 verification per deployment policy.

4.  If the ledger is unavailable, the verifier SHOULD retry with
    exponential backoff.  If the ledger remains unavailable after
    a deployment-configured number of retries, the verifier MUST
    either reject the EAT or downgrade to L2 verification per
    deployment policy.

If any L3-specific verification step fails, the EAT MUST be
rejected even if L2 verification succeeded.

### L3 Security Properties and Applicability {#l3-security}

L3 provides the following security properties beyond L2:

- Tamper-evident history (the hash chain detects any
  modification, insertion, or deletion of ledger entries)
- Cryptographic commitment (Merkle proofs or equivalent allow
  independent verification of ledger inclusion)
- Non-repudiation of recording (the receipt proves the EAT was
  committed at a specific time and position)
- All L2 properties

L3 is intended for regulated environments requiring auditable,
tamper-evident execution records, such as healthcare (FDA 21 CFR
Part 11), financial services (MiFID II, DORA {{EU-DORA}}), and
environments subject to the EU AI Act {{EU-AI-ACT}}.

## Level Selection {#level-selection}

Deployments SHOULD select the assurance level based on the
following criteria:

- Use L1 when all agents operate within a single trust domain,
  non-repudiation is not required, and transport security (TLS)
  is considered sufficient.  Typical environments: development,
  testing, internal microservice meshes.

- Use L2 when agents cross trust domain boundaries, when
  non-repudiation is required, or when agents communicate
  peer-to-peer across organizations.  L2 is the RECOMMENDED
  default for production deployments.

- Use L3 when regulatory requirements mandate tamper-evident
  audit trails with cryptographic commitment, or when the
  deployment needs to demonstrate compliance with regulatory
  frameworks.

A deployment MAY use different assurance levels for different
workflows within the same infrastructure.  When agents at
different levels interact, the higher level's verification
requirements apply to the receiving agent.  Specifically, an
EAT at a higher assurance level MAY reference parent EATs at a
lower assurance level in its "pred" claim.  In this case, the
receiving agent applies its own level's verification to the
current EAT and the parent's level verification to each parent
EAT.  Whether cross-level parent references are permitted is a
deployment policy decision; deployments MAY reject EATs whose
parents are below a minimum assurance level.

This specification does not define a level negotiation mechanism.
Deployments configure the required assurance level out of band.
A future extension MAY define in-band level signaling.

### Assurance Level Transitions at Domain Boundaries {#level-transitions}

When a workflow crosses a domain boundary, the required assurance
level may change.  For example, an internal workflow segment may
use L1 within an organization, but L2 is required when crossing
to an external partner, and L3 is required when entering a
regulated jurisdiction.

Deployments SHOULD document their assurance level policy for
cross-domain interactions.  When an EAT crosses a domain boundary
and the receiving domain requires a higher assurance level than
the sending domain:

- The receiving agent MUST produce its own EAT at the required
  level, referencing the sender's EAT in "pred".

- The receiving agent MAY verify the sender's EAT at the
  sender's assurance level, provided that level meets the
  receiver's minimum acceptable level for parent EATs.

- If the sender's assurance level is below the receiver's
  minimum for parent EATs, the receiver MUST reject the EAT.

## Backward Compatibility and Level Detection {#level-detection}

A verifier determines the assurance level of a received EAT as
follows:

1.  If the raw Execution-Context header value (or body content)
    contains exactly two period (".") characters separating three
    non-empty segments, attempt to parse the value as JWS Compact
    Serialization.  If the first segment base64url-decodes to a
    JSON object containing an "alg" field, the EAT is L2 or L3.

2.  Otherwise, base64url-decode the header value (without padding)
    and attempt to parse the result as JSON.  If successful, the
    EAT is L1.

3.  If neither parse succeeds, the EAT MUST be rejected.

L2 and L3 use the same JWS format.  Differentiation between
L2 and L3 is a matter of deployment policy: L3 deployments
require ledger recording ({{l3-ledger}}), while L2
deployments treat ledger recording as optional.

## Identity Binding {#identity-binding}

At L2 and L3, the EAT signing key MUST be verifiably bound to the
agent's identity.  This specification defines the abstract
requirements for identity binding; concrete bindings are
defined for specific identity frameworks.

An identity binding MUST satisfy the following requirements:

1.  Key Association: The "kid" value in the EAT JOSE header MUST
    resolve to a public key through the identity framework's key
    discovery mechanism.

2.  Issuer Correspondence: The "iss" claim in the EAT payload
    MUST correspond to the agent identity asserted by the identity
    credential containing the "kid" public key.

3.  Algorithm Consistency: The "alg" value in the EAT JOSE header
    MUST match the algorithm associated with the identity
    credential.

4.  Revocation Checking: The verifier MUST be able to determine
    whether the signing key has been revoked using the identity
    framework's revocation mechanism.

### Cross-Domain Identity Resolution {#cross-domain-identity}

When an EAT crosses a domain boundary, the receiving domain may
use a different identity framework than the sending domain.  For
cross-domain verification:

1.  The receiving domain MUST be able to obtain the sender's
    public key through a pre-established federation mechanism
    (e.g., shared JWK set endpoint, cross-certified X.509
    hierarchy, bilateral trust bundle exchange).

2.  The "iss" claim's URI scheme indicates the identity framework
    in use.  The receiving domain MUST support verification of
    the identity framework indicated by the "iss" URI scheme, or
    MUST reject the EAT.

3.  Deployments SHOULD document which identity frameworks are
    accepted at each domain boundary and how cross-domain key
    discovery is configured.

### X.509 Binding {#x509-binding}

When the deployment uses X.509 certificates:

- The EAT "kid" MAY be the certificate thumbprint (x5t) or
  subject key identifier.
- The EAT "iss" SHOULD be a URI derived from the certificate
  subject or subject alternative name.
- Revocation is checked via CRL or OCSP.

### OAuth Binding {#oauth-binding}

When the deployment uses OAuth 2.0 credentials:

- The EAT "kid" MUST match the "kid" parameter in the
  authorization server's published JWK set.
- The EAT "iss" SHOULD be the OAuth client identifier as a URI.
- Revocation is checked via token introspection or JWK set
  rotation.

### JWK Set Binding {#jwk-binding}

When the deployment uses plain JWK sets {{RFC7517}} with
out-of-band trust establishment:

- The EAT "kid" MUST match the "kid" parameter in a JWK from
  the trusted JWK set.
- The EAT "iss" MUST match a value associated with the JWK
  through the deployment's configuration.
- Revocation is handled by removing the key from the published
  JWK set.

### DID Binding {#did-binding}

When the deployment uses Decentralized Identifiers (DIDs):

- The EAT "kid" MUST reference a verification method in the
  DID document.
- The EAT "iss" MUST be the DID URI.
- Revocation is checked via DID document deactivation or
  verification method removal.

# Cross-Domain Audit Model {#cross-domain}

This section defines mechanisms for maintaining verifiable audit
trails across multiple administrative domains with potentially
different regulatory requirements.

## Regulatory Profiles {#regulatory-profiles}

The "eat_reg" claim carries machine-readable metadata about the
regulatory regime governing an EAT.  This enables automated
compliance checking: an auditor or receiving domain can determine
what rules apply to a given segment of the DAG without out-of-band
knowledge.

### Regulatory Profile Structure

The "eat_reg" claim is a JSON object with the following fields:

profiles:
: REQUIRED (within "eat_reg").  Array of strings.  Each string
  is a URI identifying a regulatory profile.  This specification
  defines an initial set of profile URIs in {{profile-registry}};
  additional profiles may be registered per {{iana-profiles}}.

retention_days:
: OPTIONAL.  Integer.  The minimum number of days this EAT and
  its associated audit records MUST be retained.  When multiple
  regulatory profiles apply, the value SHOULD be the maximum
  retention period across all applicable profiles.

jurisdiction:
: OPTIONAL.  String.  An ISO 3166-1 alpha-2 country code or
  regional identifier (e.g., "EU", "US") indicating the
  jurisdiction under which this EAT was produced.

redact_policy:
: OPTIONAL.  String.  A URI identifying the data minimization
  or redaction policy applicable to this EAT when it crosses
  domain boundaries.  See {{selective-disclosure}}.

### Regulatory Profile Semantics

Each regulatory profile URI defines:

- Which EAT claims are REQUIRED vs OPTIONAL under that profile
- Whether "inp_hash" and "out_hash" are mandatory
- Whether L3 ledger recording is mandatory
- Minimum retention periods
- Whether selective disclosure is permitted or required at
  domain boundaries

Deployments MUST ensure that all EATs comply with every profile
listed in their "eat_reg.profiles" array.  When profiles conflict
(e.g., one requires data retention while another requires data
deletion), the deployment MUST resolve the conflict per its legal
counsel and document the resolution.

### Example Regulatory Profile Usage

An EAT produced in the EU financial sector:

~~~json
{
  "eat_reg": {
    "profiles": [
      "urn:ietf:eat:reg:eu-dora",
      "urn:ietf:eat:reg:eu-ai-act"
    ],
    "retention_days": 2555,
    "jurisdiction": "EU"
  }
}
~~~
{: #fig-reg-eu title="EU Financial Regulatory Profile"}

An EAT produced in the US healthcare sector:

~~~json
{
  "eat_reg": {
    "profiles": [
      "urn:ietf:eat:reg:us-hipaa"
    ],
    "retention_days": 2190,
    "jurisdiction": "US",
    "redact_policy": "urn:ietf:eat:redact:hipaa-minimum"
  }
}
~~~
{: #fig-reg-us title="US Healthcare Regulatory Profile"}

## Federated Audit Ledger Model {#federated-ledger}

In cross-domain workflows, each domain operates its own audit
ledger.  The federated ledger model enables end-to-end audit
verification across domain boundaries without requiring a single
shared ledger.

### Cross-Ledger Anchoring

When an EAT crosses a domain boundary, the sending domain's
ledger produces a signed anchor receipt that the receiving
domain's ledger can reference.  This creates a chain of
cryptographic commitments across ledgers, analogous to how
Certificate Transparency logs {{CERTIFICATE-TRANSPARENCY}}
cross-reference through signed timestamps.

The anchor receipt is carried in the "ledger_receipt" claim
of the EAT:

~~~json
{
  "ledger_receipt": {
    "ledger_id": "https://ledger.bank.example.com",
    "seq": 42,
    "eat_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
    "commitment": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
    "timestamp": 1772064200,
    "sig": "MEUCIQDx...signed-by-ledger-key..."
  }
}
~~~
{: #fig-anchor title="Cross-Ledger Anchor Receipt"}

ledger_id:
: REQUIRED (within "ledger_receipt").  String.  A URI identifying
  the audit ledger that recorded the EAT.

seq:
: REQUIRED (within "ledger_receipt").  Integer.  The sequence
  number of the EAT in the ledger.

eat_hash:
: REQUIRED (within "ledger_receipt").  String.  The base64url
  encoding (without padding) of the SHA-256 hash of the recorded
  EAT.

commitment:
: REQUIRED (within "ledger_receipt").  String.  The cryptographic
  commitment proof (e.g., Merkle root hash) at the time of
  recording.

timestamp:
: REQUIRED (within "ledger_receipt").  NumericDate.  The time at
  which the ledger recorded the EAT.

sig:
: REQUIRED (within "ledger_receipt").  String.  The base64url
  encoding of the ledger's signature over the concatenation of
  ledger_id, seq, eat_hash, commitment, and timestamp, using the
  ledger's signing key.

### Cross-Ledger Verification

When a receiving domain encounters an EAT with a "ledger_receipt"
from a foreign ledger, it MUST:

1.  Verify the "sig" field using the foreign ledger's public key,
    obtained through a pre-established trust relationship.

2.  Verify that the "eat_hash" matches the SHA-256 hash of the
    received EAT.

3.  Optionally query the foreign ledger to verify the commitment
    proof.

4.  Record the foreign EAT and its receipt in the local ledger,
    creating a cross-ledger reference.

### Ledger Federation Requirements

For federated ledger operation:

1.  Each domain's ledger MUST publish its signing public key at
    a well-known endpoint or through a pre-established key
    exchange mechanism.

2.  Domains MUST establish bilateral or multilateral trust
    relationships specifying which foreign ledgers are accepted.

3.  Ledger receipts MUST be verifiable without requiring real-time
    access to the foreign ledger (the receipt is self-contained
    for basic verification).

## Selective Disclosure at Domain Boundaries {#selective-disclosure}

When an EAT crosses a domain boundary, the receiving domain may
need to verify the DAG structure without seeing all details from
the originating domain.  This is critical for regulatory
compliance: a HIPAA-governed EAT should not expose protected
health information (PHI) to a receiving domain that operates
under different regulations.

### SD-JWT Integration

At L2 and L3, deployments MAY use Selective Disclosure JWT
(SD-JWT) {{SD-JWT}} to enable selective disclosure of EAT claims
at domain boundaries.  When SD-JWT is used:

1.  The producing agent creates an SD-JWT-based EAT where
    sensitive claims (e.g., "eat_ext", "inp_hash", "out_hash",
    "exec_act" details) are selectively disclosable.

2.  At the domain boundary, the agent creates a presentation
    that discloses only the claims needed by the receiving
    domain:
    - DAG structure claims ("jti", "pred", "wid") are always
      disclosed
    - "iss" and "aud" are always disclosed for verification
    - "domain" and "eat_reg" are always disclosed for regulatory
      routing
    - Other claims are disclosed only as required by the
      receiving domain's policy

3.  The receiving domain can verify the EAT's signature and DAG
    position without accessing redacted claims.

### Minimum Disclosure Set

When selective disclosure is used, the following claims MUST
always be disclosed (the "minimum disclosure set"):

- "jti" (task identity and DAG reference)
- "iat" and "exp" (temporal validation)
- "pred" (DAG structure)
- "iss" (issuer verification)
- "domain" (regulatory routing, when present)
- "eat_reg" (regulatory profile, when present)
- "actor_type" (when present)

## Audit Evidence Profiles {#evidence-profiles}

An Audit Evidence Profile is a machine-readable specification
of the EAT claims and verification properties required by a
particular regulatory framework.  Evidence profiles allow
automated compliance checking: given an EAT, a compliance tool
can determine whether it satisfies a specific regulatory
requirement.

### Evidence Profile Structure

An Audit Evidence Profile specifies:

- Profile URI (unique identifier)
- Required claims (which EAT claims must be present)
- Required assurance level (minimum L1, L2, or L3)
- Retention period (minimum days)
- Ledger requirements (whether L3 ledger is mandatory)
- Selective disclosure policy (whether disclosure is permitted
  at boundaries, and minimum disclosure set)
- Hash requirements (whether "inp_hash" and "out_hash" are
  mandatory)

### Initial Evidence Profiles {#profile-registry}

This specification defines the following initial regulatory
profile URIs.  These profiles are informational and are intended
to illustrate the framework; deployments MUST verify that these
profiles meet their actual regulatory obligations.

urn:ietf:eat:reg:eu-dora:
: EU Digital Operational Resilience Act.  Minimum assurance
  level: L3.  Retention: 2555 days (7 years).  "inp_hash" and
  "out_hash": REQUIRED.  Ledger: REQUIRED.

urn:ietf:eat:reg:eu-ai-act:
: EU Artificial Intelligence Act.  Minimum assurance level: L2.
  Retention: 3650 days (10 years) for high-risk AI systems.
  "inp_hash" and "out_hash": REQUIRED.  Ledger: RECOMMENDED.
  "actor_type": REQUIRED.

urn:ietf:eat:reg:us-hipaa:
: US Health Insurance Portability and Accountability Act.
  Minimum assurance level: L2.  Retention: 2190 days (6 years).
  Selective disclosure at domain boundaries: REQUIRED for
  PHI-containing extensions.

urn:ietf:eat:reg:us-soc2:
: SOC 2 Type II.  Minimum assurance level: L2.
  Retention: 365 days (1 year).

urn:ietf:eat:reg:financial-mifid2:
: MiFID II.  Minimum assurance level: L3.
  Retention: 2555 days (7 years).  Ledger: REQUIRED.

# HTTP Header Transport {#http-header}

## Execution-Context Header Field

This specification defines the Execution-Context HTTP header field
{{RFC9110}} for transporting EATs between agents.

The format of the header field value depends on the assurance
level:

- At Level 1, the header field value is the base64url-encoded
  JSON payload (without padding).

- At Level 2 and Level 3, the header field value is the EAT in
  JWS Compact Serialization format {{RFC7515}}.  The value
  consists of three Base64url-encoded parts separated by period
  (".") characters.

An agent sending a request to another agent includes the
Execution-Context header alongside any identity headers required
by the deployment's identity framework.

~~~
GET /api/safety-check HTTP/1.1
Host: safety-agent.example.com
Authorization: Bearer <identity-token>
Execution-Context: eyJhbGci...EAT...
~~~
{: #fig-http-example title="HTTP Request with EAT Header"}

When multiple parent tasks contribute context to a single request,
multiple Execution-Context header field lines MAY be included, each
carrying a separate EAT.  This applies to all assurance levels.

When a receiver processes multiple Execution-Context headers, it
MUST individually verify each EAT per the applicable verification
procedure ({{l1-verification}}, {{l2-verification}}, or
{{l3-verification}}).  If any single EAT fails verification, the
receiver MUST reject the entire request.  The set of verified
parent task IDs across all received EATs represents the complete
set of parent dependencies available for the receiving agent's
subsequent EAT.

## HTTP Error Handling

When EAT verification fails during HTTP request processing, the
receiving agent SHOULD respond with HTTP 403 (Forbidden).  This
applies regardless of whether the failure is due to an invalid
EAT payload, a signature verification failure, or a missing EAT
when one is required by deployment policy.  HTTP 401
(Unauthorized) SHOULD NOT be used for EAT failures, as 401
conventionally indicates that authentication credentials are
missing or invalid and requires a WWW-Authenticate header per
{{RFC9110}}.  The response body SHOULD include a generic error
indicator without revealing which specific verification step
failed.  The receiving agent MUST NOT process the requested
action when EAT verification fails.

# DAG Validation {#dag-validation}

EATs form a Directed Acyclic Graph (DAG) where each task
references its parent tasks via the "pred" claim.  DAG validation
is performed against the EAT store — either an audit ledger or
the set of parent EATs received inline.

DAG validation applies regardless of assurance level.

When receiving and verifying an EAT, implementations MUST perform
the following DAG validation steps:

1.  Task ID Uniqueness: The "jti" claim MUST be unique within the
    applicable scope (the workflow identified by "wid", or the
    entire EAT store if "wid" is absent).  If an EAT with the same
    "jti" already exists, the EAT MUST be rejected.

2.  Parent Existence: Every task identifier listed in the "pred"
    array MUST correspond to a task that is available in the EAT
    store (either previously recorded in the ledger or received
    inline as a verified parent EAT).  If any parent task is not
    found, the EAT MUST be rejected.

3.  Temporal Ordering: The "iat" value of every parent task MUST
    NOT be greater than the "iat" value of the current task plus a
    configurable clock skew tolerance (RECOMMENDED: 30 seconds).
    That is, for each parent: `parent.iat < child.iat +
    clock_skew_tolerance`.  The tolerance accounts for clock skew
    between agents; it does not guarantee strict causal ordering
    from timestamps alone.  Causal ordering is primarily enforced
    by the DAG structure (parent existence in the EAT store), not by
    timestamps.  If any parent task violates this constraint, the
    EAT MUST be rejected.

4.  Acyclicity: Following the chain of parent references MUST NOT
    lead back to the current EAT's "jti".  If a cycle is detected,
    the EAT MUST be rejected.  Note: because the Parent Existence
    check (step 2) requires that all parents already exist in the
    EAT store, and an EAT cannot reference itself or a future EAT,
    cycles are prevented by construction.  This explicit check
    serves as defense in depth against implementation errors or
    store corruption.

5.  Domain Consistency: When "domain" is present, parent tasks
    SHOULD belong to the same domain or to a domain with which a
    federation relationship has been established.  Cross-domain
    parent references are valid when the domains have a
    pre-established trust relationship.

6.  Workflow Consistency: When "wid" is present, verifiers SHOULD
    validate that the "wid" of each parent EAT matches the "wid"
    of the current EAT.  Cross-workflow parent references (where
    a parent's "wid" differs from the child's "wid") MUST be
    rejected unless explicitly permitted by deployment policy.

7.  Cross-Workflow Composition: When a task in one workflow depends
    on the output of a task in a different workflow, the dependency
    MAY be expressed as a cross-workflow reference using a composite
    identifier in the "pred" array: `<wid>:<jti>`.  Cross-workflow
    references MUST be explicitly enabled by deployment policy and
    are subject to all verification requirements of both the source
    and target workflows.

To prevent denial-of-service via extremely deep or wide DAGs,
implementations SHOULD enforce a maximum ancestor traversal limit
(RECOMMENDED: 10000 nodes).  If the limit is reached before cycle
detection completes, the EAT SHOULD be rejected.

In distributed deployments, a parent EAT may not yet be available
locally due to replication lag.  Implementations MAY defer
validation to allow parent EATs to arrive, but MUST NOT treat
the EAT as verified until all parent references are resolved.

# Audit Ledger Interface {#ledger-interface}

EATs MAY be recorded in an immutable audit ledger for compliance
verification and post-hoc analysis.  A ledger is OPTIONAL for L1
and L2 deployments but is REQUIRED for L3 deployments.  This
specification does not mandate a specific storage technology.
Implementations MAY use append-only logs, databases with
cryptographic commitment schemes, distributed ledgers, or any
storage mechanism that provides the required properties.

## Baseline Ledger Requirements

When an audit ledger is deployed, the implementation MUST provide:

1.  Append-only semantics: Once an EAT is recorded, it MUST NOT be
    modified or deleted.

2.  Ordering: The ledger MUST maintain a total ordering of EAT
    entries via a monotonically increasing sequence number.

3.  Lookup by EAT ID: The ledger MUST support efficient retrieval
    of EAT entries by "jti" value.

4.  Lookup by Workflow ID: The ledger SHOULD support retrieval of
    all EAT entries matching a given "wid" value.

5.  Integrity verification: The ledger SHOULD provide a mechanism
    to verify that no entries have been tampered with (e.g.,
    hash chains or Merkle trees).

The ledger SHOULD be maintained by an entity independent of the
workflow agents to reduce the risk of collusion.

## L3 Ledger Requirements

At Level 3, the audit ledger MUST satisfy the baseline
requirements above and the additional requirements defined in
{{l3-ledger}}.  In particular:

- Each entry MUST include a cryptographic hash of the previous
  entry, forming a verifiable hash chain.

- The ledger MUST provide cryptographic commitment proofs
  (Merkle tree proofs, signed hash chain roots, or equivalent).

- The ledger MUST return a receipt upon successful append,
  containing the sequence number, entry hash, and commitment
  proof.

## Ledger Independence

The audit ledger SHOULD be operated by an entity that is
independent of the workflow agents.  When the ledger operator and
the workflow agents are controlled by the same organization,
additional safeguards SHOULD be implemented, such as separation
of duties between ledger administrators and agent operators, or
independent ledger replicas maintained by third parties.

## EAT Discovery API {#discovery-api}

Deployments SHOULD provide a standardized API for EAT discovery
and verification.  The following endpoints are RECOMMENDED:

Lookup by Task ID:
: `GET /eat/{jti}` — Returns the EAT and its ledger receipt
  (if recorded) for the specified task identifier.

Lookup by Workflow ID:
: `GET /eat?wid={wid}` — Returns all EATs in the specified
  workflow, ordered by ledger sequence number.

DAG Retrieval:
: `GET /eat/{jti}/dag` — Returns the complete DAG rooted at
  the specified task, including all ancestor EATs.

Ledger Verification:
: `GET /ledger/verify?seq={seq}` — Returns the commitment
  proof for the specified ledger sequence number.

These endpoints MUST require authentication and MUST enforce
access control per the deployment's authorization policy.

## L3 Ledger Verification

Auditors verifying L3 ledger integrity SHOULD perform the
following checks:

1.  Verify the hash chain: for each entry, recompute the hash of
    the previous entry and confirm it matches the recorded value.

2.  Verify the cryptographic commitment: validate Merkle inclusion
    proofs (or equivalent) for a sample or all entries.

3.  Verify EAT signatures: for each EAT in the ledger, perform
    the L2 verification procedure ({{l2-verification}}) using
    the public keys valid at the time of recording.

4.  Verify DAG consistency: confirm that all parent references in
    all EATs resolve to valid entries in the ledger.

# Security Considerations

## Threat Model

The threat model considers: (1) a malicious agent that creates
false EAT claims, (2) an agent whose private key has been
compromised, (3) a ledger tamperer attempting to modify recorded
entries, (4) a time manipulator altering timestamps to affect
perceived ordering, (5) a domain boundary attacker attempting to
inject, modify, or drop EATs at domain transitions, and (6) a
regulatory arbitrage attacker claiming false regulatory profiles
to avoid compliance requirements.

## Level-Specific Security Properties {#level-security}

### Level 1 {#sec-level-1}

L1 provides no cryptographic binding between the EAT and its
issuer.  A compromised or malicious intermediary with access to
the transport channel can modify L1 EATs without detection after
delivery.  L1 does not provide non-repudiation: the issuer can
deny having produced an EAT, and the receiver cannot prove
otherwise.

L1 MUST NOT be used across trust domain boundaries.  L1 is
appropriate only when all agents are operated by the same
organization, the transport channel is fully trusted (e.g.,
service mesh with mTLS), and the deployment does not require
non-repudiation or tamper evidence beyond transport security.

### Level 2 {#sec-level-2}

L2 inherits all security properties of the JWS-based EAT
mechanism defined in this document.  The existing security
analysis (signature verification, replay prevention, key
compromise, collusion) applies directly to L2.

### Level 3 {#sec-level-3}

L3 provides all L2 security properties plus tamper-evident
history via the audit ledger's hash chain and cryptographic
commitment.  Modifications to ledger entries are detectable
through hash chain verification.  Deletions or insertions are
detectable through Merkle proof validation.

L3 does not prevent a compromised ledger operator from refusing
to record entries (censorship), but the submitting agent's receipt
mechanism ({{l3-ledger}}) provides evidence of submission.
Deployments concerned about ledger censorship SHOULD use multiple
independent ledger replicas.

## Assurance Level Downgrade Attacks

The assurance level of an EAT is determined by its format: unsigned
JSON indicates L1, while a JWS compact serialization indicates L2
or L3.  This format-based detection determines what was sent, not
what was expected by the verifier.

A man-in-the-middle or compromised proxy could strip the JWS
signature from an L2 or L3 EAT and re-encode the payload as an
unsigned L1 JSON object.  Because the resulting EAT is
syntactically valid at L1, a verifier that accepts any assurance
level would process it without detecting the downgrade.

Verifiers MUST be configured with a minimum acceptable assurance
level and MUST reject EATs whose detected level falls below that
minimum.  Format-based level detection alone is insufficient
without a policy-enforced minimum level requirement.

## Cross-Domain Security Considerations {#cross-domain-security}

### Domain Boundary Attacks

At domain boundaries, additional attack vectors exist:

- EAT injection: An attacker at the boundary inserts a fabricated
  EAT into the workflow.  Mitigation: L2/L3 signature verification
  prevents injection of unsigned or incorrectly signed EATs.

- EAT dropping: An attacker removes an EAT at the boundary,
  breaking the DAG chain.  Mitigation: the receiving agent's DAG
  validation (parent existence check) detects missing parents.

- Regulatory profile falsification: An agent claims a regulatory
  profile that does not actually apply, to avoid stricter
  compliance requirements.  Mitigation: receiving domains SHOULD
  independently verify that the claimed jurisdiction and regulatory
  profiles are consistent with the sending domain's known
  regulatory environment.

### Mixed Identity Framework Security

When a DAG spans agents using different identity frameworks
(e.g., X.509 in one domain, OAuth in another), the verifier
must support multiple key resolution mechanisms.  This increases
the attack surface:

- Each identity framework has its own revocation semantics and
  timing.  A key revoked in one framework may not be immediately
  detectable through another framework's mechanisms.

- Deployments SHOULD maintain a unified revocation status cache
  that aggregates revocation information across all supported
  identity frameworks.

### Federated Ledger Security

- Split-view attacks: A foreign ledger could present different
  receipts to different verifiers.  Mitigation: cross-ledger
  anchoring includes the commitment proof, which can be
  independently verified.

- Receipt replay: A valid receipt from one EAT could be attached
  to a different EAT.  Mitigation: the "eat_hash" field in the
  receipt binds the receipt to a specific EAT.

- Ledger key compromise: If a foreign ledger's signing key is
  compromised, fake receipts can be generated.  Mitigation:
  ledger keys SHOULD be stored in HSMs; receipts SHOULD be
  cross-checked against the foreign ledger's published
  commitment history.

## Self-Assertion Limitation {#self-assertion-limitation}

EATs are self-asserted by the executing agent.  The agent claims
what it did, and this claim is signed with its private key (at L2
and L3).  A compromised or malicious agent could create EATs with
false claims (e.g., claiming an action was performed when it was
not).

EATs do not independently verify that:

- The claimed execution actually occurred as described
- The input/output hashes correspond to the actual data processed
- The agent faithfully performed the stated action
- The claimed regulatory profile is accurate

The trustworthiness of EAT claims depends on the trustworthiness
of the signing agent and the integrity of the broader deployment
environment.  EATs provide a technical mechanism for execution
recording; they do not by themselves satisfy any specific
regulatory compliance requirement.

## Signature Verification

For L2 and L3 deployments, EATs MUST be signed with the agent's
private key using JWS {{RFC7515}}.  The signature algorithm MUST
match the algorithm associated with the agent's identity
credential (see {{identity-binding}}).  Receivers MUST verify the
EAT signature against the corresponding public key before
processing any claims.  Receivers MUST verify that the signing key
has not been revoked within the trust domain (see step 6 in
{{l2-verification}}).

If signature verification fails or if the signing key has been
revoked, the EAT MUST be rejected entirely and the failure MUST
be logged.

Implementations MUST use established JWS libraries and MUST NOT
implement custom signature verification.  Implementations SHOULD
follow the JWT security best practices defined in {{RFC8725}}.

## Replay Attack Prevention

EATs include short expiration times (RECOMMENDED: 5-15 minutes)
and audience restriction via "aud" to limit replay attacks.
Implementations MUST maintain a cache of recently-seen "jti"
values and MUST reject EATs with duplicate "jti" values.  For
L2 and L3, each EAT is cryptographically bound to the issuing
agent via "kid"; verifiers MUST confirm that "kid" resolves to
the "iss" agent's key (step 8 in {{l2-verification}}).

## Man-in-the-Middle Protection

EATs MUST be transmitted over TLS or mTLS connections.

## Key Compromise

If an agent's private key is compromised, an attacker can forge
EATs that appear to originate from that agent.  Mitigations:

- Implementations SHOULD use short-lived keys and rotate them
  frequently.
- Private keys SHOULD be stored in hardware security modules or
  equivalent secure key storage.
- Trust domains MUST support rapid key revocation.

EATs recorded before key revocation remain valid historical
records but SHOULD be flagged for audit purposes.  New EATs
MUST NOT reference a parent EAT whose signing key is known to
be revoked at creation time.

## Collusion and DAG Integrity {#collusion-and-false-claims}

A single malicious agent cannot forge parent task references
because DAG validation requires parent tasks to exist in the EAT
store.  However, multiple colluding agents could create a false
execution history.  Additionally, a malicious agent may omit
actual parent dependencies from "pred" to hide influences on its
output; because EATs are self-asserted
({{self-assertion-limitation}}), no mechanism can force complete
dependency declaration.

Mitigations include:

- The ledger SHOULD be maintained by an entity independent of the
  workflow agents.
- Multiple independent ledger replicas can be compared for
  consistency.
- External auditors can compare the declared DAG against expected
  workflow patterns.

## Privilege Escalation via EATs

EATs record execution history; they do not convey authorization.
Verifiers MUST NOT interpret the presence of an EAT, or a
particular set of parent references in "pred", as an authorization
grant.  Authorization decisions MUST remain with the deployment's
identity and authorization layer.

## Denial of Service

Implementations SHOULD apply rate limiting to prevent excessive
EAT submissions.  For L2 and L3, DAG validation SHOULD be
performed after signature verification to avoid wasting resources
on unsigned or incorrectly signed tokens.  L1 EATs are cheaper
to validate (no signature verification) but are correspondingly
easier for an attacker to generate; L1 deployments SHOULD apply
stricter rate limits to compensate.

## Timestamp Accuracy

Implementations SHOULD use synchronized time sources (e.g., NTP)
and SHOULD allow a configurable clock skew tolerance (RECOMMENDED:
30 seconds).  Cross-domain deployments MAY require a
higher tolerance and SHOULD document the configured value.

## EAT Size Constraints

Implementations SHOULD limit the "pred" array to a maximum of
256 entries.  See {{extension-claims}} for "eat_ext" size limits.

When EATs are transported via HTTP headers, the total encoded
size of the Execution-Context header value is subject to
practical limits imposed by HTTP servers and intermediaries.
Many implementations enforce header size limits of 8 KB or 16 KB.
Implementations SHOULD ensure that the total size of an EAT
(including JWS overhead for L2/L3) does not exceed 8 KB when
transported via HTTP header.  EATs that exceed HTTP header size
limits SHOULD be transported in the HTTP request body instead
(see {{l1-transport}} and {{l2-transport}}).

## Identity Binding Security

### JWK Set Binding {#sec-jwk-binding}

When identity is bound via JWK Set URI (see {{identity-binding}}),
there is a time-of-check/time-of-use gap between JWK set
refreshes.  A key that has been removed from the JWK set may still
be accepted by a verifier whose cached copy has not yet been
refreshed.  Implementations SHOULD refresh JWK sets at
configurable intervals (RECOMMENDED: no longer than 5 minutes).

### X.509 Binding {#sec-x509-binding}

When identity is bound via X.509 certificates, revocation checking
depends on OCSP responder or CRL distribution point availability.
If the revocation source is unreachable, the verifier needs to decide
whether to accept or reject the EAT.  Implementations SHOULD
hard-fail for L3 (reject the EAT if revocation status cannot be
determined), as L3 workflows require the strongest assurance.
Implementations MAY soft-fail for L2 with logging, accepting the
EAT but recording the revocation check failure for subsequent
audit review.

## Audit Ledger Threats

### Availability

If the audit ledger is unavailable in synchronous recording mode
(see {{l3-ledger}}), all L3 workflows halt because agents cannot
obtain ledger receipts.  Deployments SHOULD implement ledger
redundancy (e.g., multiple ledger replicas behind a load balancer)
to prevent the ledger from becoming a single point of failure.

### Split-View Attacks

A compromised ledger could present different views to different
verifiers (equivocation), causing inconsistent audit state across
the deployment.  Deployments SHOULD use multiple independent
ledger replicas and SHOULD periodically compare their state to
detect divergence.

### Receipt Authenticity

If the ledger's signing key is compromised, an attacker can
generate fake receipts for entries that were never recorded.
Ledger signing keys SHOULD be stored in hardware security modules
(HSMs) and SHOULD be rotated regularly.

### Asynchronous Recording Gap

In asynchronous recording mode (see {{l3-ledger}}), downstream
agents act on EATs before ledger confirmation is received.
During this gap, an EAT that will ultimately fail ledger recording
may already have influenced downstream workflow steps.  Deployments
using asynchronous recording SHOULD implement reconciliation
procedures to detect and handle EATs that fail ledger confirmation
after downstream processing has begun.

# Privacy Considerations

## Data Exposure in EATs

EATs necessarily reveal:

- Agent identities ("iss", "aud") for accountability purposes
- Action descriptions ("exec_act") for audit trail completeness
- Timestamps ("iat", "exp") for temporal ordering
- Domain information ("domain") for regulatory routing

EATs are designed to NOT reveal:

- Actual input or output data values (replaced with cryptographic
  hashes via "inp_hash" and "out_hash")
- Internal computation details or intermediate steps
- Proprietary algorithms or intellectual property
- Personally identifiable information (PII)

Privacy exposure is equivalent across all assurance levels: the
EAT payload contains the same claims regardless of whether the
EAT is unsigned (L1), signed (L2), or signed with ledger
recording (L3).  L3 ledger recording increases the durability of
the privacy-relevant data but does not increase its scope.

## Cross-Domain Privacy {#cross-domain-privacy}

Cross-domain workflows introduce additional privacy concerns:

- Workflow topology leakage: The DAG structure reveals which
  agents interact across domains, potentially exposing
  organizational relationships or business processes.

- Regulatory conflicts: GDPR's data minimization requirements
  may conflict with another jurisdiction's audit trail
  completeness requirements.  The selective disclosure mechanism
  ({{selective-disclosure}}) helps resolve this tension.

- Jurisdiction hopping: EATs that cross multiple jurisdictions
  accumulate metadata.  Deployments SHOULD use selective disclosure
  to minimize cross-jurisdictional data exposure.

## Data Minimization {#data-minimization}

Implementations SHOULD minimize the information included in EATs.
The "exec_act" claim SHOULD use structured identifiers (e.g.,
"process_payment") rather than natural language descriptions.
Extension keys in "eat_ext" ({{extension-claims}}) deserve
particular attention: human-readable values risk exposing
sensitive operational details.

## Storage and Access Control

EATs stored in audit ledgers SHOULD be access-controlled so that
only authorized auditors can read them.  Implementations SHOULD
consider encryption at rest for ledger storage.  EATs provide
structural records of execution ordering; they are not intended
for public disclosure.

Full input and output data (corresponding to the hashes in EATs)
SHOULD be stored separately from the ledger with additional access
controls, since auditors may need to verify hash correctness but
general access to the data values is not needed.

## Workflow Topology Leakage

The DAG structure of EATs reveals workflow topology: which agents
interact, fan-out and fan-in patterns, sequential versus parallel
execution, and organizational structure.  At L3, this topology is
permanently recorded in the audit ledger.  Deployments SHOULD
consider whether workflow topology constitutes sensitive
information and apply appropriate access controls to EAT stores
and ledgers.

## Cross-Workflow Correlation

Stable agent identifiers in the "iss" claim enable cross-workflow
activity correlation: an observer with access to EATs from
multiple workflows can track which agents participate in which
workflows and how frequently.  Deployments with privacy
requirements MAY use per-workflow or rotating agent identifiers
where feasible to limit cross-workflow correlation.

# IANA Considerations

## Media Type Registration

This document requests registration of the following media type
in the "Media Types" registry maintained by IANA:

Note: The media type "application/eat+jwt" uses the "+jwt"
structured syntax suffix.  While "+jwt" is widely used in
practice, it is not yet a formally registered structured syntax
suffix per {{RFC6838}}.  Registration of the "+jwt" suffix is
the subject of ongoing work in the IETF.

### application/eat+jwt

Type name:
: application

Subtype name:
: eat+jwt

Required parameters:
: none

Optional parameters:
: none

Encoding considerations:
: 8bit; at Level 2 and Level 3, an EAT is a JWT that is a JWS
  using the Compact Serialization, which is a sequence of
  Base64url-encoded values separated by period characters.  At
  Level 1, this media type is not used; L1 EATs use
  application/json.

Security considerations:
: See the Security Considerations section of this document.

Interoperability considerations:
: none

Published specification:
: This document

Applications that use this media type:
: Applications that implement agentic workflows requiring
  cross-domain execution audit trails.

Additional information:
: Magic number(s): none
  File extension(s): none
  Macintosh file type code(s): none

Person and email address to contact for further information:
: Christian Nennemann, ietf@nennemann.de

Intended usage:
: COMMON

Restrictions on usage:
: none

Author:
: Christian Nennemann

Change controller:
: IETF

## HTTP Header Field Registration {#header-registration}

This document requests registration of the following header field
in the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
maintained by IANA:

Field name:
: Execution-Context

Status:
: permanent

Specification document:
: This document, {{http-header}}

## JWT Claims Registration {#claims-registration}

This document requests registration of the following claims in
the "JSON Web Token Claims" registry maintained by IANA:

| Claim Name | Claim Description | Change Controller | Reference |
|:---:|:---|:---:|:---:|
| wid | Workflow Identifier | IETF | {{exec-claims}} |
| exec_act | Action/Task Type | IETF | {{exec-claims}} |
| pred | Predecessor Task Identifiers | IETF | {{exec-claims}} |
| actor_type | Actor Type | IETF | {{actor-type-claim}} |
| inp_hash | Input Data Hash | IETF | {{data-integrity-claims}} |
| out_hash | Output Data Hash | IETF | {{data-integrity-claims}} |
| domain | Trust Domain Identifier | IETF | {{domain-claims}} |
| eat_reg | Regulatory Profile Metadata | IETF | {{domain-claims}} |
| ledger_receipt | Audit Ledger Receipt | IETF | {{domain-claims}} |
| eat_ext | Extension Object | IETF | {{extension-claims}} |
{: #table-claims title="JWT Claims Registrations"}

## Regulatory Profile Registry {#iana-profiles}

This document establishes a new "EAT Regulatory Profiles" registry
under the "JSON Web Token (JWT)" group.  Registration policy is
Specification Required per RFC 8126.

Each registration includes:

- Profile URI (e.g., "urn:ietf:eat:reg:eu-dora")
- Description
- Required EAT claims
- Minimum assurance level
- Reference document

Initial registrations are defined in {{profile-registry}}.

--- back

# Use Cases {#use-cases}
{:numbered="false"}

This section describes representative use cases demonstrating how
EATs provide structured execution records across multiple domains
with different regulatory requirements.

Note: task identifiers in this section are abbreviated for
readability.  In production, all "jti" values are required to be
UUIDs per {{exec-claims}}.

## Cross-Jurisdiction Financial Trading (L3)
{:numbered="false"}

An investment bank in Frankfurt coordinates with a credit rating
agency in New York.  The bank operates under DORA and MiFID II;
the rating agency operates under US SOC 2.  The DAG spans both
jurisdictions with different regulatory profiles.

~~~
Domain: bank.example.com (EU, DORA + MiFID II)
  Agent A1 (Portfolio Risk):
    jti: task-001    pred:[]
    iss: https://agents.bank.example.com/risk
    exec_act: analyze_portfolio_risk
    domain: bank.example.com
    eat_reg: {profiles: ["urn:ietf:eat:reg:eu-dora",
              "urn:ietf:eat:reg:financial-mifid2"],
              retention_days: 2555, jurisdiction: "EU"}

Domain: ratings.example.com (US, SOC 2)
  Agent B1 (Credit Rating):
    jti: task-002    pred:[]
    iss: https://agents.ratings.example.com/credit
    exec_act: assess_credit_rating
    domain: ratings.example.com
    eat_reg: {profiles: ["urn:ietf:eat:reg:us-soc2"],
              retention_days: 365, jurisdiction: "US"}

Domain: bank.example.com (EU)
  Agent A2 (Compliance):
    jti: task-003    pred:[task-001, task-002]
    iss: https://agents.bank.example.com/compliance
    exec_act: verify_trade_compliance
    domain: bank.example.com
    eat_reg: {profiles: ["urn:ietf:eat:reg:eu-dora"],
              retention_days: 2555, jurisdiction: "EU"}

  Agent A3 (Execution):
    jti: task-004    pred:[task-003]
    iss: https://agents.bank.example.com/execution
    exec_act: execute_trade
~~~
{: #fig-finance title="Cross-Jurisdiction Trading (L3)"}

The resulting DAG:

~~~
task-001 (analyze_portfolio_risk)   task-002 (assess_credit_rating)
  [bank.example.com, EU]             [ratings.example.com, US]
          \                              /
           v                            v
         task-003 (verify_trade_compliance)
           [bank.example.com, EU]
                    |
                    v
         task-004 (execute_trade)
           [bank.example.com, EU]
~~~
{: #fig-finance-dag title="Cross-Jurisdiction DAG"}

Task 002 from the US domain carries a ledger_receipt from the
US ledger.  When task 003 in the EU domain references task 002
as a parent, the EU ledger records the cross-ledger anchor,
creating an end-to-end verifiable audit trail across both
jurisdictions.

## Healthcare Agent Pipeline with HITL (L2/L3)
{:numbered="false"}

A clinical AI agent recommends a treatment plan that requires
human physician approval before the pharmacy agent can proceed.
The workflow demonstrates the "actor_type" claim for
human-in-the-loop steps.

~~~
Domain: hospital.example.org (US, HIPAA)

  Agent C1 (Clinical AI):
    jti: task-101    pred:[]
    iss: https://agents.hospital.example.org/clinical-ai
    exec_act: recommend_treatment
    actor_type: agent
    eat_reg: {profiles: ["urn:ietf:eat:reg:us-hipaa"],
              retention_days: 2190, jurisdiction: "US"}

  Dr. Smith (Physician Approval):
    jti: task-102    pred:[task-101]
    iss: https://staff.hospital.example.org/dr-smith
    exec_act: approve_treatment
    actor_type: human
    eat_reg: {profiles: ["urn:ietf:eat:reg:us-hipaa"],
              retention_days: 2190, jurisdiction: "US"}

  Agent C2 (Pharmacy):
    jti: task-103    pred:[task-102]
    iss: https://agents.hospital.example.org/pharmacy
    exec_act: dispense_medication
    actor_type: agent
~~~
{: #fig-healthcare title="Healthcare HITL Workflow (L2/L3)"}

Task 102 has "actor_type": "human", indicating a physician
reviewed and approved the AI's recommendation.  The EAT is
signed by the hospital's approval gateway on behalf of
Dr. Smith.  When this workflow's output crosses to a research
partner under GDPR, selective disclosure redacts the physician's
identity and treatment details while preserving the DAG structure
proving human approval occurred.

## Multi-Cloud AI Pipeline with Mixed Identity (L2)
{:numbered="false"}

An AI pipeline spans three cloud providers, each using a
different identity framework.  The DAG demonstrates cross-domain
identity resolution.

~~~
Domain: aws.customer.example (X.509 identity)
  Agent P1 (Data Preprocessor):
    jti: task-301    pred:[]
    iss: urn:x509:CN=preprocessor.aws.customer.example
    exec_act: preprocess_training_data
    kid: x5t#sha256:abc123...

Domain: gcp.partner.example (OAuth identity)
  Agent P2 (Model Training):
    jti: task-302    pred:[task-301]
    iss: https://oauth.gcp.partner.example/client/trainer
    exec_act: train_model
    kid: oauth-key-456

Domain: azure.customer.example (JWK Set identity)
  Agent P3 (Model Validation):
    jti: task-303    pred:[task-302]
    iss: https://agents.azure.customer.example/validator
    exec_act: validate_model
    kid: jwk-789
~~~
{: #fig-multicloud title="Multi-Cloud Mixed Identity (L2)"}

Each domain uses its own identity framework; the EAT format
remains the same across all three.  Cross-domain key resolution
is handled through pre-established federation (e.g., shared
JWK set endpoints).

## Internal Microservice Mesh (L1)
{:numbered="false"}

In an internal AI platform, multiple microservices coordinate to
process requests.  All agents operate within a single trust domain
behind a service mesh with mTLS.  Non-repudiation is not required;
the EATs are used for observability and debugging.

~~~
Domain: internal.example
  Agent S1 (Preprocessor):
    jti: task-401    pred:[]
    exec_act: preprocess_input

  Agent S2 (Model Inference):
    jti: task-402    pred:[task-401]
    exec_act: run_inference

  Agent S3 (Postprocessor):
    jti: task-403    pred:[task-402]
    exec_act: format_output
~~~
{: #fig-internal title="Internal Microservice Workflow (L1)"}

# Relationship to WIMSE ECT
{:numbered="false"}

This specification generalizes the Execution Context Token (ECT)
concept originally defined in the context of the WIMSE working
group.  The WIMSE ECT specification focuses on
SPIFFE/WIMSE-based identity; this specification provides the
same core functionality (DAG-based execution audit with three
assurance levels) while being identity-framework agnostic.

Deployments using WIMSE can implement EATs with the following
profile:

- "iss" is the workload's SPIFFE ID
  (e.g., `spiffe://trust-domain/path`)
- "kid" references the WIT public key
- "alg" matches the WIT algorithm
- Revocation is checked via SPIFFE trust bundles
- EATs are transported alongside WIT and WPT per the WIMSE
  service-to-service protocol {{I-D.ietf-wimse-s2s-protocol}}

# Related Work
{:numbered="false"}

## OAuth 2.0 Token Exchange and the "act" Claim
{:numbered="false"}

{{RFC8693}} defines the OAuth 2.0 Token Exchange protocol and
registers the "act" (Actor) claim in the JWT Claims registry.
The "act" claim creates nested JSON objects representing a
delegation chain: "who is acting on behalf of whom."  While
the nesting superficially resembles a chain, it is strictly
linear (each "act" object contains at most one nested "act"),
represents authorization delegation rather than task execution,
and carries no task identifiers or input/output integrity
data.  The "act" chain cannot represent branching (fan-out)
or convergence (fan-in) and therefore cannot form a DAG.

EATs intentionally use the distinct claim name "exec_act" for the
action/task type to avoid collision with the "act" claim.

## Transaction Tokens
{:numbered="false"}

OAuth Transaction Tokens {{I-D.ietf-oauth-transaction-tokens}}
propagate authorization context across workload call chains.
The Txn-Token "req_wl" claim accumulates a comma-separated list
of workloads that requested replacement tokens, which is the
closest existing mechanism to call-chain recording.

However, "req_wl" cannot form a DAG because it is linear, it
is incomplete (only workloads that request replacement tokens
are recorded), and it cannot represent convergence (fan-in).

EATs and Transaction Tokens are complementary: a Txn-Token
propagates authorization context ("this request is authorized
for scope X on behalf of user Y"), while an EAT records
execution accountability ("task T was performed, depending on
tasks P1 and P2").

## Distributed Tracing (OpenTelemetry)
{:numbered="false"}

OpenTelemetry {{OPENTELEMETRY}} and similar distributed tracing
systems provide observability for debugging and monitoring.  EATs
differ in several important ways: at L2 and L3, EATs are
cryptographically signed per-task with the agent's private key;
EATs are tamper-evident through JWS signatures; EATs enforce DAG
validation rules; and EATs are designed for regulatory audit rather
than operational monitoring.  OpenTelemetry data is typically
controlled by the platform operator and can be modified or deleted
without detection.

## SCITT (Supply Chain Integrity, Transparency, and Trust)
{:numbered="false"}

The SCITT architecture {{I-D.ietf-scitt-architecture}} defines a
framework for transparent and auditable supply chain records.
There is a notable parallel between SCITT's Transparency Service
and EAT's Level 3 audit ledger: both use append-only logs with
cryptographic commitment.  The federated ledger model defined in
this specification ({{federated-ledger}}) draws on similar
principles to Certificate Transparency
{{CERTIFICATE-TRANSPARENCY}} and SCITT.

## RATS (Remote Attestation Procedures)
{:numbered="false"}

RATS {{RFC9334}} defines an architecture for conveying attestation
evidence about platform trustworthiness.  RATS attests "is this
platform in a trustworthy state?" while EATs record "what did
this agent do?" — both deal with claims about entities but at
different layers.  EATs could complement RATS by recording
execution context on platforms whose trustworthiness has been
established through RATS attestation.

## Emerging Agent Protocol Frameworks
{:numbered="false"}

Several emerging frameworks address agent-to-agent communication,
including Google's Agent-to-Agent Protocol (A2A), Anthropic's
Model Context Protocol (MCP), and orchestration frameworks such
as LangChain and LangGraph.  These frameworks primarily address
agent discovery, message routing, and tool invocation but do not
provide cryptographically verifiable execution records or
DAG-based audit trails.  EATs complement these frameworks by
adding an execution accountability layer.

# Acknowledgments
{:numbered="false"}

The author thanks the WIMSE working group for their foundational
work on workload identity in multi-system environments, which
provided the original motivation for execution context tracing.
