Cursor launches Organizations feature to simplify enterprise team management
Introducing Cursor Organizations: the new enterprise management feature for centralized multi-team control. Enterprise demand for AI governance is outpacing what most dev-oriented platforms can provide—IT leaders want to enforce budgets, control access, and safely manage innovation at scale, not just spin up another user account. Cursor's new Organizations feature meets that demand directly: a real enterprise management framework with a centralized admin dashboard, granular spending governance, multi-team, and group management. This is the lever that turns ad hoc AI adoption into company-wide, auditable, sustainable practice.
What is Cursor Organizations and why does it matter for enterprises?
Cursor Organizations is an enterprise-level management framework that gives large companies centralized control across multiple teams, subsidiaries, and business units. This isn't just another team permission dropdown—it's an administrative layer built for how real organizations grow: overlapping teams, segmented business lines, company-wide standards, and real budgets.
Announced on June 8th, 2026 (Pulse 2.0), Organizations is now generally available to all Cursor enterprise customers. The primary motivation is simple: most enterprise AI adoption fails at the admin layer. Sprawling teams accumulate shadow AI spend, model access grows organically, and risk multiplies with every siloed user. Cursor Organizations gives IT a single top-level control: budgets, security policies, feature access, analytics—all in one place. For any enterprise with more than one department, that's the difference between unsanctioned sprawl and governed growth.
How does Cursor Organizations structure work for large enterprises?
Cursor Organizations introduces a clear, auditable hierarchy:
- Organization: The top-level entity tying together company identity, membership, and global configuration. This is the CEO view: company-wide policy, analytics, and spend control.
- Teams: Operate underneath Organizations. Each Team can have its own security policies, budgets, model access, and feature controls. Think: a product team, a business unit, a region.
- Groups: Lightweight collections of users who may belong to multiple teams or span organizational silos. Groups are for fine-tuned access: a cross-functional squad, a tiger team, or anyone needing custom permissions without creating a new Team.
The relationships are flexible. Users can belong to multiple Teams—and Groups can layer on top, regardless of Team boundaries. This decouples organization from org chart politics:
Organization (Acme Corp)
├── Team: Engineering (sandbox access, top models, frontier agents)
│ ├── Group: AutoML Tiger Team (custom permissions)
├── Team: Finance (restricted models, low spend ceilings)
│ ├── Group: Cost Reviewers (read-only analytics)Key: policies, usage limits, and model access can be set at each level—and inherited or overridden as needed. Want a finance team to have inevitable spreadsheet AI, but never touch experimental frontier models? That’s a single toggle, not a social negotiation.

