We started LumoAuth because identity platforms model two kinds of principal, a person and an OAuth client, and an AI agent is neither. An agent acts for a person, runs as a workload, calls tools it was not written for, and makes decisions nobody reviewed. Existing products answer that with a client ID, a long-lived secret and a bag of scopes. That is how you get an agent with a bearer token that can do everything the user can do, forever, with no record of who asked.
TL;DR
- LumoAuth is a hosted authentication and authorization service with two jobs: passwordless sign-in for people, and identity plus guardrails for AI agents.
- Every agent gets its own record, owner, bounded capability list, budget, risk score and a kill switch that reaches every token, grant and gateway key it holds.
- The agent features sit on standards: OAuth 2.1, RFC 8693 token exchange, RFC 9396 rich authorization requests, RFC 9421 HTTP message signatures, RFC 9449 DPoP, RFC 9728 protected resource metadata, the MCP authorization specification and OpenID CIBA.
- The registry, signed agent requests, one MCP server and the kill switch are on the free Developer plan, with ten agents included.
- Just-in-time permissions with human approval, the token vault and workload identity for cloud platforms are the Agent Governance and Workload identity add-ons on Pro, and included in Business.
What did identity platforms get right?
A lot. The last fifteen years of identity work gave us OpenID Connect for sign-in, SAML and SCIM for the enterprise, WebAuthn passkeys that finally beat phishing, and OAuth 2.1 as a sane baseline. Auth0, Okta, Microsoft Entra, Amazon Cognito and the open-source servers all do this well. We use the same standards and we are not pretending otherwise.
The incumbents have also started on agents, and some of it is good work. Checked 23 October 2026:
| Product | What it adds for agents | Source |
|---|---|---|
| Auth0 for AI Agents | Token Vault for third-party API tokens, asynchronous authorization built on CIBA with rich authorization requests, fine-grained authorization for RAG | Auth0 blog |
| Okta Cross App Access | An identity assertion grant (ID-JAG) so an IdP, not the user, decides which agent reaches which app | Okta developer blog |
| Microsoft Entra Agent ID | A directory entry per agent with Conditional Access policies applied to agents like users | Microsoft Learn |
| Amazon Bedrock AgentCore Identity | A workload identity per agent, a central agent directory and a token vault for outbound credentials | AWS docs |
Each of these fixes one piece. None of them fixes the model.
What changed when agents started calling APIs?
Three things that a classic OAuth client never had to deal with.
The caller is not the author. A person asked for something, a model decided how to do it, and a tool call happened. The resource server sees a token. Whose token? If it is the user’s, the audit log says the human did it. If it is the agent’s, the log loses the human. Both answers are wrong on their own. RFC 8693 token exchange defined the act claim for exactly this chain, and almost nobody issues it.
The scope is decided at runtime. A deployment pipeline knows which APIs it needs before it runs. An agent finds out mid-task. The classic fix is to grant everything up front, which is how a research assistant ends up with permission to issue refunds. The standards answer exists: rich authorization requests (RFC 9396) describe one action, and client-initiated backchannel authentication (OpenID CIBA) lets a human approve it while the agent waits.
Input is hostile. A tool result, a web page or an email can carry instructions the model will follow. Authentication cannot stop prompt injection. What it can do is make sure a hijacked agent holds a narrow, short-lived credential, so the damage is bounded by what the agent was allowed to do in the next few minutes rather than by everything it could ever do.
Where do existing IAM products fall short for agents?
Here is the list we kept writing on whiteboards. Each row names the gap, what teams do today, and the standard that already solves it.
| Need | What usually happens | Standards answer |
|---|---|---|
| An agent as a principal | A client ID or a service account, no owner, no capability bound | A registry record with an owner and a fixed capability list |
A credential that cannot be copied out of an .env file |
Long-lived API keys and client secrets | Workload identity federation: the platform the agent runs on (GitHub Actions, Kubernetes, AWS EKS, Azure, Google Cloud, SPIFFE) proves where it runs, and the token is exchanged under RFC 8693 |
| A token that is useless if stolen | Bearer tokens, replayable until expiry | DPoP (RFC 9449) for OAuth tokens, HTTP message signatures (RFC 9421) for signed requests |
| A record of who asked | The agent impersonates the user | The act claim chain from RFC 8693, carried through every hop |
| Permission for one action, not a role | Over-broad scopes granted at registration | Rich authorization requests (RFC 9396) with a short-lived token for that task |
| A human in the loop while the agent is not | MFA built for a person at a keyboard | CIBA with poll delivery, approval routed to chat or a phone |
| Authorization per tool, not per API | Access to the MCP server is all or nothing | RFC 9728 resource metadata per server, relationship checks per tool |
| Stop one agent now | Rotate a secret and hope every copy is gone | Revoke every token, grant and gateway key the agent holds, and tell downstream systems over Shared Signals (CAEP) |
| Spend limits | None, or a rate limit on the LLM gateway | A budget on the agent record, enforced on every token request |
None of this needs a new protocol. It needs one server that implements the existing ones together and treats the agent as the subject.
Why not just use OAuth clients and scopes?
Because scopes are static strings granted at registration and checked by string comparison. They say which API, never which record, which amount or which user. A payments:write scope does not express “refund order 4821 for up to 50 dollars, once, approved by the account owner”. Rich authorization requests do. A client credentials grant hands back a bearer token with every scope the client was ever granted, and it lives until it expires. That is the wrong shape for software that takes instructions from untrusted text.
The other reason is ownership. An OAuth client has no owner. When an agent misbehaves at 2 a.m., the question is not “which client ID” but “whose agent, running where, doing what for whom”. A principal model has to carry that.
How LumoAuth does it
LumoAuth is one hosted service with a US and an EU region. The person-facing half is passkeys, magic links, one-time codes, push approval, social and enterprise sign-in. The agent-facing half is below, with the plan each piece is on. Prices are from the published catalog on 23 October 2026.
- Registry. Every agent is a record with an identifier (
agt_…), an owner, an identity type and a capability list with wildcards that can never exceed its creator’s. Free Developer plan, ten agents included. Docs: agent registry. - AAuth, the native protocol. Agents sign every request with RFC 9421 HTTP message signatures and hold tokens bound to their key. Delegation is recorded as an
actchain of up to five hops. Free on every plan. Docs: AAuth. - Workload identity. An agent on GitHub Actions, Kubernetes, AWS EKS, Azure, Google Cloud, SPIFFE or a CI platform exchanges its platform token for a LumoAuth token. No stored secret. GitHub Actions and custom OpenID Connect issuers are free; the cloud and CI providers are the Workload identity add-on at $99 a month on Pro, included in Business. Docs: workload federation.
- MCP server authorization. Each registered MCP server publishes RFC 9728 protected resource metadata, challenges unauthenticated calls per the MCP authorization specification (2025-11-25 revision) and can require DPoP. Per-tool grants come from the Fine-grained authorization add-on. One server free, five on Pro, unlimited on Business. Docs: MCP authorization.
- Just-in-time permissions. The agent asks for one action using
authorization_details. A risk score decides whether a human must approve. Payment, user data, credential and admin actions always do. Approval lands in Slack, Teams, ServiceNow, Jira, the portal inbox or a phone. The token lives 60 to 900 seconds and is bound to that task. Agent Governance add-on, $149 a month on Pro, included in Business. Docs: just-in-time permissions. - Kill switch. Suspend, revoke or deactivate an agent from the portal or the API. It revokes the agent’s tokens, grants and AI-gateway keys in one unit of work and can emit a CAEP event to your other systems. Free on every plan. Docs: governance.
- Sender constraint. DPoP on OAuth tokens for clients that opt in, from Pro upward. AAuth request signing is the constraint for agent traffic. We do not issue certificate-bound tokens today.
The deliberate choice was to make the floor free. An agent registry, signed requests, one MCP server and a kill switch are the minimum a hobby project should have, so they cost nothing.
Standards involved
- OAuth 2.1 and OpenID Connect Core for sign-in and tokens
- Token exchange, RFC 8693, including the
actclaim - Rich authorization requests, RFC 9396
- HTTP message signatures, RFC 9421
- Demonstrating proof of possession (DPoP), RFC 9449
- Protected resource metadata, RFC 9728
- MCP authorization specification, 2025-11-25 revision
- OpenID client-initiated backchannel authentication (CIBA)
- Shared Signals Framework with CAEP and RISC event profiles
- SPIFFE JWT-SVID for workload identity
The full list with spec links is on the standards reference.
FAQ
Is LumoAuth only for AI agents? No. Half the product is passwordless sign-in and enterprise SSO for people. Agents act for people, so both halves have to be in one place, or the delegation chain breaks at the boundary.
Does an agent need a secret at all? Not when it runs somewhere that can vouch for it. GitHub Actions, Kubernetes, the major clouds and any OpenID Connect issuer can attest where the code runs, and LumoAuth exchanges that proof for a token. For a laptop or a long-running host, an AAuth key pair or a hashed API key is the fallback.
What happens to the human’s identity when an agent calls an API?
It stays in the token. The subject is the person; the act claim names the agent and anything the agent delegated to, up to five hops. Your API sees both and your audit log keeps both.
Can I keep my current identity provider? Yes. LumoAuth federates with any OpenID Connect or SAML provider for people, and imports agent records from Entra Agent ID, Okta, AWS AgentCore and Salesforce Agentforce so the governance layer sits across all of them.
Is it open source? The SDKs and the generated API clients are published. The service itself is hosted, in a US or an EU region that you choose when you create your organization.
How does this compare with Auth0 for AI Agents? Both offer a token vault and CIBA-based approval. LumoAuth additionally treats the agent as a registered principal with capabilities, a budget and a kill switch, signs agent requests with RFC 9421, and authorizes MCP servers per tool. A full comparison with dates is on the Auth0 comparison page.
Related: AI agent identity on the solutions pages, and the agent architecture overview in the docs.
Start free with ten agents and one MCP server at app.lumoauth.dev/register.