Cursor Enterprise: Identity & Access Management (SSO, SCIM, roles)

Cursor's identity page lists four steps, from sign-in down to admin access, and says to take them in this order.

1. 1Set up SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. so centralized authentication works first.
2. 2Enable SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. to automate the user lifecycle.
3. 3Deploy MDM policies to enforce allowed team IDs and extensions.
4. 4Assign roles to grant admin access to the right people.

Of the four steps, only SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. has a documented dependency on an earlier one. It requires an active SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. connection, and Cursor shows the SCIM setup link only after SSO is verified. The identity page gives no technical dependency for the last two steps, but running MDM early has a cost.

That cost comes from AllowedTeamId. The policy checks the team ID of the account that signs in, not the person at the laptop. Anyone whose account isn't in your Cursor team yet is logged out at once and can't sign in again until they use an allowed team ID. Push the policy after SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. and SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. have put people in the right team.

SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. lets people sign in to Cursor through your existing identity provider with their corporate credentials, instead of separate Cursor passwords. Cursor supports SAMLSecurity Assertion Markup Language. The XML-era enterprise standard that powers single sign-on: your identity provider vouches for you to each app. Older than OIDC but still what many enterprise tools speak. Press Enter for the full definition. 2.0 on Teams and Enterprise, and its identity page names Okta, Azure AD, Google Workspace and OneLogin as example providers.

Cursor's pages disagree on enforcement. The identity page says that when you enable SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition., you can require it for all team members and block password sign-in entirely. The SSO setup page says enforcement has no toggle of its own: when the domain is verified and the SSO connection is active, every user on that domain has to use SSO. Assume enforcement begins as soon as both are active, and assign everyone who needs Cursor to the Cursor app in your identity provider before that point.

The advice applies as soon as you link a second team. With team-level SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition., each team keeps its own SAMLSecurity Assertion Markup Language. The XML-era enterprise standard that powers single sign-on: your identity provider vouches for you to each app. Older than OIDC but still what many enterprise tools speak. Press Enter for the full definition. configuration, so you set up and maintain one connection per team. Keep a team-level setup where a team's identity needs differ, such as Cursor's example of a team that runs its own Okta instance.

SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. 2.0 provisioning manages your team members and directory groups from your identity provider. It's an Enterprise feature, and it needs SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. enabled. Without SCIM, you add people to your Cursor team by hand and remove them when they leave. With SCIM, the identity provider drives membership:

• New employees get Cursor access when they are added to the right group.
• Departing employees lose access when they are removed from your identity provider.
• Group membership changes propagate automatically.

SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. decides who is on your Cursor team. Which team IDs a laptop accepts and which extensions it installs are device policies, the next step in the order.

A provisioned user doesn't appear on the Members dashboard until they sign in for the first time. A short member list right after a successful sync doesn't mean the sync failed.

Cursor teams have three roles. Most people are Members, who use Cursor's paid features but can't open billing or the admin dashboard. Admins run the team. Unpaid Admins have the same admin controls without a paid seat or paid Cursor features, which suits IT or finance staff who don't need Cursor itself.

A role is quick to change. An admin picks Change role from the member's context menu, and billing adjusts from the date of the change. The other three steps reach outside Cursor, into your directory or onto every managed laptop.

In an Enterprise Organization, group mappings can set roles instead. Map an Organization Group to a team with a role, and sync enforces that role for the group's members. Roles on that team can then no longer be changed in the dashboard. You set the role on the mapping in Cursor, and role attributes in your identity provider don't sync.

Roles come last in the order, but someone needs admin rights before step one, because SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. and the security settings sit in the admin dashboard. The last step grants standing access to whoever owns these controls afterward. A team can't drop below one Admin and one paid member.

Mobile Device Management (MDM) policies set Cursor settings on each managed device, and a policy overrides the matching setting a user configured. Cursor's identity page covers MDM-based policies on macOS and Intune or Group Policy on Windows. Cursor's deployment patterns page adds Linux, through policy files on Cursor 2.0 and later.

