How to Set Up SSO and SCIM for an AI Gateway

Most AI-gateway security incidents are not exotic. They are a departed contractor's API key still working three weeks later, a shared "team key" pasted into a dozen notebooks that nobody can rotate without breaking everyone, and a model-access policy that lives in one engineer's memory. Enterprise AI access fails in boring, preventable ways, and the fix is the same identity plumbing every other serious enterprise system already uses: single sign-on for authentication and SCIM for lifecycle provisioning.

This post explains why AI access must run through SSO and SCIM rather than static keys, what each protocol does, how they map onto the specifics of an AI gateway (console login, model access, MCP server access, budgets), and how to set them up conceptually against any major identity provider. It is written for the platform or security engineer who has been handed "get the AI gateway under SSO" and needs to understand the mechanism, not just click through a wizard.

Want SSO and SCIM wired into every model and MCP server your teams use? Book a demo.

Why shared keys fail and identity fixes it

Start with the thing most teams actually do: a long-lived API key, often one per team, sometimes one for the whole company, handed around to call the gateway. It has four structural problems, and all four are solved by identity-based access.

• No attribution. A shared key means every request looks the same. You cannot tell who ran the query that cost $400 in tokens, which defeats the per-user observability and budgeting the gateway is supposed to give you.
• No lifecycle. The key does not know or care that someone left the company. Revoking it means rotating it, which means updating everyone who legitimately uses it. So in practice it is never rotated, and access never ends.
• No granularity. One key either works or does not. You cannot say "this team may use the cheap models but not the frontier one," because the key carries no identity to gate on.
• No central control. Access policy lives wherever the keys live, which is everywhere and nowhere.

SSO and SCIM replace this with a model where access is a function of who you are in the identity provider and what groups you belong to. Authentication proves identity at login. Provisioning keeps the gateway's picture of who exists, and who belongs to which group, in sync with the IdP automatically. When the IdP disables an account, access ends everywhere the account reached, with no manual step. That single property, automatic deprovisioning, is the reason this is not optional for enterprise AI.

SSO and SCIM are not the same thing

They are routinely conflated, and conflating them is how orphaned access happens. SSO logs people in. SCIM manages whether their account and group memberships exist in the first place. SSO is an authentication event; SCIM is a lifecycle sync.

The trap is to configure SSO, see people logging in with their corporate identity, and declare victory. SSO alone means that when someone is offboarded in the IdP, their ability to log in is gone, but if the gateway provisioned their account and access out of band, or if they still hold a token or key, the account and its entitlements can persist. SCIM is what reaches into the gateway and removes the account and its group memberships when the IdP says the person is gone. You want both: SSO so login is centralized and MFA-backed, SCIM so existence and access track the source of truth.

How it maps onto an AI gateway

An AI gateway has specific things to protect, and identity plugs into each of them. The chain runs from the identity provider to a concrete policy on models, MCP servers, and budgets.

Walk the chain left to right:

1. SSO for the console and for API access. When an engineer opens the gateway's console, they authenticate through the IdP via SAML or OIDC rather than a local password. The assertion or ID token proves identity and carries claims. The same identity backs programmatic access, so API calls are attributable to a real person or service, not an anonymous shared key.
2. SCIM syncs users and groups. The IdP pushes user records and their group memberships to the gateway's SCIM endpoint as they change. A new hire added to the "ml-platform" group in the IdP appears in the gateway, in that group, without anyone touching the gateway.
3. Groups map to RBAC roles. You define, once, that the "ml-platform" group maps to a role, and "finance-analysts" maps to a different role. This mapping is the heart of the design: it is where identity becomes authorization.
4. Roles gate models, MCP servers, and budgets. A role carries entitlements: which models it may call, which MCP servers it may reach, what rate limits and token budgets apply. TrueFoundry enforces budgets and rate limits per user, team, and model, returning HTTP 429 on breach, so a role can both allow access and cap spend.

The result is that access to your most expensive frontier model, or to a sensitive internal MCP server, is a property of IdP group membership. Grant it by adding someone to a group in the IdP; revoke it by removing them. The gateway's RBAC is covered in more depth alongside fine-grained authorization, and the broader "how do I even choose this" framing is in how to choose an AI gateway.

A concrete group-to-role mapping

Here is an illustrative mapping to make the abstraction concrete. Adjust the role names and entitlements to your own policy.

The last row is the whole point. Removal from the IdP groups, which SCIM propagates automatically, collapses a person's entitlements to nothing. No ticket, no manual key rotation, no "did we remember to remove their access everywhere."

See how TrueFoundry maps IdP groups to RBAC roles across the gateway. Book a demo.

Setting it up, step by step

The exact screens differ by identity provider, but the conceptual sequence is the same for Okta, Entra ID, Google Workspace, or any SAML/OIDC and SCIM 2.0 IdP. Do not invent provider-specific labels from memory; follow each IdP's own documentation for the field names. The shape is this:

Step 1: Create the application in the IdP. In the identity provider, register the gateway as an enterprise application. This is the object that will hold both the SSO configuration and, later, the SCIM configuration. Decide now which users and groups will be assigned to this application, because only assigned users will be provisioned.