The central dashboard surfaces the entire structure: who is in what, which policies apply, and where spend is happening.
11 production screens. Auth, DB, Stripe — all wired.
The SaaS Dashboard Kit ships everything already connected. No Vercel config, no Supabase account. Live demo at saas.otf-kit.dev.
What management controls are available with Cursor Organizations?
This is where the value multiplies. What admins actually want is less “user provisioning” and more real enterprise controls. Cursor Organizations delivers, and most features are available as concrete toggles or settings:
- Spending limits at every level: Each Team and Group can be assigned separate budgets. Engineering can burn 100k tokens for GPT-4, while Finance gets a $100/month ceiling. No more surprise overruns—limits are enforced, not just advisory.
- Model and agent access control: Control which LLMs, AI agent functions, or third-party APIs are available to each Team or Group. Advanced models can be restricted to technical users; department-level agents can be boxed in.
- Sandbox and production environments: Spin up isolated test environments (using Groups or Teams) for new features, policies, or access patterns—before enabling globally.
- Centralized monitoring and analytics: Dashboards expose spend, token consumption, model usage, and agent activity by Team, Group, and individual user. Service accounts and cloud agents are tracked, too.
- Internal chargeback and cost allocation: Large organizations can allocate spend to the correct business unit, team, or project—instead of a single corporate bill.
Administration is real-time, not batch. Every policy edit propagates immediately. Need a “no frontier models Fridays” rule enforced company-wide? That’s a few clicks, not a quarter-long IT project. And “centralized admin dashboard” isn’t just a landing-page phrase: admins set, monitor, and remediate in one place.
How can enterprises use Cursor Organizations for testing and governance?
Feature risk is real in AI platforms. One permission slip, and a beta LLM is suddenly burning budget in production. Cursor’s Organizations structure addresses this directly with smooth sandbox and phased rollout support:
- Testing environments: Create a Sandbox Team or Group, add only the select users or agents, grant access to the new feature, model, or policy. Observe, iterate, and tune before hitting company-wide enable.
- Phased feature enablement: Use Groups to allow specific users (power users, champion teams, risk managers) early access. Enforce spending and model boundaries within the sandbox.
- Real governance enforcement: Set policies at the Organization level—like required approval for certain model use, or restrictions on agent autonomy. Test these in a sandbox, validate the impact, and then go live.
This pattern isn’t theoretical—according to Cursor, enterprise customers are implementing this now, using the new structure to “create sandbox environments where selected users can test new features before broader deployment.”
The result: risk surfaces shrink. Early users validate both technical fit and compliance readiness. Sandboxes aren’t just QA—they’re guardrails in production.
How do I set up Cursor Organizations for my enterprise teams?
These are concrete steps. No guesswork—every step maps to a Cursor platform UI or documented API.
1. Create an Organization
This is the top-level administrative action. If you’re an enterprise admin, start here—your “Organization” in Cursor represents your company domain.
# In the Cursor admin dashboard:
Click "Create Organization" ➜ Enter company name, domain, and initial admin members.2. Add Teams
Create Teams for each business unit, department, region, or use case.
# UI steps:
Organization Settings ➜ Teams ➜ "Add Team" ➜ Name, assign users, set initial policies.3. Define Groups (for flexible access)
Groups sit across Teams; use them for temporary projects or special access levels.
# Example: A "Frontier Models Beta Testers" group:
Organization Settings ➜ Groups ➜ "Create Group" ➜ Add users (can belong to multiple Teams)
Set spending limits, model access, agent permissions for this group.4. Set budgets and configure policies
For real spend control, assign explicit budgets and policy constraints per Team and Group.
# UI: Team/Group Settings ➜ Budget ➜ Set monthly/annual ceiling
# Security: Enable or restrict model, agent, or API access
# Compliance: Require approval or multi-factor if needed5. Monitor and iterate
The dashboard shows live analytics of spend, model usage, and per-user activity.
# To view analytics:
Admin Dashboard ➜ Analytics ➜ Filter by Team, Group, User, Service Account
Export usage reports for internal billing6. Use sandboxes for safe rollout
Spin up a Team or Group as a sandbox, add pilot users, and grant early feature access. Iterate before global rollout; watch all spend and policy adherence from the top level.
Tips for maximizing value:
- use Groups for cross-departmental squads without org-chart friction.
- Set conservative initial budgets—raise as real usage patterns emerge.
- Use per-Group model access to prevent advanced APIs reaching the wrong users.
- Regularly export activity reports for audit and internal chargeback.
Cursor designed these flows to map to how real IT organizations want to govern software, not just how developers want to self-serve. No retrofitting or manual process overlays required.

Cursor Organizations is the missing control plane for enterprise AI adoption
The takeaway is clear: Cursor Organizations turns AI platform management from a wild-west of ad hoc access, shadow spending, and default-open model sprawl into a governed, observable, and intentionally segmented platform. Enterprises get real-time control over budgets, security, usage analytics, and cross-team access—without the administrative friction that stalls most “platform adoption” projects. The structure is live, proven by early enterprise usage, and is now generally available. For large companies looking to make AI sustainable, auditable, and incrementally safer, this is the administration layer that finally ships.
If you care about security, compliance, or sustainable cost in AI adoption, this is the concrete feature to act on. Structure your teams, set your budgets, and move forward—the AI platform finally respects the way you run a company.
For related analysis of AI platform security and governance, see our best practices for AI platform governance. For parallel explorations of team management and budgeting in AI tools, see our guides on AI team role management and cost controls for platform admins.
Ship the product, not the setup.
- 11 production screens — auth, billing, team, analytics, settings
- Real Postgres + Stripe + Better Auth, all wired on day 1
- CLAUDE.md pre-tuned so your agent extends instead of regenerates