Cursor Enterprise admin: teams, groups and which setting wins

Last checked: 21 Oct 2026. Every fact below comes from Cursor's own documentation, help centre, changelog, launch blog and data-use page, read on that date and linked where it is used.

Cursor Enterprise does not resolve settings with one rule. Spend limits take the highest applicable value, model access is a union of the team and every group a person sits in, and Auto-run settings merge field by field with the loosest value winning, while hook decisions run the other way, so a deny from any source holds. Because a group can only widen what a team allows, the workable pattern, and the one Cursor's docs recommend, is a strict default on each team with small, named groups for the exceptions.

This post describes the admin model in Cursor's Enterprise docs as they stand today. Where a point is our reading of those docs, we say so.

How a Cursor Enterprise instance is organised

The Organizations page describes an Organization as the "top-level container for Enterprise customers", holding shared identity, administration and organisation-wide settings above your teams. Organizations became generally available to all Enterprise customers on 3 Jun 2026.

Teams do most of the work. Cursor says each team "defines its own membership, roles, usage views, privacy settings, and usage controls", and suggests building teams around departments, business units, regions or roles. Every Organization has a default team used for login and routing. Two details change how you plan:

• People can sit in more than one team. On the Teams plan an account belongs to one team at a time. In an Enterprise Organization a person can be in several teams, with a different role in each.
• Roles exist at two layers. Team admin access does not grant org admin access. Team roles are Member, Admin and Unpaid Admin, the last of which lets IT or finance staff manage a team without using a paid seat.

Org-level settings are reached through the Organization entry in the dashboard profile menu, and only org admins can create and manage groups. Remote Control for local agents is a recent example of an organisation-level setting: Cursor's 6 Oct 2026 changelog says it is off by default for Enterprise organisations, where an admin turns it on in the organisation settings.

You may not need an Organization at all. Cursor's admin setup guide treats Organizations, teams and groups as optional, to be configured only if you need more than a single team.

Three kinds of group, and why the name matters

"Group" means three different things in Cursor's docs, and the Organization Groups page warns that they are separate.

Our summary of Cursor's Organization Groups, SCIM and Billing Groups pages, read 21 Oct 2026.

Organization Groups are the ones most admins mean. Cursor's examples are Engineering, Contractors and Pilot Users, and it says spend limits, model access and agent controls "follow group members across teams". The docs describe no settings on Billing Groups: they exist so finance can see who spent what.

Which setting wins

Cursor's headline rule, on the groups page, is that a user's effective settings come from their team plus every group they belong to, and the most permissive result applies. The launch changelog applies the same rule to people in more than one team. Several settings run the other way, and Cursor spreads them across different pages. This table puts them side by side.

This table is our summary. Cursor's wording is linked in the sections below, and the docs win where they differ.

Spend limits: the highest applicable limit applies

The groups page says "the highest applicable limit wins" across groups and team limits, and that a group limit lower than a more permissive team setting "doesn't tighten the user's access". The spend limits help page adds that member and group overrides on Enterprise are admin-only, and that changing the team default does not move anyone who already has an override until you clear it.

One case is not settled. The Organizations page says a per-user override wins over team defaults and directory group settings, while the help page applies the highest limit across all sources, overrides included. If you set a per-user override below a group's limit, test it on a sample user before relying on it. Billing mechanics are covered in our post on Cursor spend controls and model choice.

Model access: a union that groups can only widen

The model and integration management page says groups "cannot take away a model that the team (or another of the user's groups) already allows", and advises putting the strictest defaults on the team and using groups to grant extra models to selected cohorts. Our reading is that "contractors may not use model X" cannot be built as a group. It has to be the team baseline, or the contractors need a stricter team of their own.

The same page notes that personal API key controls stay on the team's Models page, that new models are not switched on for Enterprise teams automatically, and that blocking certain models has knock-on effects: Auto-review can stop working if its small model is blocked, and Bugbot stops if every model it can use is blocked.

