Execution Context Tokens for Distributed Agentic Workflows

1.1. Motivation

The Workload Identity in Multi System Environments (WIMSE) framework [I-D.ietf-wimse-arch] provides robust workload authentication through Workload Identity Tokens (WIT) and Workload Proof Tokens (WPT). The WIMSE service-to-service protocol [I-D.ietf-wimse-s2s-protocol] defines how workloads authenticate each other across call chains using the Workload-Identity and Workload-Proof-Token HTTP headers.¶

However, workload identity alone does not address execution accountability. Knowing who performed an action does not record what was done, what policy was applied, or whether compliance requirements were evaluated at each decision point.¶

Regulated environments increasingly deploy autonomous agents that coordinate across organizational boundaries. Multiple regulatory frameworks — including [EU-AI-ACT], [FDA-21CFR11], [MIFID-II], and [DORA] — require structured, auditable records of automated decision-making and execution (see Table 3 for a detailed mapping).¶

This document defines an extension to the WIMSE architecture that addresses the gap between workload identity and execution accountability. WIMSE authenticates agents; this extension records what they did, in what order, and what policy was evaluated.¶

As identified in [I-D.ni-wimse-ai-agent-identity], call context in agentic workflows needs to be visible and preserved. ECTs provide a mechanism to address this requirement with cryptographic assurances.¶

1.2. Problem Statement

Three core gaps exist in current approaches to regulated agentic systems:¶

1. WIMSE authenticates agents but does not record what they actually did. A WIT proves "Agent A is authorized" but not "Agent A executed Task X, under Policy Y, producing Output Z."¶

2. No standard mechanism exists to record policy evaluation outcomes at each decision point in a multi-agent workflow.¶

3. No mechanism exists to cryptographically link compensation and rollback decisions to original actions.¶

Existing observability tools such as distributed tracing [OPENTELEMETRY] provide visibility for debugging and monitoring but do not provide cryptographic assurances. Tracing data is not cryptographically signed, not tamper-evident, and not designed for regulatory audit scenarios.¶

1.3. Scope and Applicability

This document defines:¶

• The Execution Context Token (ECT) format (Section 4)¶

• DAG structure for task dependency ordering (Section 6)¶

• Policy checkpoint recording via extension keys (Section 4.2.3)¶

• Integration with the WIMSE identity framework (Section 3)¶

• An HTTP header for ECT transport (Section 5)¶

• Audit ledger interface requirements (Section 8)¶

The following are out of scope and are handled by WIMSE:¶

• Workload authentication and identity provisioning¶

• Key distribution and management¶

• Trust domain establishment and management¶

• Credential lifecycle management¶

1.4. Relationship to Regulatory Compliance

ECTs are a technical mechanism that can support compliance programs by providing structured, cryptographically signed execution records. ECTs do not by themselves constitute compliance with any regulatory framework referenced in this document.¶

Compliance with each referenced regulation requires organizational controls, policies, procedures, validation, and governance measures beyond the scope of this specification. The regulatory references in this document are intended to motivate the design requirements, not to claim that implementing ECTs satisfies these regulations.¶

ECTs provide evidence of claimed execution ordering and policy evaluation. They do not independently verify that the claimed execution actually occurred as described, that the policy evaluation was correct, or that the agent faithfully performed the stated action. The trustworthiness of ECT claims depends on the trustworthiness of the signing agent and the integrity of the broader deployment environment.¶

3.1. WIMSE Foundation

The WIMSE architecture [I-D.ietf-wimse-arch] defines:¶

• Workload Identity Tokens (WIT) that prove a workload's identity within a trust domain ("I am Agent X in trust domain Y")¶

• Workload Proof Tokens (WPT) that prove possession of the private key associated with a WIT ("I control the key for Agent X")¶

• Multi-hop authentication via the service-to-service protocol [I-D.ietf-wimse-s2s-protocol]¶

The following execution accountability needs are complementary to the WIMSE scope and are not addressed by workload identity alone:¶

• Recording what agents actually do with their authenticated identity¶

• Recording policy evaluation outcomes at each hop¶

• Maintaining structured execution records¶

• Linking compensation or rollback actions to original tasks¶

3.2. Extension Model

ECTs extend WIMSE by adding an execution accountability layer between the identity layer and the application layer:¶

+--------------------------------------------------+
|  WIMSE Layer (Identity)                          |
|    WIT: "I am Agent X (spiffe://td/agent/x)"    |
|    WPT: "I prove I control the key for Agent X"  |
+--------------------------------------------------+
                       |
                       v
+--------------------------------------------------+
|  ECT Layer (Execution Accountability) [This Spec]|
|    ECT: "Task executed, dependencies met,        |
|          policy evaluated, outcome recorded"      |
+--------------------------------------------------+
                       |
                       v
+--------------------------------------------------+
|  Optional: Audit Ledger (Immutable Record)       |
|    "ECTs MAY be appended to an audit ledger"     |
+--------------------------------------------------+

This extension reuses the WIMSE signing model, extends JWT claims using standard JWT extensibility [RFC7519], and maintains WIMSE concepts including trust domains and workload identifiers.¶

3.3. Integration Points

An ECT integrates with the WIMSE identity framework through the following mechanisms:¶

• The ECT JOSE header "kid" parameter MUST reference the public key identifier from the agent's WIT.¶

• In WIMSE deployments, the ECT "iss" claim SHOULD use the WIMSE workload identifier format (a SPIFFE ID [SPIFFE]).¶

• The ECT MUST be signed with the same private key associated with the agent's WIT.¶

• The ECT signing algorithm (JOSE header "alg" parameter) MUST match the algorithm used in the corresponding WIT.¶

