AI Access Control

Building agents, or configuring them?

This is the developer/protocol landing — the identity model, tokens, and APIs for building agents. Configuring and monitoring agents from the portal UI? See the AI Agents and MCP user guide.

LumoAuth gives AI agents their own verified identity, scoped capabilities, fine-grained authorization, and full audit trails — so you don't have to hand an agent a user's credentials or a long-lived API key. Terms you will meet on these pages: AAuth (the agent identity protocol: an agent signs each request with its own key instead of sending a shared secret), JIT permissions (just-in-time: a narrow, short-lived permission an agent asks for at the moment it needs it, which a human can approve), MCP (Model Context Protocol, the standard way agents call tool servers) and CAEP / shared signals (security events such as "session revoked" passed between systems so access is cut off quickly). The glossary has the rest.

Why this matters

OAuth was designed for human users clicking through consent screens. AI agents operate autonomously, chain actions together, and need fine-grained, verifiable authorization without a human in the loop for every request.

New here? Start with the architecture

How LumoAuth secures an agent → is the one-page cohesion story: how a single request flows through workload attestation (the agent proving where it runs) → agent identity → MCP authorization → JIT/HITL (human-in-the-loop) → audit, plus the full credential/token map. Then build it end-to-end in the AI Agent + MCP in 5 Minutes quickstart, or watch the same flow in the interactive demo (simulated, no signup).

The AI access control model

LumoAuth shifts the principal model from "User X is always User X" to something more precise:

"Agent A is acting as User 123, within Context Z" — with full visibility into the chain of actors behind every request.

Key concepts

1. Agent registration

Agents are registered in LumoAuth similarly to OAuth clients, with additional metadata:

• Capabilities — what the agent is allowed to do (e.g., read:data, tool:search)
• Budget policy — usage limits (tokens per day, API calls per hour)
• Allowed tools — which external tools the agent can invoke
• Delegation rules — whether the agent can act on behalf of users

2. Workload identity federation

A workload identity is a cryptographic identity token issued by the platform the workload runs on (a Kubernetes ServiceAccount token, AWS IAM signed identity, GCP metadata-server token, Azure Managed Identity). LumoAuth trusts that token directly, so no static secret is needed. Agents running in one of these environments can exchange their platform token for a LumoAuth access token:

6 / 6

1. Agent to Kubernetes: ServiceAccount Token Request
2. Kubernetes to Agent: Signed Identity JWT
3. Agent to LumoAuth: Token Exchange (RFC 8693)
4. Note: 4. Signature & Issuer Verification
5. LumoAuth to Agent: LumoAuth Access Token
6. Agent to Backend API: API Request

No secrets to manage — the agent's identity is tied to its infrastructure.

3. Chain of agency

When an agent acts on behalf of a user, LumoAuth uses token exchange to create a delegation chain (a record of which user asked which agent to act, and which agent called which). Token exchange lets a client swap one token for another — the mechanism behind delegation. A token exchange records the subject token (what the caller holds) and optionally an actor token (who is acting). The resulting access token encodes the full call chain (act claim nesting):

{
  "sub": "user:alice",            // The user being represented
  "act": {
    "sub": "agent:research-bot",  // The agent acting on behalf of user
    "act": {
      "sub": "agent:search-tool"  // Nested: a tool the agent called
    }
  },
  "scope": "read:articles search:web",
  "exp": 1704067200
}

This creates a complete audit trail: "Search Tool, used by Research Bot, acting for Alice."

4. Capability-based access

Instead of asking "can user X do Y?", agent capabilities are explicitly granted and scoped:

Capability	Meaning
read:data	Can read data from your APIs
write:data	Can create or modify data
tool:search	Can use web search tools
tool:execute_code	Can run code in sandboxes
delegate:user	Can act on behalf of users

Authentication patterns

Pattern 1: Client credentials (agent as itself)

For agents that act independently, not on behalf of any user:

