Christian Nennemann
3a139dfc7e
Strategic work for IETF submission of draft-nennemann-act-01 and
draft-nennemann-wimse-ect-02:
Package restructure:
- move ACT and ECT refimpls to workspace/packages/{act,ect}/
- ietf-act and ietf-ect distribution names (sibling packages)
- cross-spec interop test plan (INTEROP-TEST-PLAN.md)
ACT draft -01 revisions:
- rename 'par' claim to 'pred' (align with ECT)
- rename 'Agent Compact Token' to 'Agent Context Token' (semantic
alignment with ECT family)
- add Applicability section (MCP, OpenAI, LangGraph, A2A, CrewAI)
- add DAG vs Linear Delegation Chains section (differentiator vs
txn-tokens-for-agents actchain, Agentic JWT, AIP/IBCTs)
- add Related Work: AIP, SentinelAgent, Agentic JWT, txn-tokens-for-agents,
HDP, SCITT-AI-agent-execution
- pin SCITT arch to -22, note AUTH48 status
Outreach drafts:
- Emirdag liaison email (SCITT-AI coordination)
- OAuth ML response on txn-tokens-for-agents-06
Strategy document:
- STRATEGY.md with phased action plan, risk register, timeline
Submodule:
- update workspace/drafts/ietf-wimse-ect pointer to -02 commit
195 lines
9.3 KiB
Markdown
195 lines
9.3 KiB
Markdown
# 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,
|
|
<https://modelcontextprotocol.io/specification/2025-11-25>
|
|
|
|
[OPENAI-AGENTS-SDK] OpenAI, "Agents SDK",
|
|
<https://openai.github.io/openai-agents-python/>
|
|
|
|
[LANGGRAPH] LangChain, "LangGraph Documentation",
|
|
<https://langchain-ai.github.io/langgraph/>
|
|
|
|
[A2A-SPEC] Google, "Agent2Agent (A2A) Protocol",
|
|
<https://github.com/a2aproject/A2A>
|
|
|
|
[CREWAI] CrewAI, "CrewAI Documentation",
|
|
<https://docs.crewai.com/>
|
|
|
|
[AUTOGEN] Microsoft, "AutoGen Documentation",
|
|
<https://microsoft.github.io/autogen/>
|
|
```
|