Skip to main content

AI Access Control

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.

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.

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:

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 RFC 8693 — OAuth 2.0 Token Exchange to create a delegation chain. RFC 8693 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:

CapabilityMeaning
read:dataCan read data from your APIs
write:dataCan create or modify data
tool:searchCan use web search tools
tool:execute_codeCan run code in sandboxes
delegate:userCan 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 RFC 8693 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 RFC 9421 — 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.

Available endpoints​

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