Cursor Organizations: Govern Enterprise AI Coding at Scale

Cursor Organizations is the AI coding tool's new enterprise governance layer, announced on June 3, 2026, and it reframes the buying conversation around control rather than capability. Per Cursor's announcement, Organizations sits above the existing Teams structure as a company-level container: one dashboard, a rollup of spend and token usage across every team, and separate security, budget, model-access, and feature settings for each operating unit.

The launch matters because of who is buying. Cursor reports that it now serves a large share of the Fortune 500, and independent reporting puts enterprise at roughly 60% of its revenue — up from about a quarter eighteen months earlier. When most of your money comes from large organizations, the product that retains them is not a smarter autocomplete; it is the admin console that lets a CISO, a finance lead, and an engineering director all sign off on the same rollout.

This guide covers exactly what Organizations ships, how its three-tier hierarchy and spend controls work, where it lands against GitHub Copilot Enterprise governance, and one design decision — Cursor's documented "most permissive setting wins" rule — that security teams should scrutinize before they standardize. Every feature claim below is attributed to Cursor's own blog, changelog, and documentation, with third-party figures called out as such.

According to Cursor's announcement, Organizations is "the top-level container" that lets Enterprise admins manage multiple teams from one place. The dashboard surfaces a rollup of spend and token usage across the whole company and exposes per-team configuration for security, governance, budgets, and features. Cursor describes it as generally available to all Enterprise customers, paired with Teams pricing changes announced the same week.

The framing in Cursor's changelog is blunt about the job to be done: enterprises can now run distinct security, governance, budget, and feature controls for each team while keeping a single company-level view. That is a structural shift. Until this release, a large company running Cursor across several departments effectively managed a set of loosely related team accounts; Organizations gives them a parent account with real administrative gravity.

One detail in the announcement is easy to miss and matters operationally: the identity provider is configured once at the organization level and reused across every team and group, which removes the per-team IdP setup duplication that plagued multi-team deployments before. Admins can move users between teams via the dashboard, an API, or CSV bulk import — table stakes for any company past a few hundred seats.

The structure is three layers deep, and each layer answers a different governance question. The Organization is the company-level identity and admin container — the single pane of glass. Teams are the operating units: departments, regions, or subsidiaries, each with its own independent settings. Groups are the lightweight layer — collections of users that can span teams or sit inside one, carrying their own model access, spend limits, and agent permissions without forcing you to stand up an entire new team.

Groups are the quiet workhorse of the design. Before this layer existed, granting a subset of users different model access or a tighter agent policy meant either a new team (heavy) or no granularity at all (risky). Groups make per-function policy a lightweight assignment rather than an org-chart change — which is precisely what makes the segmentation use case in the next section practical at scale.

Cursor cites a sandbox-staging pattern as a named use case: a company can stand up a staging team to pilot new features while the same users participate in both the staging and production teams without duplicate accounts. For engineering organizations that already run a ring-based rollout model for their own software, the appeal is obvious — the tool they build with now mirrors how they ship.

This is the use case Cursor leads with, and it is the most commercially honest one. Per the announcement, engineering, product, and design users can be granted access to all frontier models — including the expensive fast-mode offerings — plus higher monthly budgets. Marketing, finance, and other non-product roles get restricted model access, lower budgets, and tighter controls on whether agents can run commands automatically. The whole thing is configured from one admin console.

The economic logic is straightforward. Frontier fast-mode inference is the most expensive thing a Cursor seat can consume, and the people who justify it are the ones shipping production code. Letting a finance analyst's occasional agent run pull from the same frontier pool is pure cost leakage. Segmenting model access by function is the single highest-leverage budget control an enterprise can set — and until Groups existed, there was no clean way to express it.

If you run a mixed organization where different roles genuinely need different tools, this maps cleanly onto how we already think about it in our AI digital transformation engagements: the model is a per-function decision, not a per-company one. A governance layer that encodes that distinction is doing real work, not shipping a checkbox. For the adjacent question of which roles should get which agentic tools at all, our breakdown of OpenAI Codex for every role covers the function-by-function logic in depth.

Budgets are where governance gets concrete. Per Cursor's documentation, enterprise spend limits cascade across three levels — group, team, and organization — and the system honors the most specific limit that applies to a given user. On pooled enterprise accounts, those limits apply to total usage, not just on-demand spend, and admins can set dynamic limits that auto-adjust proportionally as headcount grows or shrinks.

The proprietary table below maps Cursor's three-tier spend model. The mental model worth internalizing is the interaction rule: where GitHub Copilot's enterprise budgets apply a "lowest remaining headroom wins" principle across its budget types, Cursor's spend limits resolve to the most specific level. Those are different philosophies — one optimizes for the tightest cap, the other for the most locally-relevant cap — and a finance team should know which one it is buying.

