SCIM vs OAuth for AI agents: lifecycle vs access

3 min read · Published 17 October 2026

If you already use OAuth for your agents, you might think SCIM is redundant. It is not. They answer different questions, and the gap between them is where forgotten agents live.

Short answer

OAuth 2.0 controls access: what an agent may do, with which token, for how long. SCIM controls lifecycle: that the agent exists, who owns it, and whether it is active. You need both, and you need them connected, because disabling one does not automatically disable the other.

What OAuth does for an agent

RFC 6749, published in October 2012, describes OAuth 2.0 as a framework that lets a third-party application get limited access to an HTTP service. It can do that on behalf of a resource owner, or on its own behalf. That second case is the one agents usually live in: the agent is the client, it gets an access token from an authorization server, and it calls an API with that token.

The spec defines four roles: the resource owner, the resource server, the client, and the authorization server. Nothing in them says who deployed the client, who is responsible for it, or whether it should still exist next quarter. OAuth is not meant to say that.

What SCIM does for an agent

SCIM keeps the register. It stores the agent as a record with a name, an identifier, an owner and an active flag, and it pushes changes to the apps that need to know. For the details of the agent proposal, see SCIM for AI agents: what the IETF draft says so far.

A hotel is a good picture

A keycard opens doors. That is the OAuth token. The guest register says who the guest is, who booked the room, and whether they checked out. That is SCIM.

Now imagine the guest checks out and the receptionist updates the register. If the keycard system never hears about it, the card keeps opening the door until it expires. In many setups a token that has already been issued keeps working until it expires, unless the API checks again or the token is explicitly revoked. RFC 7009 defines a standard way to revoke OAuth tokens, but someone has to call it.

So the dangerous state looks like this: the agent is inactive in the directory, and still holds a working token. Nobody sees the problem, because the register says everything is fine.

Which tool answers which question

Question	OAuth	SCIM
What can this agent do right now?	Yes, through scopes and tokens	No
Which API calls is it allowed to make?	Yes	No
Who owns this agent?	No	Yes, in the owners field of the draft
Is it still supposed to exist?	No	Yes, through the active flag
Can I switch it off in every app at once?	Only by revoking tokens one by one	Yes, one change to the record, then each app follows

Connecting the two

The early drafts tried to join the two worlds. Microsoft's August 2025 draft had an optional attribute, oAuthClientIdentifiers, for agents that authenticate with OAuth token exchange. Each value carried a clientId, an issuer and a subject, tied to the iss and sub claims of the token. Okta's October 2025 draft had a subject string meant to match the sub claim of an inbound OpenID Connect token. With a link like that, a service could look up the agent record behind a token and check whether it is still active.

The June 2026 joint draft has neither attribute. Oracle's credentialDiscoveryUri takes a different route and points to a document that describes how the agent binds credentials. The pieces are still moving, so do not count on a standard bridge yet.

Until the standards settle, you can do the joining yourself:

Give every agent one identifier and use it in both places: the SCIM record and the OAuth client registration.
Keep token lifetimes short, so a stale agent loses access on its own.
When active turns false, run a job that revokes that agent's tokens and keys. Do not assume the flag does it.
Check the other direction too. List OAuth clients that have no matching agent record. Those are the ones nobody owns.

The same steps appear in our offboarding checklist. For how this differs from the login standards, see SCIM vs SAML vs OIDC.

Sources

Own the name for this category.

agentscim.com is for sale. If you build identity, security or agent tooling, write to me. Serious offers get a reply within 24 hours.

Make an offer

Keep reading

This is an independent page. It is not affiliated with the IETF, Okta or Microsoft. Standards and drafts change, so check the linked sources for the current state.