The identity page describes three policies. Its MDM section also covers the .cursor folder, which is not a policy:

The override is the reason to push a policy. extensions.allowed and security.workspace.trust.enabled are ordinary settings a developer can change, so on their own they are advisory. An MDM policy sets the value from a level a user setting can't outrank, which is what a security reviewer is asking about when they ask whether the allowlist is enforced.

Workspace Trust is the only one of the three that takes a boolean, so it is on or off for the whole fleet. When it is on, Cursor asks once per workspace, the first time someone opens it, and remembers the answer. The security hardening page weighs whether to enforce it.

Cursor's deployment patterns page lists three more policies that the identity page leaves out. Our deployment patterns page explains them.

Cursor calls Allowed Team IDs the most important MDM policy. It stops people from signing in to personal Cursor accounts on corporate devices, because Cursor then accepts sign-ins only from the team IDs you list. The cursorAuth.allowedTeamId setting takes a comma-separated list, so "1,3,7" allows users from those three team IDs. To manage the list centrally, push the AllowedTeamId policy, a string with the same list, which overrides the local setting.

When someone signs in with a team ID that isn't on the list, Cursor acts at once:

• The user is forcefully logged out immediately.
• An error message is displayed.
• Further sign-in attempts are blocked until a valid team ID is used.

A typo in this list costs helpdesk time, because to the person at the laptop a missing team ID looks like a revoked account. Before the policy reaches the fleet, check the list against every team ID in scope, including any that a second Enterprise team or an acquisition brought with it.

The policy works on the device. For traffic from your network, Cursor documents a separate control: the tenancy restriction header limits which organizations and teams can be used on that traffic.

Extensions can access your workspace, so Cursor gates installs with the extensions.allowed setting. It takes a JSON object keyed by publisher name or full extension ID. Each value is a boolean that allows or blocks the entry, or a version or release channel to pin.

We would start from the wildcard plus your denials, and tighten to a named list once you know which extensions people use. A named list written on day one blocks whatever you forgot, and you find out from tickets.

Admins can also set the allowlist without MDM, from the team dashboard under Security & Identity. Cursor applies it to every team member's client. It needs Cursor client 2.1 or later, and clients on older versions get no extension restrictions at all. If the allowlist seems ignored on one machine, check that machine's client version first.

A dashboard value is easier to push than to take back. Clearing the field stops Cursor from pushing a new value, but clients keep enforcing the last one they received. To return everyone to allowing all extensions, push {"*": true} first, wait for clients to pick it up, and then clear the field.

Yes, if everyone who can read the repository may see what's in it. Cursor creates the .cursor folder at the root of the repository when you open a project, and it holds project settings, rules and context. Check it in and teammates share the same rules and settings, but anyone with access to the repository can see them. No device policy reaches the folder, so review is the safeguard.

For a repository whose access you don't control, review the folder before you commit it. In any repository, keep sensitive information out of rules files. Rules don't have to live in the folder. You can also manage rules and commands from the team dashboard, which suits a repository shared more widely than the team that wrote the rules. Our page on team rules explains how they apply.

For two of the four steps, yes. Cursor lists SCIMSystem for Cross-domain Identity Management. A standard for automatically creating and removing user accounts when people join or leave. Press Enter for the full definition. and MDM policies as advanced identity controls on Enterprise, and SCIM also needs SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition.. On a Teams plan, the order shrinks to SSO and then roles.

Teams still has SAMLSecurity Assertion Markup Language. The XML-era enterprise standard that powers single sign-on: your identity provider vouches for you to each app. Older than OIDC but still what many enterprise tools speak. Press Enter for the full definition. SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. and the domain controls that decide who may join. What it lacks is automated deprovisioning and anything enforced on the device. Cursor's docs don't name a plan for the dashboard extension allowlist, so check your own dashboard before you count on it.

For a team of about fifteen, where one person runs both the directory and the laptops, we wouldn't buy Enterprise for the identity controls alone. Manual offboarding stays a small job while one person can keep the whole list in their head. Revisit the choice when the person who removes accounts is no longer the person who hears that someone left.