When an agent makes an HTTP request to another agent, the Execution-Context header is carried alongside WIMSE identity headers:¶

HTTP Request from Agent A to Agent B:
  Workload-Identity:    <WIT for Agent A>
  Execution-Context:    <ECT recording what A did>

When a Workload Proof Token (WPT) is available per [I-D.ietf-wimse-s2s-protocol], agents SHOULD include it alongside the WIT and ECT. ECT verification does not depend on the presence of a WPT; the ECT is independently verifiable via the WIT public key.¶

The receiving agent (Agent B) verifies in order:¶

1. WIT (WIMSE layer): Verifies Agent A's identity within the trust domain. WPT verification, if present, per [I-D.ietf-wimse-s2s-protocol].¶

2. ECT (this extension): Records what Agent A did, what policy was evaluated, and what precedent tasks exist.¶

3. Ledger (if deployed): Appends the verified ECT to the audit ledger.¶

4.1. JOSE Header

The ECT JOSE header MUST contain the following parameters:¶

{
  "alg": "ES256",
  "typ": "wimse-exec+jwt",
  "kid": "agent-a-key-id-123"
}

alg:

REQUIRED. The digital signature algorithm used to sign the ECT. MUST match the algorithm in the corresponding WIT. Implementations MUST support ES256 [RFC7518]. The "alg" value MUST NOT be "none". Symmetric algorithms (e.g., HS256, HS384, HS512) MUST NOT be used, as ECTs require asymmetric signatures for non-repudiation.¶

typ:

REQUIRED. MUST be set to "wimse-exec+jwt" to distinguish ECTs from other JWT types, consistent with the WIMSE convention for type parameter values.¶

kid:

REQUIRED. The key identifier referencing the public key from the agent's WIT [RFC7517]. Used by verifiers to look up the correct public key for signature verification.¶

4.2. JWT Claims

The ECT payload contains both WIMSE-compatible standard JWT claims and execution context claims defined by this specification.¶

4.3. Complete ECT Example

The following is a complete ECT payload example:¶

{
  "iss": "spiffe://example.com/agent/clinical",
  "aud": "spiffe://example.com/agent/safety",
  "iat": 1772064150,
  "exp": 1772064750,
  "jti": "550e8400-e29b-41d4-a716-446655440001",

  "wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
  "exec_act": "recommend_treatment",
  "par": [],

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

  "ext": {
    "pol": "clinical_reasoning_policy_v2",
    "pol_decision": "approved",
    "pol_enforcer": "spiffe://example.com/policy/clinical-engine",
    "pol_timestamp": 1772064145,
    "exec_time_ms": 245,
    "regulated_domain": "medtech",
    "model_version": "clinical-reasoning-v4.2"
  }
}

5.1. Execution-Context Header Field

This specification defines the Execution-Context HTTP header field [RFC9110] for transporting ECTs between agents.¶

The header field value is the ECT 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 the WIMSE Workload-Identity header:¶

GET /api/safety-check HTTP/1.1
Host: safety-agent.example.com
Workload-Identity: eyJhbGci...WIT...
Execution-Context: eyJhbGci...ECT...

When multiple parent tasks contribute context to a single request, multiple Execution-Context header field lines MAY be included, each carrying a separate ECT in JWS Compact Serialization format.¶

When a receiver processes multiple Execution-Context headers, it MUST individually verify each ECT per the procedure in Section 7. If any single ECT fails verification, the receiver MUST reject the entire request. The set of verified parent task IDs across all received ECTs represents the complete set of parent dependencies available for the receiving agent's subsequent ECT.¶

6.1. Overview

ECTs form a Directed Acyclic Graph (DAG) where each task references its parent tasks via the "par" claim. This structure provides a cryptographically signed record of execution ordering, enabling auditors to reconstruct the complete workflow and verify that required predecessor tasks were recorded before dependent tasks.¶

DAG validation is performed against the ECT store — either an audit ledger or the set of parent ECTs received inline.¶

6.2. Validation Rules

When receiving and verifying an ECT, 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 ECT store if "wid" is absent). If an ECT with the same "jti" already exists, the ECT MUST be rejected.¶

2. Parent Existence: Every task identifier listed in the "par" array MUST correspond to a task that is available in the ECT store (either previously recorded in the ledger or received inline as a verified parent ECT). If any parent task is not found, the ECT 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 ECT store), not by timestamps. If any parent task violates this constraint, the ECT MUST be rejected.¶

4. Acyclicity: Following the chain of parent references MUST NOT lead back to the current ECT's "jti". If a cycle is detected, the ECT MUST be rejected.¶

5. Parent Policy Decision: If any parent ECT's "ext" object contains a "pol_decision" of "rejected" or "pending_human_review", the current ECT's "exec_act" MUST indicate a compensation, rollback, remediation, or human review action. Implementations MUST NOT accept an ECT representing normal workflow continuation when a parent's "pol_decision" is not "approved". This rule only applies when the parent ECT's "ext" contains policy keys.¶

6. Trust Domain Consistency: Parent tasks SHOULD belong to the same trust domain or to a trust domain with which a federation relationship has been established.¶

6.3. DAG Validation Algorithm

The following pseudocode describes the DAG validation procedure:¶

function validate_dag(ect, ect_store, clock_skew_tolerance):
  // Step 1: Uniqueness check
  if ect_store.contains(ect.jti, ect.wid):
    return error("ECT ID already exists")

  // Step 2: Parent existence and temporal ordering
  for parent_id in ect.par:
    parent = ect_store.get(parent_id)
    if parent is null:
      return error("Parent task not found: " + parent_id)
    if parent.iat >= ect.iat + clock_skew_tolerance:
      return error("Parent task not earlier than current")

  // Step 3: Cycle detection (with traversal limit)
  visited = set()
  result = has_cycle(ect.jti, ect.par, ect_store, visited,
                      max_ancestor_limit)
  if result is error or result is true:
    return error("Circular dependency or depth limit exceeded")

  return success

