Skip to content
Markdown

Agent identity and access

Scope: deciding under whose authority an agent action runs. Two problems compose here: restoring the human user's identity to the backend the agent calls, and giving the agent itself a managed, attestable identity under zero trust. This is the "whose authority" facet of the control plane, enforced alongside the policy gate and intent verification.

Tokens and configs here are reference templates; pin versions and validate before relying on them.

flowchart LR
  U["User token"] --> BROKER["Credential broker (RFC 8693)"]
  A["Agent actor token (SPIFFE SVID)"] --> BROKER
  BROKER -->|"short-lived, audience-bound<br/>sub=user, act=agent"| BACKEND["Backend validates aud/sub/exp/act, logs both"]
  ROT["Rotation + kill switch"] --> A

Overview

When an agent calls a backend with a long-lived service-account key, the human behind the request disappears: the backend sees one shared identity, cannot enforce per-user authority, and cannot attribute the action. That identity collapse is the structural root of excessive agency. Fixing it has two halves. The backend leg (restoring the user's identity) is solvable today with standard token exchange. The agent itself is a non-human identity that must be managed like any other workload identity, under zero trust, rather than handed a static key.1

Core knowledge

Restore the user with a credential broker

Place a credential broker between the agent and the backend. The agent presents the user's token and its own actor token; the broker evaluates the request against policy and mints a short-lived, audience-bound token that names the user as subject and the agent as a nested actor claim (RFC 8693 token exchange). The backend validates audience, subject, expiry, and the actor claim, and logs both parties, so every action is attributable to a human and the agent that acted for them.1 The hard remaining gap is the agent-to-model-provider leg: provider SDKs take one long-lived key at construction with no per-request user hook, so the user's identity does not reach the model call the way it reaches the backend.

Zero trust for the agent

An agent inside the network perimeter is not trustworthy by virtue of position. Apply zero-trust principles (NIST SP 800-207): authenticate and authorize every request, never grant standing access by network location, and assume the agent or its inputs may be compromised. Pair this with attribute-based access control (NIST SP 800-162) so authority is decided from attributes of the subject, action, resource, and context rather than coarse static roles, which is what lets a single agent hold different authority per user, per tenant, and per data class.2

The agent is a non-human identity

Agents are non-human identities, and they now proliferate faster than human accounts in many environments. Treat each agent identity as a first-class credential: least privilege, a short time-to-live, automatic rotation (on expiry, on use, or on detected anomaly), and a kill switch that revokes it instantly. Use a workload-identity framework such as SPIFFE/SPIRE to issue cryptographic, attestable identities (SVIDs) instead of shared API keys, so the agent's identity can be verified and short-lived rather than a long-lived secret to be stolen.3 The agentic identity layer is one of the surfaces enumerated by threat-modeling frameworks such as CSA MAESTRO.4

Don't-miss checklist

  • Never call a backend with a shared service-account key; broker a per-request, user-stamped token.
  • Carry the user as subject and the agent as a nested actor claim (RFC 8693); validate both at the backend.
  • Authorize every request (zero trust); grant no standing access by network position.
  • Decide authority by attributes (ABAC), so one agent holds correct per-user, per-tenant authority.
  • Issue the agent a short-lived, attestable workload identity (SPIFFE), with rotation and a kill switch.

Failure modes

  • Service-account identity. The backend sees one shared identity; per-user authority and attribution are lost.
  • Long-lived agent keys. A stolen static key grants durable access with no rotation or revocation path.
  • Perimeter trust. An agent is trusted because it is "inside"; a compromised agent moves laterally freely.
  • Coarse roles. Role-only access over-grants; the agent can reach resources the user never could.
  • Unattested identity. A shared API key cannot be verified or scoped; there is no cryptographic identity to revoke.

Open questions & validation

  • The agent-to-model-provider identity leg lacks a standard per-request user binding; treat it as unsolved.
  • Non-human-identity inventory is often incomplete; validate that every agent credential is discovered and rotated.
  • Zero-trust for autonomous agents is early; test that revocation (kill switch) actually halts in-flight work.

References

  • RFC 8693, OAuth 2.0 Token Exchange: https://datatracker.ietf.org/doc/html/rfc8693
  • RFC 9068, JWT Profile for OAuth 2.0 Access Tokens: https://datatracker.ietf.org/doc/html/rfc9068
  • NIST SP 800-207, Zero Trust Architecture: https://csrc.nist.gov/pubs/sp/800/207/final
  • NIST SP 800-162, Attribute-Based Access Control: https://csrc.nist.gov/pubs/sp/800/162/upd2/final
  • SPIFFE / SPIRE (workload identity): https://spiffe.io/
  • CSA MAESTRO (agentic-AI threat modeling): https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro
  • OWASP Top 10 for LLM Applications (LLM06 Excessive Agency): https://genai.owasp.org/llm-top-10/

Related: Agent policy engine · Intent verification · Orchestration & control plane · Agent threat model · Security & multi-tenancy (platform) · Agentic systems

  1. A credential broker exchanges the user token plus the agent actor token for a short-lived, audience-bound token carrying the user as subject and the agent as a nested actor claim (RFC 8693); the backend validates audience, subject, expiry, and actor. The model-provider leg lacks a per-request user hook. ↩↩

  2. NIST SP 800-207 (zero trust) requires authorizing every request with no standing access by network position; NIST SP 800-162 (ABAC) decides authority from subject, action, resource, and context attributes rather than coarse roles. ↩

  3. Agents are non-human identities; manage each with least privilege, short TTL, automatic rotation (on expiry, use, or anomaly), and a kill switch, and issue attestable identities via a workload-identity framework (SPIFFE/SPIRE) rather than shared API keys. ↩

  4. CSA MAESTRO is a threat-modeling framework for agentic AI that enumerates the agent identity and access surface among others. ↩