Rolling out SSO and SCIM for your AI platform

Enterprise AI platforms touch sensitive data: internal knowledge bases, proprietary fine-tuning datasets, provider API keys, and every prompt your teams send. Identity management cannot be an afterthought. SSO and SCIM are the two mechanisms that keep ManyLayers synchronized with your organization’s authoritative identity source — and they need to be configured before you onboard your first team.

Why SCIM matters more than SSO alone

SSO (SAML 2.0 or OIDC) handles authentication — it proves that a person is who they claim to be. SCIM handles lifecycle management: provisioning new accounts when someone joins, updating group memberships when they change teams, and deprovisioning access when they leave.

Without SCIM, a departing employee’s ManyLayers account persists until an administrator manually removes it. With SCIM, the deprovisioning happens automatically as your identity provider (Okta, Azure AD, Google Workspace) processes the offboarding event. For AI platforms with access to production data, this gap matters.

The risk isn’t just theoretical. A former employee whose account persists for 30 days after their departure can continue sending requests through the gateway, querying knowledge bases, and consuming budget allocated to their former team. In a platform with hard budget caps, stale accounts can exhaust budget before the team realizes why.

Connecting your IdP

ManyLayers supports SAML 2.0 and OIDC for authentication, and SCIM 2.0 for provisioning. The setup is symmetric: you register ManyLayers as an application in your IdP, copy the metadata or endpoint URLs, and paste them into ManyLayers Platform Settings → Identity.

For Okta:

1. Create a new SAML 2.0 application in Okta Admin.
2. Set the ACS URL and Entity ID from ManyLayers Platform Settings → Identity → SAML.
3. Map the email, firstName, lastName, and groups attributes to the ManyLayers claim schema.
4. Enable SCIM provisioning, set the SCIM base URL to https://your-instance.manylayers.io/scim/v2, and generate a SCIM bearer token from ManyLayers.
5. Enable “Push Groups” in Okta — this pushes Okta group membership to ManyLayers teams.

Azure AD and Google Workspace follow the same pattern with provider-specific screens.

Mapping groups to teams and budget policies

This is where ManyLayers diverges from a typical SaaS SSO integration. Groups pushed via SCIM become ManyLayers teams, and teams are the unit of budget enforcement.

After SCIM sync, navigate to Platform Settings → Teams and assign a budget policy to each team:

{
  "team": "data-engineering",
  "monthly_budget_usd": 2000,
  "alert_threshold": 0.8,
  "hard_cap": true,
  "allowed_models": ["openai/*", "anthropic/*"],
  "denied_models": ["openai/gpt-4o"]
}

When hard_cap is true, requests from team members are rejected at the gateway once the monthly budget is exhausted. When false, the team receives an alert but requests continue. Hard caps are appropriate for teams with unpredictable usage patterns; soft caps work better for teams doing latency-sensitive production workloads.

RBAC beyond budget policies

ManyLayers has three built-in roles:

• Member — can send requests and view their own usage
• Team Admin — can manage team settings, connectors, and knowledge bases
• Org Admin — can manage all teams, policies, audit log exports, and identity settings

Roles are assignable per-team. An engineer can be a Member in the data-engineering team and a Team Admin in the ai-platform team. Assign roles in Platform Settings → Teams → Members, or map them from IdP attributes via SCIM custom extensions.

Audit log integration

Every authentication event, policy change, and team membership update is written to the ManyLayers audit log. For SCIM-driven events (provision, deprovision, group change), the log records the SCIM operation and the acting identity provider, giving you a complete chain of custody from HR system to AI platform access.

Export the audit log to your SIEM by configuring an S3-compatible export target or a Postgres sink in Platform Settings → Audit. Log entries are structured JSON, making ingestion straightforward for Splunk, Elastic, or Datadog.

Common configuration mistakes

Mistake 1: Not mapping all IdP groups before go-live. If you push SCIM sync before mapping all groups to ManyLayers teams, users who belong to unmapped groups will be provisioned without a team assignment. They can authenticate but cannot send requests. Map all groups first, or configure a default team for unmatched users.

Mistake 2: Using a personal service account for SCIM. SCIM provisioning requires an API token. Create a dedicated service account in ManyLayers for SCIM operations and rotate its token on the same schedule as other service credentials. If the service account belongs to a person who leaves the organization, SCIM provisioning fails at the next sync — which you may not notice until someone complains about missing access.

Mistake 3: Not testing deprovisioning. Most teams test the SSO login flow and SCIM provisioning, but not deprovisioning. Test it explicitly: remove a test user from their IdP group, trigger a manual SCIM sync, and verify the membership disappears from ManyLayers within the expected sync interval.

Testing before go-live

Before enabling SSO for your organization, test the full flow with a pilot group:

1. Create a test Okta group with five accounts.
2. Push the group via SCIM and verify it appears in ManyLayers → Teams.
3. Assign a low budget policy to the test team.
4. Log in with a test account via SSO and send a request through the gateway.
5. Confirm the request is logged under the correct team and counted against the budget.
6. Remove one test account from the Okta group and verify the ManyLayers membership is deprovisioned within the SCIM sync interval (typically 15–60 minutes depending on your IdP plan).

Once the pilot validates end-to-end provisioning and budget enforcement, expand SCIM to the full organization.