function has_cycle(target_jti, parent_ids, ect_store,
                   visited, max_depth):
  if visited.size() >= max_depth:
    return error("Maximum ancestor traversal limit exceeded")
  for parent_id in parent_ids:
    if parent_id == target_jti:
      return true
    if parent_id in visited:
      continue
    visited.add(parent_id)
    parent = ect_store.get(parent_id)
    if parent is not null:
      result = has_cycle(target_jti, parent.par, ect_store,
                          visited, max_depth)
      if result is error or result is true:
        return result
  return false

The cycle detection traverses the ancestor graph rooted at the current task's parents. The complexity is O(V) where V is the number of ancestor nodes reachable from the current task's parent references. For typical workflows with shallow DAGs, this is efficient. 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 ECT SHOULD be rejected. Implementations SHOULD cache cycle detection results for previously verified tasks to avoid redundant traversals.¶

7.1. Verification Procedure

When an agent receives an ECT, 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 "wimse-exec+jwt".¶

3. Verify that the "alg" header parameter is not "none" and is not a symmetric algorithm.¶

4. Verify the "kid" header parameter references a known, valid public key from a WIT within the trust domain.¶

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 trust domain's key lifecycle mechanism (e.g., certificate revocation list, OCSP, or SPIFFE trust bundle updates).¶

7. Verify the "alg" header parameter matches the algorithm in the corresponding WIT.¶

8. Verify the "iss" claim matches the "sub" claim of the WIT associated with the "kid" public key.¶

9. Verify the "aud" claim contains the verifier's own workload 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 ECT 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", "par") are present and well-formed.¶

13. If "ext" is present and contains "pol" or "pol_decision", verify that both are present and that "pol_decision" is one of "approved", "rejected", or "pending_human_review".¶

14. Perform DAG validation per Section 6.¶

15. If all checks pass and an audit ledger is deployed, the ECT SHOULD be appended to the ledger.¶

If any verification step fails, the ECT 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 ECT store, to prevent information disclosure.¶

When ECT verification fails during HTTP request processing, the receiving agent SHOULD respond with HTTP 403 (Forbidden) if the WIT is valid but the ECT is invalid, and HTTP 401 (Unauthorized) if the ECT signature verification fails. 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 ECT verification fails.¶

7.2. Verification Pseudocode

function verify_ect(ect_jws, verifier_id,
                     trust_domain_keys, ect_store):
  // Parse JWS
  (header, payload, signature) = parse_jws(ect_jws)

  // Verify header
  if header.typ != "wimse-exec+jwt":
    return reject("Invalid typ parameter")

  if header.alg == "none" or is_symmetric(header.alg):
    return reject("Prohibited algorithm")

  // Look up public key
  public_key = trust_domain_keys.get(header.kid)
  if public_key is null:
    return reject("Unknown key identifier")

  // Verify signature
  if not verify_jws_signature(header, payload,
                               signature, public_key):
    return reject("Invalid signature")

  // Verify key not revoked
  if is_key_revoked(header.kid, trust_domain_keys):
    return reject("Signing key has been revoked")

  // Verify algorithm alignment
  wit = get_wit_for_key(header.kid)
  if header.alg != wit.alg:
    return reject("Algorithm mismatch with WIT")

  // Verify issuer matches WIT subject
  if payload.iss != wit.sub:
    return reject("Issuer does not match WIT subject")

  // Verify audience
  if verifier_id not in payload.aud:
    return reject("ECT not intended for this recipient")

  // Verify not expired
  if payload.exp < current_time():
    return reject("ECT has expired")

  // Verify iat freshness (not too old, not in the future)
  if payload.iat < current_time() - max_age_threshold:
    return reject("ECT issued too long ago")
  if payload.iat > current_time() + clock_skew_tolerance:
    return reject("ECT issued in the future")

  // Verify required claims
  for claim in ["jti", "exec_act", "par"]:
    if claim not in payload:
      return reject("Missing required claim: " + claim)

  // Validate policy extension keys (optional, but must be paired)
  ext = payload.ext or {}
  if "pol" in ext or "pol_decision" in ext:
    if "pol" not in ext or "pol_decision" not in ext:
      return reject("pol and pol_decision must both be present")
    if ext.pol_decision not in
       ["approved", "rejected", "pending_human_review"]:
      return reject("Invalid pol_decision value")

  // Validate DAG (against ECT store or inline parent ECTs)
  result = validate_dag(payload, ect_store,
                         clock_skew_tolerance)
  if result is error:
    return reject("DAG validation failed")

  // All checks passed; record if store is available
  if ect_store is not null:
    ect_store.append(payload)
  return accept

9.1. Medical Device SDLC Workflow

In a medical device software development lifecycle (SDLC), AI agents assist across multiple phases from requirements analysis through release approval. Regulatory frameworks including [FDA-21CFR11] Section 11.10(e) and [EU-MDR] require audit trails documenting the complete development process for software used in medical devices.¶

Agent A (Spec Reviewer):
  jti: task-001    par: []
  exec_act: review_requirements_spec
  ext.pol: spec_review_policy_v2
  ext.pol_decision: approved

Agent B (Code Generator):
  jti: task-002    par: [task-001]
  exec_act: implement_module
  ext.pol: coding_standards_v3
  ext.pol_decision: approved

