# Section 1.5: Applicability (for draft-nennemann-act-01) Insert after Section 1.4 (Relationship to Related Work). --- ### 1.5. Applicability ACT is designed as a general-purpose primitive for AI agent authorization and execution accountability. While a sibling specification [I-D.nennemann-wimse-ect] profiles execution context tokens specifically for the WIMSE working group's workload identity infrastructure, ACT operates without any shared identity plane. This section identifies deployment contexts where ACT applies independently of WIMSE, and clarifies how ACT complements — rather than competes with — ecosystem-specific agent protocols. #### 1.5.1. Model Context Protocol (MCP) Tool-Use Flows The Model Context Protocol [MCP-SPEC] defines a client-server interface by which LLM hosts invoke external tools via structured JSON-RPC calls. MCP 2025-11-25 mandates OAuth 2.1 for transport-layer authentication, but provides no mechanism for carrying per-invocation authorization constraints or for producing a tamper-evident record of what arguments were passed and what result was returned. ACT addresses this gap as follows: when an MCP host is about to dispatch a tool call on behalf of an agent, it SHOULD issue a Phase 1 ACT Mandate encoding the permitted tool name (e.g., as a capability constraint), the declaring scope, and any parameter-level constraints applicable to that invocation. The MCP server, upon receiving the request, MAY validate the ACT Mandate and, upon completing the tool execution, SHOULD transition the token to Phase 2 by appending SHA-256 hashes of the serialized input arguments and the JSON response, then re-sign. The resulting Phase 2 ACT constitutes an unforgeable record that a specific tool was called with specific arguments and returned a specific result, independently of MCP's OAuth layer. This integration requires no modification to MCP transport; the ACT SHOULD be carried in the `ACT-Mandate` and `ACT-Record` HTTP headers defined in Section 9.1 of this document. #### 1.5.2. OpenAI Agents SDK and Function Calling The OpenAI Agents SDK [OPENAI-AGENTS-SDK] enables composition of agents via handoffs — structured transfers of control from one agent to another, each potentially invoking registered function tools. The SDK provides no built-in mechanism for a receiving agent to verify that the handoff was authorized by a named principal, nor for the invoking agent to produce a verifiable record of what functions it called. ACT is applicable at the handoff boundary: the orchestrating agent SHOULD issue a Phase 1 ACT Mandate to the receiving agent at the moment of handoff, encoding the permitted function set as capability constraints and the maximum privilege the receiving agent MAY exercise. The receiving agent SHOULD attach its Phase 2 ACT Record to any callback or downstream response, providing the orchestrator with cryptographic evidence of the actions taken. In multi-turn chains involving multiple handoffs, the DAG linkage (Section 7) allows each handoff to be expressed as a parent-child edge, preserving the full causal ordering of the agent invocation sequence. Implementations that use the OpenAI function calling API directly, without the Agents SDK, MAY apply ACT at the application layer: the calling process issues a Phase 1 ACT before the function call parameter block is finalized, and the receiving function handler returns a Phase 2 ACT alongside its JSON result. #### 1.5.3. LangGraph and LangChain Agent Graphs LangGraph [LANGGRAPH] models agent workflows as typed StateGraphs in which nodes represent agent invocations or tool calls and edges represent conditional transitions. The DAG structure of ACT (Section 7) is a natural fit for this model: each LangGraph node that performs an observable action corresponds to exactly one ACT task identifier (`tid`), and directed edges in the LangGraph correspond to `pred` (predecessor) references in successor ACTs. ACT is applicable at the node boundary: when a LangGraph node dispatches a sub-agent or invokes a tool with side effects, it SHOULD issue a Phase 1 ACT Mandate encoding the node's permitted actions before any external call is made. Upon transition out of the node, a Phase 2 ACT Record SHOULD be produced and attached to the LangGraph state object alongside the node's output. Downstream nodes that fan-in from multiple predecessors MAY retrieve the set of parent ACT identifiers from the shared state to populate their `pred` array, thereby expressing LangGraph's fan-in semantics within the ACT DAG without any additional infrastructure. In contrast to LangGraph's built-in state audit trail, which is mutable in-process memory, Phase 2 ACTs are cryptographically signed and portable: they can be exported from a LangGraph run and submitted to an external audit ledger, satisfying compliance requirements that cannot be met by in-process logging alone. #### 1.5.4. Google Agent2Agent (A2A) Protocol The Agent2Agent protocol [A2A-SPEC] defines a task-oriented JSON-RPC interface for inter-agent communication, with authentication delegated to OAuth 2.0 or API key schemes declared in each agent's Agent Card. A2A provides no mechanism for a receiving agent to verify the authorization provenance of a task request beyond the transport-layer credential, and produces no token that represents the execution of the task in a verifiable, portable form. ACT is applicable as a session-layer accountability complement to A2A: a client agent SHOULD include a Phase 1 ACT Mandate in the `metadata` field of the A2A Task object, encoding the task type as a capability constraint and the delegating agent's identity as the ACT issuer. The receiving agent SHOULD validate the Mandate before beginning task execution and SHOULD return a Phase 2 ACT Record as an artifact in the A2A TaskResult, enabling the client agent to retain cryptographic proof of what was executed on its behalf. This integration does not require modification to A2A's transport or authentication scheme; ACT and A2A's OAuth credentials operate at independent layers and are not redundant. A2A's credential answers "is this client permitted to contact this server?"; the ACT Mandate answers "is this agent permitted to request this specific task under these constraints?". #### 1.5.5. Enterprise Orchestration Without WIMSE (CrewAI, AutoGen) Enterprise orchestration frameworks such as CrewAI [CREWAI] and AutoGen [AUTOGEN] deploy multi-agent systems within a single organizational boundary, typically without SPIFFE/SPIRE workload identity infrastructure. In these environments, OAuth Authorization Servers are often unavailable or impractical to deploy for intra- process agent communication. ACT is applicable in this context via its Tier 1 (pre-shared key) trust model (Section 5.2): each agent role in a CrewAI Crew or AutoGen ConversableAgent graph is assigned an Ed25519 keypair at instantiation time. The orchestrating agent issues Phase 1 Mandates to worker agents before delegating tasks, constraining each worker to only the tools and actions relevant to its role. Worker agents produce Phase 2 Records on task completion. The resulting ACT chain is exportable as a structured audit trail that satisfies the per-action logging requirements of DORA [DORA] and EU AI Act Article 12 [EUAIA] without requiring shared infrastructure beyond the ability to exchange public keys at deployment time. Implementations SHOULD NOT use ACT's self-assertion mode (where an agent issues and records its own mandate without external sign-off) in regulated workflows; at minimum, the orchestrating agent MUST sign the initial Mandate so that accountability is anchored to a principal outside the executing agent. #### 1.5.6. Relationship to WIMSE ECT Where WIMSE infrastructure is deployed, ACT and the WIMSE Execution Context Token [I-D.nennemann-wimse-ect] serve complementary and non-overlapping functions. The ECT records workload-level execution in WIMSE terms — which SPIFFE workload executed, in which trust domain, against which service. ACT records the authorization provenance — which agent was permitted to request which action, under what capability constraints, by whose authority — and transitions that authorization record into an execution record upon task completion. In mixed environments, both tokens SHOULD be carried simultaneously: the `Workload-Identity` header carries the WIMSE ECT; the `ACT-Record` header carries the ACT. Verifiers MAY correlate the two by matching the ACT `tid` claim against application-layer identifiers present in the ECT's task context. Neither token is a profile or extension of the other; they operate at different abstraction layers and their co-presence is additive. --- ## Informative References to Add ``` [MCP-SPEC] Model Context Protocol Specification, 2025-11-25, [OPENAI-AGENTS-SDK] OpenAI, "Agents SDK", [LANGGRAPH] LangChain, "LangGraph Documentation", [A2A-SPEC] Google, "Agent2Agent (A2A) Protocol", [CREWAI] CrewAI, "CrewAI Documentation", [AUTOGEN] Microsoft, "AutoGen Documentation", ```