Identity Initial Overview and Big Picture#9
Conversation
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>
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>
|
|
||
| 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 | |
There was a problem hiding this comment.
OAuth access tokens can be arbitrarily long-lived (RFC 6749 leaves expires_in as RECOMMENDED, not REQUIRED ) and that many production deployments issue 1-hour tokens as a default.
For agents, this is architecturally unacceptable because The threat surface is continuous, not session-bounded.
| |---|---|---| | ||
| | **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. | |
There was a problem hiding this comment.
Permission accumulation is real problem with agents too..
Assumption : Permissions are stateless between requests. Each API call is evaluated against the token's fixed scope. No concept of "accumulated effective authority."
Why Agents break it? Agents with persistent memory accumulate context, credentials, and derived permissions across sessions. A token issued for Task A remains in memory when the agent pivots to Task B. Session hijacking "inherits whatever permissions the agent has accumulated". Cross-session memory means a compromised session can poison future sessions' authority.
Solution - Session-scoped credential isolation; memory-bound token invalidation; per-action re-authorization (ACS mid-execution step-up).
|
|
||
| > **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 |
There was a problem hiding this comment.
|
|
||
| They do not answer: | ||
|
|
||
| - Should this action happen, given current intent and observed agent state? |
There was a problem hiding this comment.
I think we are trying here to implement Least Agency principle.
Least Agency is the foundational AI security principle from the OWASP Top 10 for Agentic Applications. It is the agentic evolution of least privilege: dictating that agents should only have the minimum amount of autonomy and freedom to act without checking with a human necessary to perform their task.
The concept addresses the risk of AI agents acting autonomously on malicious prompts or hallucinating destructive tool-chains.Key Principles of Least Agency - 1) Autonomy must be earned: Agents should not be given "blank checks" to solve problems. For example, an agent tasked with scheduling should not possess the agency to delete or edit user accounts. 2) Constrained tool-chains: Agents should be restricted from chaining together multiple "safe" tools to execute destructive tasks or unauthorized data exfiltration (e.g., reading a CRM, then exporting it via email). 3) Action-level restrictions: Agency should be constrained at the API level (e.g., read-only access, capped transactions, or restricted destination domains
ashayraut
left a comment
ashayraut
left a comment
There was a problem hiding this comment.
This document correctly identifies the composition boundary between token-issuance standards (AIMS, OIDC, WIMSE) and runtime enforcement (ACS). The framing is sound. However, the OAuth assumptions table has structural gaps that weaken the argument:
-> Token lifetime is treated as a refresh-token problem. It's not. The core broken assumption is that access tokens can live for 60 minutes. For agents, any token outliving the current reasoning step is ambient authority waiting to be exploited. This needs its own row.
-> Permission accumulation is invisible. OAuth assumes stateless, non-accumulating permissions per request. Agents with persistent memory carry forward effective authority across sessions — the token scope is fixed but the agent's de facto capability grows. The document doesn't name this.
-> What about position on impersonation vs. delegation? The document describes delegation chains but avoids the hard architectural question: should agents ever impersonate users, or must they always act on-behalf-of with attenuated scope? Taking a position here (or explicitly marking it as an open question) would strengthen the spec.
-> Thoughts on Revocation - its is incomplete without memory invalidation. Revoking a token stops future API calls. It doesn't undo what the agent already learned or cached from that token's access. Maybe the document should acknowledge that revocation in an agentic context requires purging derived context, not just killing the credential.
Cross-resource scope union is unaddressed. An agent holding tokens for Calendar + Email + Drive has an effective permission set no single OAuth grant authorized. The dangerous triad (sensitive data access + untrusted input exposure + external communication) emerges from this union, and per-resource aud restrictions don't prevent it.
2 participants
Adds the Identity for Agents workstream overview as a working document.
This PR adds
overview.md— the 5 unique runtime identity challenges that distinguish agent systems from human/workload identity (chain integrity, over-privilege, token theft resistance, last-mile enforcement, proof of intent), with each mapped to where existing standards fall short.Next steps (for working group discussion)