Grok Bot for enterprise and teams: what exists, and what is a waitlist

Enterprise is a waitlist, not a product

xAI’s launch post on 11 August 2026 put enterprise access behind a waitlist. As of 22 August 2026 that has not changed: there is no published enterprise tier, no enterprise pricing, no enterprise feature list, and no stated timeline.

This is normal for a beta and it is also disqualifying for a certain kind of buyer. If your procurement process requires a named contract owner, a security questionnaire with answers, and a support commitment, none of those exist yet. What exists is a form.

The naming trap: SuperGrok Team is not the team plan

This one has caught enough people to deserve its own section. There are two plan families and both have plans with team-sounding names, and the intuitive mapping is wrong.

Cursor’s help page on SuperGrok and Grok Bot states it directly, and we fetched it on 22 August 2026:

• "Only individual SuperGrok Plus and individual SuperGrok Heavy grant Grok Bot usage."
• "SuperGrok Team and SuperGrok Enterprise plans are not supported."
• Basic SuperGrok is also listed as not qualifying.

The practical consequence is a specific and expensive mistake: an organisation that already standardised on SuperGrok Team, reasoning that the team plan of the vendor that makes Grok Bot would obviously include Grok Bot, has bought the one thing that does not grant it. The route in is Cursor Teams, a different vendor surface with a different contract, on a plan whose name does not contain the word Grok at all.

What buying Cursor Teams actually gets you

Both Cursor Teams tiers now carry Grok Bot. Standard has a $40 list price per seat and Premium has a $120 list price per seat, with a published 20% annual billing discount. The 21 August expansion is what brought Standard in; before that the floor was Premium.

What that buys, and what it does not.

The pattern is consistent: the seat is well defined and everything an administrator would want to do with the seat is not. You can buy access for twenty people. You cannot see what those twenty people’s Bots did last week, cap what they spend, or restrict which systems they may touch by policy rather than by instruction.

The governance gaps, one at a time

These are the answers a security review will ask for. Each one is sourced, and where the answer is "not published", that is the answer rather than a gap in our research.

The permanent link, and who should own it

Cursor documents a one-way door that almost no coverage mentions: "A SuperGrok link is permanent once created", and "You can’t unlink a Grok account from a Cursor account, and you can’t move a link to a different Cursor account."

For an individual that is a mild annoyance. For an organisation it is a governance decision that has to be made before anybody clicks anything, because the wrong answer is not reversible.

• An employee linking their personal SuperGrok to a corporate Cursor account has permanently entangled a personal subscription with company identity. It cannot be undone or moved when they leave.
• An employee linking a corporate SuperGrok to their personal Cursor account has done the reverse, and the company cannot reclaim it.
• A team that links to the wrong Cursor workspace, for example a trial workspace created during evaluation, cannot migrate the link to the production workspace later.

The mitigation is procedural rather than technical: decide which account owns the link, document it, and tell people before they install the app rather than after. There is no undo to fall back on.

The procurement checklist

Questions to put to a vendor, with the answer as it stands on 22 August 2026 so you can see which ones are genuinely open.

That last row is worth checking first, before any of the others. Many organisations turned Legacy Privacy Mode on as a condition of adopting Cursor at all. If yours did, Grok Bot is unavailable at any price until that decision is revisited, and revisiting it is a bigger conversation than adopting an agent product.

What a team that needs governance should do instead

If your blocking requirements are an audit trail, a spend ceiling, and a boundary between what different people’s agents can reach, none of those exist in Grok Bot today. Only the audit view is described as coming; the other gaps may be fixed, but no roadmap is documented. That is a wait-and-see verdict rather than a permanent one, and this page will be updated if the audit view ships.

In the meantime, the alternative that answers those requirements is the one where the agents run on infrastructure your organisation already controls. Continuum runs Claude Code, Codex, Cursor, Grok, Gemini, and OpenCode on machines your team owns, under the subscriptions your team already holds. Each Code session gets its own git worktree, spend is recorded per repository so a runaway session is visible while it runs, live quota gauges sit beside the work, and members drive sessions from an iPhone or a browser while the work continues on the host.

The organisation-level surface, including how teams share hosts and how usage rolls up, is at Continuum for organizations. The wider pattern of putting a control plane in front of several vendors’ agents rather than buying one vendor’s hosted agent is covered in the control plane guide.

Questions people ask

Keep reading

Continue through Grok Bot with Grok Bot use cases: what people actually did with it in week one.