Agent C (Test Agent):
  jti: task-003    par: [task-002]
  exec_act: execute_test_suite
  ext.pol: test_coverage_policy_v1
  ext.pol_decision: approved

Agent D (Build Agent):
  jti: task-004    par: [task-003]
  exec_act: build_release_artifact
  ext.pol: build_validation_v2
  ext.pol_decision: approved

Human Release Manager:
  jti: task-005    par: [task-004]
  exec_act: approve_release
  ext.pol: release_approval_policy
  ext.pol_decision: approved
  ext.pol_enforcer: spiffe://meddev.example/human/release-mgr-42
  ext.witnessed_by: [...]

ECTs record that requirements were reviewed before implementation began, that tests were executed against the implemented code, that the build artifact was validated, and that a human release manager explicitly approved the release. The DAG structure ensures no phase was skipped or reordered.¶

task-001 (review_requirements_spec)
  |
  v
task-002 (implement_module)
  |
  v
task-003 (execute_test_suite)
  |
  v
task-004 (build_release_artifact)
  |
  v
task-005 (approve_release) [human, witnessed]

9.2. Financial Trading Workflow

In a financial trading workflow, agents perform risk assessment, compliance verification, and trade execution. The DAG structure records that compliance checks were evaluated before trade execution.¶

Agent A (Risk Assessment):
  jti: task-001    par: []
  exec_act: calculate_risk_exposure
  ext.pol: risk_limits_policy_v2
  ext.pol_decision: approved

Agent B (Compliance):
  jti: task-002    par: [task-001]
  exec_act: verify_compliance
  ext.pol: compliance_check_v1
  ext.pol_decision: approved

Agent C (Execution):
  jti: task-003    par: [task-002]
  exec_act: execute_trade
  ext.pol: execution_policy_v3
  ext.pol_decision: approved

This can contribute to compliance with:¶

• [MIFID-II]: ECTs provide cryptographic records of the execution sequence that can support transaction audit requirements.¶

• [DORA] Article 12: ECTs contribute to ICT activity logging.¶

• [EU-AI-ACT] Article 12: Logging of decisions made by AI-driven systems.¶

9.3. Compensation and Rollback

When a compliance violation is discovered after execution, ECTs provide a mechanism to record authorized compensation actions with a cryptographic link to the original task:¶

{
  "iss": "spiffe://bank.example/agent/operations",
  "aud": "spiffe://bank.example/system/ledger",
  "iat": 1772150550,
  "exp": 1772151150,
  "jti": "550e8400-e29b-41d4-a716-446655440099",
  "wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
  "exec_act": "initiate_trade_rollback",
  "par": ["550e8400-e29b-41d4-a716-446655440003"],
  "ext": {
    "pol": "compensation_policy_v1",
    "pol_decision": "approved",
    "pol_enforcer": "spiffe://bank.example/human/compliance-officer",
    "compensation_required": true,
    "compensation_reason": "policy_violation_in_parent_trade"
  }
}

The "par" claim links the compensation action to the original trade, creating an auditable chain from execution through violation discovery to remediation.¶

9.4. Autonomous Logistics Coordination

In a logistics workflow, multiple compliance checks complete before shipment commitment. The DAG structure records that all required checks were completed:¶

Agent A (Route Planning):
  jti: task-001    par: []
  exec_act: plan_route
  ext.pol: route_policy_v1
  ext.pol_decision: approved

Agent B (Customs):
  jti: task-002    par: [task-001]
  exec_act: validate_customs
  ext.pol: customs_policy_v2
  ext.pol_decision: approved

Agent C (Safety):
  jti: task-003    par: [task-001]
  exec_act: verify_cargo_safety
  ext.pol: safety_policy_v1
  ext.pol_decision: approved

Agent D (Payment):
  jti: task-004    par: [task-002, task-003]
  exec_act: authorize_payment
  ext.pol: payment_policy_v3
  ext.pol_decision: approved

System (Commitment):
  jti: task-005    par: [task-004]
  exec_act: commit_shipment
  ext.pol: commitment_policy_v1
  ext.pol_decision: approved

Note that tasks 002 and 003 both depend only on task-001 and can execute in parallel. Task 004 depends on both, demonstrating the DAG's ability to represent parallel execution with a join point.¶

10.1. Threat Model

The following threat actors are considered:¶

• Malicious agent (insider threat): An agent within the trust domain that intentionally creates false ECT claims.¶

• Compromised agent (external attacker): An agent whose private key has been obtained by an external attacker.¶

• Ledger tamperer: An entity attempting to modify or delete ledger entries after they have been recorded.¶

• Time manipulator: An entity attempting to manipulate timestamps to alter perceived execution ordering.¶

10.2. Self-Assertion Limitation

ECTs are self-asserted by the executing agent. The agent claims what it did, and this claim is signed with its private key. A compromised or malicious agent could create ECTs with false claims (e.g., setting "pol_decision" in "ext" to "approved" without actually evaluating the policy).¶

ECTs do not independently verify that:¶

• The claimed execution actually occurred as described¶

• The policy evaluation was correctly performed¶

• The input/output hashes correspond to the actual data processed¶

• The agent faithfully performed the stated action¶

The trustworthiness of ECT claims depends on the trustworthiness of the signing agent. To mitigate single-agent false claims, regulated environments SHOULD use the "witnessed_by" extension key (carried in "ext") to include independent third-party observers at critical decision points. However, this value is self-asserted by the ECT issuer: the listed witnesses do not co-sign the ECT and there is no cryptographic evidence within a single ECT that the witnesses actually observed the task. An issuing agent could list witnesses that did not participate.¶

