> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/1.-identity-and-access/1.1-sso-and-scim-for-ai-platforms.md). # 1.1 SSO & SCIM for AI platforms Force managed login and automate lifecycle provisioning so AI platform access follows your joiners, movers, and leavers process. *Last reviewed: August 18, 2026* {% hint style="info" %} AI platform access should follow your identity provider. SSO handles sign-in. SCIM handles lifecycle. Without both, users can keep access after role changes, team moves, contract endings, or account cleanup. {% endhint %} ## What security teams need to know about SSO & SCIM for AI platforms AI tools have moved from chat windows into code editors, browsers, office files, mobile apps, and direct APIs. That makes identity the first control. If a user can reach an AI platform with a personal account or a stale invitation, most downstream policies become softer than they look in the admin console. Single sign-on gives the organization a controlled login path. It lets security teams enforce MFA, conditional access, device posture, location rules, and joiner or leaver workflows through the identity provider. SCIM (System for Cross-domain Identity Management) adds lifecycle management. It provisions users and groups into the AI platform, updates membership as people move teams, and removes access when the IdP says a person should no longer have it. SCIM matters because AI access is often group-shaped. The group may decide who can use a coding agent, who can connect Slack, who can publish a custom assistant or skill, who can reach web search, or who can use admin tooling. Manual invites do not keep up with those decisions. The clean pattern is simple: make the IdP the source of truth, sync groups into the AI platform, assign platform roles to those groups, and remove manual exceptions on a schedule. ## Common SSO & SCIM for AI platforms security failures * SSO is enabled, but users are still invited manually and never become SCIM-managed. * A user is removed inside the AI platform, then reappears on the next directory sync because the IdP assignment was never changed. * Chat, coding, API, and admin surfaces are managed separately, with different owners and different offboarding behavior. * SCIM groups are synced, but workspace roles are still assigned directly to individual users. * The default role or default seat gives more access than a newly provisioned user should receive. * The organization treats SSO as account consolidation. SSO controls sign-in, but it does not automatically migrate or clean up every personal account. ## SSO & SCIM for AI platforms security controls checklist * Require SSO for managed workspaces and enterprise accounts. * Enforce phishing-resistant MFA, conditional access, and managed-device requirements through the identity provider where supported. * Enable SCIM for every supported workspace or organization, including separate chat and API organizations where the provider splits them. * Sync groups by use case, data sensitivity, and job function rather than broad department alone. * Assign roles to groups, not individuals, except for time-limited break-glass access. * Review default role, default seat, and default capabilities before automated provisioning. * Define session lifetime, reauthentication, token revocation, and device-loss procedures for each surface. * Test whether deprovisioning ends active web, desktop, mobile, CLI, IDE, API, remote, and connector sessions. * Keep emergency administrator accounts separate, monitored, time-limited, and tested. * Remove SCIM-managed users through the IdP, not directly in the platform. * Review pending invitations, manually added users, unsupported login paths, and personal accounts each month. * Record the IdP group, platform role, product surface, authentication method, business owner, and review cadence for each access path. ## Session assurance SSO proves how a managed session begins. Security also needs to know how it ends. Record the maximum session age, refresh-token behavior, reauthentication triggers, local credential cache, device binding, and revocation path for every surface. Test a disabled user, a lost device, a removed connector grant, and an administrator role change. If a desktop, CLI, IDE, mobile, or remote session continues after the expected cutoff, treat that as a control gap rather than an implementation detail. ## Anthropic ### Overview Anthropic supports both just-in-time (JIT) and SCIM provisioning for Claude Enterprise organizations, and documents how SCIM sync applies identity-provider changes to the organization. Claude Enterprise includes Claude on web, desktop, and mobile, plus Claude Code and Cowork, so the identity design should cover the whole organization rather than a single client. Claude Console roles are separate from Claude app custom roles, so treat chat, Cowork, Claude Code, Console, and API access as related but distinct access paths, and assign Enterprise custom roles to SCIM-synced groups rather than individuals. One ordering detail matters before enablement: Anthropic documents that saving a SCIM configuration before users are assigned in the identity provider can deprovision existing users. Complete the IdP assignment first, then save the SCIM configuration, and test with a pilot group before rolling sync out to the whole organization. For Claude Code, the authentication model can include Claude.ai accounts, Console credentials, cloud provider credentials, and gateway-issued tokens. That flexibility is useful for engineering teams, but it also means identity review needs to include local CLI and CI usage. A developer with an API key in an environment variable may not be following the same lifecycle path as a user who signs in through the Claude app. ### Anthropic documentation * [Set up JIT or SCIM provisioning](https://support.claude.com/en/articles/13133195-set-up-jit-or-scim-provisioning) * [How SCIM sync works for Enterprise organizations](https://support.claude.com/en/articles/14499648-how-scim-sync-works-for-enterprise-organizations) * [Important considerations before enabling SSO and JIT/SCIM provisioning](https://support.claude.com/en/articles/10276682-important-considerations-before-enabling-single-sign-on-sso-and-jit-scim-provisioning) * [Set up single sign-on (SSO)](https://support.claude.com/en/articles/13132885-set-up-single-sign-on-sso) * [What is the Enterprise plan?](https://support.claude.com/en/articles/9797531-what-is-the-enterprise-plan) * [Claude Code authentication](https://code.claude.com/docs/en/team) * [Manage custom roles on Enterprise plans](https://support.claude.com/en/articles/13930452-manage-custom-roles-on-enterprise-plans) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview OpenAI documents SCIM for both ChatGPT workspaces and API Platform organizations, but says SCIM is not shared across those surfaces. That is an important operational detail. A clean ChatGPT offboarding flow does not automatically prove the API organization is clean. OpenAI's SCIM FAQ also warns against enabling Automatic Account Creation and SCIM together because only SCIM-managed users can be automatically deactivated through IdP group changes. ChatGPT Enterprise also has seat types as well as roles. Seat type controls which product surface the user can reach, while role controls workspace administration. ### OpenAI documentation * [SCIM Integration FAQ](https://help.openai.com/en/articles/10011769-scim-integration-faq) * [Managing members, seat types, roles and access in ChatGPT Enterprise](https://help.openai.com/en/articles/8266401-managing-members-seat-types-roles-and-access-in-chatgpt-enterprise) ### Applicable Harmonic guides for OpenAI * [Securing ChatGPT Enterprise Guide](https://www.harmonic.security/resources/securing-chatgpt-enterprise-guide) ## Frequently asked questions about SSO & SCIM for AI platforms ### Is SSO enough for AI platform access? No. SSO controls authentication, but it does not keep group membership, feature access, seat type, or deprovisioning in sync by itself. SCIM closes much of that lifecycle gap. ### Should we create one IdP group for all AI access? Use one group only for a small pilot. In production, split groups by surface and risk, such as chat-only users, coding-agent users, API developers, admins, and regulated-data users. ### What should security review first? Start with non-SCIM users, manually invited admins, default roles, pending invitations, and users with access to code, connectors, or API keys. ### What is the difference between SSO and SCIM for AI tools? SSO controls how users authenticate. SCIM controls provisioning, group sync, and deprovisioning. Most enterprise AI rollouts need both. ### Why do ChatGPT and API access need separate identity checks? OpenAI documents ChatGPT workspace SCIM and API Platform SCIM as separate configurations. Review both surfaces before treating a user as fully provisioned or fully removed. ## Applicable regulations and frameworks | Governance page | Relationship to this article | | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | G.1 Map your controls to NIST AI RMF and CSF 2.0 | This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports identity and access control. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Access Controls guidance. | | G.6 Write an AI Acceptable Use Policy that holds up | This article supplies a technical or process control used to enforce the acceptable-use policy. | | G.7 Ownership and RACI for AI security | This control depends on the ownership and evidence responsibilities defined in the RACI. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA identity, authentication, least privilege, and workforce access. | *G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.* ## Related handbook guidance * [1. Identity & Access](/handbook/1.-identity-and-access.md) * [1.2 RBAC across AI platforms](/handbook/1.-identity-and-access/1.2-rbac-across-ai-platforms.md) * [1.3 Tenant restrictions: blocking personal accounts](/handbook/1.-identity-and-access/1.3-tenant-restrictions-blocking-personal-accounts.md) * [1.4 Domain claiming: bringing shadow accounts into enterprise](/handbook/1.-identity-and-access/1.4-domain-claiming-bringing-shadow-accounts-into-enterprise.md) * [6.1 The audit gap: what you can and can't see](/handbook/6.-observability-audit-and-evidence/6.1-the-audit-gap-what-you-can-and-cant-see.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://handbook.harmonic.security/handbook/1.-identity-and-access/1.1-sso-and-scim-for-ai-platforms.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.