curl -X POST https://app.lumoauth.dev/orgs/acme-corp/api/v1/oauth/token \
  -d "grant_type=client_credentials" \
  -d "client_id=AGENT_CLIENT_ID" \
  -d "client_secret=AGENT_CLIENT_SECRET"

Pattern 2: Workload identity (no static secrets)

For agents running in trusted infrastructure:

curl -X POST https://app.lumoauth.dev/orgs/acme-corp/api/v1/oauth/token \
  -d "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
  -d "subject_token=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" \
  -d "subject_token_type=urn:ietf:params:oauth:token-type:jwt" \
  -d "subject_issuer=kubernetes"

Pattern 3: User delegation (agent acting for user)

When an agent needs to perform actions on behalf of a user — uses token exchange with both a subject token (the user) and actor token (the agent):

curl -X POST https://app.lumoauth.dev/orgs/acme-corp/api/v1/oauth/token \
  -d "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
  -d "subject_token=USER_ACCESS_TOKEN" \
  -d "subject_token_type=urn:ietf:params:oauth:token-type:access_token" \
  -d "actor_token=AGENT_ACCESS_TOKEN" \
  -d "actor_token_type=urn:ietf:params:oauth:token-type:access_token"

Pattern 4: AAuth protocol (cryptographic identity)

For agent-to-agent communication with per-request proof-of-possession. Uses signed HTTP requests (HTTP message signatures): cryptographic signatures over specific HTTP request components (method, path, selected headers, body digest). The verifier rebuilds the signature input from the request and checks the signature, giving a replay-proof, per-request proof of possession.

curl -X POST https://app.lumoauth.dev/orgs/acme-corp/api/v1/aauth/agent/token \
  -H "Content-Type: application/json" \
  -H "Agent-Auth: [HTTP Message Signature]" \
  -d '{
    "request_type": "auth",
    "agent_token": "eyJhbGc...",
    "resource_token": "eyJhbGc...",
    "scope": "read write"
  }'

See the AAuth Protocol documentation for the full spec.

Capability map

Everything in the agent-identity surface, by concern:

Identity & registration

• Agent Registry — register agents with capabilities, budgets, and framework integrations; publish and verify signed A2A agent cards.
• AAuth Protocol — cryptographic agent identity with proof-of-possession tokens and signed HTTP requests.
• AAuth 1.0 Specification — the normative wire spec: token formats, endpoint request types, signature profile, error codes.
• Workload Federation — exchange the identity a platform already gives the workload (Kubernetes, AWS, GCP, Azure, any OIDC issuer) for LumoAuth tokens; no static secrets.
• Attestation Endpoint — the agent proves where it runs with a platform-issued token; bind agents to workload identities, including SPIFFE/SPIRE JWT-SVIDs.

Delegation & cross-domain access

• Chain of Agency — token exchange, act claim chains, transaction tokens for internal call paths.
• Cross App Access (ID-JAG) — enterprise SSO bridging into MCP servers and SaaS apps via the Identity Assertion Authorization Grant.
• Token Vault (Connections) — LumoAuth keeps the long-lived third-party OAuth credentials (Google, Slack, GitHub, …) and hands agents short-lived tokens, so agents never hold refresh tokens.

Authorization

• Fine-Grained Authorization — agents as first-class subjects in ReBAC/ABAC, queried through the OpenID AuthZEN 1.0 API.
• The Ask API — pre-flight "may I do this?" checks structured for LLM tool loops.

Human-in-the-loop

• JIT Permissions — ephemeral task personas, rich authorization details, risk scoring, approval policies, and short-lived downscoped tokens.
• Push Approval for Actions — a human tap on a phone before irreversible actions.
• Async Authorization (Agent CIBA) — out-of-band user authorization over the OAuth backchannel.
• Mobile Approvals Device API — the versioned wire contract for the mobile authenticator: push payload schema, device-signed endpoints, challenge formats.

