Cursor Organization Groups: Cross-Team Cohorts for Admins

Organization Groups gather people from the teams in one Cursor Organization into a cohort, and one person can belong to many groups. Cursor names Engineering, Contractors and Pilot Users as examples. A group does two jobs: it applies settings such as spend limits, model access and agent controls to the cohort, and it can drive a team's membership and roles.

An Enterprise org can run three group concepts at once. Billing groups attribute spend for reporting, team directory groups set spend and policy within one team, and Organization Groups work across teams. Membership shape is the difference that matters most. A member sits in exactly one billing group at a time, while a user can belong to several Organization Groups, and Cursor publishes rules for combining what those groups say.

Groups live at the Organization level, not in team settings, and only org admins create and manage them. Open Organization → Groups from your profile menu and select Add. Name the group, then set its Type to Synced or Manual.

You can connect a manual group to 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. later, with Connect next to SCIM directory group in the group's Settings. From then on, your identity provider decides who is in it. In a ten-person org where one person runs Okta, that switch is a short conversation. In a large one, a new or extended directory group can wait in a queue you don't control, so open that request before you promise anyone a date.

We'd keep a pilot group manual even when everything else syncs from the directory. A pilot cohort is defined by who wants in this week, not by a department or role your directory already tracks. Manage it in the dashboard or through the Organization API, and let the directory own the long-lived groups.

Open a group and select Members to view and manage membership. What you can change depends on the group type:

None of these controls provisions a person. A manual group draws from people already in the Organization, so it organizes existing accounts and doesn't onboard new ones. If someone you expect is missing from the picker, rule out the upstream cause first. Cursor's 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. docs say a provisioned account stays off the Members dashboard until that person signs in for the first time.

Deleting a group removes the group and its settings, but not member accounts, and members keep access that other groups, their teams or per-user settings grant. If the group feeds a team, deleting it also works like removing that mapping.

Open a group and select Settings. A group can carry a per-user monthly spend limit, model access on the Models tab, and agent controls such as Auto-run and Smart Auto where available. Group settings apply to everyone in the group, then combine with each user's team settings, and overlaps resolve toward the most permissive result.

These rules make the order of setup matter. For spend limits and model access, a group can only widen what the team allows, so strictness has to exist at the team level first. If you build it the other way, with generous team defaults and a Contractors group meant to limit what contractors can use, the group changes nothing. Fixing that later means tightening the team default, which lands on everyone in that team.

Agent controls merge one field at a time. Run modes and the terminal command allowlist are unioned. For sandboxing, the loosest setting wins, so sandboxing applies only when both the team and the group enable it. Delete File Protection and Browser Protection go the other way and turn on if either level enables them.

Cursor says groups carry Auto-run and Smart Auto settings "where available", so confirm both in your own dashboard before you plan a rollout on them.

Map a group to a team as a membership source, and Cursor keeps that team's roster in line with the group. A team can have several mapped groups, and its roster is their combined membership. With 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., the chain runs from your directory to the team: the identity provider updates the directory group, sync updates the Organization Group, and the mapping updates the team.

Once a team has a mapped group, sync manages its whole roster. People who join a mapped group join the team, and people who leave are removed unless another mapped group still includes them. Admins can't add or remove members of a synced team in the dashboard. If sync removes someone from their last team in the Organization, they leave the Organization too, unless they hold an org-level role such as org admin.

A mapping can also set a team role: member, admin or no role. When a mapping carries a role, sync enforces it, and admins can't change roles on that team in the dashboard. Someone in several mapped groups gets the highest role among them. Removing a mapping removes the members only that group supplied, and removing the last one removes no one and returns the team to manual management.

Turn off Auto Add Users to Root Team in the Organization's settings when mappings should control membership. It's on by default and adds every synced user to the root team.

You're likely in a team directory group or a billing group, not an Organization Group. Cursor's Cyber Safeguards FAQ gives the fix: open Organization → Groups from your profile menu and click into a specific group. The Cyber Safeguards Models Settings section appears on that group's settings page. It's where an Organization admin applies for Anthropic's Cyber Verification Program, and Cursor takes the application only at the Organization Group level. A single-team org that wants it still has to create a group.

If you're on the right page and a group setting still seems to be ignored, check membership first. Pull the list of groups the user belongs to, because another group can supply the value that wins, and a synced group holds exactly who the last sync said it holds. Then check the user's team settings and any per-user override, since both feed into the result.

For a synced group, look upstream of Cursor first. Push group provisioning has to be enabled in the identity provider separately from user sync, 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. 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, so missing SCIM controls point at SSO rather than at the group. On the API side, check that the key is an Organization key with the members:* scope and that the id carries the g_ prefix.

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. lets your identity provider decide who belongs to a group. Connect it to your Organization first: each identity provider connection has a SCIM Directory section in the Organization's settings, where Sync Directory registers it, and push group provisioning must be on.

Handing membership to the identity provider pays off when the cohort already exists there and somebody else maintains it. You inherit their onboarding and offboarding process. The cost shows up in small changes: adding one contractor for one afternoon means a change in the identity provider, because the member list in Cursor stays read-only.

The Organization API is the direct route when your system needs to act across the teams in one Cursor Organization. It uses an Organization API key with Basic authentication: the key is the username, and the password is empty. A Team API key works only on team endpoints under /teams/*, while organization membership, pooled usage, group and model-access routes need an Organization key.

Each Organization key carries exactly one scope, so choose it per integration:

Give a reporting job usage:*, not admin:*. A script that only lists members can use members:read, but one that reads or changes groups needs members:*. Narrow keys are less convenient than one all-powerful key, and they contain the damage when a script or secret leaks. When a call fails with a scope error, fix that key's scope instead of widening every credential.