Summary and recommendation
Cursor user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Cursor's team administration lives at cursor.com/settings, where admins manage invites, seats, and usage from a single dashboard. The permission model is deliberately flat: every user is either an Admin or a Member, with no sub-roles, billing-only access, or read-only admin tier documented.
SCIM provisioning and SSO are gated behind the Enterprise plan, which carries custom pricing - the Teams plan ($40/user/month) has no automated provisioning path. This matters because every app in a developer stack that requires coordinated access control will expose the limits of manual-only seat management.
Quick facts
| Admin console path | cursor.com/settings (team/org settings tab after logging in as admin) |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Member | Full access to Cursor IDE features, AI completions, and agent requests allocated to the team pool. Can use shared team rules and context. | Cannot invite or remove other members, cannot view billing, cannot configure SSO/SCIM, cannot manage team settings. | Teams or Enterprise | $40/user/month (Teams); custom (Enterprise) | Each member consumes one paid seat. Hobby/Pro individual accounts cannot be added to a team without upgrading the team plan. |
| Admin | Can invite members, remove members, manage billing, configure SSO and SCIM (Enterprise), view usage dashboards, and distribute credits/usage pools. | Cannot assign granular per-user permission sets beyond the single admin/member distinction. No sub-admin or read-only admin role documented. | Teams or Enterprise | Consumes a paid seat at the same rate as Member ($40/user/month on Teams; custom on Enterprise). | There is no documented 'billing-only' or 'read-only admin' role. The admin role is all-or-nothing for team management actions. |
Permission model
- Model type: role-based
- Description: Cursor uses a two-role model: Admin and Member. Admins have full team-management and billing access; Members have access only to IDE and AI features. No custom roles or granular permission sets are documented.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Coarse - two fixed roles only (Admin, Member). No per-feature or per-project permission controls documented.
How to add users
- Log in at cursor.com and navigate to Settings.
- Select your team/organization from the left sidebar.
- Click 'Members' or 'Invite Members'.
- Enter the invitee's email address and select their role (Admin or Member).
- Click 'Send Invite'. The invitee receives an email to accept and join the team.
- Once accepted, the seat is consumed and the user appears in the Members list.
Required fields: Email address of invitee, Role selection (Admin or Member)
Watch out for:
- Invites are email-based; the invitee must have or create a Cursor account with that email.
- Each accepted invite immediately consumes a billable seat.
- On Teams plan, volume discounts (3% at 50 seats, 12% at 100+ seats) apply automatically at billing cycle; they are not reflected in real-time seat cost display.
- SSO enforcement (Enterprise) means users must authenticate via the configured IdP before they can access the team; invites sent before SSO is configured may need to be re-accepted.
- There is no documented bulk CSV invite flow for the Teams plan; bulk provisioning requires SCIM on Enterprise.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | Unknown | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Cursor's admin console allows admins to remove (revoke) a member from the team, which ends their access to team resources and frees the seat. Whether this constitutes a full account deletion versus a deactivation/removal from the org is not explicitly documented in public docs. SCIM deprovisioning on Enterprise deprovisions the user from the team; the underlying Cursor account may persist.
- Log in at cursor.com and navigate to Settings.
- Select your team/organization.
- Go to the 'Members' tab.
- Locate the user to remove.
- Click the options menu (⋯) next to their name and select 'Remove from team' or equivalent.
- Confirm the removal. The user loses team access immediately and the seat is freed at the next billing cycle or immediately depending on billing terms.
| Data impact | Behavior |
|---|---|
| Owned records | No documented shared project or file ownership model in Cursor - the IDE is local-first. Team-level shared rules (.cursorrules) and context remain with the team after a member is removed. |
| Shared content | Shared team rules, prompts, and context configurations remain accessible to remaining team members. The removed user's local IDE data (codebase, history) stays on their machine. |
| Integrations | Any personal API keys or integrations configured by the removed user in their local Cursor instance are not affected for the team. SCIM deprovisioning (Enterprise) revokes IdP-linked access automatically. |
| License freed | Seat is freed upon removal; billing adjustment timing depends on whether the team is on monthly or annual billing. Annual plans may not prorate mid-cycle - verify with Cursor billing support. |
Watch out for:
- Seat cost refund/proration on removal is not explicitly documented; assume no mid-cycle proration on annual plans without confirming with Cursor support.
- SCIM deprovisioning (Enterprise only) is the only automated removal path; Teams plan requires manual removal per user.
- Removed users retain their individual Cursor account and any personal plan they may have had prior to joining the team.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Teams seat | 500 agent requests/month per seat (pooled at team level on Enterprise), AI completions, access to team settings and shared context. | $40/user/month; volume discounts: 3% at 50 users, 12% at 100+ users |
| Enterprise seat | Pooled usage, SSO, SCIM, audit logs, admin-controlled credit distribution, priority support, custom security controls. | Custom pricing (contact sales) |
- Where to check usage: cursor.com/settings → [Team name] → Usage (or Billing) tab. Shows per-member and aggregate usage of requests/completions.
- How to identify unused seats: Usage dashboard at cursor.com/settings shows per-member request consumption. Members with zero or near-zero usage over a billing period can be identified manually. No automated 'inactive seat' alert is documented.
- Billing notes: Teams plan billed per seat per month. Annual billing available at a discount ($16/month equivalent for Pro; Teams annual pricing not explicitly published - confirm with Cursor). Enterprise is custom. Usage-based overages apply on Pro/Pro+ plans; Teams plan uses pooled request allocation. Volume discounts (3% at 50 seats, 12% at 100+) apply on Teams.
The cost of manual management
On the Teams plan, onboarding and offboarding each Cursor seat must be handled individually through the admin console - there is no bulk CSV invite and no API-driven provisioning below Enterprise. Identifying unused seats requires manually scanning the usage dashboard at cursor.com/settings; no automated inactive-seat alert exists.
Seat proration on mid-cycle removals is not publicly documented, so billing surprises on annual plans are a real operational risk.
What IT admins are saying
The most consistent friction reported by admins centers on the hard wall between Teams and Enterprise.
SCIM, SSO, and audit logs are all Enterprise-only, with no self-serve upgrade path and no published pricing - meaning teams that outgrow the Teams plan must go through a sales conversation before gaining any automated lifecycle controls.
The two-role model (Admin/Member) is also a recurring pain point: there is no way to grant a team lead billing visibility or a limited admin scope without giving them full team-management access.
Common complaints:
- Fast-growing adoption (40k+ engineers at some companies) straining support responsiveness.
- Enterprise features (SCIM, SSO, audit logs) locked behind custom pricing with no self-serve upgrade path from Teams.
- No clear documented path or pricing transparency for moving from Teams to Enterprise.
- Only two roles (Admin/Member) with no granular permission controls, making it difficult to give limited admin access (e.g., billing-only or read-only admin).
- No bulk CSV invite on Teams plan; bulk provisioning requires Enterprise SCIM.
- Seat proration and billing behavior on mid-cycle removals is unclear and not documented publicly.
- No automated inactive-seat detection or alerting in the admin console.
- Domain-based auto-join (allowlisting) not confirmed as available on Teams plan.
The decision
Choose the Teams plan if your organization is comfortable with manual invite-and-remove workflows and your headcount is stable enough that seat churn is infrequent. Recognize that every app requiring tight access governance in your stack will surface the same gap - no bulk provisioning, no granular roles, no automated offboarding.
Move to Enterprise if you need SSO enforcement, automated provisioning via your IdP, audit logs, or pooled usage controls, and budget for a sales cycle and custom pricing negotiation.
Volume discounts (3% at 50 seats, 12% at 100+) apply automatically on Teams at billing cycle but are not reflected in real-time seat cost display, so reconcile against your billing statement rather than the dashboard.
Bottom line
Cursor's manual administration is straightforward for small, stable teams: invite by email, remove via the Members tab, and monitor usage from the settings dashboard. The model breaks down at scale - no bulk provisioning, no granular roles, and no automated offboarding below Enterprise.
Every app in your stack that requires tight access governance will expose this gap, and the only documented remediation is an Enterprise upgrade with custom pricing and a sales-gated onboarding process.
Automate Cursor workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
