Cursor Organizations, Teams and Groups

Cursor Organizations are the top-level enterprise container for identity, administration, membership, spend and usage. Teams sit under the organization and groups cut across or within teams for model access, spend limits and agent permissions.

Knowing what shipped is the easy part. Turning Cursor Organizations, Teams and Groups into something a team relies on takes a few deliberate steps, mapped below.

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

New capability comes with new ways to get it wrong. Keep these boundaries in place as you adopt it.

They start local and get promoted. A rule or skill begins on your own machine; to share it, you move it up a level. The levels map onto the plan tiers, so governance follows the same hierarchy as your seats.

Organizations lets admins scope configuration per group - the design team gets one set of rules, PMs another, security another - and you can already specify org-wide rules that apply to everyone. A concrete org-wide security example: when writing SQL, don't allow injections, enforced across every group in the org.

Make it a team when it matches something durable in the org chart, and a group when it does not. A team carries its own security, governance, spend and feature settings, so each team you create is another copy of the whole policy surface for somebody to keep in line. A group carries three things: per-user monthly spend limits, model access, and the group-level agent and model-routing controls where those are available.

So the working test is longevity.

Except longevity is only a proxy for the thing that matters, and the difference changes what you build. The test is whether these people need a security and governance posture of their own, which is why two regions running identical policy are one group with a spend difference rather than two teams, however permanent they look on a slide.

The cohort that gets this wrong is almost always the pilot. It has a name, it has an owner, someone suggests giving it a team of its own, and two months later an admin is unpicking a governance surface that existed to give eight people early access to one model. Cursor's own list of reasons to reach for a group includes precisely that case, a pilot cohort that gets a new model ahead of the wide rollout.

Worth holding the billing vocabulary separately, because the names sit very close together. Billing Groups attribute spend for reporting and chargeback; Organization Groups carry settings. Attribution records usage against whichever group was active when the spend happened rather than reassigning it when somebody moves, so a mid-month reorg splits one person's usage across two lines. That is a reporting quirk rather than a control problem. It still tends to surface as an argument about whose budget it was.

They combine in one direction only, upward. Cursor applies the most permissive applicable limit across a user's groups and their team, so a higher group limit overrides a stricter team default, while a lower group limit will not make an already permissive team setting stricter.

Which is why the documented pattern runs restrictive-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 simply fails to bind, and the discovery arrives with a bill that does not match the policy you thought you had written.

That rules out the move people reach for first, which is using a group as a lockdown. 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.

The account worth auditing afterwards is whoever sits in the most containers at once. Usually that is a staff engineer lent to a second team, or a manager who moved in the last reorg and kept the old group. Model access combines the same permissive way that spend limits do, so a cohort widened for one project holds that access until an admin narrows it. The reverse also bites. A model blocked at team level can still shape a user's experience even where their group allows it.

Sync it when the cohort already exists somewhere else. Manage it by hand when it only exists in Cursor. Cursor recommends 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. where the group mirrors a department, a role or an access cohort your identity provider already models, and those are exactly the groups whose hand-kept membership goes stale fastest.

The trade-off is documented without much comment. 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 inside Cursor, because the next sync would overwrite whatever you changed there. On a durable cohort that is the whole point. On a pilot where you want to add two people on a Tuesday afternoon it is friction, and the change now goes 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 does not hand over policy with it.

At thirty seats and one admin, manual groups plus the CSV import are genuinely enough. I would 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 somebody starts maintaining membership from memory. Past a few thousand seats it inverts, because the cohorts are already modelled in the directory and keeping a second copy by hand is how the two drift apart. Anything that needs to be scripted goes through the Organization API, which can list groups, read members and add or remove them; group ids there carry a g_ prefix, and the whole feature sits on Enterprise.