]> Independent Researcher

ietf@nennemann.de

Security execution context workload identity agentic workflows audit trail compliance regulated systems 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 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, 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 regulatory frameworks.

Introduction

Motivation The Workload Identity in Multi System Environments (WIMSE) framework provides robust workload authentication through Workload Identity Tokens (WIT) and Workload Proof Tokens (WPT). The WIMSE service-to-service 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 prove what was done, what policy was applied, or whether compliance requirements were satisfied 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 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 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) 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) 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 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 , call context in agentic workflows must always be visible and preserved. ECTs provide a mechanism to address this requirement with cryptographic assurances.

Problem Statement Three core gaps exist in current approaches to regulated agentic systems: 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." No standard mechanism exists to record policy evaluation outcomes at each decision point in a multi-agent workflow. No mechanism exists to cryptographically link compensation and rollback decisions to original actions. Existing observability tools such as distributed tracing 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.

Scope and Applicability This document defines: The Execution Context Token (ECT) format () DAG structure for task dependency ordering () Policy checkpoint recording () Integration with the WIMSE identity framework () An HTTP header for ECT transport () Audit ledger interface requirements () 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

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.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used in this document:

Agent:

An autonomous workload, as defined by WIMSE , that executes tasks within a workflow.

Task:

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

Directed Acyclic Graph (DAG):

A graph structure representing task dependency ordering where edges are directed and no cycles exist.

Execution Context Token (ECT):

A JSON Web Token defined by this specification that records task execution details and policy evaluation outcomes.

Audit Ledger:

An append-only, immutable log of all ECTs within a workflow or set of workflows, used for regulatory audit and compliance verification.

Policy Checkpoint:

A point in a workflow where a policy evaluation outcome is recorded within an ECT.

Workload Identity Token (WIT):

A WIMSE credential proving a workload's identity within a trust domain.

Workload Proof Token (WPT):

A WIMSE proof-of-possession token used for request-level authentication.

Trust Domain:

A WIMSE concept representing an organizational boundary with a shared identity issuer, corresponding to a SPIFFE trust domain.

Witness:

A third-party entity that observes and attests to the execution of a task, providing additional accountability.

WIMSE Architecture Integration

WIMSE Foundation The WIMSE architecture 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 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

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

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

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. The ECT "iss" claim MUST use the WIMSE workload identifier format (a SPIFFE ID ). The ECT MUST be signed with the same private key used to generate the agent's WPT. 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:

Workload-Proof-Token: Execution-Context: ]]>

The receiving agent (Agent B) verifies in order: WIT and WPT (WIMSE layer): Proves who Agent A is and that the request is authentic. 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.

Execution Context Token Format An Execution Context Token is a JSON Web Token (JWT) signed as a JSON Web Signature (JWS) using the Compact Serialization. JWS JSON Serialization MUST NOT be used for ECTs.

JOSE Header The ECT JOSE header MUST contain the following parameters:

alg:

REQUIRED. The digital signature algorithm used to sign the ECT. MUST match the algorithm in the corresponding WIT. Implementations MUST support ES256 . 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 . Used by verifiers to look up the correct public key for signature verification.

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

WIMSE-Compatible Claims The following standard JWT claims MUST be present in every ECT:

iss:

REQUIRED. StringOrURI. The issuer of the ECT, which MUST be the workload's SPIFFE ID in the format spiffe://<trust-domain>/<path>. This MUST match the "sub" claim of the agent's WIT.

sub:

OPTIONAL. StringOrURI. The subject of the ECT. When present, MUST equal the "iss" claim.

aud:

REQUIRED. StringOrURI or array of StringOrURI. The intended recipient(s) of the ECT. Typically the next agent in the workflow or the ledger endpoint.

iat:

REQUIRED. NumericDate. The time at which the ECT was issued. The ECT records a completed action, so the "iat" value reflects when the record was created, not when task execution began.

exp:

REQUIRED. NumericDate. The expiration time of the ECT. Implementations SHOULD set this to 5 to 15 minutes after "iat" to limit the replay window while allowing for reasonable clock skew and processing time.

jti:

OPTIONAL. String. A unique identifier for the ECT, useful for additional replay detection.

Execution Context Claims The following claims are defined by this specification:

wid:

OPTIONAL. String. A workflow identifier that groups related ECTs into a single workflow. When present, MUST be a UUID . When absent, the "tid" uniqueness requirement applies globally across the entire ledger.

tid:

REQUIRED. String. A globally unique task identifier in UUID format . Each task MUST have a unique "tid" value. When "wid" is present, uniqueness is scoped to the workflow; when "wid" is absent, uniqueness MUST be enforced globally across the ledger.

