How to Set Up SSO and SCIM for AI Tools and Agents

An AI tool with its own usernames and its own group list is a second directory to keep in step with the first. SSO and SCIM are how you avoid that, and the setup is mostly deciding what your identity provider is the source of truth for.

What do SSO and SCIM each do?

Single sign-on (SSO) handles sign-in. With SAML (Security Assertion Markup Language) 2.0, an identity provider authenticates the person and sends the tool a signed assertion. The assertion can carry attributes such as email and group membership. OpenID Connect (OIDC) plays the same role with a different protocol.

System for Cross-domain Identity Management (SCIM) handles accounts. It is an HTTP and JSON protocol, defined in RFC 7644, with standard Users and Groups resources and operations to create, read, replace, patch, and delete them. Its core schema includes an active attribute, where false typically means the account is suspended.

The difference matters at offboarding. SSO decides whether someone can sign in. SCIM decides whether the account and its group memberships still exist.

What does Metorial document today?

Metorial documents SSO for portals. Portal authentication covers SSO tenants, email or domain allowlists, and session expiry. Access groups can apply to every account by default or match SSO group IDs, and the product pages describe SAML sign-in with group import.

Accounts are created by invitation. In Workforce, under Identity, Accounts, select Invite User. Metorial's public documentation does not describe SCIM provisioning or deprovisioning. If you need it, ask in a demo before you plan around it. The rest of this page describes what the standards expect, so you can check any tool against it.

How do you set up SSO for AI tools?

1. Pick the groups first. List the identity provider groups that should map to AI tool access, such as engineering, support, and finance. Reuse existing groups where you can.

2. Configure sign-in. In Metorial, open Workforce, then Portals, open the portal, and go to its authentication settings. Add the SSO tenant, set any email or domain allowlist, and choose a session expiry.

3. Create matching access groups. Under Access, Groups, create a group for each team and match it to the SSO group ID. Turn on default assignment only for a group every new account should join.

4. Allow groups on resources. Open each integration or skill, select Add Group in its Access section, set Allow or Deny, and save. How to control which AI tools each team can use covers this in more depth.

5. Test the real path. Open the portal as a person in each group, using the same sign-in route your users will, and confirm they see the right integrations and skills.

What should provisioning do?

Whether through SCIM or a manual process, provisioning has four jobs:

1. Create the account when someone is assigned to the application in the identity provider.
2. Keep group membership current as people change teams.
3. Suspend the account when someone leaves, which SCIM expresses as active set to false.
4. Keep the record of what the person did, even after the account is gone.

Without SCIM, jobs one to three become manual steps. Follow How to onboard and offboard employees' AI tool access: remove group assignments and direct grants on the account's Access view, and offboard the person in the identity provider. Their past calls stay in Tracing.

What should you check in a security review?

• Who owns the mapping between identity provider groups and tool groups, and who is told when it changes.
• How long a session lasts after a person is disabled. A short session expiry limits the gap.
• Whether agents act under the person's identity or a shared credential. The tokenless approach ties them to the person.
• Whether automated agents use service accounts with named owners.
• Whether logs show the person for every call.

How do you test offboarding?

Do not assume the chain works. Each quarter, create a test account in a test group, connect an integration, and run one tool call. Then disable the account in the identity provider, remove its groups, and try again. Check the Tool Calls table for the result, and write down how long the gap lasted. That number, not the vendor's feature list, is what your security team needs.