Step 2: Configure SSO (metadata and claims). Choose SAML or OIDC. For SAML, exchange metadata: the IdP provides its entity ID, sign-in URL, and signing certificate; the gateway provides its assertion consumer service (ACS) URL and entity ID. For OIDC, you register a client and exchange issuer URL, client ID, and secret, and set redirect URIs. Either way, configure the claims: at minimum the user's email or unique identifier, and crucially the user's group memberships, because groups are what you will map to roles. Confirm the group claim is actually included in the assertion or token; a missing group claim is the most common reason role mapping silently fails.

Step 3: Enable SCIM (token and endpoint). Turn on provisioning. The gateway exposes a SCIM 2.0 base endpoint (a URL) and you generate a bearer token that authorizes the IdP to call it. Paste the endpoint and token into the IdP's provisioning configuration. The IdP will test the connection by calling the SCIM endpoint; a successful test means the IdP can create, read, update, and deactivate users and groups in the gateway.

Step 4: Map attributes and groups to roles. Configure attribute mappings so the IdP's user fields (email, display name, external ID) populate the gateway's user record, and SCIM group pushes land as gateway groups. Then, in the gateway, map each group to an RBAC role with its model, MCP server, and budget entitlements, as in the table above. This mapping is the policy; get it reviewed by whoever owns access governance.

Step 5: Test the full lifecycle. Do not ship on a login test alone. Test all three lifecycle events:

• Provision: add a test user to a mapped group in the IdP, confirm they appear in the gateway in the right role, and confirm they can call exactly the models and servers that role allows and nothing else.
• Move: change the test user's group in the IdP, confirm their gateway role and entitlements change to match.
• Deprovision: disable the test user in the IdP, confirm the SCIM deactivation removes their access, and confirm a call that previously worked now fails. This is the step that proves the orphaned-access problem is actually solved.

The lifecycle SCIM automates

The entire value proposition is in three events over an employee's or contractor's lifetime, and SCIM handles all three without a human touching the gateway.

• Join. HR or IT adds the person to groups in the IdP as part of onboarding. SCIM provisions the gateway account and, through group-to-role mapping, grants exactly the right entitlements. The person has working, correctly scoped AI access on day one with no gateway-side ticket.
• Move. Someone transfers from product engineering to the ML platform team. Their IdP group membership changes. SCIM propagates the change; their gateway role changes; they gain access to the frontier models and lose access to the old team's data servers. Access tracks the org chart automatically.
• Leave. The person is offboarded. The IdP disables the account. SCIM deactivates the gateway account and strips group memberships. Every entitlement, every model, every MCP server, every budget, goes to zero immediately. There is no window during which a departed person retains access, because there is no manual step to forget.

Compare that to the shared-key world: onboarding means finding and sharing the right key, moves mean nothing changes automatically, and leaving means someone has to remember to rotate a key that breaks everyone else when rotated, so it does not happen. The lifecycle gap is exactly where breaches live.

Beyond humans: agents and data residency

Human identity through SSO and SCIM is the foundation, but enterprise AI access has two dimensions humans do not fully cover.

First, agents are callers too. An autonomous agent that invokes models and MCP servers needs its own identity, its own role, and its own budget, not a borrowed human key. The same RBAC machinery that maps human groups to roles extends to agent identities, so an agent gets least-privilege access to specific tools and a capped budget. This is the natural continuation of the identity work; see AI agent identity and the MCP-specific controls in enterprise MCP governance.

Second, where identity and data live matters. Authentication and provisioning decide who may call what; deployment decides where the requests and their data physically go. TrueFoundry deploys as SaaS, in-VPC, on-prem, or air-gapped, so the data plane stays inside your network while identity integrates with your IdP. For regulated workloads this separation is the difference between a usable gateway and a compliance blocker; data residency and the control plane vs data plane split cover how that works.

Where teams get this wrong

They configure SSO and skip SCIM. Login is centralized, everyone is happy, and offboarding still leaves accounts and entitlements behind because nothing syncs deprovisioning. SSO without SCIM solves authentication and ignores lifecycle. Configure both.

They never test deprovisioning. The provision path gets tested because new users need access on day one. The deprovision path, the one that actually protects you, gets assumed. Disable a test account and confirm a previously working call now fails, every time you change the configuration.

They forget the group claim. SSO works, users log in, and then everyone lands in a default or empty role because the IdP assertion did not include group memberships. Role mapping depends entirely on the group claim being present and correctly named. Verify it in an actual assertion or token.

They keep a shared key as a "backup." A single admin or break-glass key left active defeats the whole model, because it is unattributable and never deprovisioned. If you need break-glass access, make it a named, audited, short-lived path, not a permanent shared secret.

They map everyone to one broad role. Provisioning through SCIM into a single "all users" role gives you attribution but not least privilege; everyone can call the frontier model and every MCP server. The point of group-to-role mapping is granularity. Model real teams and real entitlements.

Conclusion

Enterprise AI access does not fail in clever ways. It fails because a shared key outlived the person who used it, because offboarding was a manual step someone forgot, because nobody could say who spent the token budget. SSO and SCIM close those gaps by making access a function of identity: SSO authenticates every login through your identity provider, and SCIM keeps the gateway's picture of who exists, and who belongs to which group, in automatic sync with the source of truth.

Set up both, map groups to roles with real least-privilege entitlements, and test the deprovision path until you trust it. Do that, and access to your most expensive models and most sensitive MCP servers becomes something you grant by adding someone to a group and revoke by removing them, instantly and everywhere. That same identity foundation then carries forward to agent identity, fine-grained per-tool authorization, and the data-residency controls that regulated AI requires.

Automate joiner-mover-leaver access for your AI stack. Book a demo.