exec_act:

REQUIRED. String. The action or task type identifier describing what the agent performed (e.g., "process_payment", "validate_safety", "calculate_dosage"). Note: this claim is intentionally named "exec_act" rather than "act" to avoid collision with the "act" (Actor) claim registered by .

par:

REQUIRED. Array of strings. Parent task identifiers representing DAG dependencies. Each element MUST be a valid "tid" from a previously executed task. An empty array indicates a root task with no dependencies. A workflow MAY contain multiple root tasks.

Policy Claims The following claims record policy evaluation outcomes:

pol:

REQUIRED. String. The identifier of the policy rule that was evaluated for this task (e.g., "clinical_data_access_policy_v1").

pol_decision:

REQUIRED. String. The result of the policy evaluation. MUST be one of: "approved", "rejected", or "pending_human_review".

pol_enforcer:

OPTIONAL. StringOrURI. The identity of the entity (system or person) that evaluated the policy decision. When present, SHOULD use SPIFFE ID format.

pol_timestamp:

OPTIONAL. NumericDate. The time at which the policy decision was made. When present, MUST be equal to or earlier than the "iat" claim.

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

inp_hash:

OPTIONAL. String. A cryptographic hash of the input data, formatted as "hash-algorithm:base64url-encoded-hash" (e.g., "sha-256:n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg"). The hash algorithm identifier SHOULD be "sha-256". The hash MUST be computed over the raw octets of the input data.

out_hash:

OPTIONAL. String. A cryptographic hash of the output data, using the same format as "inp_hash".

inp_classification:

OPTIONAL. String. The data sensitivity classification of the input (e.g., "public", "confidential", "restricted").

Operational Claims The following claims provide additional operational context:

exec_time_ms:

OPTIONAL. Integer. The execution duration of the task in milliseconds. MUST be a non-negative integer.

regulated_domain:

OPTIONAL. String. The regulatory domain applicable to this task. Values are drawn from an extensible set; initial values include "medtech", "finance", and "military".

model_version:

OPTIONAL. String. The version identifier of the AI or ML model used to perform the task, if applicable.

Witness Claims

witnessed_by:

OPTIONAL. Array of StringOrURI. Identifiers of third-party entities that observed or attested to the execution of this task. When present, each element SHOULD use SPIFFE ID format. In regulated environments, implementations SHOULD use witness attestation for critical decision points to mitigate the risk of single-agent false claims.

Compensation Claims

compensation_required:

OPTIONAL. Boolean. Indicates whether this task is a compensation or rollback action for a previous task.

compensation_reason:

OPTIONAL. String. A human-readable reason for the compensation action. MUST be present if "compensation_required" is true.

Note: compensation ECTs reference historical parent tasks via the "par" claim. The referenced parent ECTs may have passed their own "exp" time; ECT expiration applies to the verification window of the ECT itself, not to its validity as a parent reference in the ledger.

Extension Claims

ext:

OPTIONAL. Object. An extension object for domain-specific claims not defined by this specification. Implementations that do not understand extension claims SHOULD ignore them. To avoid key collisions between different domains, extension key names SHOULD use reverse domain notation (e.g., "com.example.custom_field").

The "ext" claim is a generic extension mechanism; it is not registered in the IANA JWT Claims registry because its semantics depend on the domain-specific claims within it.

Complete ECT Example The following is a complete ECT payload example:

HTTP Header Transport

Execution-Context Header Field This specification defines the Execution-Context HTTP header field for transporting ECTs between agents. The header field value is the ECT in JWS Compact Serialization format . 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 and Workload-Proof-Token headers:

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.

DAG Validation

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.

Validation Rules When receiving and verifying an ECT, implementations MUST perform the following DAG validation steps: Task ID Uniqueness: The "tid" claim MUST be unique within the applicable scope (the workflow identified by "wid", or the entire ledger if "wid" is absent). If a task with the same "tid" already exists, the ECT MUST be rejected. Parent Existence: Every task identifier listed in the "par" array MUST correspond to a task that has been previously recorded in the ledger. If any parent task is not found, the ECT MUST be rejected. Temporal Ordering: The "iat" value of every parent task MUST be less than the "iat" value of the current task plus a configurable clock skew tolerance (RECOMMENDED: 30 seconds). If any parent task has an "iat" that violates this constraint, the ECT MUST be rejected. Acyclicity: Following the chain of parent references MUST NOT lead back to the current task's "tid". If a cycle is detected, the ECT MUST be rejected. 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.

