SCIM Group Sync for an AI Governance Proxy: Enforcing Per-Team Policies from Your IdP

Provisioning, authentication, and authorization are separate jobs

Each concern is handled by a different mechanism, and keeping them apart makes the design easier to reason about and to test.

• Provisioning: SCIM brings users and groups into the proxy.
• Authentication: SSO, using OIDC or SAML, remains responsible for proving who the user is.
• Authorization: policies are evaluated on every request, with default deny.

Because the identity provider is the source of truth, team membership is changed only in the IdP. The proxy offers no manual membership editing for synced groups.

Designing the group-to-policy mapping

Map stable group identifiers to policy sets. The directory and mapping store holds users, groups, memberships, and a table binding each group identifier to one or more policy sets. Because the binding uses a stable identifier, a renamed group in the IdP does not change enforcement.

A reference pipeline

A minimal pipeline has five components. The names are generic, and the same responsibilities apply whatever IdP or proxy you run.

1. IdP as authority

   Team membership is changed only in the IdP. The proxy offers no manual membership editing for synced groups.

2. SCIM endpoint

   Receives user and group create, update, and deactivate operations. Handlers should be idempotent so replays do not corrupt state.

3. Directory and mapping store

   Holds users, groups, memberships, and a table binding each group identifier to one or more policy sets.

4. Policy resolver

   Turns a user's current memberships into one effective policy for the request, applying conflict rules and default deny.

5. Enforcement point and audit log

   The proxy applies the effective policy to model access, tool calls, data handling, and spend and rate limits, and records the decision with its inputs.

Resolving conflicts and defaulting to deny

The policy resolver turns a user's current memberships into one effective policy for each request. It applies explicit conflict rules and default deny, so a user with no mapped group is denied on every route.

Test conflicting memberships before rollout: a user in overlapping groups with conflicting policies should receive the result your resolution rule predicts. Also confirm that nested group behavior matches what your IdP actually sends, including a cycle test.

Latency, deprovisioning, failures, and audit evidence

Measure worst-case sync latency and document it. Deprovisioning is the case that matters most: deactivating a user should block requests, issued keys, and sessions within the latency you measured.

Sync can fail, arrive partially, or be replayed. Each of these should leave the proxy in a known state, and each should be visible in the audit log. Idempotent SCIM handlers keep replays from corrupting state.

Validate before rollout

• Group mappings use a stable identifier, and a renamed group in the IdP does not change enforcement.
• A user with no mapped group is denied on every route.
• Deactivating a user blocks requests, issued keys, and sessions within the latency you measured and documented.
• A user in overlapping groups with conflicting policies receives the result your resolution rule predicts.
• Nested group behavior matches what your IdP actually sends, including a cycle test.
• A failed, partial, and replayed sync each leave the proxy in a known state, and each is visible in the audit log.