To strengthen witness attestation beyond self-assertion, witnesses SHOULD submit their own independent signed ECTs referencing the observed task's "jti" in the "par" array. Auditors can then cross-check the "witnessed_by" extension against independent witness ECTs in the ECT store.¶

10.3. Organizational Prerequisites

ECTs operate within a broader trust framework. The guarantees provided by ECTs are only meaningful when the following organizational controls are in place:¶

• Key management governance: Controls over who provisions agent keys and how keys are protected.¶

• Ledger integrity governance: The ledger is maintained by an entity independent of the workflow agents.¶

• Policy lifecycle management: Policy identifiers in ECTs map to actual, validated policy rules.¶

• Agent deployment governance: Agents are deployed and maintained in a manner that preserves their integrity.¶

10.4. Signature Verification

ECTs MUST be signed with the agent's private key using JWS [RFC7515]. The signature algorithm MUST match the algorithm specified in the agent's WIT. Receivers MUST verify the ECT signature against the WIT 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 Section 7).¶

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

Implementations MUST use established JWS libraries and MUST NOT implement custom signature verification.¶

10.5. Replay Attack Prevention

ECTs include short expiration times (RECOMMENDED: 5-15 minutes) to limit the window for replay attacks. The "aud" claim restricts replay to unintended recipients: an ECT intended for Agent B will be rejected by Agent C. The "iat" claim enables receivers to reject ECTs that are too old, even if not yet expired.¶

The DAG structure provides additional replay protection: an ECT referencing parent tasks that already have a recorded child task with the same action can be flagged as a potential replay.¶

Implementations MUST maintain a cache of recently-seen "jti" values to detect replayed ECTs within the expiration window. An ECT with a duplicate "jti" value MUST be rejected.¶

10.6. Man-in-the-Middle Protection

ECTs do not replace transport-layer security. ECTs MUST be transmitted over TLS or mTLS connections. When used with the WIMSE service-to-service protocol [I-D.ietf-wimse-s2s-protocol], transport security is already established. HTTP Message Signatures [RFC9421] provide an alternative channel binding mechanism.¶

The defense-in-depth model provides:¶

• TLS/mTLS (transport layer): Prevents network-level tampering.¶

• WIT/WPT (WIMSE identity layer): Proves agent identity and request authorization.¶

• ECT (execution accountability layer): Records what the agent did and under what policy.¶

10.7. Key Compromise

If an agent's private key is compromised, an attacker can forge ECTs that appear to originate from that agent. To mitigate this risk:¶

• Implementations SHOULD use short-lived keys and rotate them frequently (hours to days, not months).¶

• Private keys SHOULD be stored in Hardware Security Modules (HSMs) or equivalent secure key storage.¶

• Trust domains MUST support rapid key revocation.¶

• Upon suspected compromise, the trust domain MUST revoke the compromised key and issue a new WIT with a fresh key pair.¶

ECTs signed with a compromised key that were recorded in the ledger before revocation remain valid historical records but SHOULD be flagged in the ledger as "signed with subsequently revoked key" for audit purposes.¶

10.8. Collusion and False Claims

A single malicious agent cannot forge parent task references because DAG validation requires parent tasks to exist in the ledger. However, multiple colluding agents could potentially create a false execution history if they control the ledger.¶

Mitigations include:¶

• Independent ledger maintenance: The ledger SHOULD be maintained by an entity independent of the workflow agents.¶

• Witness attestation: Using the "witnessed_by" extension key in "ext" to include independent third-party observers.¶

• Cross-verification: Multiple independent ledger replicas can be compared for consistency.¶

• Out-of-band audit: External auditors periodically verify ledger contents against expected workflow patterns.¶

10.9. Denial of Service

ECT signature verification is computationally inexpensive (approximately 1ms per ECT on modern hardware for ES256). DAG validation complexity is O(V) where V is the number of ancestor nodes reachable from the parent references; for typical shallow DAGs this is efficient.¶

Implementations SHOULD apply rate limiting at the API layer to prevent excessive ECT submissions. DAG validation SHOULD be performed after signature verification to avoid wasting resources on unsigned or incorrectly signed tokens.¶

10.10. Timestamp Accuracy

ECTs rely on timestamps ("iat", "exp") for temporal ordering. Clock skew between agents can lead to incorrect ordering judgments. Implementations SHOULD use synchronized time sources (e.g., NTP) and SHOULD allow a configurable clock skew tolerance (RECOMMENDED: 30 seconds).¶

Cross-organizational deployments where agents span multiple trust domains with independent time sources MAY require a higher clock skew tolerance. Deployments using trust domain federation SHOULD document their configured clock skew tolerance value and SHOULD ensure all participating trust domains agree on a common tolerance.¶

The temporal ordering check in DAG validation incorporates the clock skew tolerance to account for minor clock differences between agents.¶

10.11. ECT Size Constraints

ECTs with many parent tasks or large extension objects can increase HTTP header size. Implementations SHOULD limit the "par" array to a maximum of 256 entries. Workflows requiring more parent references SHOULD introduce intermediate aggregation tasks. The "ext" object SHOULD NOT exceed 4096 bytes when serialized as JSON and SHOULD NOT exceed a nesting depth of 5 levels (see also Section 4.2.6).¶

11.1. Data Exposure in ECTs

ECTs necessarily reveal:¶

• Agent identities ("iss", "aud") for accountability purposes¶

• Action descriptions ("exec_act") for audit trail completeness¶

• Policy evaluation outcomes (via "ext" keys "pol", "pol_decision") when present, for compliance verification¶

• Timestamps ("iat", "exp") for temporal ordering¶

ECTs 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)¶

11.2. Data Minimization

