Cursor for teams and enterprises

Rolling Cursor out to a team takes five decisions, in order: what data may leave the machine, which plan-dependent controls the vendor must confirm in writing, which agent configuration lives in the repository, what checks agent output before a human reviews it, and when unattended Cloud Agents are allowed. Each decision has a page below and leaves evidence.

This hub is for the tech lead taking Cursor from a pilot of two to a team of ten, and the CTO or security lead who signs off the rollout. The pilot worked because two enthusiasts tuned their own settings. Now eight more people join, security asks where the code goes, and nobody can say which rules the agent actually loads. If the pilot is not yet set up, start with Cursor quick start.

Which Cursor team page answers your question?

Your question	Page
Where does our code go, and how do we stop the agent reading secrets or running curl?	Privacy and security in Cursor
How do we share rules, MCP servers and skills so every clone runs the same agent?	Team collaboration in Cursor
What checks a pull request before a human reviews it?	Code review in Cursor and Bugbot
When may agents run unattended in the cloud?	Cloud Agents and Automations
How do we keep spend predictable?	Token management in Cursor and AI usage cost governance

Running Claude Code or Codex as well? Use one managed policy across every coding agent, and see the sibling hubs for Claude Code and Codex.

In what order should you roll Cursor out to a team?

Data that already left the machine cannot be recalled, so the organisation-level decisions come before the repository files.

1. Decide the data flow. Every agent request goes through Cursor’s backend with the files, command output and MCP results the agent reads. Privacy Mode is an account setting on Cursor’s side, not a file in the repository. Cursor’s runtime (@cursor/sdk 1.0.32, npm, checked 2026-09-26) tracks whether the setting is enforced by the team, so confirm enforcement in the admin dashboard and keep a dated screenshot. Cursor’s docs add that Privacy Mode is on by default for all team members and for Enterprise, and that admins can enforce it organisation-wide (checked 2026-10-12).

2. Get plan-dependent answers in writing. Cursor lists two business plans: Teams (Standard $40 and Premium $120 per user a month, or $32 and $96 on annual billing) and Enterprise (custom pricing), and the AI Code Tracking API is Enterprise only (Cursor help, Cursor’s Teams docs and a June 2026 Cursor blog post, checked 2026-10-12). Which plan includes SSO and SCIM provisioning, and what the audit logs cover, depend on the plan and the contract, and this page states neither because they are not verified. Use the questions to put to Cursor before you sign and procurement for AI coding tools.

3. Commit the shared configuration. Project rules in .cursor/rules/, MCP servers in .cursor/mcp.json with tokens kept in each developer’s environment, a .cursorignore, hooks in .cursor/hooks.json, and skills, all protected by CODEOWNERS. Put the short list of cross-repository policy in team rules; the SDK lists team and mdm as settings sources beside project and user.

4. Add a pre-review gate. CI runs types, lint and tests, and Bugbot reviews each pull request before a person does. Human review then goes to intent and design, as described in the review queue when agents open the pull requests.

5. Open Cloud Agents and Automations last. They run in isolated cloud VMs with your repository and act without a person watching. Start with one repository once steps 1–4 hold, and require that their changes pass the same gate as human work.

Copy-paste prompt: audit the shared Cursor config before the rollout

Audit this repository's shared Cursor configuration for a team rollout. Do not edit
any files. Read .cursor/rules/, .cursor/mcp.json, .cursor/hooks.json, .cursorignore,
.cursor/skills/ and CODEOWNERS. Report:
1. Secret-bearing paths in the repository (.env*, *.pem, *.key, *.tfvars, dumps)
   that .cursorignore does not cover.
2. Every MCP server: what it can reach, whether its package version is pinned, and
   any token written into the file instead of read from an environment variable.
3. Rules or skills that only work on one machine: absolute paths, personal tools.
4. Rules that try to act as a security control ("never run curl"); name the hook
   or .cursorignore entry that should enforce it instead.
5. Which of these files CODEOWNERS does not protect.
End with a table: finding, risk (high, medium, low), one-line fix.

Copy-paste prompt: day-one smoke test for a new teammate

Run a setup check for this repository without changing any files.
1. List every rule from .cursor/rules/ that is active in this conversation.
2. Try to read .env.canary and report whether the read was refused; never print
   file contents.
3. List the MCP servers you can call, and call one read-only tool on each.
4. Run the project's test command and report pass or fail with the count.
Answer as a four-row table: check, expected, actual, pass or fail. Expected:
the rules match the directory listing, the .env.canary read is refused, every
server responds, and the tests pass.

Before running it, create .env.canary in the repository root containing CANARY=not-a-secret. The .env.* entry in .cursorignore and the hook’s .env pattern cover it, so the test never touches a real secret. The smoke test is checkable without reading code: each row passes or fails. A teammate whose canary read succeeds is not covered by the controls and should not start work yet.

How do you prove the Cursor rollout holds without watching every session?

Each step leaves evidence that someone owns.

Evidence	What it proves	Owner
Dated admin-dashboard screenshot of enforced Privacy Mode	The data-flow decision applies to every seat	CTO or security lead
Written vendor answers on SSO, SCIM, audit logs and retention	Plan-dependent controls exist on your contract	CTO
The smoke test above passes on a freshly imaged laptop	Shared rules, .cursorignore and MCP config work beyond the pilot	Tech lead
A CI job that feeds sample events to the hooks guard and expects deny	The guard still blocks after every refactor (how to prove the controls still work)	Security lead
CI and Bugbot results on every agent pull request	Output is checked before a human spends time on it	Tech lead

What breaks when Cursor goes from one developer to a team?

Symptom	Cause	Recovery
Pull requests look like eight different codebases	Conventions live in personal settings, not in .cursor/rules/	Move them into project rules and rerun the smoke test on each machine
A developer’s session ignores the organisation’s Privacy Mode	Signed in with a personal account	Require sign-in with company accounts and ask Cursor how your plan blocks personal accounts on managed devices
The agent read a secret despite a rule forbidding it	A rule shapes output; it does not block a read	Add the path to .cursorignore, add a hook deny, rotate the credential
A leaver keeps access for weeks	Deprovisioning is manual	Ask Cursor which plan includes SCIM, then remove access in the identity provider

Where to go next with Cursor for teams

Lock it down

Privacy and security in Cursor

Share the config

Team collaboration in Cursor

Lead the team

Leading a team that ships with agents and the adoption roadmap

Set org policy

Governance and autonomy