DAG Validation Algorithm The following pseudocode describes the DAG validation procedure:

= ect.iat + clock_skew_tolerance: return error("Parent task not earlier than current") // Step 3: Cycle detection visited = set() if has_cycle(ect.tid, ect.par, ledger, visited): return error("Circular dependency detected") return success function has_cycle(target_tid, parent_ids, ledger, visited): for parent_id in parent_ids: if parent_id == target_tid: return true if parent_id in visited: continue visited.add(parent_id) parent = ledger.get(parent_id) if parent is not null: if has_cycle(target_tid, parent.par, ledger, visited): return true 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. Implementations SHOULD cache cycle detection results for previously verified tasks to avoid redundant traversals.

Signature and Token Verification

Verification Procedure When an agent receives an ECT, it MUST perform the following verification steps in order: Parse the JWS Compact Serialization to extract the JOSE header, payload, and signature components per . Verify that the "typ" header parameter is "wimse-exec+jwt". Verify that the "alg" header parameter is not "none" and is not a symmetric algorithm. Verify the "kid" header parameter references a known, valid public key from a WIT within the trust domain. Retrieve the public key identified by "kid" and verify the JWS signature per Section 5.2. Verify the "alg" header parameter matches the algorithm in the corresponding WIT. Verify the "iss" claim matches the "sub" claim of the WIT associated with the "kid" public key. Verify the "aud" claim contains the verifier's own workload identity or an expected recipient identifier. Verify the "exp" claim indicates the ECT has not expired. Verify the "iat" claim is not unreasonably far in the past (implementation-specific threshold, RECOMMENDED maximum of 15 minutes). Verify all required claims ("tid", "exec_act", "par", "pol", "pol_decision") are present and well-formed. Verify "pol_decision" is one of "approved", "rejected", or "pending_human_review". Perform DAG validation per . 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 failure MUST be logged for audit purposes. Error messages SHOULD NOT reveal whether specific parent task IDs exist in the ledger, to prevent information disclosure.

Verification Pseudocode

Audit Ledger Interface

Overview 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 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.

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. Lookup by task ID: The ledger MUST support efficient retrieval of ECT entries by "tid" value. Integrity verification: The ledger SHOULD provide a mechanism to verify that no entries have been tampered with (e.g., hash chains or Merkle trees). The ledger SHOULD be maintained by an entity independent of the workflow agents to reduce the risk of collusion.

Ledger Entry Structure Each ledger entry is a logical record containing:

", "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.

Use Cases 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 readability. In production, all "tid" values MUST be UUIDs per .

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 Section 11.10(e) and require audit trails documenting the complete development process for software used in medical devices.

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.

FDA Audit with DAG Reconstruction 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:

The reconstructed DAG provides cryptographic evidence that: Each phase was executed by an identified and authenticated agent. Policy checkpoints were evaluated at every phase transition. The execution sequence was maintained (no step was bypassed). A human-in-the-loop approved the final release, with independent witness attestation. Timestamps and execution durations are recorded for each step. This can contribute to compliance with: Section 11.10(e): Computer-generated audit trails that record the date, time, and identity of the operator. Annex II: Technical documentation traceability for the software development lifecycle. Article 12: Automatic logging capabilities for high-risk AI systems involved in the development process. Article 14: ECTs can record evidence that human oversight events occurred during the release process.

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.

This can contribute to compliance with: : ECTs provide cryptographic records of the execution sequence that can support transaction audit requirements. Article 12: ECTs contribute to ICT activity logging. Article 12: Logging of decisions made by AI-driven systems.

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:

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

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

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.

Security Considerations This section addresses security considerations following the guidance in .

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.

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" 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" mechanism to include independent third-party observers at critical decision points.

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.

Signature Verification ECTs MUST be signed with the agent's private key using JWS . 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. If signature verification fails, 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.

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 SHOULD maintain a cache of recently-seen "jti" values (when present) to detect replayed ECTs within the expiration window.

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 , transport security is already established. HTTP Message Signatures 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.

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.

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" claim 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.

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.

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). The temporal ordering check in DAG validation incorporates the clock skew tolerance to account for minor clock differences between agents.

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 reasonable size and SHOULD set maximum size limits for the "ext" object to prevent abuse.

Privacy Considerations

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 ("pol", "pol_decision") 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)

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" claim SHOULD reference policy identifiers rather than embedding policy content.

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.

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.

IANA Considerations

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

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,