Auto-run and sandbox settings: merged field by field

The groups page says "Cursor merges each field independently", and the direction differs by field:

• Run modes and the terminal command allowlist are unions.
• Delete File Protection and Browser Protection are on if either level turns them on.
• Sandboxing applies only when both levels enable it, so a group with sandboxing disabled switches it off for its members.
• Sandbox networking and Git access are blocked only when both levels block them, and read access takes the looser setting.
• Auto-review instructions are the exception: a group's replace the team's for that user.

Our reading is that one group with sandboxing off loosens sandboxing for everyone in it, whatever the team enforces, so keep such groups small, named and reviewed. The run modes page confirms that team settings take precedence over individual and project configuration, and that read access controls need Cursor 3.23 or later. A policy only protects clients new enough to apply it, and Cursor's security advisories show sandbox and allowlist fixes arriving in named versions, so in our view a minimum client version belongs on the admin checklist.

Hooks, the MCP allowlist and Team Rules work differently

Hooks resolve towards the strictest answer. Cursor's hooks documentation says every matching hook from every source runs, and "any deny wins over ask, and ask wins over allow, regardless of source". Team hooks are distributed from the dashboard on Enterprise and sync to members every thirty minutes. A hook that crashes or times out fails open by default, so set failClosed on any hook that protects something important. Cursor's safety documentation says most teams use hooks to block dangerous operations, and that the terminal allowlist is best-effort and not a security boundary. Hooks are therefore the place for a rule that must hold whatever the group settings say.

The MCP allowlist is an Enterprise team setting. The model and integration page ranks the team dashboard above the user's permissions.json and the editor allowlist, and says higher-priority sources replace lower ones without merging. Adding a server to the allowlist does not install it on anyone's machine. We found no statement that Organization Groups carry an allowlist.

Team Rules, on Teams and Enterprise, let admins decide per rule whether it is enforced. The rules page says members can switch off a rule that is not enforced, and that "AI guidance should not be your only security control." A rule guides the agent, while hooks and dashboard settings enforce. Our post on Cursor rules, skills, subagents and hooks covers how to write each.

What SSO and SCIM control, and what they leave to Cursor

SSO is SAML 2.0 on Teams and Enterprise. Once domain verification and the provider connection are active, users on that domain must sign in with SSO. Nested groups often fail with providers such as Microsoft Entra ID, so assign people directly. Cursor's identity and access page recommends setting up SSO, then SCIM, then device management policies, then roles.

SCIM 2.0 is Enterprise only and needs an active SSO connection. In Cursor's words: "Your identity provider decides who belongs. Cursor decides what the group can do." Spend limits, model access, agent controls and team mappings never sync from the directory, and roles come from the mapping in Cursor. Our reading is that group membership becomes an access control, so joiners, movers and leavers in the directory change what Cursor lets people do. Three behaviours catch admins out:

• Auto Add Users to Root Team defaults on. Every synced user lands in the root team. Turn it off if group-to-team mappings are meant to control membership.
• Mapped teams lock. Once a team has a mapped group, sync manages its whole roster and manual edits are disabled.
• Leaving the last team means leaving the Organization, unless the person holds an org-level role directly.

Where Privacy Mode sits

Privacy Mode is a team setting. Cursor's privacy and data governance page says it is "on by default for Enterprise teams" and that admins can enforce it so members cannot switch it off. We found no page that places it among Organization Group settings, so in an Organization with several teams, check it is on and enforced on every team, including teams created later. On managed devices, the Allowed Team IDs policy stops staff signing in to a personal Cursor account that may not have Privacy Mode on.

Cursor's data-use page (last updated 3 Sep 2026) says customer data is not used for training and that Cursor holds zero data retention agreements with its providers, though data that triggers abuse classifiers may be stored for investigation. The governance page adds that a few models require retention at the provider and need admin approval, and that zero retention does not apply to people's own API keys. Cloud agents are the one feature that requires Cursor to store code, which our post on Cursor cloud agent security covers.