Implementations SHOULD minimize the information included in ECTs. The "exec_act" claim SHOULD use structured identifiers (e.g., "process_payment") rather than natural language descriptions. The "pol" extension key SHOULD reference policy identifiers rather than embedding policy content.¶

The "compensation_reason" extension key in "ext" (Section 4.2.5) deserves particular attention: because it is human-readable, it risks exposing sensitive operational details. See Section 4.2.6 for guidance on using structured identifiers.¶

11.3. Storage and Access Control

ECTs stored in audit ledgers SHOULD be access-controlled so that only authorized auditors and regulators can read them. Implementations SHOULD consider encryption at rest for ledger storage containing sensitive regulatory data.¶

Full input and output data (corresponding to the hashes in ECTs) 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.¶

11.4. Regulatory Access

ECTs are designed for interpretation by qualified human auditors and regulators. ECTs provide structural records of execution ordering and policy evaluation; they are not intended for public disclosure.¶

12.1. Media Type Registration

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

Type name:

application¶

Subtype name:

wimse-exec+jwt¶

Required parameters:

none¶

Optional parameters:

none¶

Encoding considerations:

8bit; an ECT is a JWT that is a JWS using the Compact Serialization, which is a sequence of Base64url-encoded values separated by period characters.¶

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 regulated agentic workflows requiring execution context tracing and 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¶

12.2. HTTP Header Field 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, Section 5¶

12.3. JWT Claims Registration

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

Note: Policy evaluation keys ("pol", "pol_decision", "pol_enforcer") are carried within the "ext" object as spec-defined extension keys (Section 4.2.3) and do not require separate JWT Claims registration.¶

12.4. ECT Policy Decision Values Registry

This document establishes the "ECT Policy Decision Values" registry under the "JSON Web Token (JWT)" group. Registration policy is Specification Required per [RFC8126].¶

The initial contents of the registry are:¶

13.1. Normative References

[I-D.ietf-wimse-arch]

Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft-ietf-wimse-arch-06, 30 September 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-06>.

[I-D.ietf-wimse-s2s-protocol]

Campbell, B., Salowey, J. A., Schwenkschuster, A., and Y. Sheffer, "WIMSE Workload-to-Workload Authentication", Work in Progress, Internet-Draft, draft-ietf-wimse-s2s-protocol-07, 16 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-s2s-protocol-07>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC7517]

Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/rfc/rfc7517>.

[RFC7518]

Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/rfc/rfc7518>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9562]

Davis, K., Peabody, B., and P. Leach, "Universally Unique IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May 2024, <https://www.rfc-editor.org/rfc/rfc9562>.

13.2. Informative References

[DORA]

European Parliament and Council of the European Union, "Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)", 14 December 2022, <https://eur-lex.europa.eu/eli/reg/2022/2554>.

[EU-AI-ACT]

European Parliament and Council of the European Union, "Regulation (EU) 2024/1689 of the European Parliament and of the Council laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)", 13 June 2024, <https://eur-lex.europa.eu/eli/reg/2024/1689>.

[EU-MDR]

European Parliament and Council of the European Union, "Regulation (EU) 2017/745 on medical devices (MDR)", 5 April 2017, <https://eur-lex.europa.eu/eli/reg/2017/745>.

[FDA-21CFR11]

U.S. Food and Drug Administration, "Title 21, Code of Federal Regulations, Part 11: Electronic Records; Electronic Signatures", <https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11>.

[I-D.ietf-oauth-transaction-tokens]

Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-07, 24 January 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-07>.

[I-D.ietf-scitt-architecture]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", Work in Progress, Internet-Draft, draft-ietf-scitt-architecture-22, 10 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-22>.

[I-D.ni-wimse-ai-agent-identity]

Yuan, N. and P. C. Liu, "WIMSE Applicability for AI Agents", Work in Progress, Internet-Draft, draft-ni-wimse-ai-agent-identity-01, 20 October 2025, <https://datatracker.ietf.org/doc/html/draft-ni-wimse-ai-agent-identity-01>.

[I-D.oauth-transaction-tokens-for-agents]

Raut, A., "Transaction Tokens For Agents", Work in Progress, Internet-Draft, draft-oauth-transaction-tokens-for-agents-04, 10 February 2026, <https://datatracker.ietf.org/doc/html/draft-oauth-transaction-tokens-for-agents-04>.

[MIFID-II]

European Parliament and Council of the European Union, "Directive 2014/65/EU of the European Parliament and of the Council on markets in financial instruments (MiFID II)", 15 May 2014, <https://eur-lex.europa.eu/eli/dir/2014/65>.

[OPENTELEMETRY]

Cloud Native Computing Foundation, "OpenTelemetry Specification", <https://opentelemetry.io/docs/specs/otel/>.

[RFC3552]

Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/rfc/rfc3552>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC9421]

Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

[SPIFFE]

"Secure Production Identity Framework for Everyone (SPIFFE)", <https://spiffe.io/docs/latest/spiffe-about/overview/>.

WIMSE Workload Identity

The WIMSE architecture [I-D.ietf-wimse-arch] and service-to- service protocol [I-D.ietf-wimse-s2s-protocol] provide the identity foundation upon which ECTs are built. WIT/WPT answer "who is this agent?" and "does it control the claimed key?" while ECTs record "what did this agent do?" and "what policy was evaluated?" Together they form an identity-plus-accountability framework for regulated agentic systems.¶

OAuth 2.0 Token Exchange and the "act" Claim