JWT Claims Registration This document requests registration of the following claims in the "JSON Web Token Claims" registry maintained by IANA: Claim Name Claim Description Change Controller Reference wid Workflow Identifier IETF tid Task Identifier IETF exec_act Action/Task Type IETF par Parent Task Identifiers IETF pol Policy Rule Identifier IETF pol_decision Policy Decision Result IETF pol_enforcer Policy Enforcer Identity IETF pol_timestamp Policy Decision Timestamp IETF inp_hash Input Data Hash IETF out_hash Output Data Hash IETF inp_classification Input Data Classification IETF exec_time_ms Execution Time (ms) IETF witnessed_by Witness Identities IETF regulated_domain Regulatory Domain IETF model_version AI/ML Model Version IETF compensation_required Compensation Flag IETF compensation_reason Compensation Reason IETF

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. CyberArk Zscaler University of Applied Sciences Bonn-Rhein-Sieg The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as a running instance of software executing for a specific purpose. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. Ping Identity CyberArk SPIRL Intuit The WIMSE architecture defines authentication and authorization for software workloads in a variety of runtime environments, from the most basic ones up to complex multi-service, multi-cloud, multi- tenant deployments. This document defines the simplest, atomic unit of this architecture: the protocol between two workloads that need to verify each other's identity in order to communicate securely. The scope of this protocol is a single HTTP request-and-response pair. To address the needs of different setups, we propose two protocols, one at the application level and one that makes use of trusted TLS transport. These two protocols are compatible, in the sense that a single call chain can have some calls use one protocol and some use the other. Workload A can call Workload B with mutual TLS authentication, while the next call from Workload B to Workload C would be authenticated at the application level. All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. Huawei Huawei This document discusses WIMSE applicability to Agentic AI, so as to establish independent identities and credential management mechanisms for AI agents. European Parliament and Council of the European Union U.S. Food and Drug Administration European Parliament and Council of the European Union European Parliament and Council of the European Union European Parliament and Council of the European Union Cloud Native Computing Foundation

Related Work

WIMSE Workload Identity The WIMSE architecture and service-to- service 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 defines the OAuth 2.0 Token Exchange protocol and registers the "act" (Actor) claim in the JWT Claims registry. ECTs intentionally use the distinct claim name "exec_act" for the action/task type to avoid collision with the "act" claim. Transaction tokens in OAuth establish API authorization context; ECTs serve the complementary purpose of recording execution accountability across multi-step workflows.

Distributed Tracing (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 .

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.

Implementation Guidance

Minimal Implementation A minimal conforming implementation should: Create JWTs with all required claims ("iss", "aud", "iat", "exp", "tid", "exec_act", "par", "pol", "pol_decision"). Sign ECTs with the agent's private key using an algorithm matching the WIT (ES256 recommended). Verify ECT signatures against WIT public keys. Perform DAG validation (parent existence, temporal ordering, cycle detection). Append verified ECTs to an audit ledger.

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 should use established JWT/JWS libraries (JOSE) for token creation and verification. Custom cryptographic implementations should not be used. Implementations should be tested against multiple JWT libraries to ensure interoperability.

Regulatory Compliance Mapping The following table summarizes how ECTs can contribute to compliance with various regulatory frameworks. ECTs are a technical building block; achieving compliance requires additional organizational measures beyond this specification. Regulation Requirement ECT Contribution FDA 21 CFR Part 11 Audit trails recording date, time, operator, actions (11.10(e)) Cryptographic signatures and append-only ledger contribute to audit trail requirements EU MDR Technical documentation traceability (Annex II) ECTs provide signed records of AI-assisted decision sequences EU AI Act Art. 12 Automatic logging capabilities for high-risk AI ECTs contribute cryptographic activity logging EU AI Act Art. 14 Human oversight capability ECTs can record evidence that human oversight events occurred MiFID II Transaction records for supervisory authorities ECTs provide cryptographic execution sequence records DORA Art. 12 ICT activity logging policies ECT ledger contributes to ICT activity audit trail

Examples

Example 1: Simple Two-Agent Workflow Agent A executes a data retrieval task and sends the ECT to Agent B: ECT JOSE Header:

ECT Payload:

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

The resulting DAG:

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):

Task 2 (Code Generation Agent):

Task 3 (Autonomous Test Agent):

Task 4 (Build Agent):

Task 5 (Human Release Manager Approval):

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 with independent witness attestation.

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 004 ECT payload:

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

Acknowledgments The author thanks the WIMSE working group for their foundational work on workload identity in multi-system environments. The concepts of Workload Identity Tokens and Workload Proof Tokens provide the identity foundation upon which execution context tracing is built.