This document defines Execution Context Tokens (ECTs), an extension to the Workload Identity in Multi System Environments (WIMSE) architecture for distributed agentic workflows in regulated -environments. ECTs provide cryptographic proof of task execution -order, policy enforcement decisions, and compliance state across +environments. ECTs provide signed, structured records of task +execution order, policy evaluation outcomes, and compliance state +across agent-to-agent communication. By extending WIMSE Workload Identity Tokens with execution context claims in JSON Web Token (JWT) format, this specification enables regulated systems to maintain structured audit trails that support compliance verification. ECTs use a directed acyclic graph (DAG) structure to represent task dependencies, record policy evaluation outcomes at each decision -point, and integrate with WIMSE Workload Identity Tokens (WIT) and -Workload Proof Tokens (WPT) using the same signing model and -cryptographic primitives. A new HTTP header field, +point, and integrate with WIMSE Workload Identity Tokens (WIT) +using the same signing model and cryptographic primitives. A new +HTTP header field, Execution-Context, is defined for transporting ECTs alongside existing WIMSE headers. ECTs are a technical building block that supports, but does not by itself constitute, compliance with @@ -1444,211 +1446,186 @@ regulatory frameworks.¶
11.2. Self-Assertion Limitation
-However, workload identity alone does not address execution -accountability. Knowing who performed an action does not prove +accountability. Knowing who performed an action does not record what was done, what policy was applied, or whether compliance -requirements were satisfied at each decision point.¶
+requirements were evaluated at each decision point.¶Regulated environments increasingly deploy autonomous agents that coordinate across organizational boundaries. Multiple regulatory -frameworks motivate the need for structured execution records:¶
-The EU Artificial Intelligence Act [EU-AI-ACT] Article 12 -requires high-risk AI systems to be designed with capabilities -enabling automatic recording of events ("logs") while the -system is operating.¶
-The U.S. FDA 21 CFR Part 11 [FDA-21CFR11] requires -computer-generated, timestamped audit trails that independently -record the date, time, operator identity, and actions taken -(Section 11.10(e)).¶
-The Markets in Financial Instruments Directive (MiFID II) -[MIFID-II] requires firms to maintain records of transactions -and orders that are sufficient to enable supervisory authorities -to monitor compliance.¶
-The Digital Operational Resilience Act (DORA) [DORA] Article 12 -requires financial entities to have logging policies that record -ICT activities and anomalies.¶
-This document defines an extension to the WIMSE architecture that +frameworks — including [EU-AI-ACT], [FDA-21CFR11], [MIFID-II], +and [DORA] — require structured, auditable records of automated +decision-making and execution (see Table 4 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 +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.¶
+assurances.¶An HTTP header for ECT transport (Section 5)¶
Operational modes including ledger-optional deployment -(Section 8)¶
-The following are out of scope and are handled by WIMSE:¶
@@ -1992,23 +1943,23 @@ key identifier from the agent's WIT.[SPIFFE]).¶The ECT MUST be signed with the same private key used to -generate the agent's WPT.¶
+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 three -tokens are carried in their respective HTTP header fields:¶
+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> - Workload-Proof-Token: <WPT proving A controls key> Execution-Context: <ECT recording what A did>
The receiving agent (Agent B) verifies in order:¶
-WIT and WPT (WIMSE layer): Proves who Agent A is and that the -request is authentic.¶
+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:¶
+WIT (WIMSE layer): Verifies Agent A's identity within the +trust domain. WPT verification, if present, per +[I-D.ietf-wimse-s2s-protocol].¶
ECT (this extension): Records what Agent A did, what policy was -evaluated, and what precedent tasks exist.¶
+ECT (this extension): Records what Agent A did, what policy was +evaluated, and what precedent tasks exist.¶
Ledger: Appends the verified ECT to the audit ledger.¶
+Ledger: Appends the verified ECT to the audit ledger.¶
OPTIONAL. String. The result of the policy evaluation. When present, MUST be one of the values registered in the ECT Policy -Decision Values registry (Section 13.4). MUST be +Decision Values registry (Section 12.4). MUST be present when "pol" is present. Initial values are:¶
OPTIONAL. String. The regulatory domain applicable to this task. Values MUST be registered in the ECT Regulated Domain -Values registry (Section 13.5).¶
+Values registry (Section 12.5).¶An agent sending a request to another agent includes the Execution-Context header alongside the WIMSE Workload-Identity -and Workload-Proof-Token headers:¶
+header:¶DAG validation can be performed against an audit ledger (when -available) or against parent ECTs received inline via -Execution-Context headers (in point-to-point mode per -Section 8). The validation rules below use the term -"ECT store" to refer to either the ledger or the set of inline -parent ECTs available to the verifier.¶
+DAG validation is performed against the audit ledger, which +serves as the authoritative store of previously verified ECTs.¶
-function validate_dag(ect, ect_store, clock_skew_tolerance):
- // ect_store: ledger or local cache of verified ECTs
+function validate_dag(ect, ledger, clock_skew_tolerance):
// Step 1: Uniqueness check
- if ect_store.contains(ect.jti, ect.wid):
+ if ledger.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)
+ parent = ledger.get(parent_id)
if parent is null:
return error("Parent task not found: " + parent_id)
if parent.iat >= ect.iat + clock_skew_tolerance:
@@ -2648,14 +2599,14 @@ function validate_dag(ect, ect_store, clock_skew_tolerance):
// Step 3: Cycle detection (with traversal limit)
visited = set()
- result = has_cycle(ect.jti, ect.par, ect_store, visited,
+ result = has_cycle(ect.jti, ect.par, ledger, 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,
+function has_cycle(target_jti, parent_ids, ledger,
visited, max_depth):
if visited.size() >= max_depth:
return error("Maximum ancestor traversal limit exceeded")
@@ -2665,9 +2616,9 @@ function has_cycle(target_jti, parent_ids, ect_store,
if parent_id in visited:
continue
visited.add(parent_id)
- parent = ect_store.get(parent_id)
+ parent = ledger.get(parent_id)
if parent is not null:
- result = has_cycle(target_jti, parent.par, ect_store,
+ result = has_cycle(target_jti, parent.par, ledger,
visited, max_depth)
if result is error or result is true:
return result
@@ -2770,10 +2721,8 @@ present and that "pol_decision" is one of "approved",
If all checks pass and an audit ledger is available, the ECT -SHOULD be appended to the audit ledger. In point-to-point -mode (Section 8), the verified ECT is retained -locally by the receiving agent.¶
+If all checks pass, the ECT MUST be appended to the audit +ledger.¶
If any verification step fails, the ECT MUST be rejected and the @@ -2782,7 +2731,7 @@ failure MUST be logged for audit purposes. Error mes ledger, to prevent information disclosure.¶
When ECT verification fails during HTTP request processing, the receiving agent SHOULD respond with HTTP 403 (Forbidden) if the -WIT and WPT are valid but the ECT is invalid, and HTTP 401 +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 @@ -2862,17 +2811,13 @@ function verify_ect(ect_jws, verifier_id, return reject("Invalid pol_decision value") // Validate DAG (against ledger or inline parent ECTs) - result = validate_dag(payload, ect_store, + result = validate_dag(payload, ledger, clock_skew_tolerance) if result is error: return reject("DAG validation failed") - // All checks passed - if ledger is available: - ledger.append(payload) - else: - // Point-to-point mode: retain locally - local_ect_cache.store(payload) + // All checks passed; append to ledger + ledger.append(payload) return accept
ECTs can be deployed in three operational modes depending on the -availability and requirements of the deployment environment. All -modes use the same ECT format and verification procedure; they -differ in how parent ECTs are resolved during DAG validation and -where verified ECTs are stored.¶
-In point-to-point mode, agents pass parent ECTs directly to -downstream agents via multiple Execution-Context HTTP headers. -No centralized ledger is required. The receiving agent verifies -each parent ECT independently and validates the DAG against the -set of ECTs received in the request.¶
-This mode is suitable for:¶
-Cross-organizational workflows where no shared ledger exists¶
-Lightweight deployments where infrastructure is constrained¶
-Early adoption scenarios before ledger infrastructure is -available¶
-Limitations of point-to-point mode:¶
-No persistent audit trail unless agents independently retain -ECTs¶
-Global replay detection relies solely on "jti" caches at each -agent; there is no centralized "jti" uniqueness check¶
-The parent ECT chain grows with each hop, increasing HTTP -header size¶
-Post-hoc audit reconstruction requires collecting ECTs from -multiple agents¶
-Agents operating in point-to-point mode MUST retain verified -parent ECTs for at least the duration of the workflow to support -DAG validation of downstream requests. Agents SHOULD persist -ECTs locally for audit purposes even when no centralized ledger -is available.¶
-In deferred ledger mode, agents create and verify ECTs in-flight -using point-to-point delivery, and submit collected ECTs to an -audit ledger after the workflow completes or at periodic intervals.¶
-This mode decouples real-time workflow execution from ledger -availability. DAG validation during execution uses inline parent -ECTs; full DAG validation against the complete workflow is -performed at ledger submission time.¶
-Agents MUST include all collected ECTs when submitting to the -ledger. The ledger MUST re-validate the complete DAG upon -submission.¶
-In full ledger mode, every verified ECT is immediately appended -to an audit ledger. DAG validation is performed against the -ledger, which serves as the authoritative ECT store. This is -the RECOMMENDED mode for regulated environments where persistent, -centralized audit trails are required.¶
-Use of an audit ledger is RECOMMENDED for regulated environments -and any deployment requiring persistent, centralized audit trails. -ECTs are designed to be recorded in an immutable audit ledger for +
ECTs are designed to be recorded in an immutable audit ledger for compliance verification and post-hoc analysis. This specification -defines the logical interface for the ledger but does not mandate +defines required properties for the ledger but 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.¶
-An audit ledger implementation MUST provide:¶
-Append-only semantics: Once an ECT is recorded, it MUST NOT be -modified or deleted.¶
+required properties.¶ +An audit ledger implementation MUST provide:¶
+Append-only semantics: Once an ECT is recorded, it MUST NOT be +modified or deleted.¶
Ordering: The ledger MUST maintain a total ordering of ECT -entries via a monotonically increasing sequence number.¶
+Ordering: The ledger MUST maintain a total ordering of ECT +entries via a monotonically increasing sequence number.¶
Lookup by task ID: The ledger MUST support efficient retrieval -of ECT entries by "jti" value.¶
+Lookup by ECT ID: The ledger MUST support efficient retrieval +of ECT entries by "jti" value.¶
Integrity verification: The ledger SHOULD provide a mechanism +
Integrity verification: The ledger SHOULD provide a mechanism to verify that no entries have been tampered with (e.g., -hash chains or Merkle trees).¶
+hash chains or Merkle trees).¶The ledger SHOULD be maintained by an entity independent of the -workflow agents to reduce the risk of collusion.¶
-Each ledger entry is a logical record containing:¶
-
-{
- "ledger_sequence": 42,
- "ect_jti": "550e8400-e29b-41d4-a716-446655440001",
- "agent_id": "spiffe://example.com/agent/clinical",
- "action": "recommend_treatment",
- "parents": [],
- "ect_jws": "eyJhbGciOiJFUzI1NiIs...<complete JWS>",
- "signature_verified": true,
- "verification_timestamp": "2026-02-24T15:42:31.000Z",
- "stored_timestamp": "2026-02-24T15:42:31.050Z"
-}
-
-The "ect_jws" field contains the full JWS Compact Serialization -and is the authoritative record. The other fields ("agent_id", -"action", "parents") are convenience indexes derived from the -ECT payload; if they disagree with the JWS payload, the JWS -payload takes precedence. Implementations SHOULD validate that -convenience index fields match the corresponding values in the -JWS payload at write time to prevent desynchronization between -the authoritative JWS and the indexed fields.¶
-The ledger SHOULD be maintained by an entity independent of the +workflow agents to reduce the risk of collusion.¶
This section describes representative use cases demonstrating how +
This section describes representative use cases demonstrating how ECTs provide execution records in regulated environments. These examples demonstrate ECT mechanics; production deployments would include additional domain-specific requirements beyond the scope -of this specification.¶
-Note: task identifiers in this section are abbreviated for +of this specification.¶
+Note: task identifiers in this section are abbreviated for readability. In production, all "jti" values are required to be -UUIDs per Section 4.2.2.¶
+UUIDs per Section 4.2.2.¶In a medical device software development lifecycle (SDLC), +
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.¶
+software used in medical devices.¶Agent A (Spec Reviewer): jti: task-001 par: [] @@ -3119,28 +2921,28 @@ Human Release Manager: witnessed_by: [spiffe://meddev.example/audit/qa-observer-1]
ECTs record that requirements were reviewed before implementation +
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.¶
+phase was skipped or reordered.¶During a regulatory audit, an FDA reviewer requests evidence of +
During a regulatory audit, an FDA reviewer requests evidence of the development process for a specific software release. The auditing authority retrieves all ECTs sharing the same workflow identifier ("wid") from the audit ledger and reconstructs the -complete DAG:¶
+complete DAG:¶task-001 (review_requirements_spec) | @@ -3157,46 +2959,46 @@ task-004 (build_release_artifact) task-005 (approve_release) [human, witnessed]
The reconstructed DAG provides cryptographic evidence that:¶
+The reconstructed DAG provides cryptographic evidence that:¶
Each phase was executed by an identified and authenticated agent.¶
+Each phase was executed by an identified and authenticated agent.¶
Policy checkpoints were evaluated at every phase transition.¶
+Policy checkpoints were evaluated at every phase transition.¶
The execution sequence was maintained (no step was bypassed).¶
+The execution sequence was maintained (no step was bypassed).¶
A human-in-the-loop approved the final release, with independent -witness attestation.¶
+A human-in-the-loop approved the final release, with independent +witness attestation.¶
Timestamps and execution durations are recorded for each step.¶
+Timestamps and execution durations are recorded for each step.¶
This can contribute to compliance with:¶
+This can contribute to compliance with:¶
[FDA-21CFR11] Section 11.10(e): Computer-generated audit trails -that record the date, time, and identity of the operator.¶
+[FDA-21CFR11] Section 11.10(e): Computer-generated audit trails +that record the date, time, and identity of the operator.¶
[EU-MDR] Annex II: Technical documentation traceability for the -software development lifecycle.¶
+[EU-MDR] Annex II: Technical documentation traceability for the +software development lifecycle.¶
[EU-AI-ACT] Article 12: Automatic logging capabilities for -high-risk AI systems involved in the development process.¶
+[EU-AI-ACT] Article 12: Automatic logging capabilities for +high-risk AI systems involved in the development process.¶
[EU-AI-ACT] Article 14: ECTs can record evidence that human -oversight events occurred during the release process.¶
+[EU-AI-ACT] Article 14: ECTs can record evidence that human +oversight events occurred during the release process.¶
In a financial trading workflow, agents perform risk assessment, +
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.¶
+execution.¶Agent A (Risk Assessment): jti: task-001 par: [] @@ -3232,37 +3034,37 @@ Agent C (Execution): pol: execution_policy_v3 pol_decision: approved
This can contribute to compliance with:¶
+This can contribute to compliance with:¶
[MIFID-II]: ECTs provide cryptographic records of the execution -sequence that can support transaction audit requirements.¶
+[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.¶
+[DORA] Article 12: ECTs contribute to ICT activity logging.¶
[EU-AI-ACT] Article 12: Logging of decisions made by AI-driven -systems.¶
+[EU-AI-ACT] Article 12: Logging of decisions made by AI-driven +systems.¶
When a compliance violation is discovered after execution, ECTs +
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:¶
+a cryptographic link to the original task:¶
{
"iss": "spiffe://bank.example/agent/operations",
@@ -3282,26 +3084,26 @@ a cryptographic link to the original task:Figure 12:
+Figure 11:
Compensation ECT Example
The "par" claim links the compensation action to the original +
The "par" claim links the compensation action to the original trade, creating an auditable chain from execution through -violation discovery to remediation.¶
+violation discovery to remediation.¶In a logistics workflow, multiple compliance checks complete +
In a logistics workflow, multiple compliance checks complete before shipment commitment. The DAG structure records that all -required checks were completed:¶
+required checks were completed:¶Agent A (Route Planning): jti: task-001 par: [] @@ -3329,383 +3131,383 @@ System (Commitment): pol: commitment_policy_v1 pol_decision: approved
Note that tasks 002 and 003 both depend only on task-001 and can +
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.¶
+DAG's ability to represent parallel execution with a join point.¶This section addresses security considerations following the -guidance in [RFC3552].¶
+This section addresses security considerations following the +guidance in [RFC3552].¶
The following threat actors are considered:¶
+The following threat actors are considered:¶
Malicious agent (insider threat): An agent within the trust -domain that intentionally creates false ECT claims.¶
+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.¶
+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.¶
+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.¶
+Time manipulator: An entity attempting to manipulate timestamps +to alter perceived execution ordering.¶
ECTs are self-asserted by the executing agent. The agent claims +
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" to "approved" without actually -evaluating the policy).¶
-ECTs do not independently verify that:¶
+evaluating the policy).¶ +ECTs do not independently verify that:¶
The claimed execution actually occurred as described¶
+The claimed execution actually occurred as described¶
The policy evaluation was correctly performed¶
+The policy evaluation was correctly performed¶
The input/output hashes correspond to the actual data processed¶
+The input/output hashes correspond to the actual data processed¶
The agent faithfully performed the stated action¶
+The agent faithfully performed the stated action¶
The trustworthiness of ECT claims depends on the trustworthiness +
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" mechanism to include independent third-party observers at critical decision points. However, the "witnessed_by" claim is self-asserted by the ECT issuer: the listed witnesses do not co-sign the ECT and -there is no cryptographic proof within a single ECT that the +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.¶
+list witnesses that did not participate.¶To address the self-assertion limitation of the "witnessed_by" +
To address the self-assertion limitation of the "witnessed_by" claim, witnesses SHOULD submit their own independent signed ECTs to the audit ledger attesting to the observed task. A witness -attestation ECT:¶
+attestation ECT:¶MUST set "iss" to the witness's own workload identity.¶
+MUST set "iss" to the witness's own workload identity.¶
MUST set "exec_act" to "witness_attestation" (or a domain- -specific equivalent).¶
+MUST set "exec_act" to "witness_attestation" (or a domain- +specific equivalent).¶
MUST include the observed task's "jti" in the "par" array, -linking the attestation to the original task.¶
+MUST include the observed task's "jti" in the "par" array, +linking the attestation to the original task.¶
MUST set "pol_decision" to "approved" to indicate the witness -confirms the observation.¶
+MUST set "pol_decision" to "approved" to indicate the witness +confirms the observation.¶
When a task's "witnessed_by" claim lists one or more witnesses, +
When a task's "witnessed_by" claim lists one or more witnesses, auditors SHOULD verify that corresponding witness attestation ECTs exist in the ledger for each listed witness. A mismatch between the "witnessed_by" list and the set of independent witness -ECTs in the ledger SHOULD be flagged during audit review.¶
-This model converts witness attestation from a self-asserted claim +ECTs in the ledger SHOULD be flagged during audit review.¶
+This model converts witness attestation from a self-asserted claim to a cryptographically verifiable property of the ledger: the witness independently signs their own ECT using their own key, and the ledger records both the original task ECT and the witness -attestation ECTs.¶
+attestation ECTs.¶ECTs operate within a broader trust framework. The guarantees +
ECTs operate within a broader trust framework. The guarantees provided by ECTs are only meaningful when the following -organizational controls are in place:¶
+organizational controls are in place:¶Key management governance: Controls over who provisions agent -keys and how keys are protected.¶
+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.¶
+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.¶
+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.¶
+Agent deployment governance: Agents are deployed and maintained +in a manner that preserves their integrity.¶
ECTs MUST be signed with the agent's private key using JWS +
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 +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.¶
+be logged.¶ +Implementations MUST use established JWS libraries and MUST NOT +implement custom signature verification.¶
ECTs include short expiration times (RECOMMENDED: 5-15 minutes) to +
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 +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" +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.¶
+An ECT with a duplicate "jti" value MUST be rejected.¶ECTs do not replace transport-layer security. ECTs MUST be +
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:¶
+[RFC9421] provide an alternative channel binding mechanism.¶ +The defense-in-depth model provides:¶
TLS/mTLS (transport layer): Prevents network-level tampering.¶
+TLS/mTLS (transport layer): Prevents network-level tampering.¶
WIT/WPT (WIMSE identity layer): Proves agent identity and -request authorization.¶
+WIT/WPT (WIMSE identity layer): Proves agent identity and +request authorization.¶
ECT (execution accountability layer): Records what the agent did -and under what policy.¶
+ECT (execution accountability layer): Records what the agent did +and under what policy.¶
If an agent's private key is compromised, an attacker can forge +
If an agent's private key is compromised, an attacker can forge ECTs that appear to originate from that agent. To mitigate this -risk:¶
+risk:¶Implementations SHOULD use short-lived keys and rotate them -frequently (hours to days, not months).¶
+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.¶
+Private keys SHOULD be stored in Hardware Security Modules (HSMs) +or equivalent secure key storage.¶
Trust domains MUST support rapid key revocation.¶
+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.¶
+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 +
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.¶
+for audit purposes.¶A single malicious agent cannot forge parent task references +
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:¶
+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.¶
+Independent ledger maintenance: The ledger SHOULD be maintained +by an entity independent of the workflow agents.¶
Witness attestation: Using the "witnessed_by" claim to include -independent third-party observers.¶
+Witness attestation: Using the "witnessed_by" claim to include +independent third-party observers.¶
Cross-verification: Multiple independent ledger replicas can be -compared for consistency.¶
+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.¶
+Out-of-band audit: External auditors periodically verify ledger +contents against expected workflow patterns.¶
ECT signature verification is computationally inexpensive +
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 +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.¶
+on unsigned or incorrectly signed tokens.¶ECTs rely on timestamps ("iat", "exp") for temporal ordering. +
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 +(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 +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.¶
+between agents.¶ECTs with many parent tasks or large extension objects can +
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.7).¶
+5 levels (see also Section 4.2.7).¶ECTs necessarily reveal:¶
+ECTs necessarily reveal:¶
Agent identities ("iss", "aud") for accountability purposes¶
+Agent identities ("iss", "aud") for accountability purposes¶
Action descriptions ("exec_act") for audit trail completeness¶
+Action descriptions ("exec_act") for audit trail completeness¶
Policy evaluation outcomes ("pol", "pol_decision") for -compliance verification¶
+Policy evaluation outcomes ("pol", "pol_decision") for +compliance verification¶
Timestamps ("iat", "exp") for temporal ordering¶
+Timestamps ("iat", "exp") for temporal ordering¶
ECTs are designed to NOT reveal:¶
+ECTs are designed to NOT reveal:¶
Actual input or output data values (replaced with cryptographic -hashes via "inp_hash" and "out_hash")¶
+Actual input or output data values (replaced with cryptographic +hashes via "inp_hash" and "out_hash")¶
Internal computation details or intermediate steps¶
+Internal computation details or intermediate steps¶
Proprietary algorithms or intellectual property¶
+Proprietary algorithms or intellectual property¶
Personally identifiable information (PII)¶
+Personally identifiable information (PII)¶
Implementations SHOULD minimize the information included in ECTs. +
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" claim SHOULD reference policy identifiers rather than -embedding policy content.¶
-The "compensation_reason" claim (Section 4.2.6) +embedding policy content.¶
+The "compensation_reason" claim (Section 4.2.6) deserves particular attention: because it is human-readable and may describe the circumstances of a failure or policy violation, it risks exposing sensitive operational details. Implementations @@ -3713,167 +3515,167 @@ it risks exposing sensitive operational details. Implementations "policy_violation_in_parent_trade") rather than free-form natural language explanations. Implementers SHOULD review "compensation_reason" values for potential information leakage -before deploying to production.¶
+before deploying to production.¶ECTs stored in audit ledgers SHOULD be access-controlled so that +
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) +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.¶
+general access to the data values is not needed.¶ECTs are designed for interpretation by qualified human auditors +
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.¶
+disclosure.¶This document requests registration of the following media type -in the "Media Types" registry maintained by IANA:¶
-application¶
+This document requests registration of the following media type +in the "Media Types" registry maintained by IANA:¶
+application¶
wimse-exec+jwt¶
+wimse-exec+jwt¶
none¶
+none¶
none¶
+none¶
8bit; an ECT is a JWT that is a JWS using the Compact +
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.¶
+separated by period characters.¶See the Security Considerations section of this document.¶
+See the Security Considerations section of this document.¶
none¶
+none¶
This document¶
+This document¶
Applications that implement regulated agentic workflows requiring -execution context tracing and audit trails.¶
+Applications that implement regulated agentic workflows requiring +execution context tracing and audit trails.¶
Magic number(s): none +
Magic number(s): none File extension(s): none -Macintosh file type code(s): none¶
+Macintosh file type code(s): none¶Christian Nennemann, ietf@nennemann.de¶
+Christian Nennemann, ietf@nennemann.de¶
COMMON¶
+COMMON¶
none¶
+none¶
Christian Nennemann¶
+Christian Nennemann¶
IETF¶
+IETF¶
This document requests registration of the following header field +
This document requests registration of the following header field in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" -maintained by IANA:¶
-This document requests registration of the following claims in -the "JSON Web Token Claims" registry maintained by IANA:¶
+This document requests registration of the following claims in +the "JSON Web Token Claims" registry maintained by IANA:¶