[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, policy decisions, or input/output integrity data. The "act" chain cannot represent branching (fan-out) or convergence (fan-in) and therefore cannot form a DAG.¶

ECTs intentionally use the distinct claim name "exec_act" for the action/task type to avoid collision with the "act" claim. The two concepts are orthogonal: "act" records "who authorized whom," ECTs record "what was done, in what order, with what policy outcomes."¶

Transaction Tokens

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: a comma-separated string with no branching or merging representation. When a workload fans out to multiple downstream services, each receives the same "req_wl" value and the branching is invisible.¶

• It is incomplete: only workloads that request a replacement token from the Transaction Token Service appear in "req_wl"; workloads that forward the token unchanged are not recorded.¶

• It carries no task-level granularity, no parent references, no policy evaluation outcomes, and no execution content.¶

Extensions for agentic use cases ([I-D.oauth-transaction-tokens-for-agents]) add agent identity and constraints ("agentic_ctx") but no execution ordering or DAG structure.¶

ECTs 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 ECT records execution accountability ("task T was performed, depending on tasks P1 and P2, with policy Z evaluated and approved"). An agent request could carry both a Txn-Token for authorization and an ECT for execution recording. The WPT "tth" claim defined in [I-D.ietf-wimse-s2s-protocol] can hash-bind a WPT to a co-present Txn-Token; a similar binding mechanism for ECTs is a potential future extension.¶

Distributed Tracing (OpenTelemetry)

OpenTelemetry [OPENTELEMETRY] and similar distributed tracing systems provide observability for debugging and monitoring. ECTs differ in several important ways: ECTs are cryptographically signed per-task with the agent's private key; ECTs are tamper-evident through JWS signatures; ECTs enforce DAG validation rules; and ECTs 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. ECTs and distributed traces are complementary: traces provide observability while ECTs provide signed execution records. ECTs may reference OpenTelemetry trace identifiers in the "ext" claim for correlation.¶

Blockchain and Distributed Ledgers

Both ECTs and blockchain systems provide immutable records. This specification intentionally defines only the ECT token format and is agnostic to the storage mechanism. ECTs can be stored in append-only logs, databases with cryptographic commitments, blockchain networks, or any storage providing the required properties defined in Section 8.¶

SCITT (Supply Chain Integrity, Transparency, and Trust)

The SCITT architecture [I-D.ietf-scitt-architecture] defines a framework for creating transparent and auditable supply chain records through Transparency Services, Signed Statements, and Receipts. ECTs and SCITT are naturally complementary: the ECT "wid" (Workflow Identifier) claim can serve as a correlation identifier referenced in SCITT Signed Statements, linking a complete ECT audit trail to a supply chain transparency record. For example, in a regulated manufacturing workflow, each agent step produces an ECT (recording what was done, by whom, under what policy), while the overall workflow identified by "wid" is registered as a SCITT Signed Statement on a Transparency Service. This enables auditors to verify both the individual execution steps (via ECT DAG validation) and the end-to-end supply chain integrity (via SCITT Receipts) using the "wid" as the shared correlation point. The "ext" claim in ECTs (Section 4.2.2) can carry SCITT-specific metadata such as Transparency Service identifiers or Receipt references for tighter integration.¶

W3C Verifiable Credentials

W3C Verifiable Credentials represent claims about subjects (e.g., identity, qualifications). ECTs represent execution records of actions (what happened, in what order, under what policy). While both use JWT/JWS as a serialization format, their semantics and use cases are distinct.¶

Minimal Implementation

A minimal conforming implementation needs to:¶

1. Create JWTs with all required claims ("iss", "aud", "iat", "exp", "jti", "exec_act", "par") and policy extension keys ("ext.pol", "ext.pol_decision") when policy evaluation was performed.¶

2. Sign ECTs with the agent's private key using an algorithm matching the WIT (ES256 recommended).¶

3. Verify ECT signatures against WIT public keys.¶

4. Perform DAG validation (parent existence, temporal ordering, cycle detection).¶

5. If an audit ledger is deployed, append verified ECTs to it.¶

Storage Recommendations

• Append-only log: Simplest approach; immutability by design.¶

• Database with hash chains: Periodic cryptographic commitments over batches of entries.¶

• Distributed ledger: Maximum immutability guarantees for cross-organizational audit.¶

• Hybrid: Hot storage in a database, cold archive in immutable storage.¶

Performance Considerations

• ES256 signature verification: approximately 1ms per ECT on modern hardware.¶

• DAG validation: O(V) where V is the number of reachable ancestor nodes (typically small for shallow workflows).¶

• JSON serialization: sub-millisecond per ECT.¶

• Total per-request overhead: approximately 5-10ms, acceptable for regulated workflows where correctness is prioritized over latency.¶

Interoperability

Implementations are expected to use established JWT/JWS libraries (JOSE) for token creation and verification. Custom cryptographic implementations are strongly discouraged. Implementations are expected to be tested against multiple JWT libraries to ensure interoperability.¶

Example 1: Simple Two-Agent Workflow

Agent A executes a data retrieval task and sends the ECT to Agent B:¶

ECT JOSE Header:¶

{
  "alg": "ES256",
  "typ": "wimse-exec+jwt",
  "kid": "agent-a-key-2026-02"
}

ECT Payload:¶

{
  "iss": "spiffe://example.com/agent/data-retrieval",
  "aud": "spiffe://example.com/agent/validator",
  "iat": 1772064150,
  "exp": 1772064750,
  "jti": "550e8400-e29b-41d4-a716-446655440001",
  "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
  "exec_act": "fetch_patient_data",
  "par": [],
  "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
  "ext": {
    "pol": "clinical_data_access_policy_v1",
    "pol_decision": "approved"
  }
}

Agent B receives the ECT, verifies it, executes a validation task, and creates its own ECT:¶

{
  "iss": "spiffe://example.com/agent/validator",
  "aud": "spiffe://example.com/system/ledger",
  "iat": 1772064160,
  "exp": 1772064760,
  "jti": "550e8400-e29b-41d4-a716-446655440002",
  "wid": "b1c2d3e4-f5a6-7890-bcde-f01234567890",
  "exec_act": "validate_safety",
  "par": ["550e8400-e29b-41d4-a716-446655440001"],
  "ext": {
    "pol": "safety_validation_policy_v2",
    "pol_decision": "approved"
  }
}

The resulting DAG:¶

task-...-0001 (fetch_patient_data)
  |
  v
task-...-0002 (validate_safety)

Example 2: Medical Device SDLC with Release Approval

A multi-step medical device software lifecycle workflow with autonomous agents and human release approval:¶

Task 1 (Spec Review Agent):¶

{
  "iss": "spiffe://meddev.example/agent/spec-reviewer",
  "aud": "spiffe://meddev.example/agent/code-gen",
  "iat": 1772064150,
  "exp": 1772064750,
  "jti": "a1b2c3d4-0001-0000-0000-000000000001",
  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
  "exec_act": "review_requirements_spec",
  "par": [],
  "inp_hash": "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
  "out_hash": "sha-256:LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
  "ext": {
    "pol": "spec_review_policy_v2",
    "pol_decision": "approved"
  }
}

Task 2 (Code Generation Agent):¶

{
  "iss": "spiffe://meddev.example/agent/code-gen",
  "aud": "spiffe://meddev.example/agent/test-runner",
  "iat": 1772064200,
  "exp": 1772064800,
  "jti": "a1b2c3d4-0001-0000-0000-000000000002",
  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
  "exec_act": "implement_module",
  "par": ["a1b2c3d4-0001-0000-0000-000000000001"],
  "ext": {
    "pol": "coding_standards_v3",
    "pol_decision": "approved"
  }
}

Task 3 (Autonomous Test Agent):¶

{
  "iss": "spiffe://meddev.example/agent/test-runner",
  "aud": "spiffe://meddev.example/agent/build",
  "iat": 1772064260,
  "exp": 1772064860,
  "jti": "a1b2c3d4-0001-0000-0000-000000000003",
  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
  "exec_act": "execute_test_suite",
  "par": ["a1b2c3d4-0001-0000-0000-000000000002"],
  "ext": {
    "pol": "test_coverage_policy_v1",
    "pol_decision": "approved"
  }
}

Task 4 (Build Agent):¶

{
  "iss": "spiffe://meddev.example/agent/build",
  "aud": "spiffe://meddev.example/human/release-mgr-42",
  "iat": 1772064310,
  "exp": 1772064910,
  "jti": "a1b2c3d4-0001-0000-0000-000000000004",
  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
  "exec_act": "build_release_artifact",
  "par": ["a1b2c3d4-0001-0000-0000-000000000003"],
  "out_hash": "sha-256:Ry1YfOoW2XpC5Mq8HkGzNx3dL9vBa4sUjE7iKt0wPZc",
  "ext": {
    "pol": "build_validation_v2",
    "pol_decision": "approved"
  }
}

Task 5 (Human Release Manager Approval):¶

{
  "iss": "spiffe://meddev.example/human/release-mgr-42",
  "aud": "spiffe://meddev.example/system/ledger",
  "iat": 1772064510,
  "exp": 1772065110,
  "jti": "a1b2c3d4-0001-0000-0000-000000000005",
  "wid": "c2d3e4f5-a6b7-8901-cdef-012345678901",
  "exec_act": "approve_release",
  "par": ["a1b2c3d4-0001-0000-0000-000000000004"],
  "ext": {
    "pol": "release_approval_policy",
    "pol_decision": "approved",
    "pol_enforcer": "spiffe://meddev.example/human/release-mgr-42",
    "witnessed_by": [
      "spiffe://meddev.example/audit/qa-observer-1"
    ]
  }
}

The resulting DAG records the complete SDLC: spec review preceded implementation, implementation preceded testing, testing preceded build, and a human release manager approved the final release. The "ext" object in task 5 carries witness metadata via the "witnessed_by" extension key.¶

task-...-0001 (review_requirements_spec)
  |
  v
task-...-0002 (implement_module)
  |
  v
task-...-0003 (execute_test_suite)
  |
  v
task-...-0004 (build_release_artifact)
  |
  v
task-...-0005 (approve_release) [human]

An FDA auditor reconstructs this DAG by querying the audit ledger for all ECTs with wid "c2d3e4f5-a6b7-8901-cdef-012345678901" and verifying each signature. The DAG provides cryptographic evidence that the SDLC followed the prescribed process with human oversight at the release gate.¶

Example 3: Parallel Execution with Join

A workflow where two tasks execute in parallel and a third task depends on both:¶

task-...-0001 (assess_risk)
  |            \
  v             v
task-...-0002  task-...-0003
(check         (verify
compliance)    liquidity)
  |            /
  v           v
task-...-0004 (execute_trade)

Task 004 ECT payload:¶

{
  "iss": "spiffe://bank.example/agent/execution",
  "aud": "spiffe://bank.example/system/ledger",
  "iat": 1772064250,
  "exp": 1772064850,
  "jti": "f1e2d3c4-0004-0000-0000-000000000004",
  "wid": "d3e4f5a6-b7c8-9012-def0-123456789012",
  "exec_act": "execute_trade",
  "par": [
    "f1e2d3c4-0002-0000-0000-000000000002",
    "f1e2d3c4-0003-0000-0000-000000000003"
  ],
  "ext": {
    "pol": "trade_execution_policy_v3",
    "pol_decision": "approved"
  }
}

The "par" array with two entries records that both compliance checking and liquidity verification were completed before trade execution.¶