Obot v0.27 makes your identity provider the single source of truth for who can use your AI infrastructure. The release adds SCIM provisioning, starting with Okta, with Microsoft Entra ID next in line. When someone joins a team, changes roles or leaves the company, Obot now hears about it directly from Okta and adjusts their access to MCP servers, models, skills and agents to match. This feature is for convenience and security. SCIM lets Obot enforce least privilege continuously, not just at the moment someone signs in. This post explains what changed and how it works.
SCIM, the System for Cross-domain Identity Management, is an open standard (RFCs 7642, 7643 and 7644) for pushing users and groups from an identity provider into downstream applications. Instead of each app discovering users when they log in, the identity provider tells the app about every create, update, deactivation and group change as it happens. Before v0.27, Obot learned about Okta users the way most applications do: through single sign-on. A user’s identity and group memberships were read at sign-in and refreshed from the directory roughly every ten minutes. That model works, but it has gaps. Obot had no concept of a user being inactive. If someone was removed from Okta, an Obot admin also had to delete them in Obot. And any credentials that person had already been issued kept working until they expired or were cleaned up by hand. For a web app, that gap is an annoyance. For an AI governance platform, it is a real exposure. Obot sits in front of MCP servers that can read email, query databases, open pull requests and move money. It issues API keys to headless agents and OAuth tokens to AI clients such as Claude Code, Codex, and Cursor. Those credentials are designed to work without a human in the loop, so they must stop working the moment the human behind them loses the right to use them.
Try Obot today — the open-source MCP gateway. Self-hostable, MIT licensed, full audit trail at every tool call.
The setup is straightforward. An Obot owner enables SCIM on the Okta auth provider, and Obot generates a SCIM base URL (served under /scim/v2) and a bearer token. The admin configures SCIM in Okta and chooses which users and groups to push. From then on, Okta drives the user lifecycle:
When a user is assigned to the Obot app, Okta creates their account in Obot. When a pushed group changes, Obot updates its members, and every access rule that references that group takes effect immediately. When a user is unassigned or deactivated, Obot marks them inactive and revokes what they hold. Obot also gives admins the tools to run this safely in production. The SCIM token can be rotated, and Obot warns before it expires. Teams already on Okta SSO can migrate in place: Obot keeps existing group references working until those groups are pushed through SCIM, then hands control over.
Why this is least privilege in practice
Least privilege means every person and every agent has only the access their current role requires, and no more. Most access problems are not about granting too much on day one. They come from access that outlives its reason: the contractor whose project ended, the engineer who moved teams, the employee who left on Friday. SCIM closes this gap in three ways. Access is granted by group, and groups are owned by Okta. In Obot, MCP servers, models, skills, virtual MCP servers and agent access are all governed by rules that reference groups. With SCIM, those groups are pushed from Okta and kept in step with it. Nobody hand-edits a list in Obot. When a person leaves the Finance group in Okta, they lose the Finance MCP servers in Obot in the same moment. Removal is total, not partial. v0.27 introduces a real inactive state for users. When Okta deactivates someone, Obot refuses every request from them at the front door, and revokes their sessions, API keys, OAuth tokens and persistent tokens. SSO alone only stops new sign-ins. It does nothing about the agent running on a server with a key that person created last month.
There is no standing access to clean up. Because Okta is authoritative, an Obot admin no longer has to remember to mirror every HR change. The safest state, where access matches the directory exactly, becomes the default state. And when a group is deleted in Okta, Obot removes it from the policies that referenced it, so stale rules do not quietly linger.
Why least privilege is critical for AI governance
Identity teams have pushed least privilege for decades, so why does it deserve fresh attention now? Because AI agents change the cost of a mistake. A human with too much access is limited by their own attention. They can only open so many tabs and run so many queries in a day. An agent has no such limit. Give it a credential, and it can call every tool that credential unlocks, many times a minute, around the clock. If that credential belongs to someone who should no longer have it, the blast radius is far larger than one forgotten SaaS login. Agents also make access harder to see. A person who leaves a company stops showing up at work, which is a visible signal. An agent they configured does not stop. It keeps running in a CI pipeline, a scheduled job or a teammate’s laptop, using a key that looks perfectly valid. The only reliable defense is to make sure it can reach as little as possible, for as short a time as possible. This is why Obot treats identity as part of the control plane for AI. Access rules decide which MCP servers and models a group can use. Agent Auth Scopes narrow what a headless agent can do. Audit logs record every tool call. SCIM guarantees the identities and groups they depend on are always current.
Microsoft Entra ID is next
Okta came first because it is widely used by teams running Obot, and because its SCIM client is well documented and predictable. Microsoft Entra ID is next on the roadmap. For organizations that run on Microsoft 365, that means the same guarantee will apply: whoever Entra says should have access gets it, and whoever Entra removes loses it everywhere in Obot at once. We will share more as Entra support lands.
Getting started
The Okta SCIM guide in the Obot docs walks through setup, migration from SSO-only and troubleshooting. If you have feedback, or want to help test Entra support, find us on Discord. Access that matches reality, all the time, is what least privilege was always meant to be.
