Cursor Organizations, Teams and Groups

The table lists each level and the controls it holds. Read the most-permissive row twice, because it decides what a user in several teams or groups can do.

Cursor's release notes and announcements say what changed. They don't say how a team should act on it. The steps below are our suggested order, and the next section lists what to watch out for along the way.

1. 1Use the organization for company-level administration and identity.
2. 2Map teams to durable departments, subsidiaries or regions.
3. 3Use groups for temporary cohorts, policy exceptions and differences in model or spend.
4. 4Review effective permissions for users who sit in several teams or groups.

Each item below is either a fact about the release, such as its beta status or plan access, or our advice for using it safely. Plan around each one, and recheck the facts when Cursor ships an update.

• Don't make every cohort a team when a group would keep administration simpler.
• Write down each case where the most-permissive rule gives a user more access than expected.
• Tie spend, usage and model controls to business units before a broad rollout.

A rule or skill starts on your own machine. To share it, you move it up a level. Project rules work on any plan, Team RulesRules promoted to apply across a whole organisation and shared consistently between the Cursor IDE, Agent and Bugbot. Press Enter for the full definition. need a Teams or Enterprise plan, and Organizations is an Enterprise feature.

Cursor's rules docs list Team RulesRules promoted to apply across a whole organisation and shared consistently between the Cursor IDE, Agent and Bugbot. Press Enter for the full definition. on both the Teams and Enterprise plans: admins manage them from the dashboard and can enforce each one for every member. The speaker went further and described Organizations scoping rules per group, so design, PMs and security each get their own set, plus org-wide rules such as one against SQL injection. Cursor's Organizations announcement and Organization Groups docs don't mention rules, so treat per-group rules as unconfirmed.

Make it a team when it matches something durable in the org chart, and a group when it doesn't. A team carries its own security, governance, spend and feature settings, so each new team is another copy of the whole policy surface for someone to keep in line. A group carries a smaller set: a per-user monthly spend limit, model access, agent controls such as Auto-run, and Cursor Router settings.

Durability is only a proxy, though. The real test is whether these people need a security and governance posture of their own. Two regions running identical policy are one group with different spend limits, however permanent they look on a slide.

Pilots are the easiest cohort to get wrong. A pilot has a name and an owner, so someone suggests giving it a team. Two months later, an admin is unpicking a governance surface that existed to give eight people early access to one model. Cursor's docs list pilot users as a typical group, and they describe group model access as suited to controlled rollouts.

Keep the billing vocabulary separate, because the names are close. Billing Groups attribute spend for reporting and chargeback, and Organization Groups carry settings. Billing attribution records usage against the group that was active when the spend happened and doesn't move it when someone changes groups. So a mid-month reorg splits one person's usage across two lines. That is only a reporting quirk, and it still tends to start an argument about whose budget it was.

They mostly combine upward, toward the more permissive setting. For spend limits and model access, Cursor applies the most permissive result across a user's groups and their team. A higher group limit overrides a stricter team default, and a lower group limit doesn't make a permissive team setting any stricter. A few agent controls work the other way. Delete File Protection and Browser Protection turn on if either level turns them on, and a group's Auto-review instructions replace the team's for its members.

That is why the documented pattern is to restrict first and then widen: set the strict default at team level, then open it up per cohort at group level. Build it the other way and nothing looks broken. The group setting never takes effect, and you find out from a bill that doesn't match the policy you thought you wrote.

It also rules out using a group to lock down spend or models. If contractors need a tighter ceiling than staff, the ceiling has to come from the team they belong to. Putting them in a low-limit group achieves nothing.

Afterward, audit the accounts that sit in the most groups at once, such as a staff engineer lent to a second team, or a manager who moved in the last reorg and kept the old group. A cohort widened for one project keeps its wider model access until an admin narrows it.

Sync it when the cohort already exists somewhere else, and manage it by hand when it only exists in Cursor. A 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.-synced group mirrors a directory group: your identity provider decides who belongs, and Cursor decides what the group can do. That fits a department, a role or an access cohort your identity provider already models, and those are the groups whose hand-kept membership goes stale fastest.

The docs state the trade-off plainly. Membership in a 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.-synced group is read-only in Cursor, because the next sync would overwrite any change you made there. On a durable cohort, that is what you want. On a pilot where you want to add two people on a Tuesday afternoon, it gets in the way, because the change has to go through whoever owns the directory.

Settings stay yours either way. Admins still control the Cursor-owned parts of a synced group, spend limits and model access included, so handing membership to the IdP doesn't hand over policy with it.

At thirty seats and one admin, manual groups and the CSV import are enough. Leave 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. alone until someone starts maintaining membership from memory. Past a few thousand seats the answer flips, because the cohorts are already modeled in the directory and a second copy kept by hand drifts. For scripts, the Organization API can list groups, read members, and add or remove members of manual groups. Group ids there carry a g_ prefix, and the whole feature is on Enterprise.