From 73c611fef08166f1aa9ae33b765fca8097ffa78c Mon Sep 17 00:00:00 2001
From: Eva <130791729+evabenn@users.noreply.github.com>
Date: Sun, 31 May 2026 20:31:50 -0700
Subject: [PATCH 1/8] Create overview.md for Identity for Agents

Added an overview document for the Identity for Agents workstream, detailing unique identity challenges and the evolving nature of identity standards in agent systems.

Signed-off-by: Eva <130791729+evabenn@users.noreply.github.com>
---
 identity/overview.md | 146 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 146 insertions(+)
 create mode 100644 identity/overview.md

diff --git a/identity/overview.md b/identity/overview.md
new file mode 100644
index 0000000..100c273
--- /dev/null
+++ b/identity/overview.md
@@ -0,0 +1,146 @@
+# Identity for Agents Overview
+
+> **Note:** This is a working document. It is not intended to be comprehensive and will evolve as the ACS Identity workstream matures. Content, scope, and recommendations are subject to change.
+>
+
+There are 5 unique identity challenges that this standard aims to solve, where existing use cases that traditional identity models cannot support. It does not propose a wire format or normative requirements yet. Those will follow once the working group has aligned. This is an evolving space and we are taking a conservative approach with normative requirements.
+
+For taxonomy and definitions, see [Core Concepts](https://github.com/Agent-Control-Standard/ACS/blob/main/docs/topics/core_concepts.md).
+
+## What's Changing with Agents
+
+For decades, application security worked because software was deterministic.
+
+A traditional application follows a predefined execution path. Security teams can inspect the code, review dependencies, define permissions, and understand expected behavior before deployment. Identity policies can be established in advance because the software's capabilities are known before it runs. A car rental website cannot suddenly provide therapy advice, manage payroll, or execute financial transactions because those capabilities do not exist in its code.
+
+```text
+Traditional Software
+
+Code
+  ↓
+Dependencies
+  ↓
+Permissions
+  ↓
+Execution
+
+Behavior Known Before Runtime
+```
+
+Large Language Models (LLMs) introduced a fundamentally different execution model. Unlike traditional software, an LLM does not execute a fixed sequence of instructions. It generates outputs probabilistically based on its training data, prompts, and context. The same prompt can produce different outputs across executions.
+
+```text
+Prompt
+  ↓
+Model Reasoning
+  ↓
+Generated Output
+
+Behavior Determined At Runtime
+```
+
+This introduced non-determinism into systems that had previously been predictable. On its own, however, an LLM is mostly generating text. Agents act, plan, call tools, invoke other agents, and reach production systems in milliseconds. Today most of them act under a borrowed human identity or a single static service account. That breaks accountability, breaks least-privilege, and makes the ACS Trace pillar lie about who did what.
+
+At runtime an agent determines:
+
+- What tool to call
+- What data to retrieve
+- Which API to invoke
+- Whether to delegate to another agent
+- What action to perform
+
+The effective execution path is assembled dynamically while the system is running.
+
+```text
+Agent
+
+Goal
+  ↓
+Model Reasoning
+  ↓
+Tool Selection
+  ↓
+Data Retrieval
+  ↓
+Delegation
+  ↓
+Action
+
+Behavior Composed During Runtime
+```
+
+Two executions of the same agent on the same task can take entirely different paths. Recent academic work characterizes this as agents resolving capability *probabilistically* at runtime rather than at build time — see *SOK: A Taxonomy of Attack Vectors and Defense Strategies for Agentic Supply Chain Runtime* ([arXiv:2602.19555](https://arxiv.org/abs/2602.19555)), which describes how agentic systems shift the attack surface from build-time dependencies to *inference-time* dependencies assembled from untrusted data and probabilistic capability resolution. Unlike traditional software, where dependencies are resolved before deployment, agentic systems assemble portions of their effective execution context at runtime. Retrieved documents, tool outputs, external APIs, memory entries, and other agents become runtime dependencies selected through probabilistic reasoning rather than predetermined code paths.
+
+This breaks the assumptions identity standards were designed around. Human identity standards assume a long-lived principal, a session, and a narrow blast radius per action. Workload identity standards assume the workload's behavior is determined by its code. Neither holds for agents.
+
+Traditional identity models assume:
+
+- The actor is known
+- The execution path is known
+- The permissions are known
+- The delegation chain is known
+
+Agent systems invalidate all four assumptions.
+
+The question is no longer:
+
+> Who is the principal?
+
+The question becomes:
+
+> Who is acting, on whose behalf, for what purpose, using what authority, through which delegation chain, at this moment?
+
+That is the runtime identity problem ACS aims to solve.
+
+An agent has a goal, a set of tools, some memory, and a model that decides at runtime what to call next, in what order, with what arguments. The effective code path is composed in the moment, by a non-deterministic component, based on whatever the agent just read. The supply chain you signed off on at build time is not the supply chain that executes.
+
+A single tool call can chain through nine or more identities: the human user, the platform, the orchestrator, one or more sub-agents, the model, the tool, the downstream API, the trigger source, and the data subject. Each hop needs its own scope. Each hop needs to be verifiable. Today, identity at runtime is usually one or two of those at best.
+
+```text
+Human ──delegates──▶ Orchestrator Agent ──delegates──▶ Sub-Agent ──invokes──▶ Tool ──acts on──▶ Resource
+   │                       │                              │                     │
+   │                       ▼                              ▼                     ▼
+   │              ingests RAG / docs / web      may spawn more sub-agents   external write
+   │              (untrusted instructions)                                   (irreversible)
+   │
+   └──── audit subject: which link in this chain, under which intent? ────────────────▶
+```
+
+Agent systems are introducing a new class of failures where every token is valid, every API call is authorized, and the outcome is still a security incident.
+
+---
+
+## The 5 Unique Runtime Identity Challenges for Agents
+
+These are the five unique runtime identity challenges that distinguish agent systems from human or workload identity. Each one is a place where existing standards fall short and where the ACS Identity workstream is concentrating its effort. The list is deliberately tight: every challenge below is genuinely distinct and together they cover the runtime surface that today's identity standards do not.
+
+A concrete example that illustrates several of these challenges is Palo Alto Networks Unit 42's 2025 research, *[Agent Session Smuggling in Agent2Agent Systems](https://unit42.paloaltonetworks.com/agent-session-smuggling-in-agent2agent-systems/)*. In the demonstrated attack, a malicious agent injected hidden instructions into a legitimate Agent2Agent (A2A) session. The victim agent subsequently disclosed sensitive information and performed unauthorized actions while using valid credentials and authorized APIs. Authentication and authorization succeeded. The failure occurred because the runtime could not distinguish user intent from adversarial instructions introduced during execution. This illustrates the central identity challenge of agent systems.
+
+| # | Challenge / Question | Why It's Challenging | Standards Today That Aren't Sufficient | What Needs to Change for Runtime | ACS Mechanism |
+|---|---|---|---|---|---|
+| 1 | **Chain Integrity**<br/>*Can the full delegation chain be named and verified end-to-end?* | A single agent task can chain through five to ten identities: user → orchestrator → sub-agent → tool → downstream API. Two failures compound: the chain is not *named* (audit collapses into "the agent did it"), and the chain is not *verifiable* (downstream resources cannot confirm the chain without trusting every intermediary). In practice the full chain is often not reconstructable end-to-end, and there is a known class of attacks where the chain itself can be spliced. | **[OAuth 2.0](https://www.rfc-editor.org/rfc/rfc6749) access tokens** identify the bearer, not the chain.<br/>**[OIDC Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html) ID tokens** name the human at the start but lose granularity at each hop.<br/>**[SPIFFE SVIDs](https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/)** identify the workload but not which call within it.<br/>**[OAuth Token Exchange (RFC 8693)](https://www.rfc-editor.org/rfc/rfc8693)** defines nested `act` claims that can express a chain, but per [§4.1](https://www.rfc-editor.org/rfc/rfc8693#section-4.1) *"prior actors identified by any nested `act` claims are informational only and are not to be considered in access control decisions."* The chain is recorded, not normatively enforceable.<br/>**[OAuth Identity Chaining draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/)** and **[Transaction Tokens draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/)** address parts but specify neither chain verification rules nor revocation propagation as required runtime behavior.<br/>**[W3C Trace Context](https://www.w3.org/TR/trace-context/)** correlates but [does not authenticate](https://www.w3.org/TR/trace-context/#privacy-of-traceparent-field). | Every action must produce, at the moment of execution, a signed record that names the specific link in the chain and lets any participant (including the downstream resource) verify the entire chain end-to-end without trusting any intermediary. Cryptographic chain structure, mandatory scope attenuation at every hop, revocation propagation. | Pending |
+| 2 | **Over-Privilege**<br/>*Was this action within the agent's purpose?* | Agents inherit broad standing privileges. Service accounts. Long-lived API keys. OAuth scopes designed for human applications. One compromised agent has the union of every permission anyone has ever granted to it. The fix is not bigger scopes; the fix is no standing privilege. | **[OAuth scopes (RFC 6749 §3.3)](https://www.rfc-editor.org/rfc/rfc6749#section-3.3)** are coarse, deployment-defined strings (e.g. `read`, `write`, `repo`). Per **[RFC 9396 §1](https://www.rfc-editor.org/rfc/rfc9396#section-1)**, scope is "sufficient... for coarse-grained authorization requests" but "not sufficient to specify fine-grained authorization requirements" — it does not express per-action, per-resource, per-data-cell intent.<br/>**RBAC and ABAC** scope by role or attribute, granted once, evaluated coarsely.<br/>**AIMS** does not require **[RAR (RFC 9396)](https://www.rfc-editor.org/rfc/rfc9396)** and treats scope semantics as deployment-specific. | Credentials minted just before the call, scoped to one downstream callee, structured (per-action, per-resource), expired in minutes. Authorization evaluated per-call against the immutable intent for the run, not per-session. | Pending |
+| 3 | **Token Theft Resistance**<br/>*If a token leaks from agent memory, is it useless to the attacker?* | The agent threat model breaks OAuth's bearer-token assumption entirely. Prompt injection can exfiltrate tokens from memory. Tool outputs can leak tokens. Sub-agents can replay tokens. Logs and crash dumps capture tokens. Long-lived refresh tokens in agent memory are the worst case: a durable credential held in storage that any indirect prompt injection can read. | **[OAuth 2.0 Bearer Tokens (RFC 6750 §1.2)](https://www.rfc-editor.org/rfc/rfc6750#section-1.2)** explicitly treat possession as sufficient: *"Using a bearer token does not require a bearer to prove possession of cryptographic key material."*<br/>**API keys** are bearer secrets by definition.<br/>**[OAuth refresh tokens (RFC 6749 §1.5)](https://www.rfc-editor.org/rfc/rfc6749#section-1.5)** were designed for "the same user, returning later," which does not describe how agents work.<br/>**[DPoP (RFC 9449)](https://www.rfc-editor.org/rfc/rfc9449)** and **[OAuth 2.0 Mutual-TLS Certificate-Bound Access Tokens (RFC 8705)](https://www.rfc-editor.org/rfc/rfc8705)** solve sender-constraint but are optional extensions that most deployments do not enforce.<br/>None of these are required by the OAuth core. | All non-trivial tokens sender-constrained (DPoP or mTLS) so a leaked token is useless without the corresponding private key. Aggressive lifetime ceilings measured in minutes or seconds, not hours. No long-lived secrets in model-visible context. Credentials fetched at task start, used within a tight window, discarded at task end. | Pending |
+| 4 | **Last-Mile Enforcement**<br/>*Did the resource actually enforce the decision, on every call, inside the runtime?* | The moment the action reaches a production system. All upstream identity work either holds here or fails here. Most systems today cannot distinguish an authorized action by an agent acting in good faith from the same call by an agent hijacked by indirect prompt injection. Gateway-only enforcement misses tool calls and sub-agent invocations that never cross a gateway. Cached decisions miss revocation, scope change, and freshly-discovered taint. | **API gateways and service meshes** enforce at the edge; agent tool calls never reach them.<br/>**[OAuth 2.0 resource servers (RFC 6749 §1.1)](https://www.rfc-editor.org/rfc/rfc6749#section-1.1)** validate the token but not the action's relationship to intent.<br/>**[mTLS (RFC 8705)](https://www.rfc-editor.org/rfc/rfc8705)** and **[SPIFFE](https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/)** establish workload identity but do not enforce per-action policy.<br/>None fire inside the agent runtime where the decision is made. | Enforcement fires at every tool call, inside the agent runtime, before the action executes. The runtime verifies identity, scope, taint, freshness, and intent on every call. No cached decisions; the LLM call cost dwarfs the re-authorization cost. Default-deny verified by a negative test in CI. | Pending |
+| 5 | **Proof of Intent**<br/>*Was the action bound to an immutable, declared purpose that survives mid-task reframing?* | OAuth scopes say what the user *can* do. They do not say what the user *is doing right now*. Without intent binding at runtime, every agent action is a guess about user authorization. The agent's reasoning can be reframed mid-task by an instruction hidden in a document or a tool output. The original intent has to survive that. This is the hardest of the five, because it is the only one OAuth cannot patch with an extension: the underlying problem is non-deterministic client behavior under adversarial inputs. | **None at the identity layer.** Intent is implicit in the OAuth consent screen and discarded after token issuance.<br/>**[RFC 9396 RAR](https://www.rfc-editor.org/rfc/rfc9396)** can carry purpose claims as `authorization_details` data but does not bind them as runtime invariants against the LLM client.<br/>**IBAC (Intent-Based Access Control)** is research-stage with no IETF/W3C standard track.<br/>No production standard treats intent as a first-class, immutable, normatively-enforced runtime invariant. | Intent treated as a first-class governance concept with a normative immutability invariant. Intent must flow across all three ACS pillars: Instrument fires decisions against it, Trace records it as a span attribute, Inspect catalogs what it authorized. Intent extension permitted only through an explicit, human-approved path. | Pending |
+
+---
+
+## What this Identity workstream is not trying to do
+
+- **Replace existing Identity Standards like OAuth, OIDC, SPIFFE.** ACS-Identity composes with them.
+- **Specify a new agent framework.** The mechanisms must work for any framework that can emit a signed action record.
+
+## How ACS-Identity composes with the rest of ACS
+
+ACS-Identity is one of seven cross-cutting concepts (Identity, Provenance, Trust, Intent, Capability, Agents, Session Lifecycle). It produces signals that the three pillars consume:
+
+- **Instrument** fires authorization decisions against identity + intent + taint.
+- **Trace** records each chain link as a span attribute (signed, verifiable).
+- **Inspect** catalogs which agent, under which intent, exercised which capability.
+
+Identity does not solve any of the five challenges alone. It composes with Provenance (taint), Capability (what the agent is allowed to do at all), and Intent (what it is doing right now).
+
+## Read Next
+
+- [ACS in Action](./ACS_in_action_example.md)

From 878b9612c8bf978645e394b81d69b9b9b54b787d Mon Sep 17 00:00:00 2001
From: Eva <130791729+evabenn@users.noreply.github.com>
Date: Sun, 31 May 2026 20:32:42 -0700
Subject: [PATCH 2/8] Document identity and authentication standards for ACS

Added a comprehensive overview of identity, authentication, and authorization standards relevant to ACS, including existing and emerging standards, their gaps, and the role of ACS in addressing these gaps.

Signed-off-by: Eva <130791729+evabenn@users.noreply.github.com>
---
 identity/standards.md | 286 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 286 insertions(+)
 create mode 100644 identity/standards.md

diff --git a/identity/standards.md b/identity/standards.md
new file mode 100644
index 0000000..ca4dd6f
--- /dev/null
+++ b/identity/standards.md
@@ -0,0 +1,286 @@
+# Related and Emerging Standards
+
+This page is the single source of truth for the identity, authentication, authorization, delegation, workload identity, and observability standards that **ACS** composes with, and for the specific gaps in those standards that ACS is designed to fill.
+
+> **ACS does not replace these standards.**
+> ACS does not recommend one implementation over another.
+> ACS does not redefine token formats, credential formats, grant flows, workload identifiers, or authentication protocols.
+
+Instead, ACS builds upon existing work from the **IETF**, **OpenID Foundation**, **SPIFFE / WIMSE community**, **OpenTelemetry**, **OCSF**, and other standards bodies, adding the runtime enforcement layer those standards intentionally do not define.
+
+The goal is simple:
+
+> **One place where builders can understand the identity landscape for agentic systems, and where ACS fits into it.**
+
+This page intentionally includes:
+
+- **Mature standards** already deployed in production (OAuth 2.0, OIDC, SPIFFE, the foundational RFCs)
+- **Emerging standards and drafts** being developed specifically for agent ecosystems (AIMS, WIMSE, Transaction Tokens, AAuth, Agentic JWT)
+- **The gaps** in both that ACS exists to address
+
+## At a Glance
+
+The diagram below frames how the standards on this page relate to each other and to ACS.
+
+```mermaid
+flowchart TB
+    subgraph Legend["Legend"]
+        direction LR
+        L1["Existing standard"]:::existing
+        L2["Emerging draft"]:::emerging
+        L3["ACS"]:::acs
+    end
+
+    subgraph Human["Human Identity & Authorization"]
+        OAuth20["OAuth 2.0 (RFC 6749)"]:::existing
+        OAuth21["OAuth 2.1"]:::existing
+        OIDC["OpenID Connect"]:::existing
+        GNAP["GNAP (RFC 9635)"]:::existing
+        AMR["AMR (RFC 8176)"]:::existing
+    end
+
+    subgraph Workload["Workload Identity"]
+        SPIFFE["SPIFFE / SPIRE"]:::existing
+        WIMSE_ARCH["WIMSE Architecture"]:::emerging
+        WIMSE_ID["WIMSE Identifier"]:::emerging
+        WIMSE_CRED["WIMSE Credentials"]:::emerging
+        WIMSE_WPT["WIMSE WPT"]:::emerging
+        WIMSE_SIG["WIMSE HTTP Signatures"]:::emerging
+    end
+
+    subgraph Delegation["Delegation, Binding & Context"]
+        TOKEX["Token Exchange (RFC 8693)"]:::existing
+        RAR["RAR (RFC 9396)"]:::existing
+        DPOP["DPoP (RFC 9449)"]:::existing
+        MTLS["mTLS-Bound Tokens (RFC 8705)"]:::existing
+        CHAIN["OAuth Identity Chaining"]:::emerging
+        TXTOK["Transaction Tokens"]:::emerging
+        TXTOK_A["Transaction Tokens for Agents"]:::emerging
+    end
+
+    subgraph Agents["Agent-Specific Drafts"]
+        AIMS["AIMS"]:::emerging
+        AAUTH["AAuth"]:::emerging
+        AJWT["Agentic JWT"]:::emerging
+    end
+
+    subgraph Signals["Runtime Signals & Telemetry"]
+        CAEP["CAEP"]:::existing
+        SSF["Shared Signals Framework"]:::existing
+        OTEL["OpenTelemetry"]:::existing
+        TRACE["W3C Trace Context"]:::existing
+        OCSF["OCSF"]:::existing
+    end
+
+    Human --> Delegation
+    Workload --> Delegation
+    Delegation --> Agents
+    Human --> Agents
+    Workload --> Agents
+    Signals -.-> ACS
+    Agents --> ACS
+    Delegation --> ACS
+
+    ACS["ACS<br/>Runtime enforcement,<br/>intent &amp; policy decisions"]:::acs
+
+    classDef existing fill:#1f8a4c,stroke:#0e5a30,color:#fff,font-weight:bold;
+    classDef emerging fill:#e67e22,stroke:#a85a10,color:#fff,font-weight:bold;
+    classDef acs fill:#1f6feb,stroke:#0b3d91,color:#fff,font-weight:bold;
+```
+
+---
+
+## Existing Standards
+
+The following standards are broadly adopted and form the foundation of modern identity systems.
+
+| Standard | Description | Link |
+|---|---|---|
+| **OAuth 2.0 (RFC 6749)** | The original delegated authorization framework. Defines authorization code, client credentials, and other grants. Foundational, but designed for **registered, deterministic web/native clients**. See [Why OAuth 2.0 Alone Doesn't Meet Agent Needs](#why-oauth-20-alone-doesnt-meet-agent-needs) below. | [RFC 6749](https://datatracker.ietf.org/doc/rfc6749/) |
+| **OAuth 2.1** | In-progress consolidation of OAuth 2.0 and later security best practices for delegated authorization. | [oauth.net/2.1](https://oauth.net/2.1/) |
+| **OpenID Connect (OIDC)** | Authentication layer built on OAuth that establishes human identity. | [openid.net](https://openid.net/developers/how-connect-works/) |
+| **SPIFFE / SPIRE** | Cryptographically verifiable workload identity for machines and services. A conformant implementation of the WIMSE identifier model. | [spiffe.io](https://spiffe.io/) |
+| **RFC 8693, Token Exchange** | Exchange one identity token for another with reduced scope and delegated authority. Single-hop by design; multi-hop chain semantics are **underspecified** and are being addressed by [OAuth Identity Chaining](#delegation-chains--transaction-context) and emerging agent-delegation drafts. | [RFC 8693](https://datatracker.ietf.org/doc/rfc8693/) |
+| **RFC 9396, Rich Authorization Requests (RAR)** | Fine-grained, structured authorization requests beyond traditional OAuth scopes. **Required by ACS** for non-trivial agent actions. | [RFC 9396](https://datatracker.ietf.org/doc/rfc9396/) |
+| **RFC 9449, DPoP** | Sender-constrained access tokens that reduce token theft and replay attacks. Required by AIMS and ACS for agent contexts. | [RFC 9449](https://datatracker.ietf.org/doc/rfc9449/) |
+| **RFC 8705, mTLS Certificate-Bound Tokens** | Binds access tokens to client certificates for workload-to-workload authentication. | [RFC 8705](https://datatracker.ietf.org/doc/rfc8705/) |
+| **RFC 8176, AMR** | Standardized representation of authentication strength and methods. | [RFC 8176](https://datatracker.ietf.org/doc/rfc8176/) |
+| **GNAP (RFC 9635)** | Modern authorization protocol supporting interactive and delegated authorization flows. | [RFC 9635](https://datatracker.ietf.org/doc/rfc9635/) |
+| **OpenID CIBA** | Client-Initiated Backchannel Authentication for out-of-band human approval. Used by AIMS for human-in-the-loop, but does **not** natively support mid-execution re-authorization (see [§ Why OAuth 2.0 Alone Doesn't Meet Agent Needs](#why-oauth-20-alone-doesnt-meet-agent-needs)). | [CIBA Core](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) |
+| **CAEP** | Continuous Access Evaluation Profile for near real-time session revocation and risk signaling. | [CAEP 1.0](https://openid.net/specs/openid-caep-specification-1_0.html) |
+| **OpenID Shared Signals Framework (SSF)** | Standardized risk, security, and session-change event sharing between systems. Adopted by AIMS as the eventing transport. | [Shared Signals WG](https://openid.net/wg/sharedsignals/) |
+| **W3C Trace Context** | Standardized trace propagation across distributed systems. | [W3C Trace Context](https://www.w3.org/TR/trace-context/) |
+| **OpenTelemetry** | Open standard for distributed tracing, metrics, and observability. | [opentelemetry.io](https://opentelemetry.io/) |
+| **OCSF** | Open Cybersecurity Schema Framework for normalized security telemetry. | [schema.ocsf.io](https://schema.ocsf.io/) |
+
+### What These Standards Solve
+
+Collectively, the mature standards above answer foundational identity questions:
+
+- **Who** is the actor?
+- **How** does the actor authenticate?
+- **How** are credentials issued?
+- **How** is delegated authority represented (single-hop)?
+- **How** are workloads identified?
+- **How** is request context propagated?
+- **How** is trust transferred across systems?
+
+### What These Standards Do **Not** Solve
+
+These standards establish **trust**. They do not determine whether an action **should** happen, and several were not designed with autonomous, non-deterministic agents in mind.
+
+They do not:
+
+- Evaluate intent
+- Detect prompt injection or memory poisoning
+- Decide whether delegated authority remains appropriate after runtime reasoning changes course
+- Verify multi-hop delegation chain integrity end-to-end
+- Specify failure-mode behavior when the IdP is unreachable
+
+> Those questions belong to **ACS**.
+
+---
+
+## Why OAuth 2.0 Alone Doesn't Meet Agent Needs
+
+OAuth 2.0 is the foundation, but its design assumptions break for autonomous agents. The drafts under [Emerging Agent Identity Standards](#emerging-agent-identity-standards) (AIMS, AAuth, Agentic JWT, Transaction Tokens for Agents, and OAuth Identity Chaining) exist precisely because of these gaps. ACS addresses the **runtime** subset.
+
+| OAuth 2.0 Assumption | How Agents Break It | What Addresses It |
+|---|---|---|
+| **The client is a stable, registered software identity** with approximately constant behavior. | An agent's execution path is composed at runtime by a non-deterministic model over inputs that may include adversarial content (indirect prompt injection). A registered client with valid credentials can have its reasoning hijacked. OAuth client auth cannot distinguish "authenticated and behaving" from "authenticated and hijacked." | **ACS runtime enforcement.** No token-issuance standard can patch this; it requires inline behavioral verification at action time. |
+| **Delegation is single-hop** (`user → client → resource server`). | Agent chains are `user → orchestrator → sub-agent → tool → API`. RFC 8693 Token Exchange retrofits multi-hop but leaves chain verification, mandatory scope attenuation, and revocation propagation unspecified. A **delegation chain splicing vulnerability** was disclosed on the OAuth WG list in February 2026. | OAuth Identity Chaining draft; AIMS §10.5; **ACS delegation-integrity checks** at every hop. |
+| **Consent is grant-time, not action-time.** Approve scope once, client holds token until revoked. | Agents need consent that is **fresh** (user still present) and **granular** (this specific action, not just this scope). CAEP adds freshness signals; CIBA adds step-up, but **CIBA only covers client initiation**, not mid-execution re-authorization. AIMS §10.6 names this gap explicitly. | **ACS mid-execution step-up** and intent-aligned policy checks. |
+| **Scopes are pre-declared static strings** (`read`, `write`, `repo`). | Static scopes can't express per-action, per-resource, per-data-cell intent that agents operate at. | **RFC 9396 (RAR)**, required by ACS for non-trivial scopes. |
+| **Bearer tokens.** Possession is sufficient for use. | Agent memory, tool outputs, logs, and crash dumps are all token-leak surfaces. Prompt injection can exfiltrate tokens from working memory. | **DPoP (RFC 9449)** and **mTLS-bound tokens (RFC 8705)**, required by both AIMS and ACS. |
+| **Refresh tokens** assume "the same user, returning later." | Long-lived refresh tokens stored in prompt-injection-readable agent memory are the worst-case credential. | **Short-lived credentials with aggressive rotation** (AIMS §6; ACS §3.1 imposes tighter ceilings, e.g. 15 min for LLM, 5 min for MCP, 60 s for high-risk). |
+| **The IdP is always reachable.** | Agents operate at machine speed. An IdP outage forces a choice between denial of service and security regression (fall back to cached credentials). Neither OAuth nor AIMS specifies a failure-mode contract. | **Open ACS work item:** fail-closed vs. fail-cached vs. tier-dependent policy. |
+| **Client behavior is deterministic.** | Restatement of row 1, and the deepest problem: every other limitation can be patched with an extension. This one **cannot**. It requires a runtime layer that observes the client, detects deviation from policy, and intercepts actions. | **ACS, by definition.** |
+
+> **Summary.** OAuth 2.0 plus its extensions (RAR, DPoP, mTLS-bound tokens, Token Exchange) plus the agent-specific drafts (AIMS, Transaction Tokens for Agents, Identity Chaining) cover **token issuance, binding, and propagation**. None of them cover **runtime enforcement of the authenticated agent's behavior**. That is the boundary ACS occupies.
+
+---
+
+## Emerging Agent Identity Standards
+
+> **Status Note: these are Internet-Drafts.**
+> All drafts in this section are **Internet-Drafts** and have **not yet been ratified as RFCs**. Internet-Drafts are working documents and may be revised, replaced, or withdrawn at any time. The authoritative source for any draft's status is its Datatracker landing page. ACS deliberately tracks landing pages rather than pinning revisions.
+
+The following drafts are actively shaping identity for autonomous systems, AI agents, and machine-to-machine delegation. ACS tracks them closely because they address identity problems that traditional IAM systems were never designed to solve.
+
+> **NIST signal.** The **NIST AI Agent Standards Initiative** (February 2026, NCCoE concept paper on agent identity and authorization) references this body of IETF work. ACS aligns with the same reference points.
+
+### Agent Authentication & Authorization
+
+| Draft | Description | Link |
+|---|---|---|
+| **AIMS, AI Agent Authentication and Authorization** | The de facto IETF reference point for agent identity. Composes WIMSE, SPIFFE, and OAuth 2.0 into a framework for agent auth. Treats agents as workloads; mandates WIMSE identifiers, short-lived credentials, attestation-fed issuance, and OAuth-derived tokens. **Security Considerations (§14): "TODO Security"**, explicitly leaving runtime enforcement out of scope. | [draft-klrc-aiagent-auth](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/) |
+| **AAuth** (Rosenberg, White) | OAuth 2.1 extension defining an **Agent Authorization Grant** for non-redirect-based agent token acquisition. Overlaps with, and in places competes with, parts of AIMS. | [draft-rosenberg-oauth-aauth-00](https://www.ietf.org/archive/id/draft-rosenberg-oauth-aauth-00.html) |
+| **Agentic JWT** | OAuth 2.0 extension addressing zero-trust drift caused by non-deterministic agentic AI clients, where the user's intent and the client application's actions can diverge. | [draft-goswami-agentic-jwt](https://datatracker.ietf.org/doc/draft-goswami-agentic-jwt/) |
+
+### Workload Identity (WIMSE)
+
+The WIMSE working group's workload identity stack that AIMS composes onto. **ACS treats WIMSE identifiers as the normative agent identifier**, with SPIFFE SVIDs as a conformant implementation.
+
+| Draft | Description | Link |
+|---|---|---|
+| **WIMSE Architecture** | Architectural model for workload identity across systems and trust domains. | [draft-ietf-wimse-arch](https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/) |
+| **WIMSE Workload Identifier** | URI format used to uniquely identify workloads and agents. | [draft-ietf-wimse-identifier](https://datatracker.ietf.org/doc/draft-ietf-wimse-identifier/) |
+| **WIMSE Workload Credentials** | Credential formats workloads use to prove identity ownership. | [draft-ietf-wimse-workload-creds](https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/) |
+| **WIMSE Workload Proof Token (WPT)** | Application-layer authentication tokens for workload-to-workload communication. | [draft-ietf-wimse-wpt](https://datatracker.ietf.org/doc/draft-ietf-wimse-wpt/) |
+| **WIMSE HTTP Message Signatures** | Request signing using workload credentials. | [draft-ietf-wimse-http-signature](https://datatracker.ietf.org/doc/draft-ietf-wimse-http-signature/) |
+
+### Delegation Chains & Transaction Context
+
+| Draft | Description | Link |
+|---|---|---|
+| **OAuth Identity and Authorization Chaining Across Domains** | How delegation chains propagate across trust boundaries and administrative domains. Referenced by AIMS §10.5. Addresses (in part) the multi-hop gap in RFC 8693. | [draft-ietf-oauth-identity-chaining](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/) |
+| **Transaction Tokens** | Downscopes access tokens to specific transactions; mitigates token replay between microservices. Referenced by AIMS §10.4. | [draft-ietf-oauth-transaction-tokens](https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/) |
+| **Transaction Tokens for Agents** | Extends Transaction Tokens with agent-specific delegation chains, actor transitions, hop metadata, and trust attenuation. | [draft-araut-oauth-transaction-tokens-for-agents](https://datatracker.ietf.org/doc/draft-araut-oauth-transaction-tokens-for-agents/) |
+
+### What These Drafts Solve
+
+The emerging drafts extend the existing identity foundation to answer agent-specific questions:
+
+- **How** does an autonomous agent acquire tokens without a redirect-based human flow?
+- **How** is a delegation chain represented across multiple agent hops?
+- **How** is the difference between a user's intent and an agent's actions captured in a token?
+- **How** do workloads and agents present cryptographic identity at the application layer?
+- **How** does transaction context survive across microservice and trust-domain boundaries?
+
+### What These Drafts Do **Not** Solve
+
+These drafts establish **trust and context**. They do not decide whether the resulting action **should** execute. AIMS's own Security Considerations section reads, in full, **"TODO Security."** That gap is not an oversight; it is the boundary between identity issuance and runtime enforcement.
+
+They do not answer:
+
+- Should this action happen, given current intent and observed agent state?
+- Has the agent been influenced by untrusted content since the token was issued?
+- Has the delegation chain become unsafe mid-execution?
+- Should mid-execution user re-authorization fire **right now** (a gap CIBA does not cover)?
+- What happens when the IdP is unreachable and the agent is mid-task?
+
+> Those questions belong to **ACS**.
+
+---
+
+## The ACS ↔ AIMS Composition Boundary
+
+If ACS and AIMS are positioned correctly, they are **complementary, not competing**.
+
+### AIMS handles, ACS does not need to
+
+- Agent identifier issuance and structure (WIMSE identifier; SPIFFE as a conformant implementation)
+- Cryptographic binding of credentials to identifier (WIMSE credentials, SPIFFE SVIDs)
+- Credential provisioning, rotation, and lifecycle
+- Attestation feeding credential issuance
+- Transport and application-layer authentication (mTLS, WIMSE Proof Tokens, HTTP Message Signatures)
+- OAuth grant flows for agent token acquisition
+- Cross-domain token exchange (Identity Chaining, JWT Authorization Grant)
+- Token format and discovery metadata
+- Eventing transport for security signals (Shared Signals + CAEP / RISC)
+
+### ACS handles, AIMS does not
+
+- **Runtime policy enforcement** as a policy decision point that returns allow / deny / modify verdicts inline, before an action reaches a production system
+- **Hook-level identity validation:** re-checking identity, delegation chain, and attestation at every agent decision point, not just at token issuance
+- **Tainted-input handling:** tracking which agent invocations have ingested untrusted content and denying writes from tainted contexts
+- **Mid-execution step-up:** the runtime layer that recognizes when a CIBA challenge should fire (the gap AIMS §10.6 explicitly names)
+- **AgBOM enumeration:** dynamic inventory of every model, tool, capability, knowledge source, and dependency, joined to identity at runtime
+- **Control set tiers (0–3):** conformance bundles mapping deployment risk to identity controls
+- **Embedded sub-agent identity:** the case AIMS §10.3.3 collapses to "agents accessed by other agents"
+- **Cross-platform conformance:** bridging AWS, Azure, GCP primitives to a single runtime enforcement model
+- **The OAuth gaps from the table above:** IdP unavailability and non-deterministic client behavior
+
+### Where ACS and AIMS overlap (resolved in favor of AIMS where appropriate)
+
+| Topic | Resolution |
+|---|---|
+| **Identifier model** | **WIMSE identifier required; SPIFFE conformant.** Aligns ACS with AIMS, WIMSE WG, and NIST. |
+| **Token lifetimes** | AIMS sets the baseline; ACS ceilings (15 min LLM / 5 min MCP / 60 s high-risk) are conformance refinements. |
+| **Sender-constrained tokens** | Both require DPoP or mTLS. Cross-reference, no divergence. |
+| **Audit logging** | ACS identity blocks **extend** AIMS minimum audit event fields rather than diverging from them. |
+
+---
+
+## Responsibility Map
+
+ACS specifies the runtime enforcement contract that **consumes** the identity, delegation, workload, and transaction context produced by the standards above.
+
+| Layer | Responsibility |
+|---|---|
+| OAuth 2.0 / 2.1 / OIDC | Human authentication and authorization (foundation; insufficient alone for agents) |
+| SPIFFE / SPIRE | Workload identity (conformant WIMSE implementation) |
+| WIMSE | Normative workload identity stack |
+| AIMS | Agent authentication and token acquisition |
+| AAuth / Agentic JWT | Alternative or complementary agent token issuance models |
+| Token Exchange + Identity Chaining | Delegation and cross-domain attenuation |
+| Transaction Tokens (+ for Agents) | Request and agent-chain context propagation |
+| CAEP / SSF | Continuous risk and session signaling |
+| **ACS Identity** | Runtime identity verification |
+| **ACS Provenance** | Origin and lineage verification |
+| **ACS Crypto** | Integrity, signatures, attestations, and non-repudiation |
+| **ACS** | Runtime enforcement and policy decisions |
+
+ACS verifies identity, delegation, scope, provenance, and intent **immediately before an action executes**, and fills AIMS's open "TODO Security" gap with a runtime contract.
+
+> ACS does not replace these standards. ACS **composes** with them.

From fe23f5db131db79784388965976cb0f0a2c7a89d Mon Sep 17 00:00:00 2001
From: Eva <130791729+evabenn@users.noreply.github.com>
Date: Wed, 8 Jul 2026 15:53:04 -0700
Subject: [PATCH 3/8] address comments on identity standards

Updated various sections to clarify the scope of AIMS and ACS, including token lifetimes, identifier models, and runtime enforcement. Added details on agent behavior and security considerations.

Signed-off-by: Eva <130791729+evabenn@users.noreply.github.com>
---
 identity/standards.md | 33 +++++++++++++++++++++++----------
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/identity/standards.md b/identity/standards.md
index ca4dd6f..b73a5ef 100644
--- a/identity/standards.md
+++ b/identity/standards.md
@@ -34,7 +34,7 @@ flowchart TB
     subgraph Human["Human Identity & Authorization"]
         OAuth20["OAuth 2.0 (RFC 6749)"]:::existing
         OAuth21["OAuth 2.1"]:::existing
-        OIDC["OpenID Connect"]:::existing
+        OIDC["OpenID Connect"]:::existingF
         GNAP["GNAP (RFC 9635)"]:::existing
         AMR["AMR (RFC 8176)"]:::existing
     end
@@ -152,12 +152,24 @@ OAuth 2.0 is the foundation, but its design assumptions break for autonomous age
 | **Consent is grant-time, not action-time.** Approve scope once, client holds token until revoked. | Agents need consent that is **fresh** (user still present) and **granular** (this specific action, not just this scope). CAEP adds freshness signals; CIBA adds step-up, but **CIBA only covers client initiation**, not mid-execution re-authorization. AIMS §10.6 names this gap explicitly. | **ACS mid-execution step-up** and intent-aligned policy checks. |
 | **Scopes are pre-declared static strings** (`read`, `write`, `repo`). | Static scopes can't express per-action, per-resource, per-data-cell intent that agents operate at. | **RFC 9396 (RAR)**, required by ACS for non-trivial scopes. |
 | **Bearer tokens.** Possession is sufficient for use. | Agent memory, tool outputs, logs, and crash dumps are all token-leak surfaces. Prompt injection can exfiltrate tokens from working memory. | **DPoP (RFC 9449)** and **mTLS-bound tokens (RFC 8705)**, required by both AIMS and ACS. |
-| **Refresh tokens** assume "the same user, returning later." | Long-lived refresh tokens stored in prompt-injection-readable agent memory are the worst-case credential. | **Short-lived credentials with aggressive rotation** (AIMS §6; ACS §3.1 imposes tighter ceilings, e.g. 15 min for LLM, 5 min for MCP, 60 s for high-risk). |
+| **Access tokens can live for an hour.** [RFC 6749 §4.2.2](https://www.rfc-editor.org/rfc/rfc6749#section-4.2.2) leaves `expires_in` RECOMMENDED, not REQUIRED, and 60-minute defaults are common in production. | The agent threat surface is continuous, not session-bounded. Any access token that outlives the current reasoning step is standing authority: an indirect prompt injection landing mid-task can spend whatever the token still permits, long after the step that justified it. | **Per-step, short-lived credentials** minted close to the call (see refresh-token row); proposed ACS lifetime ceilings (open work item). |
+| **Permissions are stateless between requests.** Each API call is evaluated against the token's fixed scope; there is no concept of accumulated effective authority. | Agents with persistent memory accumulate context, credentials, and derived permissions across sessions. A token issued for Task A can remain in memory when the agent pivots to Task B, and a hijacked session inherits everything the agent has accumulated. Cross-session memory lets a compromised session poison the authority of future ones. Token scope stays fixed while de facto capability grows. | **Session-scoped credential isolation, memory-bound token invalidation, and per-action re-authorization** (ACS mid-execution step-up). Identity workstream open work item. |
+| **Refresh tokens** assume the same user returning later to resume a session. | Long-lived refresh tokens stored in prompt-injection-readable agent memory are the worst-case credential. | **Short-lived credentials with aggressive rotation** (AIMS §6 sets the baseline; tighter ACS ceilings such as 15 min for LLM, 5 min for MCP, and 60 s for high-risk actions are **proposed** and tracked as an open work item until a normative clause exists to cite). |
 | **The IdP is always reachable.** | Agents operate at machine speed. An IdP outage forces a choice between denial of service and security regression (fall back to cached credentials). Neither OAuth nor AIMS specifies a failure-mode contract. | **Open ACS work item:** fail-closed vs. fail-cached vs. tier-dependent policy. |
-| **Client behavior is deterministic.** | Restatement of row 1, and the deepest problem: every other limitation can be patched with an extension. This one **cannot**. It requires a runtime layer that observes the client, detects deviation from policy, and intercepts actions. | **ACS, by definition.** |
+| **Client behavior is deterministic.** | Restatement of row 1, and the deepest problem: every other limitation can be patched with an extension. This one **cannot**. It requires a runtime layer that confines the authenticated client to its declared intent and scope, and intercepts actions that fall outside them. | **ACS, by definition.** |
 
 > **Summary.** OAuth 2.0 plus its extensions (RAR, DPoP, mTLS-bound tokens, Token Exchange) plus the agent-specific drafts (AIMS, Transaction Tokens for Agents, Identity Chaining) cover **token issuance, binding, and propagation**. None of them cover **runtime enforcement of the authenticated agent's behavior**. That is the boundary ACS occupies.
 
+Runtime enforcement here is the identity-layer mechanism for the **Least Agency** principle from the [OWASP Top 10 for Agentic Applications](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/): agents get the minimum autonomy needed for the task, tool chains are constrained so individually safe capabilities cannot be composed into destructive ones, and agency is restricted at the action level. The controls in this document (per-call authorization against immutable intent, scope attenuation at every hop, mid-execution step-up) are how that principle gets enforced at the identity layer rather than stated as guidance.
+
+### Open Questions for the Working Group
+
+The following are real architectural questions the table above does not settle. They are recorded here as open items rather than positions.
+
+1. **Impersonation vs. delegation.** Should an agent ever impersonate a user, or must it always act on-behalf-of with attenuated scope and an explicit actor chain? The working assumption in this document is on-behalf-of only (impersonation collapses the delegation chain this workstream exists to preserve), but the position needs WG sign-off before it becomes normative.
+2. **Revocation vs. memory invalidation.** Revoking a token stops future API calls. It does not undo what the agent already read, derived, or cached under that token's access. Revocation in an agentic context may need to require purging derived context, not just killing the credential. No current standard specifies this.
+3. **Cross-resource scope union.** An agent holding valid tokens for calendar, email, and file storage has an effective permission set no single grant authorized. The dangerous triad (sensitive data access, untrusted input exposure, external communication) emerges from that union, and per-resource `aud` restrictions do not prevent it. Whether ACS should evaluate policy against the union of live credentials, rather than per-token, is open.
+
 ---
 
 ## Emerging Agent Identity Standards
@@ -173,13 +185,14 @@ The following drafts are actively shaping identity for autonomous systems, AI ag
 
 | Draft | Description | Link |
 |---|---|---|
-| **AIMS, AI Agent Authentication and Authorization** | The de facto IETF reference point for agent identity. Composes WIMSE, SPIFFE, and OAuth 2.0 into a framework for agent auth. Treats agents as workloads; mandates WIMSE identifiers, short-lived credentials, attestation-fed issuance, and OAuth-derived tokens. **Security Considerations (§14): "TODO Security"**, explicitly leaving runtime enforcement out of scope. | [draft-klrc-aiagent-auth](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/) |
+| **AIMS, AI Agent Authentication and Authorization** | The de facto IETF reference point for agent identity. Composes WIMSE, SPIFFE, and OAuth 2.0 into a framework for agent auth. Treats agents as workloads; mandates WIMSE identifiers, short-lived credentials, attestation-fed issuance, and OAuth-derived tokens. As of draft -02 (June 2026) the Security Considerations section is substantive; runtime enforcement of the authenticated agent's behavior remains out of AIMS's scope. | [draft-klrc-aiagent-auth](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/) |
 | **AAuth** (Rosenberg, White) | OAuth 2.1 extension defining an **Agent Authorization Grant** for non-redirect-based agent token acquisition. Overlaps with, and in places competes with, parts of AIMS. | [draft-rosenberg-oauth-aauth-00](https://www.ietf.org/archive/id/draft-rosenberg-oauth-aauth-00.html) |
 | **Agentic JWT** | OAuth 2.0 extension addressing zero-trust drift caused by non-deterministic agentic AI clients, where the user's intent and the client application's actions can diverge. | [draft-goswami-agentic-jwt](https://datatracker.ietf.org/doc/draft-goswami-agentic-jwt/) |
+| **OAuth Client Instance Assertions** (McGuinness) | Names *which runtime instance* of a logical OAuth client is acting (a specific agent session, container, or function invocation), via a new `actor_token_type` presented on standard grants, and extends `actor_token` beyond token exchange. Prohibits bearer tokens under the profile, requires per-instance sender-constrained keys, and gives SPIFFE first-class support. Complements AIMS at the token endpoint by making the actor granular enough for ACS runtime records to attribute actions to a single instance. | [draft-mcguinness-oauth-client-instance-assertion](https://www.ietf.org/archive/id/draft-mcguinness-oauth-client-instance-assertion-00.html) |
 
 ### Workload Identity (WIMSE)
 
-The WIMSE working group's workload identity stack that AIMS composes onto. **ACS treats WIMSE identifiers as the normative agent identifier**, with SPIFFE SVIDs as a conformant implementation.
+The WIMSE working group's workload identity stack that AIMS composes onto. This page **proposes** WIMSE identifiers as the recommended agent identifier, with SPIFFE SVIDs as a conformant implementation. Whether ACS mandates a specific identifier scheme is an open working group question. The normative position remains [docs/concepts/identity.md](https://github.com/Agent-Control-Standard/ACS/blob/main/docs/concepts/identity.md), which mandates no authentication mechanism and keeps identifier schemes off the wire; a deployment using `posix_uid` or `oauth_subject` stays conformant today.
 
 | Draft | Description | Link |
 |---|---|---|
@@ -209,7 +222,7 @@ The emerging drafts extend the existing identity foundation to answer agent-spec
 
 ### What These Drafts Do **Not** Solve
 
-These drafts establish **trust and context**. They do not decide whether the resulting action **should** execute. AIMS's own Security Considerations section reads, in full, **"TODO Security."** That gap is not an oversight; it is the boundary between identity issuance and runtime enforcement.
+These drafts establish **trust and context**. They do not decide whether the resulting action **should** execute. AIMS scopes runtime enforcement out of its model: its Security Considerations (added in draft -02, June 2026) address token, transport, and delegation risks, and stop at the point where the authenticated agent starts acting. That gap is deliberate; it is the boundary between identity issuance and runtime enforcement.
 
 They do not answer:
 
@@ -255,8 +268,8 @@ If ACS and AIMS are positioned correctly, they are **complementary, not competin
 
 | Topic | Resolution |
 |---|---|
-| **Identifier model** | **WIMSE identifier required; SPIFFE conformant.** Aligns ACS with AIMS, WIMSE WG, and NIST. |
-| **Token lifetimes** | AIMS sets the baseline; ACS ceilings (15 min LLM / 5 min MCP / 60 s high-risk) are conformance refinements. |
+| **Identifier model** | **Proposed: WIMSE identifier recommended, SPIFFE conformant.** Would align ACS with AIMS, WIMSE WG, and NIST. Pending WG sign-off and reconciliation with [docs/concepts/identity.md](https://github.com/Agent-Control-Standard/ACS/blob/main/docs/concepts/identity.md), which currently mandates no identifier scheme. |
+| **Token lifetimes** | AIMS sets the baseline; proposed ACS ceilings (15 min LLM / 5 min MCP / 60 s high-risk) are open work items pending a normative spec clause. |
 | **Sender-constrained tokens** | Both require DPoP or mTLS. Cross-reference, no divergence. |
 | **Audit logging** | ACS identity blocks **extend** AIMS minimum audit event fields rather than diverging from them. |
 
@@ -270,7 +283,7 @@ ACS specifies the runtime enforcement contract that **consumes** the identity, d
 |---|---|
 | OAuth 2.0 / 2.1 / OIDC | Human authentication and authorization (foundation; insufficient alone for agents) |
 | SPIFFE / SPIRE | Workload identity (conformant WIMSE implementation) |
-| WIMSE | Normative workload identity stack |
+| WIMSE | Workload identity stack (proposed reference model; see note under [Workload Identity](#workload-identity-wimse)) |
 | AIMS | Agent authentication and token acquisition |
 | AAuth / Agentic JWT | Alternative or complementary agent token issuance models |
 | Token Exchange + Identity Chaining | Delegation and cross-domain attenuation |
@@ -281,6 +294,6 @@ ACS specifies the runtime enforcement contract that **consumes** the identity, d
 | **ACS Crypto** | Integrity, signatures, attestations, and non-repudiation |
 | **ACS** | Runtime enforcement and policy decisions |
 
-ACS verifies identity, delegation, scope, provenance, and intent **immediately before an action executes**, and fills AIMS's open "TODO Security" gap with a runtime contract.
+ACS verifies identity, delegation, scope, provenance, and intent **immediately before an action executes**, supplying the runtime enforcement contract that AIMS leaves out of scope.
 
 > ACS does not replace these standards. ACS **composes** with them.

From 31146f2b8bb1d62bdc8e75e9235ff7612277d5b6 Mon Sep 17 00:00:00 2001
From: Eva <130791729+evabenn@users.noreply.github.com>
Date: Wed, 8 Jul 2026 18:04:46 -0700
Subject: [PATCH 4/8] address comments on identity overview

Updated the overview document to reflect the feedback in the comments

Signed-off-by: Eva <130791729+evabenn@users.noreply.github.com>
---
 identity/overview.md | 349 +++++++++++++++++++++++++++++++------------
 1 file changed, 251 insertions(+), 98 deletions(-)

diff --git a/identity/overview.md b/identity/overview.md
index 100c273..b73a5ef 100644
--- a/identity/overview.md
+++ b/identity/overview.md
@@ -1,146 +1,299 @@
-# Identity for Agents Overview
+# Related and Emerging Standards
+
+This page is the single source of truth for the identity, authentication, authorization, delegation, workload identity, and observability standards that **ACS** composes with, and for the specific gaps in those standards that ACS is designed to fill.
+
+> **ACS does not replace these standards.**
+> ACS does not recommend one implementation over another.
+> ACS does not redefine token formats, credential formats, grant flows, workload identifiers, or authentication protocols.
+
+Instead, ACS builds upon existing work from the **IETF**, **OpenID Foundation**, **SPIFFE / WIMSE community**, **OpenTelemetry**, **OCSF**, and other standards bodies, adding the runtime enforcement layer those standards intentionally do not define.
+
+The goal is simple:
+
+> **One place where builders can understand the identity landscape for agentic systems, and where ACS fits into it.**
+
+This page intentionally includes:
+
+- **Mature standards** already deployed in production (OAuth 2.0, OIDC, SPIFFE, the foundational RFCs)
+- **Emerging standards and drafts** being developed specifically for agent ecosystems (AIMS, WIMSE, Transaction Tokens, AAuth, Agentic JWT)
+- **The gaps** in both that ACS exists to address
+
+## At a Glance
+
+The diagram below frames how the standards on this page relate to each other and to ACS.
+
+```mermaid
+flowchart TB
+    subgraph Legend["Legend"]
+        direction LR
+        L1["Existing standard"]:::existing
+        L2["Emerging draft"]:::emerging
+        L3["ACS"]:::acs
+    end
+
+    subgraph Human["Human Identity & Authorization"]
+        OAuth20["OAuth 2.0 (RFC 6749)"]:::existing
+        OAuth21["OAuth 2.1"]:::existing
+        OIDC["OpenID Connect"]:::existingF
+        GNAP["GNAP (RFC 9635)"]:::existing
+        AMR["AMR (RFC 8176)"]:::existing
+    end
+
+    subgraph Workload["Workload Identity"]
+        SPIFFE["SPIFFE / SPIRE"]:::existing
+        WIMSE_ARCH["WIMSE Architecture"]:::emerging
+        WIMSE_ID["WIMSE Identifier"]:::emerging
+        WIMSE_CRED["WIMSE Credentials"]:::emerging
+        WIMSE_WPT["WIMSE WPT"]:::emerging
+        WIMSE_SIG["WIMSE HTTP Signatures"]:::emerging
+    end
+
+    subgraph Delegation["Delegation, Binding & Context"]
+        TOKEX["Token Exchange (RFC 8693)"]:::existing
+        RAR["RAR (RFC 9396)"]:::existing
+        DPOP["DPoP (RFC 9449)"]:::existing
+        MTLS["mTLS-Bound Tokens (RFC 8705)"]:::existing
+        CHAIN["OAuth Identity Chaining"]:::emerging
+        TXTOK["Transaction Tokens"]:::emerging
+        TXTOK_A["Transaction Tokens for Agents"]:::emerging
+    end
+
+    subgraph Agents["Agent-Specific Drafts"]
+        AIMS["AIMS"]:::emerging
+        AAUTH["AAuth"]:::emerging
+        AJWT["Agentic JWT"]:::emerging
+    end
+
+    subgraph Signals["Runtime Signals & Telemetry"]
+        CAEP["CAEP"]:::existing
+        SSF["Shared Signals Framework"]:::existing
+        OTEL["OpenTelemetry"]:::existing
+        TRACE["W3C Trace Context"]:::existing
+        OCSF["OCSF"]:::existing
+    end
+
+    Human --> Delegation
+    Workload --> Delegation
+    Delegation --> Agents
+    Human --> Agents
+    Workload --> Agents
+    Signals -.-> ACS
+    Agents --> ACS
+    Delegation --> ACS
+
+    ACS["ACS<br/>Runtime enforcement,<br/>intent &amp; policy decisions"]:::acs
+
+    classDef existing fill:#1f8a4c,stroke:#0e5a30,color:#fff,font-weight:bold;
+    classDef emerging fill:#e67e22,stroke:#a85a10,color:#fff,font-weight:bold;
+    classDef acs fill:#1f6feb,stroke:#0b3d91,color:#fff,font-weight:bold;
+```
 
-> **Note:** This is a working document. It is not intended to be comprehensive and will evolve as the ACS Identity workstream matures. Content, scope, and recommendations are subject to change.
->
+---
 
-There are 5 unique identity challenges that this standard aims to solve, where existing use cases that traditional identity models cannot support. It does not propose a wire format or normative requirements yet. Those will follow once the working group has aligned. This is an evolving space and we are taking a conservative approach with normative requirements.
+## Existing Standards
 
-For taxonomy and definitions, see [Core Concepts](https://github.com/Agent-Control-Standard/ACS/blob/main/docs/topics/core_concepts.md).
+The following standards are broadly adopted and form the foundation of modern identity systems.
 
-## What's Changing with Agents
+| Standard | Description | Link |
+|---|---|---|
+| **OAuth 2.0 (RFC 6749)** | The original delegated authorization framework. Defines authorization code, client credentials, and other grants. Foundational, but designed for **registered, deterministic web/native clients**. See [Why OAuth 2.0 Alone Doesn't Meet Agent Needs](#why-oauth-20-alone-doesnt-meet-agent-needs) below. | [RFC 6749](https://datatracker.ietf.org/doc/rfc6749/) |
+| **OAuth 2.1** | In-progress consolidation of OAuth 2.0 and later security best practices for delegated authorization. | [oauth.net/2.1](https://oauth.net/2.1/) |
+| **OpenID Connect (OIDC)** | Authentication layer built on OAuth that establishes human identity. | [openid.net](https://openid.net/developers/how-connect-works/) |
+| **SPIFFE / SPIRE** | Cryptographically verifiable workload identity for machines and services. A conformant implementation of the WIMSE identifier model. | [spiffe.io](https://spiffe.io/) |
+| **RFC 8693, Token Exchange** | Exchange one identity token for another with reduced scope and delegated authority. Single-hop by design; multi-hop chain semantics are **underspecified** and are being addressed by [OAuth Identity Chaining](#delegation-chains--transaction-context) and emerging agent-delegation drafts. | [RFC 8693](https://datatracker.ietf.org/doc/rfc8693/) |
+| **RFC 9396, Rich Authorization Requests (RAR)** | Fine-grained, structured authorization requests beyond traditional OAuth scopes. **Required by ACS** for non-trivial agent actions. | [RFC 9396](https://datatracker.ietf.org/doc/rfc9396/) |
+| **RFC 9449, DPoP** | Sender-constrained access tokens that reduce token theft and replay attacks. Required by AIMS and ACS for agent contexts. | [RFC 9449](https://datatracker.ietf.org/doc/rfc9449/) |
+| **RFC 8705, mTLS Certificate-Bound Tokens** | Binds access tokens to client certificates for workload-to-workload authentication. | [RFC 8705](https://datatracker.ietf.org/doc/rfc8705/) |
+| **RFC 8176, AMR** | Standardized representation of authentication strength and methods. | [RFC 8176](https://datatracker.ietf.org/doc/rfc8176/) |
+| **GNAP (RFC 9635)** | Modern authorization protocol supporting interactive and delegated authorization flows. | [RFC 9635](https://datatracker.ietf.org/doc/rfc9635/) |
+| **OpenID CIBA** | Client-Initiated Backchannel Authentication for out-of-band human approval. Used by AIMS for human-in-the-loop, but does **not** natively support mid-execution re-authorization (see [§ Why OAuth 2.0 Alone Doesn't Meet Agent Needs](#why-oauth-20-alone-doesnt-meet-agent-needs)). | [CIBA Core](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) |
+| **CAEP** | Continuous Access Evaluation Profile for near real-time session revocation and risk signaling. | [CAEP 1.0](https://openid.net/specs/openid-caep-specification-1_0.html) |
+| **OpenID Shared Signals Framework (SSF)** | Standardized risk, security, and session-change event sharing between systems. Adopted by AIMS as the eventing transport. | [Shared Signals WG](https://openid.net/wg/sharedsignals/) |
+| **W3C Trace Context** | Standardized trace propagation across distributed systems. | [W3C Trace Context](https://www.w3.org/TR/trace-context/) |
+| **OpenTelemetry** | Open standard for distributed tracing, metrics, and observability. | [opentelemetry.io](https://opentelemetry.io/) |
+| **OCSF** | Open Cybersecurity Schema Framework for normalized security telemetry. | [schema.ocsf.io](https://schema.ocsf.io/) |
 
-For decades, application security worked because software was deterministic.
+### What These Standards Solve
 
-A traditional application follows a predefined execution path. Security teams can inspect the code, review dependencies, define permissions, and understand expected behavior before deployment. Identity policies can be established in advance because the software's capabilities are known before it runs. A car rental website cannot suddenly provide therapy advice, manage payroll, or execute financial transactions because those capabilities do not exist in its code.
+Collectively, the mature standards above answer foundational identity questions:
 
-```text
-Traditional Software
+- **Who** is the actor?
+- **How** does the actor authenticate?
+- **How** are credentials issued?
+- **How** is delegated authority represented (single-hop)?
+- **How** are workloads identified?
+- **How** is request context propagated?
+- **How** is trust transferred across systems?
 
-Code
-  ↓
-Dependencies
-  ↓
-Permissions
-  ↓
-Execution
+### What These Standards Do **Not** Solve
 
-Behavior Known Before Runtime
-```
+These standards establish **trust**. They do not determine whether an action **should** happen, and several were not designed with autonomous, non-deterministic agents in mind.
 
-Large Language Models (LLMs) introduced a fundamentally different execution model. Unlike traditional software, an LLM does not execute a fixed sequence of instructions. It generates outputs probabilistically based on its training data, prompts, and context. The same prompt can produce different outputs across executions.
+They do not:
 
-```text
-Prompt
-  ↓
-Model Reasoning
-  ↓
-Generated Output
+- Evaluate intent
+- Detect prompt injection or memory poisoning
+- Decide whether delegated authority remains appropriate after runtime reasoning changes course
+- Verify multi-hop delegation chain integrity end-to-end
+- Specify failure-mode behavior when the IdP is unreachable
 
-Behavior Determined At Runtime
-```
+> Those questions belong to **ACS**.
+
+---
 
-This introduced non-determinism into systems that had previously been predictable. On its own, however, an LLM is mostly generating text. Agents act, plan, call tools, invoke other agents, and reach production systems in milliseconds. Today most of them act under a borrowed human identity or a single static service account. That breaks accountability, breaks least-privilege, and makes the ACS Trace pillar lie about who did what.
+## Why OAuth 2.0 Alone Doesn't Meet Agent Needs
 
-At runtime an agent determines:
+OAuth 2.0 is the foundation, but its design assumptions break for autonomous agents. The drafts under [Emerging Agent Identity Standards](#emerging-agent-identity-standards) (AIMS, AAuth, Agentic JWT, Transaction Tokens for Agents, and OAuth Identity Chaining) exist precisely because of these gaps. ACS addresses the **runtime** subset.
 
-- What tool to call
-- What data to retrieve
-- Which API to invoke
-- Whether to delegate to another agent
-- What action to perform
+| OAuth 2.0 Assumption | How Agents Break It | What Addresses It |
+|---|---|---|
+| **The client is a stable, registered software identity** with approximately constant behavior. | An agent's execution path is composed at runtime by a non-deterministic model over inputs that may include adversarial content (indirect prompt injection). A registered client with valid credentials can have its reasoning hijacked. OAuth client auth cannot distinguish "authenticated and behaving" from "authenticated and hijacked." | **ACS runtime enforcement.** No token-issuance standard can patch this; it requires inline behavioral verification at action time. |
+| **Delegation is single-hop** (`user → client → resource server`). | Agent chains are `user → orchestrator → sub-agent → tool → API`. RFC 8693 Token Exchange retrofits multi-hop but leaves chain verification, mandatory scope attenuation, and revocation propagation unspecified. A **delegation chain splicing vulnerability** was disclosed on the OAuth WG list in February 2026. | OAuth Identity Chaining draft; AIMS §10.5; **ACS delegation-integrity checks** at every hop. |
+| **Consent is grant-time, not action-time.** Approve scope once, client holds token until revoked. | Agents need consent that is **fresh** (user still present) and **granular** (this specific action, not just this scope). CAEP adds freshness signals; CIBA adds step-up, but **CIBA only covers client initiation**, not mid-execution re-authorization. AIMS §10.6 names this gap explicitly. | **ACS mid-execution step-up** and intent-aligned policy checks. |
+| **Scopes are pre-declared static strings** (`read`, `write`, `repo`). | Static scopes can't express per-action, per-resource, per-data-cell intent that agents operate at. | **RFC 9396 (RAR)**, required by ACS for non-trivial scopes. |
+| **Bearer tokens.** Possession is sufficient for use. | Agent memory, tool outputs, logs, and crash dumps are all token-leak surfaces. Prompt injection can exfiltrate tokens from working memory. | **DPoP (RFC 9449)** and **mTLS-bound tokens (RFC 8705)**, required by both AIMS and ACS. |
+| **Access tokens can live for an hour.** [RFC 6749 §4.2.2](https://www.rfc-editor.org/rfc/rfc6749#section-4.2.2) leaves `expires_in` RECOMMENDED, not REQUIRED, and 60-minute defaults are common in production. | The agent threat surface is continuous, not session-bounded. Any access token that outlives the current reasoning step is standing authority: an indirect prompt injection landing mid-task can spend whatever the token still permits, long after the step that justified it. | **Per-step, short-lived credentials** minted close to the call (see refresh-token row); proposed ACS lifetime ceilings (open work item). |
+| **Permissions are stateless between requests.** Each API call is evaluated against the token's fixed scope; there is no concept of accumulated effective authority. | Agents with persistent memory accumulate context, credentials, and derived permissions across sessions. A token issued for Task A can remain in memory when the agent pivots to Task B, and a hijacked session inherits everything the agent has accumulated. Cross-session memory lets a compromised session poison the authority of future ones. Token scope stays fixed while de facto capability grows. | **Session-scoped credential isolation, memory-bound token invalidation, and per-action re-authorization** (ACS mid-execution step-up). Identity workstream open work item. |
+| **Refresh tokens** assume the same user returning later to resume a session. | Long-lived refresh tokens stored in prompt-injection-readable agent memory are the worst-case credential. | **Short-lived credentials with aggressive rotation** (AIMS §6 sets the baseline; tighter ACS ceilings such as 15 min for LLM, 5 min for MCP, and 60 s for high-risk actions are **proposed** and tracked as an open work item until a normative clause exists to cite). |
+| **The IdP is always reachable.** | Agents operate at machine speed. An IdP outage forces a choice between denial of service and security regression (fall back to cached credentials). Neither OAuth nor AIMS specifies a failure-mode contract. | **Open ACS work item:** fail-closed vs. fail-cached vs. tier-dependent policy. |
+| **Client behavior is deterministic.** | Restatement of row 1, and the deepest problem: every other limitation can be patched with an extension. This one **cannot**. It requires a runtime layer that confines the authenticated client to its declared intent and scope, and intercepts actions that fall outside them. | **ACS, by definition.** |
 
-The effective execution path is assembled dynamically while the system is running.
+> **Summary.** OAuth 2.0 plus its extensions (RAR, DPoP, mTLS-bound tokens, Token Exchange) plus the agent-specific drafts (AIMS, Transaction Tokens for Agents, Identity Chaining) cover **token issuance, binding, and propagation**. None of them cover **runtime enforcement of the authenticated agent's behavior**. That is the boundary ACS occupies.
 
-```text
-Agent
+Runtime enforcement here is the identity-layer mechanism for the **Least Agency** principle from the [OWASP Top 10 for Agentic Applications](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/): agents get the minimum autonomy needed for the task, tool chains are constrained so individually safe capabilities cannot be composed into destructive ones, and agency is restricted at the action level. The controls in this document (per-call authorization against immutable intent, scope attenuation at every hop, mid-execution step-up) are how that principle gets enforced at the identity layer rather than stated as guidance.
 
-Goal
-  ↓
-Model Reasoning
-  ↓
-Tool Selection
-  ↓
-Data Retrieval
-  ↓
-Delegation
-  ↓
-Action
+### Open Questions for the Working Group
 
-Behavior Composed During Runtime
-```
+The following are real architectural questions the table above does not settle. They are recorded here as open items rather than positions.
 
-Two executions of the same agent on the same task can take entirely different paths. Recent academic work characterizes this as agents resolving capability *probabilistically* at runtime rather than at build time — see *SOK: A Taxonomy of Attack Vectors and Defense Strategies for Agentic Supply Chain Runtime* ([arXiv:2602.19555](https://arxiv.org/abs/2602.19555)), which describes how agentic systems shift the attack surface from build-time dependencies to *inference-time* dependencies assembled from untrusted data and probabilistic capability resolution. Unlike traditional software, where dependencies are resolved before deployment, agentic systems assemble portions of their effective execution context at runtime. Retrieved documents, tool outputs, external APIs, memory entries, and other agents become runtime dependencies selected through probabilistic reasoning rather than predetermined code paths.
+1. **Impersonation vs. delegation.** Should an agent ever impersonate a user, or must it always act on-behalf-of with attenuated scope and an explicit actor chain? The working assumption in this document is on-behalf-of only (impersonation collapses the delegation chain this workstream exists to preserve), but the position needs WG sign-off before it becomes normative.
+2. **Revocation vs. memory invalidation.** Revoking a token stops future API calls. It does not undo what the agent already read, derived, or cached under that token's access. Revocation in an agentic context may need to require purging derived context, not just killing the credential. No current standard specifies this.
+3. **Cross-resource scope union.** An agent holding valid tokens for calendar, email, and file storage has an effective permission set no single grant authorized. The dangerous triad (sensitive data access, untrusted input exposure, external communication) emerges from that union, and per-resource `aud` restrictions do not prevent it. Whether ACS should evaluate policy against the union of live credentials, rather than per-token, is open.
 
-This breaks the assumptions identity standards were designed around. Human identity standards assume a long-lived principal, a session, and a narrow blast radius per action. Workload identity standards assume the workload's behavior is determined by its code. Neither holds for agents.
+---
 
-Traditional identity models assume:
+## Emerging Agent Identity Standards
 
-- The actor is known
-- The execution path is known
-- The permissions are known
-- The delegation chain is known
+> **Status Note: these are Internet-Drafts.**
+> All drafts in this section are **Internet-Drafts** and have **not yet been ratified as RFCs**. Internet-Drafts are working documents and may be revised, replaced, or withdrawn at any time. The authoritative source for any draft's status is its Datatracker landing page. ACS deliberately tracks landing pages rather than pinning revisions.
 
-Agent systems invalidate all four assumptions.
+The following drafts are actively shaping identity for autonomous systems, AI agents, and machine-to-machine delegation. ACS tracks them closely because they address identity problems that traditional IAM systems were never designed to solve.
 
-The question is no longer:
+> **NIST signal.** The **NIST AI Agent Standards Initiative** (February 2026, NCCoE concept paper on agent identity and authorization) references this body of IETF work. ACS aligns with the same reference points.
 
-> Who is the principal?
+### Agent Authentication & Authorization
 
-The question becomes:
+| Draft | Description | Link |
+|---|---|---|
+| **AIMS, AI Agent Authentication and Authorization** | The de facto IETF reference point for agent identity. Composes WIMSE, SPIFFE, and OAuth 2.0 into a framework for agent auth. Treats agents as workloads; mandates WIMSE identifiers, short-lived credentials, attestation-fed issuance, and OAuth-derived tokens. As of draft -02 (June 2026) the Security Considerations section is substantive; runtime enforcement of the authenticated agent's behavior remains out of AIMS's scope. | [draft-klrc-aiagent-auth](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/) |
+| **AAuth** (Rosenberg, White) | OAuth 2.1 extension defining an **Agent Authorization Grant** for non-redirect-based agent token acquisition. Overlaps with, and in places competes with, parts of AIMS. | [draft-rosenberg-oauth-aauth-00](https://www.ietf.org/archive/id/draft-rosenberg-oauth-aauth-00.html) |
+| **Agentic JWT** | OAuth 2.0 extension addressing zero-trust drift caused by non-deterministic agentic AI clients, where the user's intent and the client application's actions can diverge. | [draft-goswami-agentic-jwt](https://datatracker.ietf.org/doc/draft-goswami-agentic-jwt/) |
+| **OAuth Client Instance Assertions** (McGuinness) | Names *which runtime instance* of a logical OAuth client is acting (a specific agent session, container, or function invocation), via a new `actor_token_type` presented on standard grants, and extends `actor_token` beyond token exchange. Prohibits bearer tokens under the profile, requires per-instance sender-constrained keys, and gives SPIFFE first-class support. Complements AIMS at the token endpoint by making the actor granular enough for ACS runtime records to attribute actions to a single instance. | [draft-mcguinness-oauth-client-instance-assertion](https://www.ietf.org/archive/id/draft-mcguinness-oauth-client-instance-assertion-00.html) |
 
-> Who is acting, on whose behalf, for what purpose, using what authority, through which delegation chain, at this moment?
+### Workload Identity (WIMSE)
 
-That is the runtime identity problem ACS aims to solve.
+The WIMSE working group's workload identity stack that AIMS composes onto. This page **proposes** WIMSE identifiers as the recommended agent identifier, with SPIFFE SVIDs as a conformant implementation. Whether ACS mandates a specific identifier scheme is an open working group question. The normative position remains [docs/concepts/identity.md](https://github.com/Agent-Control-Standard/ACS/blob/main/docs/concepts/identity.md), which mandates no authentication mechanism and keeps identifier schemes off the wire; a deployment using `posix_uid` or `oauth_subject` stays conformant today.
 
-An agent has a goal, a set of tools, some memory, and a model that decides at runtime what to call next, in what order, with what arguments. The effective code path is composed in the moment, by a non-deterministic component, based on whatever the agent just read. The supply chain you signed off on at build time is not the supply chain that executes.
+| Draft | Description | Link |
+|---|---|---|
+| **WIMSE Architecture** | Architectural model for workload identity across systems and trust domains. | [draft-ietf-wimse-arch](https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/) |
+| **WIMSE Workload Identifier** | URI format used to uniquely identify workloads and agents. | [draft-ietf-wimse-identifier](https://datatracker.ietf.org/doc/draft-ietf-wimse-identifier/) |
+| **WIMSE Workload Credentials** | Credential formats workloads use to prove identity ownership. | [draft-ietf-wimse-workload-creds](https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/) |
+| **WIMSE Workload Proof Token (WPT)** | Application-layer authentication tokens for workload-to-workload communication. | [draft-ietf-wimse-wpt](https://datatracker.ietf.org/doc/draft-ietf-wimse-wpt/) |
+| **WIMSE HTTP Message Signatures** | Request signing using workload credentials. | [draft-ietf-wimse-http-signature](https://datatracker.ietf.org/doc/draft-ietf-wimse-http-signature/) |
 
-A single tool call can chain through nine or more identities: the human user, the platform, the orchestrator, one or more sub-agents, the model, the tool, the downstream API, the trigger source, and the data subject. Each hop needs its own scope. Each hop needs to be verifiable. Today, identity at runtime is usually one or two of those at best.
+### Delegation Chains & Transaction Context
 
-```text
-Human ──delegates──▶ Orchestrator Agent ──delegates──▶ Sub-Agent ──invokes──▶ Tool ──acts on──▶ Resource
-   │                       │                              │                     │
-   │                       ▼                              ▼                     ▼
-   │              ingests RAG / docs / web      may spawn more sub-agents   external write
-   │              (untrusted instructions)                                   (irreversible)
-   │
-   └──── audit subject: which link in this chain, under which intent? ────────────────▶
-```
+| Draft | Description | Link |
+|---|---|---|
+| **OAuth Identity and Authorization Chaining Across Domains** | How delegation chains propagate across trust boundaries and administrative domains. Referenced by AIMS §10.5. Addresses (in part) the multi-hop gap in RFC 8693. | [draft-ietf-oauth-identity-chaining](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/) |
+| **Transaction Tokens** | Downscopes access tokens to specific transactions; mitigates token replay between microservices. Referenced by AIMS §10.4. | [draft-ietf-oauth-transaction-tokens](https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/) |
+| **Transaction Tokens for Agents** | Extends Transaction Tokens with agent-specific delegation chains, actor transitions, hop metadata, and trust attenuation. | [draft-araut-oauth-transaction-tokens-for-agents](https://datatracker.ietf.org/doc/draft-araut-oauth-transaction-tokens-for-agents/) |
 
-Agent systems are introducing a new class of failures where every token is valid, every API call is authorized, and the outcome is still a security incident.
+### What These Drafts Solve
 
----
+The emerging drafts extend the existing identity foundation to answer agent-specific questions:
 
-## The 5 Unique Runtime Identity Challenges for Agents
+- **How** does an autonomous agent acquire tokens without a redirect-based human flow?
+- **How** is a delegation chain represented across multiple agent hops?
+- **How** is the difference between a user's intent and an agent's actions captured in a token?
+- **How** do workloads and agents present cryptographic identity at the application layer?
+- **How** does transaction context survive across microservice and trust-domain boundaries?
 
-These are the five unique runtime identity challenges that distinguish agent systems from human or workload identity. Each one is a place where existing standards fall short and where the ACS Identity workstream is concentrating its effort. The list is deliberately tight: every challenge below is genuinely distinct and together they cover the runtime surface that today's identity standards do not.
+### What These Drafts Do **Not** Solve
 
-A concrete example that illustrates several of these challenges is Palo Alto Networks Unit 42's 2025 research, *[Agent Session Smuggling in Agent2Agent Systems](https://unit42.paloaltonetworks.com/agent-session-smuggling-in-agent2agent-systems/)*. In the demonstrated attack, a malicious agent injected hidden instructions into a legitimate Agent2Agent (A2A) session. The victim agent subsequently disclosed sensitive information and performed unauthorized actions while using valid credentials and authorized APIs. Authentication and authorization succeeded. The failure occurred because the runtime could not distinguish user intent from adversarial instructions introduced during execution. This illustrates the central identity challenge of agent systems.
+These drafts establish **trust and context**. They do not decide whether the resulting action **should** execute. AIMS scopes runtime enforcement out of its model: its Security Considerations (added in draft -02, June 2026) address token, transport, and delegation risks, and stop at the point where the authenticated agent starts acting. That gap is deliberate; it is the boundary between identity issuance and runtime enforcement.
 
-| # | Challenge / Question | Why It's Challenging | Standards Today That Aren't Sufficient | What Needs to Change for Runtime | ACS Mechanism |
-|---|---|---|---|---|---|
-| 1 | **Chain Integrity**<br/>*Can the full delegation chain be named and verified end-to-end?* | A single agent task can chain through five to ten identities: user → orchestrator → sub-agent → tool → downstream API. Two failures compound: the chain is not *named* (audit collapses into "the agent did it"), and the chain is not *verifiable* (downstream resources cannot confirm the chain without trusting every intermediary). In practice the full chain is often not reconstructable end-to-end, and there is a known class of attacks where the chain itself can be spliced. | **[OAuth 2.0](https://www.rfc-editor.org/rfc/rfc6749) access tokens** identify the bearer, not the chain.<br/>**[OIDC Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html) ID tokens** name the human at the start but lose granularity at each hop.<br/>**[SPIFFE SVIDs](https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/)** identify the workload but not which call within it.<br/>**[OAuth Token Exchange (RFC 8693)](https://www.rfc-editor.org/rfc/rfc8693)** defines nested `act` claims that can express a chain, but per [§4.1](https://www.rfc-editor.org/rfc/rfc8693#section-4.1) *"prior actors identified by any nested `act` claims are informational only and are not to be considered in access control decisions."* The chain is recorded, not normatively enforceable.<br/>**[OAuth Identity Chaining draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/)** and **[Transaction Tokens draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/)** address parts but specify neither chain verification rules nor revocation propagation as required runtime behavior.<br/>**[W3C Trace Context](https://www.w3.org/TR/trace-context/)** correlates but [does not authenticate](https://www.w3.org/TR/trace-context/#privacy-of-traceparent-field). | Every action must produce, at the moment of execution, a signed record that names the specific link in the chain and lets any participant (including the downstream resource) verify the entire chain end-to-end without trusting any intermediary. Cryptographic chain structure, mandatory scope attenuation at every hop, revocation propagation. | Pending |
-| 2 | **Over-Privilege**<br/>*Was this action within the agent's purpose?* | Agents inherit broad standing privileges. Service accounts. Long-lived API keys. OAuth scopes designed for human applications. One compromised agent has the union of every permission anyone has ever granted to it. The fix is not bigger scopes; the fix is no standing privilege. | **[OAuth scopes (RFC 6749 §3.3)](https://www.rfc-editor.org/rfc/rfc6749#section-3.3)** are coarse, deployment-defined strings (e.g. `read`, `write`, `repo`). Per **[RFC 9396 §1](https://www.rfc-editor.org/rfc/rfc9396#section-1)**, scope is "sufficient... for coarse-grained authorization requests" but "not sufficient to specify fine-grained authorization requirements" — it does not express per-action, per-resource, per-data-cell intent.<br/>**RBAC and ABAC** scope by role or attribute, granted once, evaluated coarsely.<br/>**AIMS** does not require **[RAR (RFC 9396)](https://www.rfc-editor.org/rfc/rfc9396)** and treats scope semantics as deployment-specific. | Credentials minted just before the call, scoped to one downstream callee, structured (per-action, per-resource), expired in minutes. Authorization evaluated per-call against the immutable intent for the run, not per-session. | Pending |
-| 3 | **Token Theft Resistance**<br/>*If a token leaks from agent memory, is it useless to the attacker?* | The agent threat model breaks OAuth's bearer-token assumption entirely. Prompt injection can exfiltrate tokens from memory. Tool outputs can leak tokens. Sub-agents can replay tokens. Logs and crash dumps capture tokens. Long-lived refresh tokens in agent memory are the worst case: a durable credential held in storage that any indirect prompt injection can read. | **[OAuth 2.0 Bearer Tokens (RFC 6750 §1.2)](https://www.rfc-editor.org/rfc/rfc6750#section-1.2)** explicitly treat possession as sufficient: *"Using a bearer token does not require a bearer to prove possession of cryptographic key material."*<br/>**API keys** are bearer secrets by definition.<br/>**[OAuth refresh tokens (RFC 6749 §1.5)](https://www.rfc-editor.org/rfc/rfc6749#section-1.5)** were designed for "the same user, returning later," which does not describe how agents work.<br/>**[DPoP (RFC 9449)](https://www.rfc-editor.org/rfc/rfc9449)** and **[OAuth 2.0 Mutual-TLS Certificate-Bound Access Tokens (RFC 8705)](https://www.rfc-editor.org/rfc/rfc8705)** solve sender-constraint but are optional extensions that most deployments do not enforce.<br/>None of these are required by the OAuth core. | All non-trivial tokens sender-constrained (DPoP or mTLS) so a leaked token is useless without the corresponding private key. Aggressive lifetime ceilings measured in minutes or seconds, not hours. No long-lived secrets in model-visible context. Credentials fetched at task start, used within a tight window, discarded at task end. | Pending |
-| 4 | **Last-Mile Enforcement**<br/>*Did the resource actually enforce the decision, on every call, inside the runtime?* | The moment the action reaches a production system. All upstream identity work either holds here or fails here. Most systems today cannot distinguish an authorized action by an agent acting in good faith from the same call by an agent hijacked by indirect prompt injection. Gateway-only enforcement misses tool calls and sub-agent invocations that never cross a gateway. Cached decisions miss revocation, scope change, and freshly-discovered taint. | **API gateways and service meshes** enforce at the edge; agent tool calls never reach them.<br/>**[OAuth 2.0 resource servers (RFC 6749 §1.1)](https://www.rfc-editor.org/rfc/rfc6749#section-1.1)** validate the token but not the action's relationship to intent.<br/>**[mTLS (RFC 8705)](https://www.rfc-editor.org/rfc/rfc8705)** and **[SPIFFE](https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/)** establish workload identity but do not enforce per-action policy.<br/>None fire inside the agent runtime where the decision is made. | Enforcement fires at every tool call, inside the agent runtime, before the action executes. The runtime verifies identity, scope, taint, freshness, and intent on every call. No cached decisions; the LLM call cost dwarfs the re-authorization cost. Default-deny verified by a negative test in CI. | Pending |
-| 5 | **Proof of Intent**<br/>*Was the action bound to an immutable, declared purpose that survives mid-task reframing?* | OAuth scopes say what the user *can* do. They do not say what the user *is doing right now*. Without intent binding at runtime, every agent action is a guess about user authorization. The agent's reasoning can be reframed mid-task by an instruction hidden in a document or a tool output. The original intent has to survive that. This is the hardest of the five, because it is the only one OAuth cannot patch with an extension: the underlying problem is non-deterministic client behavior under adversarial inputs. | **None at the identity layer.** Intent is implicit in the OAuth consent screen and discarded after token issuance.<br/>**[RFC 9396 RAR](https://www.rfc-editor.org/rfc/rfc9396)** can carry purpose claims as `authorization_details` data but does not bind them as runtime invariants against the LLM client.<br/>**IBAC (Intent-Based Access Control)** is research-stage with no IETF/W3C standard track.<br/>No production standard treats intent as a first-class, immutable, normatively-enforced runtime invariant. | Intent treated as a first-class governance concept with a normative immutability invariant. Intent must flow across all three ACS pillars: Instrument fires decisions against it, Trace records it as a span attribute, Inspect catalogs what it authorized. Intent extension permitted only through an explicit, human-approved path. | Pending |
+They do not answer:
+
+- Should this action happen, given current intent and observed agent state?
+- Has the agent been influenced by untrusted content since the token was issued?
+- Has the delegation chain become unsafe mid-execution?
+- Should mid-execution user re-authorization fire **right now** (a gap CIBA does not cover)?
+- What happens when the IdP is unreachable and the agent is mid-task?
+
+> Those questions belong to **ACS**.
 
 ---
 
-## What this Identity workstream is not trying to do
+## The ACS ↔ AIMS Composition Boundary
+
+If ACS and AIMS are positioned correctly, they are **complementary, not competing**.
+
+### AIMS handles, ACS does not need to
+
+- Agent identifier issuance and structure (WIMSE identifier; SPIFFE as a conformant implementation)
+- Cryptographic binding of credentials to identifier (WIMSE credentials, SPIFFE SVIDs)
+- Credential provisioning, rotation, and lifecycle
+- Attestation feeding credential issuance
+- Transport and application-layer authentication (mTLS, WIMSE Proof Tokens, HTTP Message Signatures)
+- OAuth grant flows for agent token acquisition
+- Cross-domain token exchange (Identity Chaining, JWT Authorization Grant)
+- Token format and discovery metadata
+- Eventing transport for security signals (Shared Signals + CAEP / RISC)
 
-- **Replace existing Identity Standards like OAuth, OIDC, SPIFFE.** ACS-Identity composes with them.
-- **Specify a new agent framework.** The mechanisms must work for any framework that can emit a signed action record.
+### ACS handles, AIMS does not
 
-## How ACS-Identity composes with the rest of ACS
+- **Runtime policy enforcement** as a policy decision point that returns allow / deny / modify verdicts inline, before an action reaches a production system
+- **Hook-level identity validation:** re-checking identity, delegation chain, and attestation at every agent decision point, not just at token issuance
+- **Tainted-input handling:** tracking which agent invocations have ingested untrusted content and denying writes from tainted contexts
+- **Mid-execution step-up:** the runtime layer that recognizes when a CIBA challenge should fire (the gap AIMS §10.6 explicitly names)
+- **AgBOM enumeration:** dynamic inventory of every model, tool, capability, knowledge source, and dependency, joined to identity at runtime
+- **Control set tiers (0–3):** conformance bundles mapping deployment risk to identity controls
+- **Embedded sub-agent identity:** the case AIMS §10.3.3 collapses to "agents accessed by other agents"
+- **Cross-platform conformance:** bridging AWS, Azure, GCP primitives to a single runtime enforcement model
+- **The OAuth gaps from the table above:** IdP unavailability and non-deterministic client behavior
+
+### Where ACS and AIMS overlap (resolved in favor of AIMS where appropriate)
+
+| Topic | Resolution |
+|---|---|
+| **Identifier model** | **Proposed: WIMSE identifier recommended, SPIFFE conformant.** Would align ACS with AIMS, WIMSE WG, and NIST. Pending WG sign-off and reconciliation with [docs/concepts/identity.md](https://github.com/Agent-Control-Standard/ACS/blob/main/docs/concepts/identity.md), which currently mandates no identifier scheme. |
+| **Token lifetimes** | AIMS sets the baseline; proposed ACS ceilings (15 min LLM / 5 min MCP / 60 s high-risk) are open work items pending a normative spec clause. |
+| **Sender-constrained tokens** | Both require DPoP or mTLS. Cross-reference, no divergence. |
+| **Audit logging** | ACS identity blocks **extend** AIMS minimum audit event fields rather than diverging from them. |
+
+---
 
-ACS-Identity is one of seven cross-cutting concepts (Identity, Provenance, Trust, Intent, Capability, Agents, Session Lifecycle). It produces signals that the three pillars consume:
+## Responsibility Map
 
-- **Instrument** fires authorization decisions against identity + intent + taint.
-- **Trace** records each chain link as a span attribute (signed, verifiable).
-- **Inspect** catalogs which agent, under which intent, exercised which capability.
+ACS specifies the runtime enforcement contract that **consumes** the identity, delegation, workload, and transaction context produced by the standards above.
 
-Identity does not solve any of the five challenges alone. It composes with Provenance (taint), Capability (what the agent is allowed to do at all), and Intent (what it is doing right now).
+| Layer | Responsibility |
+|---|---|
+| OAuth 2.0 / 2.1 / OIDC | Human authentication and authorization (foundation; insufficient alone for agents) |
+| SPIFFE / SPIRE | Workload identity (conformant WIMSE implementation) |
+| WIMSE | Workload identity stack (proposed reference model; see note under [Workload Identity](#workload-identity-wimse)) |
+| AIMS | Agent authentication and token acquisition |
+| AAuth / Agentic JWT | Alternative or complementary agent token issuance models |
+| Token Exchange + Identity Chaining | Delegation and cross-domain attenuation |
+| Transaction Tokens (+ for Agents) | Request and agent-chain context propagation |
+| CAEP / SSF | Continuous risk and session signaling |
+| **ACS Identity** | Runtime identity verification |
+| **ACS Provenance** | Origin and lineage verification |
+| **ACS Crypto** | Integrity, signatures, attestations, and non-repudiation |
+| **ACS** | Runtime enforcement and policy decisions |
 
-## Read Next
+ACS verifies identity, delegation, scope, provenance, and intent **immediately before an action executes**, supplying the runtime enforcement contract that AIMS leaves out of scope.
 
-- [ACS in Action](./ACS_in_action_example.md)
+> ACS does not replace these standards. ACS **composes** with them.

From 390282cc0b8e576c614863ff5a91bc0cde96ebad Mon Sep 17 00:00:00 2001
From: Eva <130791729+evabenn@users.noreply.github.com>
Date: Wed, 8 Jul 2026 18:09:57 -0700
Subject: [PATCH 5/8] Revise identity standards overview to address comments

Updated the identity standards document to focus on agents, outlining unique identity challenges and how ACS addresses them. Added sections on existing and emerging standards, and clarified the relationship between ACS and AIMS.

Signed-off-by: Eva <130791729+evabenn@users.noreply.github.com>
---
 identity/overview.md | 349 ++++++++++++-------------------------------
 1 file changed, 98 insertions(+), 251 deletions(-)

diff --git a/identity/overview.md b/identity/overview.md
index b73a5ef..969ca7b 100644
--- a/identity/overview.md
+++ b/identity/overview.md
@@ -1,299 +1,146 @@
-# Related and Emerging Standards
-
-This page is the single source of truth for the identity, authentication, authorization, delegation, workload identity, and observability standards that **ACS** composes with, and for the specific gaps in those standards that ACS is designed to fill.
-
-> **ACS does not replace these standards.**
-> ACS does not recommend one implementation over another.
-> ACS does not redefine token formats, credential formats, grant flows, workload identifiers, or authentication protocols.
-
-Instead, ACS builds upon existing work from the **IETF**, **OpenID Foundation**, **SPIFFE / WIMSE community**, **OpenTelemetry**, **OCSF**, and other standards bodies, adding the runtime enforcement layer those standards intentionally do not define.
-
-The goal is simple:
-
-> **One place where builders can understand the identity landscape for agentic systems, and where ACS fits into it.**
-
-This page intentionally includes:
-
-- **Mature standards** already deployed in production (OAuth 2.0, OIDC, SPIFFE, the foundational RFCs)
-- **Emerging standards and drafts** being developed specifically for agent ecosystems (AIMS, WIMSE, Transaction Tokens, AAuth, Agentic JWT)
-- **The gaps** in both that ACS exists to address
-
-## At a Glance
-
-The diagram below frames how the standards on this page relate to each other and to ACS.
-
-```mermaid
-flowchart TB
-    subgraph Legend["Legend"]
-        direction LR
-        L1["Existing standard"]:::existing
-        L2["Emerging draft"]:::emerging
-        L3["ACS"]:::acs
-    end
-
-    subgraph Human["Human Identity & Authorization"]
-        OAuth20["OAuth 2.0 (RFC 6749)"]:::existing
-        OAuth21["OAuth 2.1"]:::existing
-        OIDC["OpenID Connect"]:::existingF
-        GNAP["GNAP (RFC 9635)"]:::existing
-        AMR["AMR (RFC 8176)"]:::existing
-    end
-
-    subgraph Workload["Workload Identity"]
-        SPIFFE["SPIFFE / SPIRE"]:::existing
-        WIMSE_ARCH["WIMSE Architecture"]:::emerging
-        WIMSE_ID["WIMSE Identifier"]:::emerging
-        WIMSE_CRED["WIMSE Credentials"]:::emerging
-        WIMSE_WPT["WIMSE WPT"]:::emerging
-        WIMSE_SIG["WIMSE HTTP Signatures"]:::emerging
-    end
-
-    subgraph Delegation["Delegation, Binding & Context"]
-        TOKEX["Token Exchange (RFC 8693)"]:::existing
-        RAR["RAR (RFC 9396)"]:::existing
-        DPOP["DPoP (RFC 9449)"]:::existing
-        MTLS["mTLS-Bound Tokens (RFC 8705)"]:::existing
-        CHAIN["OAuth Identity Chaining"]:::emerging
-        TXTOK["Transaction Tokens"]:::emerging
-        TXTOK_A["Transaction Tokens for Agents"]:::emerging
-    end
-
-    subgraph Agents["Agent-Specific Drafts"]
-        AIMS["AIMS"]:::emerging
-        AAUTH["AAuth"]:::emerging
-        AJWT["Agentic JWT"]:::emerging
-    end
-
-    subgraph Signals["Runtime Signals & Telemetry"]
-        CAEP["CAEP"]:::existing
-        SSF["Shared Signals Framework"]:::existing
-        OTEL["OpenTelemetry"]:::existing
-        TRACE["W3C Trace Context"]:::existing
-        OCSF["OCSF"]:::existing
-    end
-
-    Human --> Delegation
-    Workload --> Delegation
-    Delegation --> Agents
-    Human --> Agents
-    Workload --> Agents
-    Signals -.-> ACS
-    Agents --> ACS
-    Delegation --> ACS
-
-    ACS["ACS<br/>Runtime enforcement,<br/>intent &amp; policy decisions"]:::acs
-
-    classDef existing fill:#1f8a4c,stroke:#0e5a30,color:#fff,font-weight:bold;
-    classDef emerging fill:#e67e22,stroke:#a85a10,color:#fff,font-weight:bold;
-    classDef acs fill:#1f6feb,stroke:#0b3d91,color:#fff,font-weight:bold;
-```
-
----
-
-## Existing Standards
-
-The following standards are broadly adopted and form the foundation of modern identity systems.
+# Identity for Agents Overview
 
-| Standard | Description | Link |
-|---|---|---|
-| **OAuth 2.0 (RFC 6749)** | The original delegated authorization framework. Defines authorization code, client credentials, and other grants. Foundational, but designed for **registered, deterministic web/native clients**. See [Why OAuth 2.0 Alone Doesn't Meet Agent Needs](#why-oauth-20-alone-doesnt-meet-agent-needs) below. | [RFC 6749](https://datatracker.ietf.org/doc/rfc6749/) |
-| **OAuth 2.1** | In-progress consolidation of OAuth 2.0 and later security best practices for delegated authorization. | [oauth.net/2.1](https://oauth.net/2.1/) |
-| **OpenID Connect (OIDC)** | Authentication layer built on OAuth that establishes human identity. | [openid.net](https://openid.net/developers/how-connect-works/) |
-| **SPIFFE / SPIRE** | Cryptographically verifiable workload identity for machines and services. A conformant implementation of the WIMSE identifier model. | [spiffe.io](https://spiffe.io/) |
-| **RFC 8693, Token Exchange** | Exchange one identity token for another with reduced scope and delegated authority. Single-hop by design; multi-hop chain semantics are **underspecified** and are being addressed by [OAuth Identity Chaining](#delegation-chains--transaction-context) and emerging agent-delegation drafts. | [RFC 8693](https://datatracker.ietf.org/doc/rfc8693/) |
-| **RFC 9396, Rich Authorization Requests (RAR)** | Fine-grained, structured authorization requests beyond traditional OAuth scopes. **Required by ACS** for non-trivial agent actions. | [RFC 9396](https://datatracker.ietf.org/doc/rfc9396/) |
-| **RFC 9449, DPoP** | Sender-constrained access tokens that reduce token theft and replay attacks. Required by AIMS and ACS for agent contexts. | [RFC 9449](https://datatracker.ietf.org/doc/rfc9449/) |
-| **RFC 8705, mTLS Certificate-Bound Tokens** | Binds access tokens to client certificates for workload-to-workload authentication. | [RFC 8705](https://datatracker.ietf.org/doc/rfc8705/) |
-| **RFC 8176, AMR** | Standardized representation of authentication strength and methods. | [RFC 8176](https://datatracker.ietf.org/doc/rfc8176/) |
-| **GNAP (RFC 9635)** | Modern authorization protocol supporting interactive and delegated authorization flows. | [RFC 9635](https://datatracker.ietf.org/doc/rfc9635/) |
-| **OpenID CIBA** | Client-Initiated Backchannel Authentication for out-of-band human approval. Used by AIMS for human-in-the-loop, but does **not** natively support mid-execution re-authorization (see [§ Why OAuth 2.0 Alone Doesn't Meet Agent Needs](#why-oauth-20-alone-doesnt-meet-agent-needs)). | [CIBA Core](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) |
-| **CAEP** | Continuous Access Evaluation Profile for near real-time session revocation and risk signaling. | [CAEP 1.0](https://openid.net/specs/openid-caep-specification-1_0.html) |
-| **OpenID Shared Signals Framework (SSF)** | Standardized risk, security, and session-change event sharing between systems. Adopted by AIMS as the eventing transport. | [Shared Signals WG](https://openid.net/wg/sharedsignals/) |
-| **W3C Trace Context** | Standardized trace propagation across distributed systems. | [W3C Trace Context](https://www.w3.org/TR/trace-context/) |
-| **OpenTelemetry** | Open standard for distributed tracing, metrics, and observability. | [opentelemetry.io](https://opentelemetry.io/) |
-| **OCSF** | Open Cybersecurity Schema Framework for normalized security telemetry. | [schema.ocsf.io](https://schema.ocsf.io/) |
+> **Note:** This is a working document. It is not intended to be comprehensive and will evolve as the ACS Identity workstream matures. Content, scope, and recommendations are subject to change.
+>
 
-### What These Standards Solve
+There are 5 unique identity challenges that this standard aims to solve, where existing use cases that traditional identity models cannot support. It does not propose a wire format or normative requirements yet. Those will follow once the working group has aligned. This is an evolving space and we are taking a conservative approach with normative requirements.
 
-Collectively, the mature standards above answer foundational identity questions:
+For taxonomy and definitions, see [Core Concepts](https://github.com/Agent-Control-Standard/ACS/blob/main/docs/topics/core_concepts.md).
 
-- **Who** is the actor?
-- **How** does the actor authenticate?
-- **How** are credentials issued?
-- **How** is delegated authority represented (single-hop)?
-- **How** are workloads identified?
-- **How** is request context propagated?
-- **How** is trust transferred across systems?
+## What's Changing with Agents
 
-### What These Standards Do **Not** Solve
+For decades, application security worked because software was deterministic.
 
-These standards establish **trust**. They do not determine whether an action **should** happen, and several were not designed with autonomous, non-deterministic agents in mind.
-
-They do not:
-
-- Evaluate intent
-- Detect prompt injection or memory poisoning
-- Decide whether delegated authority remains appropriate after runtime reasoning changes course
-- Verify multi-hop delegation chain integrity end-to-end
-- Specify failure-mode behavior when the IdP is unreachable
-
-> Those questions belong to **ACS**.
-
----
+A traditional application follows a predefined execution path. Security teams can inspect the code, review dependencies, define permissions, and understand expected behavior before deployment. Identity policies can be established in advance because the software's capabilities are known before it runs. A car rental website cannot suddenly provide therapy advice, manage payroll, or execute financial transactions because those capabilities do not exist in its code.
 
-## Why OAuth 2.0 Alone Doesn't Meet Agent Needs
+```text
+Traditional Software
 
-OAuth 2.0 is the foundation, but its design assumptions break for autonomous agents. The drafts under [Emerging Agent Identity Standards](#emerging-agent-identity-standards) (AIMS, AAuth, Agentic JWT, Transaction Tokens for Agents, and OAuth Identity Chaining) exist precisely because of these gaps. ACS addresses the **runtime** subset.
+Code
+  ↓
+Dependencies
+  ↓
+Permissions
+  ↓
+Execution
 
-| OAuth 2.0 Assumption | How Agents Break It | What Addresses It |
-|---|---|---|
-| **The client is a stable, registered software identity** with approximately constant behavior. | An agent's execution path is composed at runtime by a non-deterministic model over inputs that may include adversarial content (indirect prompt injection). A registered client with valid credentials can have its reasoning hijacked. OAuth client auth cannot distinguish "authenticated and behaving" from "authenticated and hijacked." | **ACS runtime enforcement.** No token-issuance standard can patch this; it requires inline behavioral verification at action time. |
-| **Delegation is single-hop** (`user → client → resource server`). | Agent chains are `user → orchestrator → sub-agent → tool → API`. RFC 8693 Token Exchange retrofits multi-hop but leaves chain verification, mandatory scope attenuation, and revocation propagation unspecified. A **delegation chain splicing vulnerability** was disclosed on the OAuth WG list in February 2026. | OAuth Identity Chaining draft; AIMS §10.5; **ACS delegation-integrity checks** at every hop. |
-| **Consent is grant-time, not action-time.** Approve scope once, client holds token until revoked. | Agents need consent that is **fresh** (user still present) and **granular** (this specific action, not just this scope). CAEP adds freshness signals; CIBA adds step-up, but **CIBA only covers client initiation**, not mid-execution re-authorization. AIMS §10.6 names this gap explicitly. | **ACS mid-execution step-up** and intent-aligned policy checks. |
-| **Scopes are pre-declared static strings** (`read`, `write`, `repo`). | Static scopes can't express per-action, per-resource, per-data-cell intent that agents operate at. | **RFC 9396 (RAR)**, required by ACS for non-trivial scopes. |
-| **Bearer tokens.** Possession is sufficient for use. | Agent memory, tool outputs, logs, and crash dumps are all token-leak surfaces. Prompt injection can exfiltrate tokens from working memory. | **DPoP (RFC 9449)** and **mTLS-bound tokens (RFC 8705)**, required by both AIMS and ACS. |
-| **Access tokens can live for an hour.** [RFC 6749 §4.2.2](https://www.rfc-editor.org/rfc/rfc6749#section-4.2.2) leaves `expires_in` RECOMMENDED, not REQUIRED, and 60-minute defaults are common in production. | The agent threat surface is continuous, not session-bounded. Any access token that outlives the current reasoning step is standing authority: an indirect prompt injection landing mid-task can spend whatever the token still permits, long after the step that justified it. | **Per-step, short-lived credentials** minted close to the call (see refresh-token row); proposed ACS lifetime ceilings (open work item). |
-| **Permissions are stateless between requests.** Each API call is evaluated against the token's fixed scope; there is no concept of accumulated effective authority. | Agents with persistent memory accumulate context, credentials, and derived permissions across sessions. A token issued for Task A can remain in memory when the agent pivots to Task B, and a hijacked session inherits everything the agent has accumulated. Cross-session memory lets a compromised session poison the authority of future ones. Token scope stays fixed while de facto capability grows. | **Session-scoped credential isolation, memory-bound token invalidation, and per-action re-authorization** (ACS mid-execution step-up). Identity workstream open work item. |
-| **Refresh tokens** assume the same user returning later to resume a session. | Long-lived refresh tokens stored in prompt-injection-readable agent memory are the worst-case credential. | **Short-lived credentials with aggressive rotation** (AIMS §6 sets the baseline; tighter ACS ceilings such as 15 min for LLM, 5 min for MCP, and 60 s for high-risk actions are **proposed** and tracked as an open work item until a normative clause exists to cite). |
-| **The IdP is always reachable.** | Agents operate at machine speed. An IdP outage forces a choice between denial of service and security regression (fall back to cached credentials). Neither OAuth nor AIMS specifies a failure-mode contract. | **Open ACS work item:** fail-closed vs. fail-cached vs. tier-dependent policy. |
-| **Client behavior is deterministic.** | Restatement of row 1, and the deepest problem: every other limitation can be patched with an extension. This one **cannot**. It requires a runtime layer that confines the authenticated client to its declared intent and scope, and intercepts actions that fall outside them. | **ACS, by definition.** |
+Behavior Known Before Runtime
+```
 
-> **Summary.** OAuth 2.0 plus its extensions (RAR, DPoP, mTLS-bound tokens, Token Exchange) plus the agent-specific drafts (AIMS, Transaction Tokens for Agents, Identity Chaining) cover **token issuance, binding, and propagation**. None of them cover **runtime enforcement of the authenticated agent's behavior**. That is the boundary ACS occupies.
+Large Language Models (LLMs) introduced a fundamentally different execution model. Unlike traditional software, an LLM does not execute a fixed sequence of instructions. It generates outputs probabilistically based on its training data, prompts, and context. The same prompt can produce different outputs across executions.
 
-Runtime enforcement here is the identity-layer mechanism for the **Least Agency** principle from the [OWASP Top 10 for Agentic Applications](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/): agents get the minimum autonomy needed for the task, tool chains are constrained so individually safe capabilities cannot be composed into destructive ones, and agency is restricted at the action level. The controls in this document (per-call authorization against immutable intent, scope attenuation at every hop, mid-execution step-up) are how that principle gets enforced at the identity layer rather than stated as guidance.
+```text
+Prompt
+  ↓
+Model Reasoning
+  ↓
+Generated Output
 
-### Open Questions for the Working Group
+Behavior Determined At Runtime
+```
 
-The following are real architectural questions the table above does not settle. They are recorded here as open items rather than positions.
+This introduced non-determinism into systems that had previously been predictable. On its own, however, an LLM is mostly generating text. Agents act, plan, call tools, invoke other agents, and reach production systems in milliseconds. Today most of them act under a borrowed human identity or a single static service account. That breaks accountability, breaks least-privilege, and makes the ACS Trace pillar lie about who did what.
 
-1. **Impersonation vs. delegation.** Should an agent ever impersonate a user, or must it always act on-behalf-of with attenuated scope and an explicit actor chain? The working assumption in this document is on-behalf-of only (impersonation collapses the delegation chain this workstream exists to preserve), but the position needs WG sign-off before it becomes normative.
-2. **Revocation vs. memory invalidation.** Revoking a token stops future API calls. It does not undo what the agent already read, derived, or cached under that token's access. Revocation in an agentic context may need to require purging derived context, not just killing the credential. No current standard specifies this.
-3. **Cross-resource scope union.** An agent holding valid tokens for calendar, email, and file storage has an effective permission set no single grant authorized. The dangerous triad (sensitive data access, untrusted input exposure, external communication) emerges from that union, and per-resource `aud` restrictions do not prevent it. Whether ACS should evaluate policy against the union of live credentials, rather than per-token, is open.
+At runtime an agent determines:
 
----
+- What tool to call
+- What data to retrieve
+- Which API to invoke
+- Whether to delegate to another agent
+- What action to perform
 
-## Emerging Agent Identity Standards
+The effective execution path is assembled dynamically while the system is running.
 
-> **Status Note: these are Internet-Drafts.**
-> All drafts in this section are **Internet-Drafts** and have **not yet been ratified as RFCs**. Internet-Drafts are working documents and may be revised, replaced, or withdrawn at any time. The authoritative source for any draft's status is its Datatracker landing page. ACS deliberately tracks landing pages rather than pinning revisions.
+```text
+Agent
 
-The following drafts are actively shaping identity for autonomous systems, AI agents, and machine-to-machine delegation. ACS tracks them closely because they address identity problems that traditional IAM systems were never designed to solve.
+Goal
+  ↓
+Model Reasoning
+  ↓
+Tool Selection
+  ↓
+Data Retrieval
+  ↓
+Delegation
+  ↓
+Action
 
-> **NIST signal.** The **NIST AI Agent Standards Initiative** (February 2026, NCCoE concept paper on agent identity and authorization) references this body of IETF work. ACS aligns with the same reference points.
-
-### Agent Authentication & Authorization
+Behavior Composed During Runtime
+```
 
-| Draft | Description | Link |
-|---|---|---|
-| **AIMS, AI Agent Authentication and Authorization** | The de facto IETF reference point for agent identity. Composes WIMSE, SPIFFE, and OAuth 2.0 into a framework for agent auth. Treats agents as workloads; mandates WIMSE identifiers, short-lived credentials, attestation-fed issuance, and OAuth-derived tokens. As of draft -02 (June 2026) the Security Considerations section is substantive; runtime enforcement of the authenticated agent's behavior remains out of AIMS's scope. | [draft-klrc-aiagent-auth](https://datatracker.ietf.org/doc/draft-klrc-aiagent-auth/) |
-| **AAuth** (Rosenberg, White) | OAuth 2.1 extension defining an **Agent Authorization Grant** for non-redirect-based agent token acquisition. Overlaps with, and in places competes with, parts of AIMS. | [draft-rosenberg-oauth-aauth-00](https://www.ietf.org/archive/id/draft-rosenberg-oauth-aauth-00.html) |
-| **Agentic JWT** | OAuth 2.0 extension addressing zero-trust drift caused by non-deterministic agentic AI clients, where the user's intent and the client application's actions can diverge. | [draft-goswami-agentic-jwt](https://datatracker.ietf.org/doc/draft-goswami-agentic-jwt/) |
-| **OAuth Client Instance Assertions** (McGuinness) | Names *which runtime instance* of a logical OAuth client is acting (a specific agent session, container, or function invocation), via a new `actor_token_type` presented on standard grants, and extends `actor_token` beyond token exchange. Prohibits bearer tokens under the profile, requires per-instance sender-constrained keys, and gives SPIFFE first-class support. Complements AIMS at the token endpoint by making the actor granular enough for ACS runtime records to attribute actions to a single instance. | [draft-mcguinness-oauth-client-instance-assertion](https://www.ietf.org/archive/id/draft-mcguinness-oauth-client-instance-assertion-00.html) |
+Two executions of the same agent on the same task can take entirely different paths. Recent academic work characterizes this as agents resolving capability *probabilistically* at runtime rather than at build time — see *SOK: A Taxonomy of Attack Vectors and Defense Strategies for Agentic Supply Chain Runtime* ([arXiv:2602.19555](https://arxiv.org/abs/2602.19555)), which describes how agentic systems shift the attack surface from build-time dependencies to *inference-time* dependencies assembled from untrusted data and probabilistic capability resolution. Unlike traditional software, where dependencies are resolved before deployment, agentic systems assemble portions of their effective execution context at runtime. Retrieved documents, tool outputs, external APIs, memory entries, and other agents become runtime dependencies selected through probabilistic reasoning rather than predetermined code paths.
 
-### Workload Identity (WIMSE)
+This breaks the assumptions identity standards were designed around. Human identity standards assume a long-lived principal, a session, and a narrow blast radius per action. Workload identity standards assume the workload's behavior is determined by its code. Neither holds for agents.
 
-The WIMSE working group's workload identity stack that AIMS composes onto. This page **proposes** WIMSE identifiers as the recommended agent identifier, with SPIFFE SVIDs as a conformant implementation. Whether ACS mandates a specific identifier scheme is an open working group question. The normative position remains [docs/concepts/identity.md](https://github.com/Agent-Control-Standard/ACS/blob/main/docs/concepts/identity.md), which mandates no authentication mechanism and keeps identifier schemes off the wire; a deployment using `posix_uid` or `oauth_subject` stays conformant today.
+Traditional identity models assume:
 
-| Draft | Description | Link |
-|---|---|---|
-| **WIMSE Architecture** | Architectural model for workload identity across systems and trust domains. | [draft-ietf-wimse-arch](https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/) |
-| **WIMSE Workload Identifier** | URI format used to uniquely identify workloads and agents. | [draft-ietf-wimse-identifier](https://datatracker.ietf.org/doc/draft-ietf-wimse-identifier/) |
-| **WIMSE Workload Credentials** | Credential formats workloads use to prove identity ownership. | [draft-ietf-wimse-workload-creds](https://datatracker.ietf.org/doc/draft-ietf-wimse-workload-creds/) |
-| **WIMSE Workload Proof Token (WPT)** | Application-layer authentication tokens for workload-to-workload communication. | [draft-ietf-wimse-wpt](https://datatracker.ietf.org/doc/draft-ietf-wimse-wpt/) |
-| **WIMSE HTTP Message Signatures** | Request signing using workload credentials. | [draft-ietf-wimse-http-signature](https://datatracker.ietf.org/doc/draft-ietf-wimse-http-signature/) |
+- The actor is known
+- The execution path is known
+- The permissions are known
+- The delegation chain is known
 
-### Delegation Chains & Transaction Context
+Agent systems invalidate all four assumptions.
 
-| Draft | Description | Link |
-|---|---|---|
-| **OAuth Identity and Authorization Chaining Across Domains** | How delegation chains propagate across trust boundaries and administrative domains. Referenced by AIMS §10.5. Addresses (in part) the multi-hop gap in RFC 8693. | [draft-ietf-oauth-identity-chaining](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/) |
-| **Transaction Tokens** | Downscopes access tokens to specific transactions; mitigates token replay between microservices. Referenced by AIMS §10.4. | [draft-ietf-oauth-transaction-tokens](https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/) |
-| **Transaction Tokens for Agents** | Extends Transaction Tokens with agent-specific delegation chains, actor transitions, hop metadata, and trust attenuation. | [draft-araut-oauth-transaction-tokens-for-agents](https://datatracker.ietf.org/doc/draft-araut-oauth-transaction-tokens-for-agents/) |
+The question is no longer:
 
-### What These Drafts Solve
+> Who is the principal?
 
-The emerging drafts extend the existing identity foundation to answer agent-specific questions:
+The question becomes:
 
-- **How** does an autonomous agent acquire tokens without a redirect-based human flow?
-- **How** is a delegation chain represented across multiple agent hops?
-- **How** is the difference between a user's intent and an agent's actions captured in a token?
-- **How** do workloads and agents present cryptographic identity at the application layer?
-- **How** does transaction context survive across microservice and trust-domain boundaries?
+> Who is acting, on whose behalf, for what purpose, using what authority, through which delegation chain, at this moment?
 
-### What These Drafts Do **Not** Solve
+That is the runtime identity problem ACS aims to solve.
 
-These drafts establish **trust and context**. They do not decide whether the resulting action **should** execute. AIMS scopes runtime enforcement out of its model: its Security Considerations (added in draft -02, June 2026) address token, transport, and delegation risks, and stop at the point where the authenticated agent starts acting. That gap is deliberate; it is the boundary between identity issuance and runtime enforcement.
+An agent has a goal, a set of tools, some memory, and a model that decides at runtime what to call next, in what order, with what arguments. The effective code path is composed in the moment, by a non-deterministic component, based on whatever the agent just read. The supply chain you signed off on at build time is not the supply chain that executes.
 
-They do not answer:
+A single tool call can chain through nine or more identities: the human user, the platform, the orchestrator, one or more sub-agents, the model, the tool, the downstream API, the trigger source, and the data subject. Each hop needs its own scope. Each hop needs to be verifiable. Today, identity at runtime is usually one or two of those at best.
 
-- Should this action happen, given current intent and observed agent state?
-- Has the agent been influenced by untrusted content since the token was issued?
-- Has the delegation chain become unsafe mid-execution?
-- Should mid-execution user re-authorization fire **right now** (a gap CIBA does not cover)?
-- What happens when the IdP is unreachable and the agent is mid-task?
+```text
+Human ──delegates──▶ Orchestrator Agent ──delegates──▶ Sub-Agent ──invokes──▶ Tool ──acts on──▶ Resource
+   │                       │                              │                     │
+   │                       ▼                              ▼                     ▼
+   │              ingests RAG / docs / web      may spawn more sub-agents   external write
+   │              (untrusted instructions)                                   (irreversible)
+   │
+   └──── audit subject: which link in this chain, under which intent? ────────────────▶
+```
 
-> Those questions belong to **ACS**.
+Agent systems are introducing a new class of failures where every token is valid, every API call is authorized, and the outcome is still a security incident.
 
 ---
 
-## The ACS ↔ AIMS Composition Boundary
-
-If ACS and AIMS are positioned correctly, they are **complementary, not competing**.
+## The 5 Unique Runtime Identity Challenges for Agents
 
-### AIMS handles, ACS does not need to
+These are the five unique runtime identity challenges that distinguish agent systems from human or workload identity. Each one is a place where existing standards fall short and where the ACS Identity workstream is concentrating its effort. The list is deliberately tight: every challenge below is genuinely distinct and together they cover the runtime surface that today's identity standards do not.
 
-- Agent identifier issuance and structure (WIMSE identifier; SPIFFE as a conformant implementation)
-- Cryptographic binding of credentials to identifier (WIMSE credentials, SPIFFE SVIDs)
-- Credential provisioning, rotation, and lifecycle
-- Attestation feeding credential issuance
-- Transport and application-layer authentication (mTLS, WIMSE Proof Tokens, HTTP Message Signatures)
-- OAuth grant flows for agent token acquisition
-- Cross-domain token exchange (Identity Chaining, JWT Authorization Grant)
-- Token format and discovery metadata
-- Eventing transport for security signals (Shared Signals + CAEP / RISC)
+A concrete example that illustrates several of these challenges is Palo Alto Networks Unit 42's 2025 research, *[Agent Session Smuggling in Agent2Agent Systems](https://unit42.paloaltonetworks.com/agent-session-smuggling-in-agent2agent-systems/)*. In the demonstrated attack, a malicious agent injected hidden instructions into a legitimate Agent2Agent (A2A) session. The victim agent subsequently disclosed sensitive information and performed unauthorized actions while using valid credentials and authorized APIs. Authentication and authorization succeeded. The failure occurred because the runtime could not distinguish user intent from adversarial instructions introduced during execution. This illustrates the central identity challenge of agent systems.
 
-### ACS handles, AIMS does not
+| # | Challenge / Question | Why It's Challenging | Standards Today That Aren't Sufficient | What Needs to Change for Runtime | ACS Mechanism |
+|---|---|---|---|---|---|
+| 1 | **Chain Integrity**<br/>*Can the full delegation chain be named and verified end-to-end?* | A single agent task can chain through five to ten identities: user → orchestrator → sub-agent → tool → downstream API. Two failures compound: the chain is not *named* (audit collapses into "the agent did it"), and the chain is not *verifiable* (downstream resources cannot confirm the chain without trusting every intermediary). In practice the full chain is often not reconstructable end-to-end, and there is a known class of attacks where the chain itself can be spliced. | **[OAuth 2.0](https://www.rfc-editor.org/rfc/rfc6749) access tokens** identify the bearer, not the chain.<br/>**[OIDC Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html) ID tokens** name the human at the start but lose granularity at each hop.<br/>**[SPIFFE SVIDs](https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/)** identify the workload but not which call within it.<br/>**[OAuth Token Exchange (RFC 8693)](https://www.rfc-editor.org/rfc/rfc8693)** defines nested `act` claims that can express a chain, but per [§4.1](https://www.rfc-editor.org/rfc/rfc8693#section-4.1) *"prior actors identified by any nested `act` claims are informational only and are not to be considered in access control decisions."* The chain is recorded, not normatively enforceable.<br/>**[OAuth Identity Chaining draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-chaining/)** and **[Transaction Tokens draft](https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/)** address parts but specify neither chain verification rules nor revocation propagation as required runtime behavior.<br/>**[W3C Trace Context](https://www.w3.org/TR/trace-context/)** correlates but [does not authenticate](https://www.w3.org/TR/trace-context/#privacy-of-traceparent-field). | Every action must produce, at the moment of execution, a signed record that names the specific link in the chain and lets any participant (including the downstream resource) verify the entire chain end-to-end without trusting any intermediary. Cryptographic chain structure, mandatory scope attenuation at every hop, revocation propagation. | Pending |
+| 2 | **Over-Privilege**<br/>*Was this action within the agent's purpose?* | Agents inherit broad standing privileges. Service accounts. Long-lived API keys. OAuth scopes designed for human applications. One compromised agent has the union of every permission anyone has ever granted to it. The fix is not bigger scopes; the fix is no standing privilege. | **[OAuth scopes (RFC 6749 §3.3)](https://www.rfc-editor.org/rfc/rfc6749#section-3.3)** are coarse, deployment-defined strings (e.g. `read`, `write`, `repo`). Per **[RFC 9396 §1](https://www.rfc-editor.org/rfc/rfc9396#section-1)**, scope is "sufficient... for coarse-grained authorization requests" but "not sufficient to specify fine-grained authorization requirements" — it does not express per-action, per-resource, per-data-cell intent.<br/>**RBAC and ABAC** scope by role or attribute, granted once, evaluated coarsely.<br/>**AIMS** does not require **[RAR (RFC 9396)](https://www.rfc-editor.org/rfc/rfc9396)** and treats scope semantics as deployment-specific. | Credentials minted just before the call, scoped to one downstream callee, structured (per-action, per-resource), expired in minutes. Authorization evaluated per-call against the immutable intent for the run, not per-session. | Pending |
+| 3 | **Token Theft Resistance**<br/>*If a token leaks from agent memory, is it useless to the attacker?* | The agent threat model breaks OAuth's bearer-token assumption entirely. Prompt injection can exfiltrate tokens from memory. Tool outputs can leak tokens. Sub-agents can replay tokens. Logs and crash dumps capture tokens. Long-lived refresh tokens in agent memory are the worst case: a durable credential held in storage that any indirect prompt injection can read. | **[OAuth 2.0 Bearer Tokens (RFC 6750 §1.2)](https://www.rfc-editor.org/rfc/rfc6750#section-1.2)** explicitly treat possession as sufficient: *"Using a bearer token does not require a bearer to prove possession of cryptographic key material."*<br/>**API keys** are bearer secrets by definition.<br/>**[OAuth refresh tokens (RFC 6749 §1.5)](https://www.rfc-editor.org/rfc/rfc6749#section-1.5)** were designed for the same user returning later to resume a session, which does not describe how agents work.<br/>**[DPoP (RFC 9449)](https://www.rfc-editor.org/rfc/rfc9449)** and **[OAuth 2.0 Mutual-TLS Certificate-Bound Access Tokens (RFC 8705)](https://www.rfc-editor.org/rfc/rfc8705)** solve sender-constraint but are optional extensions that most deployments do not enforce.<br/>None of these are required by the OAuth core. | All non-trivial tokens sender-constrained (DPoP or mTLS) so a leaked token is useless without the corresponding private key. Aggressive lifetime ceilings measured in minutes or seconds, not hours. No long-lived secrets in model-visible context. Credentials fetched at task start, used within a tight window, discarded at task end. | Pending |
+| 4 | **Last-Mile Enforcement**<br/>*Did the resource actually enforce the decision, on every call, inside the runtime?* | The moment the action reaches a production system. All upstream identity work either holds here or fails here. Most systems today cannot distinguish an authorized action by an agent acting in good faith from the same call by an agent hijacked by indirect prompt injection. Gateway-only enforcement misses tool calls and sub-agent invocations that never cross a gateway. Cached decisions miss revocation, scope change, and freshly-discovered taint. | **API gateways and service meshes** enforce at the edge; agent tool calls never reach them.<br/>**[OAuth 2.0 resource servers (RFC 6749 §1.1)](https://www.rfc-editor.org/rfc/rfc6749#section-1.1)** validate the token but not the action's relationship to intent.<br/>**[mTLS (RFC 8705)](https://www.rfc-editor.org/rfc/rfc8705)** and **[SPIFFE](https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/)** establish workload identity but do not enforce per-action policy.<br/>None fire inside the agent runtime where the decision is made. | Enforcement fires at every tool call, inside the agent runtime, before the action executes. The runtime verifies identity, scope, taint, freshness, and intent on every call. The LLM call cost dwarfs the re-authorization cost, so caching decisions is not required for performance. Default-deny verified by a negative test in CI. | **Partially specified.** The ACS Instrument spec already defines the honoring-decisions contract in [§6.4 (Honoring Decisions, Normative)](https://github.com/Agent-Control-Standard/ACS/blob/main/docs/spec/instrument/specification.md#64-honoring-decisions-normative): the Observed Agent MUST wait for the Guardian's decision up to the negotiated timeout, MUST apply it, and MUST record every fail-open proceed as an audit event. Note the spec's current default on timeout is **fail-open with audit**, which is in tension with this row's default-deny / no-cache goal; whether identity-tier actions should tighten that to fail-closed is an open work item for this workstream. |
+| 5 | **Proof of Intent**<br/>*Was the action bound to an immutable, declared purpose that survives mid-task reframing?* | OAuth scopes say what the user *can* do. They do not say what the user *is doing right now*. Without intent binding at runtime, every agent action is a guess about user authorization. The agent's reasoning can be reframed mid-task by an instruction hidden in a document or a tool output. The original intent has to survive that. This is the hardest of the five, because it is the only one OAuth cannot patch with an extension: the underlying problem is non-deterministic client behavior under adversarial inputs. | **None at the identity layer.** Intent is implicit in the OAuth consent screen and discarded after token issuance.<br/>**[RFC 9396 RAR](https://www.rfc-editor.org/rfc/rfc9396)** can carry purpose claims as `authorization_details` data but does not bind them as runtime invariants against the LLM client.<br/>**IBAC (Intent-Based Access Control)** is research-stage with no IETF/W3C standard track.<br/>No production standard treats intent as a first-class, immutable, normatively-enforced runtime invariant. | Intent treated as a first-class governance concept with a normative immutability invariant. Intent must flow across all three ACS pillars: Instrument fires decisions against it, Trace records it as a span attribute, Inspect catalogs what it authorized. Intent extension permitted only through an explicit, human-approved path. | Pending |
 
-- **Runtime policy enforcement** as a policy decision point that returns allow / deny / modify verdicts inline, before an action reaches a production system
-- **Hook-level identity validation:** re-checking identity, delegation chain, and attestation at every agent decision point, not just at token issuance
-- **Tainted-input handling:** tracking which agent invocations have ingested untrusted content and denying writes from tainted contexts
-- **Mid-execution step-up:** the runtime layer that recognizes when a CIBA challenge should fire (the gap AIMS §10.6 explicitly names)
-- **AgBOM enumeration:** dynamic inventory of every model, tool, capability, knowledge source, and dependency, joined to identity at runtime
-- **Control set tiers (0–3):** conformance bundles mapping deployment risk to identity controls
-- **Embedded sub-agent identity:** the case AIMS §10.3.3 collapses to "agents accessed by other agents"
-- **Cross-platform conformance:** bridging AWS, Azure, GCP primitives to a single runtime enforcement model
-- **The OAuth gaps from the table above:** IdP unavailability and non-deterministic client behavior
+---
 
-### Where ACS and AIMS overlap (resolved in favor of AIMS where appropriate)
+## What this Identity workstream is not trying to do
 
-| Topic | Resolution |
-|---|---|
-| **Identifier model** | **Proposed: WIMSE identifier recommended, SPIFFE conformant.** Would align ACS with AIMS, WIMSE WG, and NIST. Pending WG sign-off and reconciliation with [docs/concepts/identity.md](https://github.com/Agent-Control-Standard/ACS/blob/main/docs/concepts/identity.md), which currently mandates no identifier scheme. |
-| **Token lifetimes** | AIMS sets the baseline; proposed ACS ceilings (15 min LLM / 5 min MCP / 60 s high-risk) are open work items pending a normative spec clause. |
-| **Sender-constrained tokens** | Both require DPoP or mTLS. Cross-reference, no divergence. |
-| **Audit logging** | ACS identity blocks **extend** AIMS minimum audit event fields rather than diverging from them. |
+- **Replace existing Identity Standards like OAuth, OIDC, SPIFFE.** ACS-Identity composes with them.
+- **Specify a new agent framework.** The mechanisms must work for any framework that can emit a signed action record.
 
----
+## How ACS-Identity composes with the rest of ACS
 
-## Responsibility Map
+ACS-Identity is one of eight cross-cutting concepts (Identity, Provenance, Trust, Intent, Capability, Skill, Agents, Session Lifecycle). It produces signals that the three pillars consume:
 
-ACS specifies the runtime enforcement contract that **consumes** the identity, delegation, workload, and transaction context produced by the standards above.
+- **Instrument** fires authorization decisions against identity + intent + taint.
+- **Trace** records each chain link as a span attribute (signed, verifiable).
+- **Inspect** catalogs which agent, under which intent, exercised which capability.
 
-| Layer | Responsibility |
-|---|---|
-| OAuth 2.0 / 2.1 / OIDC | Human authentication and authorization (foundation; insufficient alone for agents) |
-| SPIFFE / SPIRE | Workload identity (conformant WIMSE implementation) |
-| WIMSE | Workload identity stack (proposed reference model; see note under [Workload Identity](#workload-identity-wimse)) |
-| AIMS | Agent authentication and token acquisition |
-| AAuth / Agentic JWT | Alternative or complementary agent token issuance models |
-| Token Exchange + Identity Chaining | Delegation and cross-domain attenuation |
-| Transaction Tokens (+ for Agents) | Request and agent-chain context propagation |
-| CAEP / SSF | Continuous risk and session signaling |
-| **ACS Identity** | Runtime identity verification |
-| **ACS Provenance** | Origin and lineage verification |
-| **ACS Crypto** | Integrity, signatures, attestations, and non-repudiation |
-| **ACS** | Runtime enforcement and policy decisions |
+Identity does not solve any of the five challenges alone. It composes with Provenance (taint), Capability (what the agent is allowed to do at all), and Intent (what it is doing right now).
 
-ACS verifies identity, delegation, scope, provenance, and intent **immediately before an action executes**, supplying the runtime enforcement contract that AIMS leaves out of scope.
+## Read Next
 
-> ACS does not replace these standards. ACS **composes** with them.
+- [ACS in Action](./ACS_in_action_example.md)

From 7546a7075c0d1855fc9f9f23d885193c561f868c Mon Sep 17 00:00:00 2001
From: Eva <130791729+evabenn@users.noreply.github.com>
Date: Fri, 10 Jul 2026 19:14:04 -0700
Subject: [PATCH 6/8] Move identity/overview.md to docs/identity/ and fix
 relative link

Signed-off-by: Eva <130791729+evabenn@users.noreply.github.com>
---
 {identity => docs/identity}/overview.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename {identity => docs/identity}/overview.md (99%)

diff --git a/identity/overview.md b/docs/identity/overview.md
similarity index 99%
rename from identity/overview.md
rename to docs/identity/overview.md
index 969ca7b..09b8fe4 100644
--- a/identity/overview.md
+++ b/docs/identity/overview.md
@@ -143,4 +143,4 @@ Identity does not solve any of the five challenges alone. It composes with Prove
 
 ## Read Next
 
-- [ACS in Action](./ACS_in_action_example.md)
+- [ACS in Action](../topics/ACS_in_action_example.md)

From d05ce5a029d68f79ba91884046b197fee54aacc6 Mon Sep 17 00:00:00 2001
From: Eva <130791729+evabenn@users.noreply.github.com>
Date: Fri, 10 Jul 2026 19:16:07 -0700
Subject: [PATCH 7/8] Move identity/standards.md to docs/identity/ and fix
 in-page anchor

Signed-off-by: Eva <130791729+evabenn@users.noreply.github.com>
---
 {identity => docs/identity}/standards.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename {identity => docs/identity}/standards.md (99%)

diff --git a/identity/standards.md b/docs/identity/standards.md
similarity index 99%
rename from identity/standards.md
rename to docs/identity/standards.md
index b73a5ef..94e230b 100644
--- a/identity/standards.md
+++ b/docs/identity/standards.md
@@ -100,7 +100,7 @@ The following standards are broadly adopted and form the foundation of modern id
 | **OAuth 2.1** | In-progress consolidation of OAuth 2.0 and later security best practices for delegated authorization. | [oauth.net/2.1](https://oauth.net/2.1/) |
 | **OpenID Connect (OIDC)** | Authentication layer built on OAuth that establishes human identity. | [openid.net](https://openid.net/developers/how-connect-works/) |
 | **SPIFFE / SPIRE** | Cryptographically verifiable workload identity for machines and services. A conformant implementation of the WIMSE identifier model. | [spiffe.io](https://spiffe.io/) |
-| **RFC 8693, Token Exchange** | Exchange one identity token for another with reduced scope and delegated authority. Single-hop by design; multi-hop chain semantics are **underspecified** and are being addressed by [OAuth Identity Chaining](#delegation-chains--transaction-context) and emerging agent-delegation drafts. | [RFC 8693](https://datatracker.ietf.org/doc/rfc8693/) |
+| **RFC 8693, Token Exchange** | Exchange one identity token for another with reduced scope and delegated authority. Single-hop by design; multi-hop chain semantics are **underspecified** and are being addressed by [OAuth Identity Chaining](#delegation-chains-transaction-context) and emerging agent-delegation drafts. | [RFC 8693](https://datatracker.ietf.org/doc/rfc8693/) |
 | **RFC 9396, Rich Authorization Requests (RAR)** | Fine-grained, structured authorization requests beyond traditional OAuth scopes. **Required by ACS** for non-trivial agent actions. | [RFC 9396](https://datatracker.ietf.org/doc/rfc9396/) |
 | **RFC 9449, DPoP** | Sender-constrained access tokens that reduce token theft and replay attacks. Required by AIMS and ACS for agent contexts. | [RFC 9449](https://datatracker.ietf.org/doc/rfc9449/) |
 | **RFC 8705, mTLS Certificate-Bound Tokens** | Binds access tokens to client certificates for workload-to-workload authentication. | [RFC 8705](https://datatracker.ietf.org/doc/rfc8705/) |

From eeae6fae5b1743a28a587aea37115154dc6775d9 Mon Sep 17 00:00:00 2001
From: Eva <130791729+evabenn@users.noreply.github.com>
Date: Fri, 10 Jul 2026 19:17:38 -0700
Subject: [PATCH 8/8] Add Identity docs to mkdocs nav and enable mermaid
 superfences

Signed-off-by: Eva <130791729+evabenn@users.noreply.github.com>
---
 mkdocs.yml | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/mkdocs.yml b/mkdocs.yml
index 1478734..c3bfb0b 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -76,6 +76,9 @@ nav:
     - Skill: concepts/skill.md
     - Provenance: concepts/provenance.md
     - Trust Basis: concepts/trust.md
+  - Identity:
+    - Overview: identity/overview.md
+    - Standards: identity/standards.md
   - Specification:
     - Conformance Profiles: spec/conformance.md
     - Instrument:
@@ -113,7 +116,11 @@ markdown_extensions:
       pygments_lang_class: true
   - pymdownx.inlinehilite
   - pymdownx.snippets
-  - pymdownx.superfences
+  - pymdownx.superfences:
+      custom_fences:
+        - name: mermaid
+          class: mermaid
+          format: !!python/name:pymdownx.superfences.fence_code_format
   # Callouts
   - admonition
   - pymdownx.details