Agent identity shipped, API-first · MCP designed, not built
Agent & MCP Identity
An identity for the software acting on your customers’ behalf
AI agents are starting to do what people used to do inside your product, and they are doing it on someone else’s authority. RealmSSO gives each one its own identity in your customer’s realm rather than a shared API key nobody can revoke: a per-agent client with a deliberately narrow registration policy, claims your application can check to tell an agent from a person, a path for the customer’s own identity provider to vouch for an agent without a browser, and two kill switches whose real strengths we state rather than blur. All of it is API-first. The assertion grant is off by default at two grains; registering an agent client is not behind that switch, which card five below spells out rather than lets you assume. The MCP half — discovery, brokered outbound calls, delegation — is a design in ADR 0017 that is Proposed, not accepted, and not built. Published to be examined, not oversold.
Why Agent & MCP Identity?
Everything you need for enterprise-grade identity federation.
An identity per agent, not a shared API key
RealmSSO mints a confidential, client-credentials-only client for each named agent inside your customer’s own realm. No browser flows, no direct access grants, no realm roles, and offline_access is refused outright — so the credential cannot be traded for a standing refresh token. The agent still holds a static client secret today; authenticating it with a platform-minted JWT instead is designed and not built.
Your application can tell an agent from a person
Every token minted for an agent carries four normalized claims — agent, agent_source, agent_owner and agent_parent — and a human’s token carries none of them. They ride in the access token and the userinfo response, and are deliberately kept out of the ID token, which is the artifact most likely to be logged or handed to a browser. The claim names are a convention ratified in ADR 0003; no SDK yet tells your application to validate them.
The customer’s own provider can vouch for an agent
An agent can authenticate into a customer’s realm non-interactively with a JWT their identity provider signed, using the RFC 7523 JWT Authorization Grant. It is verified against a real Keycloak, including the negative case where a foreign issuer is refused. It works on OIDC connections only, a SAML connection is refused, and it stays off until two separate switches are turned on.
Two kill switches, and we state which one is immediate
Revoking an agent client is immediate for new tokens: the client is disabled, so nobody holding that secret gets another one — a revoked client’s next request returns 401, verified against a real Keycloak. Revoking an agent principal is weaker and we say so. It stops every token minted afterwards from carrying the agent claims, but a token already issued stays valid until it expires, so the exposure window is your realm’s access-token lifetime. We quote that number rather than call it immediate (ADR 0004).
Off until you turn it on, at two grains
Agent access is disabled by default on every account, and the assertion grant is disabled by default on every connection. Turning the account switch off cascades to every connection beneath it and fails loudly if the cascade only partly lands. Note the account switch governs assertion grants, not agent clients — two different mechanisms, and we would rather name the gap than let you assume one switch covers both.
What is not built: MCP, egress, and agent-aware authorization
MCP is a design, not a feature. RealmSSO publishes no protected-resource metadata, does no standards-based dynamic client registration, performs no token exchange, and brokers no outbound agent call — so nothing here governs what an agent reaches on its way out. Authorization inside the realm is partial too: agent clients get a registration-time scope policy, but an agent principal shares the account’s client with its humans, so there is no per-agent role split, and the audit log names the person or key that acted on an agent rather than the agent itself. Agents are not detected automatically either: an agent principal is flagged by an explicit API call naming a Keycloak user, and nothing infers one from a directory sync. ADR 0017 sets out how all of it would work in both directions. None of it is built.
Interested in early access?
What ships today is agent identity inside a customer realm: per-agent clients, the four agent claims, the RFC 7523 grant verified against a real Keycloak, and two revocation paths. It is API-only — there is no screen for any of it. The RFC 7523 assertion grant is off by default at both the account and the connection; registering an agent client is gated by API authorization instead, not by that switch. What does not ship is anything MCP-shaped: no protected-resource metadata, no dynamic client registration, no token exchange, and no control over what an agent calls outward. Agent-aware authorization is partial, and the audit log does not yet name an agent as an actor. ADR 0017 is Proposed and unbuilt. If you are designing around agents now, we would rather hear from you while the record is still open.