The identity story is where Cursor's tiering quietly diverges from the competition. Per Cursor's docs, SAML 2.0 SSO is available on both Teams and Enterprise plans at no additional cost, with support for Okta, Azure AD, Google Workspace, and OneLogin, plus Just-in-Time provisioning so new users auto-enroll on first SSO login. SCIM 2.0 provisioning is available on Enterprise plans with SSO enabled — access is granted when an employee joins a designated IdP group and revoked when they leave, with directory groups and memberships syncing in real time.

That SCIM-to-Groups link is what makes the segmentation model durable rather than a one-time spreadsheet exercise. When a marketer moves into a product role in your identity provider, their Cursor group membership — and therefore their model access and budget — follows automatically. Governance that drifts the moment HR makes a change is not governance; the real-time directory sync is the part that keeps the policy honest.

Here is the design decision security teams should read twice. Cursor's blog documents that when a user belongs to multiple teams or groups, the most permissive setting wins. A user who sits in both a restricted marketing group and a permissive engineering group inherits the higher-access configuration. This is documented for the settings Cursor's announcement describes; we are not extrapolating it to every control in the product.

For convenience, the rule is sensible — it stops a contributor from being silently locked out of a model their other group grants. But it runs directly counter to the least-privilege principle that governs most enterprise security programs, where overlapping memberships should resolve to the tightest permission, not the loosest. Cursor chose velocity; a default-deny posture would have chosen lock-down. Naming that explicitly is the kind of analysis no vendor blog will publish — and it is the first thing your security reviewer will ask about.

This is also the cleanest point of contrast with GitHub Copilot's governance model, which is built to cascade down: enterprise owners set policies and can delegate to org owners, with the framework designed so control flows from the top. Two products, two opposite instincts about how permissions should resolve under conflict. Neither is wrong in the abstract — but a regulated enterprise and a fast-moving startup will not pick the same one.

The timing is not a coincidence. GitHub launched the Copilot App in technical preview on June 2, 2026, and moved Copilot to usage-based billing on June 1 — the same week Cursor shipped Organizations. Putting both on one timeline makes the implication clear: these two are in a direct enterprise-governance race, and the battleground is admin control, not model quality. The matrix below maps the governance surface across both platforms.

Two contrasts do the analytical work. First, the SSO entry tier: Cursor democratizes single sign-on down to its Teams plan, while Copilot gates SAML SSO behind Enterprise. Second, the budget interaction rule: Cursor resolves to the most specific limit, Copilot to the lowest remaining headroom. The first favors mid-market buyers; the second is a genuine philosophy difference your finance team should pressure-test against its own forecasting model. For teams still weighing whether to extend an incumbent like Copilot or adopt a new-category IDE, this matrix is exactly the input that the build vs. buy decision hinges on.

Organizations did not appear because Cursor suddenly cared about admin consoles. It appeared because the revenue mix demanded it. TechCrunch reported in April 2026 that Cursor crossed $2B ARR in February 2026, with enterprise revenue growing from roughly a quarter of the total in late 2024 to about 60% at the $2B milestone. Fortune, reporting independently in March 2026, profiled the same enterprise surge. When most of your money comes from large organizations, governance tooling stops being a feature and becomes the thing that keeps the contract.

The product, in other words, has been rebuilt around enterprise needs as enterprise grew — it was not architected this way from day one. That reframing matters for buyers: Organizations is the expansion and retention mechanism for the segment that already pays Cursor's bills, which is exactly why it is comprehensive on budgets and access but comparatively young on the hardest least-privilege controls. Vendor coverage frames this as a feature launch; the more useful frame is that it is a defensive move in a market the CEO himself describes as consolidating.

There is a practical "why now" underneath the strategic one. Industry coverage in early June framed the moment as a tokenomics reckoning: the spend controls and pricing changes that landed alongside Organizations are, in part, a response to enterprise customers who could not forecast their AI bills. Read that way, Organizations is not only about who can use which model — it is about giving finance a way to put a hard ceiling on a line item that had been growing unpredictably. That is a real adoption unlock, and it is the part of the story most feature write-ups skip.

Organizations changes the calculus for a few specific buyer profiles and leaves the rest unchanged. Here is the honest version of who should move and who should wait.

For everyone running a single small team, the change is marginal — Organizations is an enterprise-scale answer to an enterprise-scale problem. The right move for most organizations is to pilot the governance model against a real policy: assign a finance group with a hard cap, an engineering group with frontier access, and one user in both, then watch how the access resolves. That single test tells you more than any feature list. The same competitive context plays out in the broader IDE field — see our read on Windsurf's migration to Devin Desktop and the underlying agent layer in Cursor 3's agent-first architecture, which is what Organizations is ultimately built to govern.