Governance & signals

• Agent Governance — risk scoring, conditional access policies, dormancy lifecycle.
• Shared Signals (SSF/CAEP) — push Security Event Tokens to your receivers when agent risk changes.

Standards support

The standards reference maps each plain name below to its specification.

Standard	Status	Where
MCP Authorization spec 2026-07-28 (2025-11-25 + SEP-835, SEP-837, SEP-2350, SEP-2351, SEP-2352, SEP-2468; CIMD first, DCR deprecated)	Implemented	MCP authorization
MCP Enterprise-Managed Authorization extension (authorization_grant_profiles_supported = ID-JAG)	Implemented (resource AS)	Cross App Access
Client ID Metadata Documents (CIMD, draft-ietf-oauth-client-id-metadata-document)	Implemented	CIMD
Identity Assertion Authorization Grant (ID-JAG, draft-ietf-oauth-identity-assertion-authz-grant, both roles)	Implemented	Cross App Access
Token exchange (delegation)	Implemented	Chain of Agency, Workload Federation
OAuth Actor Profile for Delegation (draft-mcguinness-oauth-actor-profile: act.iss, act.sub_profile)	Implemented	Chain of Agency
Transaction Tokens (draft-ietf-oauth-transaction-tokens)	Implemented	Chain of Agency
Rich authorization requests	Implemented	JIT Permissions
Signed HTTP requests (HTTP message signatures)	Implemented	AAuth spec §4
Sender-constrained tokens (DPoP)	Implemented	OAuth security
Protected resource metadata	Implemented	MCP resource metadata
Resource indicators	Implemented	Resource indicators
Issuer identifier in the response (iss)	Implemented	MCP authorization
OpenID AuthZEN 1.0 (single + boxcarred evaluations)	Implemented	Fine-Grained Authorization
AuthZEN MCP tool profile (COAZ-style mcp_tool resource mapping)	Implemented (mapping)	Fine-Grained Authorization
A2A v1.0 signed Agent Cards	Implemented	Agent Registry
SSF 1.0 / CAEP 1.0 (transmitter: push delivery; receiver: push and poll delivery, user and agent subjects)	Implemented	Shared Signals
SPIFFE JWT-SVID	Implemented	Attestation
Attestation-Based Client Authentication (draft-ietf-oauth-attestation-based-client-auth)	Implemented	Client attestation
OpenID CIBA Core (agent-initiated profile)	Implemented	Async Authorization

Security practices

• Least privilege — give agents only the capabilities they need
• Use workload identity — avoid static secrets in cloud infrastructure
• Set budget limits — prevent runaway costs with token and API limits
• Enable audit logging — track all agent actions for compliance
• Use short-lived tokens — access tokens for agents should have short lifetimes
• Verify before delegating — confirm user consent before acting on their behalf

Standards used on this page

Plain name	Standard
Token exchange (delegation)	RFC 8693
Signed HTTP requests (HTTP message signatures)	RFC 9421
Rich authorization requests	RFC 9396
Model Context Protocol (MCP) authorization	MCP Authorization specification
Client ID metadata documents	OAuth Client ID Metadata Document (draft)
Cross App Access (identity assertion JWT authorization grant, ID-JAG)	Identity Assertion Authorization Grant (draft)
Sender-constrained tokens (DPoP)	RFC 9449
Protected resource metadata	RFC 9728
Resource indicators	RFC 8707
Issuer identifier in the response	RFC 9207
Authorization API (AuthZEN)	OpenID AuthZEN Authorization API 1.0
Shared Signals Framework (SSF) and Continuous Access Evaluation Profile (CAEP)	OpenID SSF 1.0 and OpenID CAEP 1.0
Push delivery of security events	RFC 8935
Poll delivery of security events	RFC 8936
Client-initiated backchannel authentication (CIBA)	OpenID CIBA Core 1.0

See the standards reference for what each one covers and how LumoAuth uses it.