Data residency is also enrolled per team. The governance page says customers can enrol in US-only data residency today and that EU and UK inference-only coverage is available on request. Ask the account team what is on offer and whether it covers the features you use. For mapping regulatory obligations onto these controls, see Cursor in regulated businesses.

A practical pattern: a strict team default, with groups for exceptions

Cursor's docs repeat the same advice: strictest defaults on the team, groups to grant more. Its launch post describes separate teams by department, with engineering and product the most permissive and functions such as sales, marketing and finance tighter. This is how we would turn that into a configuration:

1. Decide whether you need more than one team. If everyone writing code can share one baseline, start with one team and directory groups.
2. Set each team's baseline as the strictest thing those people should have: approved models, spend limit, Auto-run with sandboxing on, the MCP allowlist and Privacy Mode enforced.
3. Create a few named groups for exceptions, such as a pilot group for new models, each with an owner and a reason.
4. Put rules that must hold in hooks, set to fail closed, because a hook's deny survives whatever the groups allow.
5. Turn off Auto Add Users to Root Team if mappings drive membership, and agree with the identity team who approves changes to groups that carry settings.
6. Review on a schedule. Audit logs (Enterprise only) record administrative events, including settings, roles, Privacy Mode, team hooks, MCP configuration and Organization Groups being created, deleted or having their spending limit changed. They never record prompts or generated code. Check the log shows the group change you care about before relying on it.

The same questions apply to any AI coding tool, and our post on AI coding governance that actually runs covers the vendor-neutral version. We use Cursor in our own engineering, and this is how we would approach a client's instance.

What Cursor's docs do not settle yet

Three questions have no clear public answer as at 21 Oct 2026, so test rather than assume:

• Whether a per-user spend override lower than a group's limit holds.
• How the editor decides which team's settings apply to someone in two teams. Treat multi-team users as you treat multi-group users.
• Whether hooks or the MCP allowlist can be scoped to a group. The docs describe both at team level, and Cursor says it is still adding policy controls to Organizations.

For how Cursor, Grok and Grok Bot fit together, start with our guide to SpaceX Super Intelligence (SpaceXSI) for UK business.

Common questions

If someone is in two Cursor groups, which spend limit applies?

The highest applicable limit applies, across their groups and the team. A group limit lower than a more permissive team setting does not tighten anything. Cursor's pages do not settle what happens when a per-user override is lower than a group limit, so test a sample user before relying on it.

Can a Cursor group stop someone using a model their team allows?

No. Model access is a union of the team setting and every group the person belongs to, so groups can only add models. Put the restriction on the team, and put the people who need more models in a group.

Is Privacy Mode on by default in Cursor Enterprise, and can users switch it off?

It is on by default for Enterprise teams. It is set at team level, and an admin can enforce it so members cannot turn it off. Cursor does not train on your data, with exceptions it lists: a few models need admin-approved retention at the provider, your own API keys follow the provider's policy, and abuse detection can cause data to be stored.

Do SCIM groups carry settings from our identity provider?

Only membership syncs. Spend limits, model access, agent controls and team mappings are set in Cursor and never sync from the directory, and team roles come from the group-to-team mapping in Cursor.

Do we need a Cursor organisation, or is one team enough?

Cursor's admin setup guide treats Organizations, teams and groups as optional unless you need more than a single team. Organizations are Enterprise only. A single team with directory groups is a documented starting point.

If you want a second pair of eyes on your Cursor set-up, or help designing the team and group structure before rollout, start with our diagnostics, or see our SpaceXSI implementation services and Request a Quote.

John Kelleher holds the SpaceX Super Intelligence Partner Network Accreditation: Forward Deployed Engineer, and the SpaceX Super Intelligence Technical Architect Accreditation.