Skip to main content
Flow diagram. An identity provider such as Okta or Microsoft Entra sends users and groups into StackOne, and an AI platform sends tool calls over MCP. Inside StackOne, three checks run in order: who gets in, set by SSO, JIT and SCIM; who can link accounts, set by Connector Profile Access; and who can use each account, set by Shared Accounts and groups. A user who holds a role on the linked account has their agent act through it. A user with no role finds the account unavailable to their agent. A user deactivated in the identity provider has their access suspended and is signed out. Below StackOne, an arrow labeled Logs API leads to your SIEM, which receives the logs through a collector you run.
Rolling StackOne out to the whole organization gives everyone the same MCP connection, with access set by your identity provider (IdP) and by the people who own each system. The IdP decides who is in the organization. Groups carry access to projects, connector profiles and linked accounts. Each system’s owner decides who can link accounts to it, and who can use the account they linked. StackOne logs every tool call and setup change. The Logs API hands those logs to your security information and event management (SIEM) system.
These settings control access to StackOne. They never change permissions inside a connected provider.

​
What each part decides

​
Choose how users join

Just-in-Time Provisioning and SCIM Provisioning can run on the same SSO connection: Use SCIM Provisioning wherever the IdP supports it, so a user the IdP deactivates loses access to StackOne without a separate step.
SCIM Provisioning is only available on certain plans. See plans and pricing.

​
Roll out access

Run these steps as an Organization Admin, with admin access to the StackOne application in the IdP. Keep provisioned access to the projects every user needs, and give each team the rest through its group. SCIM Provisioning applies provisioned access again on every update from the IdP, so a project you remove from a user comes back.
1

Connect the identity provider

SAML SSO is only available on certain plans. See plans and pricing.
Follow the guide for your IdP to create the SAML app, register it in StackOne and verify the email domain your users sign in with:

Okta

Microsoft Entra ID

Other SAML 2.0 provider

2

Open the SSO connection

  1. In the StackOne dashboard, go to Organization > Security > SSO.
  2. Open the verified SSO connection.
  3. Select the Provisioning tab.
3

Choose projects and roles

  1. On the Provisioned access card, select Manage access.
  2. Pick the projects new users should join.
  3. Choose a role for each one. See Project Roles.
  4. Select Save changes.
Provisioned access applies to users added by both Just-in-Time Provisioning and SCIM Provisioning.
The Provisioned access panel with a project checked and its own role dropdown set to Viewer, and a note that the organization role is set separately.
4

Enable JIT

On the Just-in-time provisioning card, select Enable JIT. See Just-in-Time Provisioning for when a user isn’t added.
5

Link SCIM and copy the credentials

  1. On the Directory Sync card, select Link SCIM.
  2. In the SCIM Details section, copy the SCIM base URL and the Provisioning token. You paste both into the IdP.
The Provisioning tab on an SSO connection, showing the Provisioned access, Just-in-time provisioning, and Directory Sync cards with their Manage access, Enable JIT, and Link SCIM actions.
The Directory Sync panel showing the SCIM base URL and the masked provisioning token with a Regenerate action.
The token is only shown once. Store it somewhere safe before you close the panel. To replace a lost or leaked token, see Rotate the token.
6

Turn on provisioning in the IdP

Paste the SCIM base URL and the Provisioning token into the IdP, then assign the users who should join:
7

Push each team's group

  1. In StackOne, create an empty group with the same name as the directory group, and assign it to the team’s projects. See Prepare the access before you push.
  2. Push the directory group from the IdP. The pushed group takes over the empty one and keeps its projects.
Push the group from the app’s Push Groups tab. See Push groups.
On the Groups tab of Organization > Manage Team, each pushed group carries a Synced tag. To give a group more projects later, see Assign a group to a project.
Project Settings > Access with the Users / Groups switch set to Groups, showing each assigned group with its role and a Revoke action.

A project's Access view, with groups and their project roles

8

Restrict sensitive connector profiles

Connector Profile Access is only available on certain plans. See plans and pricing.
When only one team should connect to a provider, such as a payroll system, switch the connector profile to Restricted on its Access tab and grant the team’s group Connector Profile Member. Everyone else in the project can no longer link accounts through it. See Restrict a connector profile.
A connector profile's Access tab set to Restricted, explaining that only the listed users and groups can link new accounts while already-linked accounts stay connected, above a user roster with Member and Admin roles and Revoke buttons

A connector profile restricted to the users and groups granted on it

To have new connector profiles in a project start Restricted, change the project’s default access.
9

Share accounts a team works through

When a team acts through one login, such as a support mailbox, the user who linked the account grants the team’s group Account Member on the account’s Access tab. Linking an account makes that user its Account Admin. See Assign a group to an account.
10

Require SSO

Requiring SSO is only available on certain plans. See plans and pricing.
Once assigned users can sign in through the IdP, require SSO so that password sign-in stops working. Test a sign-in first, as Require SSO describes, because enforcement locks out anyone the IdP can’t authenticate.

​
When someone leaves

Deactivate or unassign the user in the IdP. With SCIM Provisioning linked, their access to the organization is suspended, they leave every synced group, and they’re signed out. Their agents can no longer act through StackOne. Their own accounts inside each provider are managed in that provider. SCIM Provisioning never deactivates the organization’s last active Organization Admin. Make another user an Organization Admin before that admin leaves. See Deprovisioning. With Just-in-Time Provisioning only, disable the user in StackOne as well. See Removing access to the organization.

​
Send audit logs to your SIEM

The Logs API is only available on certain plans. See plans and pricing.
StackOne records an action log for every tool call, with the Linked Account it ran through, and a platform log for every change to StackOne itself, such as a new Linked Account. To keep them with the rest of your audit data, run a collector that pulls records from the Logs API and forwards them to your SIEM or data platform, such as Splunk or Datadog: Each API key reads one project’s logs, so give the collector a key for every project you roll out. If the project has IP restrictions, add the collector’s IP address. Sign-in attempts are in Security logs, under Organization > Security > Logs.

​
Examples

An HR team that handles payroll.
  1. Restrict the HR connector profile that reaches payroll data.
  2. Grant the HR team’s group Connector Profile Member on it.
  3. Only the HR team can link accounts through it.
A support lead and a team of agents who all answer customers from one shared inbox.
  1. The support lead links the mailbox once.
  2. They grant each agent Account Member on it.
  3. Agents send replies through the mailbox without needing its password.

​
Next steps

AI Platforms

Give users the MCP connection for their AI platform.

Tool Policies

Decide which tools each user’s or group’s agents can use.

Roles and Groups

How roles combine, and what admins can do with other users’ linked accounts.

IP Restrictions

Limit which IP addresses can call a project’s API.