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

Identity and access management controls who can use Cursor in your organization and what they can do, from who can sign in (SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition.) down to which extensions a device may install. Cursor recommends implementing the controls in a specific order so each one builds on the last.

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 user lifecycle management.
3. 3Deploy MDM policies to enforce allowed team IDs and extensions.
4. 4Assign roles to grant admin access to the right people.

Only the first two steps are a hard dependency. 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. needs 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 to function at all, and Cursor keeps the SCIM setup link hidden until 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. is verified, so provisioning cannot come first. The last two are ordered by what a wrong value costs.

MDM is where that bites. Nothing technical stops you pushing AllowedTeamId to the fleet on day one. The policy checks the team ID on the account signing in, though, not the person holding the laptop, so anybody who has not landed in your Cursor team yet is logged out on sight and blocked from retrying. Run it 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 where they belong.

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 users authenticate to Cursor with your existing identity provider 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, so you sign in through whatever identity provider you already run. When you enable SSO you can require it for all team members, which prevents password-based authentication entirely.

The provider question mostly answers itself. Cursor names Okta, Azure AD, Google Workspace and OneLogin, and the doc frames those as examples rather than a closed list. The Cursor half of the work is small either way.

Two teams is where that recommendation starts to matter, not ten. 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. leaves every team carrying 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, and they drift on separate schedules. Cursor keeps the exception open for a team whose identity requirements genuinely differ, an acquisition still on its own directory being the obvious one.

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 automatically manages team members and directory groups through your identity provider. It is available on Enterprise plans with 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 and remove users in Cursor by hand; with it, the identity provider drives membership.

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

What 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. does not reach is the device layer.

Membership arriving from your directory decides who exists in Cursor, not which team IDs a given laptop will accept or which extensions it will install. Both of those are device policies, which is the step after this one.

A provisioned account does not appear on the Members dashboard until that person signs in for the first time. Which means a member list that looks empty right after a successful push is not evidence the push failed.

Cursor teams have three roles. Most people are Members, who use Cursor day to day. Admins run the team, and Unpaid Admins do the same without taking up a paid seat, which is useful for an IT or security owner who never writes code in the editor.

Role assignment sits last because it is the cheapest of the four to change. An admin edits a role from the member context menu and billing adjusts from the change date, where the other three steps reach outside Cursor into a directory or a fleet of laptops.

Step four is not really about your own account. Somebody has to hold admin rights before step one, since 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 behind the admin dashboard. What you are granting at the end is standing access for whoever owns these controls afterwards, inside the constraint that a team needs at least one Admin and one paid member at all times.

Mobile Device Management (MDM) systems enforce policies on user devices. Cursor supports MDM-based policies on macOS and Intune / Group Policy on Windows. An MDM policy overrides the equivalent user-configured Cursor setting on each device.

Three of the four are true MDM policies: which team IDs can log in (AllowedTeamId), which extensions install (AllowedExtensions), and whether the Workspace Trust prompt is forced on or off (WorkspaceTrustEnabled). Each overrides the matching Cursor setting on the device. The fourth row below, the project-level .cursor folder, is not a policy at all.

The overrides in that list are the point of pushing a policy at all. extensions.allowed and security.workspace.trust.enabled are ordinary Cursor settings a developer can edit, so expressed that way a control is advisory. The MDM policy states the same control from a place a user setting cannot outrank, and that 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 the choice is on or off for the whole fleet. Trust decisions are saved per workspace once made, and the prompt lands once per workspace rather than on every open. The case for and against pushing it at all is argued on the security hardening page.

The .cursor folder is the exception in that list. No device policy touches it. Cursor writes it at the root of a project, and the settings, indexing cache, rules and context inside it are readable by anyone who can read the repository. Review it before the first commit on a repo whose access list you do not own, and keep sensitive information out of rules files.

Rules do not have to live in that folder at all. Rules and commands can be managed from the team dashboard instead, which is worth doing on a repository shared wider than the team that wrote them (team rules covers how those apply).

The most important MDM policy prevents users from logging into personal Cursor accounts on corporate devices. When you set an allowed team ID policy, Cursor only permits authentication to those specific team IDs. The cursorAuth.allowedTeamId setting accepts a comma-separated list, so "1,3,7" allows users from those three team IDs. To manage it centrally, configure the AllowedTeamId policy through your MDM, which overrides the local setting.

Sign in with a team ID that isn't on the list and Cursor acts at once:

• The user is forcefully logged out immediately.
• An error message is displayed.
• Further authentication attempts are prevented until a valid team ID is used.

The lockout is immediate and complete, which makes this the one policy where a typo carries a helpdesk cost. A team ID missing from that comma-separated list looks, to the person holding the laptop, like a revoked account rather than a config mistake. Check the list against every team ID in scope before it reaches the fleet, including any that a second Enterprise team or an acquisition brought with it.

Extensions can read your workspace, so Cursor gates them with a single setting. extensions.allowed takes a JSON object keyed by publisher name or full extension ID, with a boolean saying whether it is permitted, or a version or release channel to pin instead. The model it uses is an allowlist, and that changes what a single entry does.

The instinct with an allowlist is to enumerate what you trust, and I would not start there. Deploy the wildcard with your denials underneath it, watch what the fleet actually installs for a couple of weeks, then tighten to a named list once you know what is on it. Start from enumeration and the first thing you learn is which formatter somebody needed, from a ticket.

An over-tight first attempt also costs more than it looks, since a policy is easier to push than to take back. Clients keep enforcing the last value they received, so clearing the field later leaves them where they are, and the way back to allowing everything runs through {"*": true} first.

There is a middle path between a local setting and an MDM policy. Team admins can set the allowlist from the team dashboard under Security and Identity, and it reaches every member's client automatically. It carries a version floor: admin-portal configuration needs Cursor client 2.1 or later, and anyone on an older build gets no restrictions applied. When a policy looks like it is being ignored on one machine, the client version is the thing to rule out first.

The two-week watch needs one correction on the back of that. What you are seeing is what the clients enforcing the policy installed, and on the admin-portal route a machine below Cursor 2.1 has no restrictions applied at all, so it is telling you about its own build rather than about your allowlist. Pull the client versions before you read anything into the install list.

Two of the four steps are Enterprise features. 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 the advanced identity controls that come with Enterprise, and SCIM 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 on top of that. On a self-serve Teams plan the sequence collapses to SSO and then roles. That costs less than it reads. 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. SSO and the domain controls that decide who may join, plus the extension allowlist in the team dashboard. What you give up is automated deprovisioning and anything enforced on the device.

Fifteen people, one person running both the directory and the laptops, and I would not buy Enterprise for the identity controls on their own. Manual offboarding stays a small job while one person can hold the whole list in their head. Revisit it once the person who removes accounts is no longer the person who hears that somebody left.