Product · Extend
Agent & MCP Identity
An identity for the software acting on your customers’ behalf
AI agents now act in your product on someone else’s authority. RealmSSO gives each agent an identity of its own in your customer’s realm, the separate sign-in space RealmSSO keeps for that account. Live now: a client for each agent, with a secret or with none, four attribution claims you can log and audit, the customer’s own provider vouching for an agent, a kill switch for each agent client, an MCP discovery template and a dashboard page. Building now: scopes granted per agent, brokered egress, a stop for one agent principal, and an RFC 7591 registration policy. Each group below carries its status.
Your agent
client secret, or a platform-issued token (no secret stored)
Customer's realm
an identity per agent · four attribution claims · revoke · audit
Your app / MCP server
can log who acted · discovery template from the config route
Building now: lanes 2 and 3, the designs for scopes and egress
Your resource
you would name its scopes; a platform operator would register them
Account admin would grant
scopes to one agent; the realm is designed to refuse to mint the rest
Your server
must still check each scope
Your agent
would hold no third-party key
RealmSSO egress broker
an egress grant would name a destination and its tools; default deny; every decision would be audited
Third-party MCP / API
would be called by the broker, using the key the broker holds
Agent identities, assigned to accounts
Each agent gets an identity of its own inside one customer’s realm, so you can tell it from a person, audit it and, for an agent client, stop it.
An identity for each agent, in your customer’s realm
RealmSSO creates a confidential, client-credentials-only client for each named agent in your customer’s own realm. A realm is the separate sign-in space RealmSSO keeps for each account. An agent client cannot use a browser, carries no roles in its tokens, and cannot get a refresh token: offline_access is refused. A client with a secret gets the secret once, in the registration response. RealmSSO’s database does not keep it. Registration is RealmSSO’s own API, not RFC 7591. API and dashboard.
Or no secret at all, where the agent’s platform can vouch for it
Instead of a secret, the agent presents a JWT that its platform minted: a managed Kubernetes cluster’s service-account token, or a GitHub Actions token. Then no secret exists: not in the response, not in our database and not in the sign-in service. The issuer must be public and use https, and RealmSSO refuses a private or in-cluster issuer. It is designed for public issuers such as these. Not yet tested against GitHub Actions or a managed Kubernetes service: the tests used a stand-in issuer shaped like them. A hostname move lists every secretless agent it would strand, and refuses to apply until a platform operator acknowledges them. API and dashboard.
Your audit trail can tell an agent from a person
An agent client’s tokens carry four attribution claims: agent, agent_source, agent_owner and agent_parent. For an agent principal, only tokens issued by the account’s own client carry them. A human’s token carries none of them. They ride in the access token and the userinfo response, and are kept out of the ID token, which is the artifact most likely to be logged. They say who acted, never what the agent may do. When an agent client authenticates, or fails to, the audit log records the agent itself as the actor, up to a minute late. That record covers agent clients only, not agent principals.
The customer’s own provider can vouch for an agent
An agent can sign in to a customer’s realm with a JWT their identity provider signed, through the RFC 7523 assertion grant. An integration test on the real sign-in service shows that a valid assertion mints a token, and that a foreign issuer and a disabled user are refused. The assertion grant works on OIDC connections only, and stays off until two switches are on: the account’s agent access and the connection’s assertion grant. A save that keeps the connection’s issuer keeps every user’s link. A save that changes the issuer replaces its identity provider and deletes every user’s link to it; an agent principal is then refused with “User not found”, and nothing re-links it. The account switch also covers agent clients. While it is off, no agent client can be registered. Turning it off disables every existing agent client in the sign-in service, so none can get a new token. Turning it back on re-enables those clients, but not one that was revoked. Tokens already minted stay valid until they expire.
A kill switch for each agent client, with its strength stated
Revoking an agent client disables it in the sign-in service, so it can get no new token — its next token request returns 401. Tokens it already holds are not recalled: an application that checks only the signature accepts them until they expire. An agent principal has no switch of its own yet. Un-marking one removes the attribution claims from its new tokens, but it does not stop the agent. To stop it, turn off its connection’s assertion grant, which stops every principal on that connection.
A dashboard page for all of it
The Agent Identity page in the dashboard lists, registers, shows and revokes agent clients — the secret is shown once. It turns the account’s agent access on and off. Off refuses new agent clients and disables the existing ones, and the page marks each client the switch disabled. It also lists any connection that a partial switch-off left with its assertion grant on. Per connection, it turns the assertion grant on and off, and marks and un-marks agent principals, with their history from the audit log. It can also register a secretless agent client, which has no secret to show.
MCP-ready discovery
Stand an MCP server in front of a customer’s realm: /config returns that realm as the authorization server, and an RFC 9728 protected-resource document with only your own URL left to fill in. You publish it on your server; RealmSSO publishes none of its own. The template adds no scope. Your server must still check each token and decide each call. API and dashboard: the account’s SSO configuration card shows it, with a copy button.
Scopes, egress and a stop for one agent principal
We are building each item below now. None of it is available yet, and nothing on this page says any of it works today. Each row says what would happen.
You would name the scopes; a platform operator would register them
In the design, you would name the scopes of your resource, such as orders:read and orders:write. A platform operator would register the resource. A registration would reach only the accounts given explicit access, and every other account would be denied by default. No part of this is built.
An account admin would grant them to one agent
In the design, granting a registered scope to an agent would take the account’s admin role, or an API key with its own dedicated scope. A registered scope would not be granted until someone grants it, and a granted scope would reach a token only when the agent asks for it. The realm is designed to refuse to mint a scope that was not granted to that agent.
Your server must still check each scope
RealmSSO never sees a call to your application or your MCP server, so a token decides nothing by itself. In the design, your server must still check each scope and decide each call, as it does for people today. The attribution claims above would never become an authorization input.
The agent would call out and never hold the key
In the design, an agent would send its call to RealmSSO’s egress broker with its own RealmSSO token. The broker would hold the third-party MCP server’s or API’s credential and attach it to the call. A steered agent could misuse what its egress grant allows, but it could not leak a key it never had. Where a client must hold a token itself, the broker would hand out a short-lived, narrowed one instead.
An egress grant would name the agent, the destination and the tools
In the design, each egress grant would name one agent client and one destination, the scopes or tools it may use there, how long each credential it issues lives, and an optional call budget. An agent with no egress grant would reach nothing, and an egress grant with an empty tool list would be refused, never stored as “everything”. Every allow and every refusal would be audited with the agent as the actor. An account admin would write egress grants, and a member could revoke one or disable a destination.
The one place RealmSSO could allow or deny a third-party tool call
Only an outbound call that passes through the broker could be allowed or denied by RealmSSO. A call an agent makes directly to a third-party MCP server, or to yours, never reaches RealmSSO, and nothing here can see it or stop it. So the broker is where per-tool control of outbound calls would live, and it is not built.
A stop for one agent principal
A stop for one agent principal on the RFC 7523 path is being built now, and it is not available yet. Today the only stops are the connection’s assertion grant, which covers every principal on that connection, and disabling the user.
A registration policy for RFC 7591
RealmSSO’s registration route is its own API and is not RFC 7591. A registration policy that follows RFC 7591 is designed behind that route. It is not built.
Talk to the people who build it.
We run RealmSSO for you. Tell us which identity providers your customers use and how many customers you have, and we will tell you what fits today.