An Agent With Its Own Computer Just Landed on a 40 Dollar Seat, and the Admin Console Is on a Waitlist
On 21 August xAI extended Grok Bot to Cursor Pro+, Cursor Teams Standard and SuperGrok Plus. Each Bot gets a cloud computer with browser and terminal access, signs into your apps as a human would, learns routines by watching, and runs unattended. Enterprise administration is waitlisted, so the capability reached ordinary seats before the controls did.
On 21 August 2026 xAI extended Grok Bot beyond the tiers it launched on. It went into beta on 11 August limited to SuperGrok Heavy at around 300 dollars a month, Cursor Ultra at 200 dollars a month and Cursor Teams Premium at roughly 120 dollars per seat, which is a price band that mostly self-selects for deliberate buyers. Ten days later it was added to SuperGrok Plus at 100 dollars, Cursor Pro+ at 60 dollars and Cursor Teams Standard at 40 dollars per seat. The same announcement says enterprise users can join a waitlist while access ramps for larger team and company rollouts. Read those two facts next to each other and the shape of the problem is immediate: the capability shipped to the seats most likely to be expensed on a personal card, and the administration plane for governing it is not open yet.
What a Bot actually is matters more than the tier list. xAI describes each one as having its own computer in the cloud, with browser and terminal access, and the product copy is direct about the point of that: Bots sign into your apps and the work happens in the actual tool. That is the design goal, not a side effect. It is what lets a Bot operate against systems that expose no API and no MCP server, which is most of the long tail of software a business actually runs on. Bots persist context across conversations, keep working while the user is away, come back when something needs approval rather than asking for direction at each step, run many at once, message each other, and can be taught a routine by watching a job done once and then repeating it on a schedule. Independent coverage at launch noted no model name, no stated concurrency limit, and no published security guidance.
Strip the branding away and the security description is short. This is an unattended, persistent, remotely hosted process that holds interactive session credentials to your business systems, executes arbitrary commands in a shell, browses the open web with those credentials resident, retains state between runs, and self-schedules. Every one of those properties on its own is something a security team would normally review. Assembled into one product and distributed through a 40 dollar seat licence, they arrive together and unannounced. There is no purchase order, no architecture review and no data flow diagram, because from a procurement standpoint nothing was bought. A subscription that already existed gained a feature.
The credential question is the one to press hardest, and the honest position is that the vendor has not answered it publicly. Signing into an app as a human does means one of a small number of things: the Bot holds a stored password, or it holds a live authenticated session, or a human completes the login and hands over the resulting session, or it uses OAuth against an app registration nobody in your business approved. Each of those carries a different blast radius and each requires a different control, and none of them is compatible with the multi-factor and session-management assumptions your access control policy almost certainly makes today. We wrote earlier this month about browser agents inheriting a human session, and this is the same failure mode with the human removed entirely and a persistent virtual machine put in their place. When your logs show a login from a named employee, that assertion is now unreliable, and unreliable attribution undermines every access review and every incident timeline built on top of it.
Learning by demonstration deserves its own paragraph because it changes what a change is. A Bot that watches a job once and saves the steps as a routine has just created an automated business process, with no specification, no code review, no test, no owner recorded anywhere and no version history you can inspect. If the underlying application changes its layout next month, the routine does not fail loudly, it does something slightly different and keeps going on its schedule. Anyone who has run a screen-scraping automation estate recognises this: the automation is invisible until the day it is wrong, and by then nobody remembers who created it or what it was supposed to do. The control that matters here is inventory, and inventory of routines nobody registered is exactly the thing that will not exist unless you go looking this week.
The framework mapping is unglamorous and completely conventional, which is rather the point. ISO 27001 gives you access control, identity management, privileged access rights, logging, and use of cryptography and secrets, and a process that authenticates as a person breaks the first three at once. The SOC 2 common criteria expect logical access to be provisioned, reviewed and removed on a defined basis, and expect changes affecting the control environment to be identified and responded to. ISO 42001 adds the obligation to maintain an inventory of AI systems, record what each one does, define who owns it by name, and assess the impact before deployment, and an always-on agent operating inside production applications is squarely in scope. If a Bot ever touches a payment page or the systems around it, PCI DSS expectations on access, inventory and script integrity follow it. It is worth being blunt about the platforms: Vanta, Drata, Secureframe and Sprinto will confirm your access review ran on time and your policies are approved, and none of them can tell you that an engineer taught a cloud-hosted Bot to log into your billing console at seven each morning. Our compliance readiness tool and the access control policy template in our policy templates library both assume you can name every identity with access, so the register is the place this work starts.
There is a fair counterargument. Rolling a capability down the price tiers is normal product behaviour, an early beta legitimately ships ahead of its administration console, and a waitlist is at least an admission that enterprise deployment needs something the current build lacks. Bots pausing for approval rather than acting unilaterally at every step is a real design choice in the right direction. Doing work in the actual tool rather than through a brittle integration genuinely solves a problem that has defeated automation vendors for two decades, and the productivity case is not imaginary. None of that argues for waiting. It argues for asking now, while the answer is still being written and while a customer question can still shape what the enterprise controls turn out to be. Ask for the credential storage model, the audit log format and retention, the tenant isolation model for the cloud computer, the egress controls on the browser and terminal, the data residency of the virtual machine, and whether an administrator can enumerate and revoke Bots created by users in their organisation. Keep the reply.
The wider pattern is what should worry you rather than this one product. In the space of ten days a single vendor relationship produced a change of control, a default-on code hosting service and an autonomous agent with shell access, all reaching the same engineering seats. We covered the first two on 20 August and the sequence has not slowed since. If your change management process only registers a supplier when someone raises an invoice, none of these three events generated a record anywhere in your business. Meanwhile the market moved the other way on the protocol side: the 2026-07-28 MCP specification removed protocol-level sessions and the session header entirely, pushing state into explicit server-minted handles, which makes MCP-based tool access easier to route, log and inspect at a gateway. That contrast is the useful one. Structured tool access is getting more governable at exactly the moment that agents signing in as humans are getting cheaper, and the second path is the one that leaves you nothing to show an assessor.
The exercise for this week takes an afternoon and produces something durable. First, find out who holds a Cursor Pro+, Cursor Teams or SuperGrok subscription, including contractors and anyone expensing it personally, since the enterprise controls that would let you answer this centrally do not exist yet. Second, ask each of them directly whether a Bot has been created, what it has been signed into, and whether any routine is running on a schedule, and write the answers down. Third, publish a short interim position, one page is enough: no agent authenticates using a named human identity, no agent gets credentials to a production or customer-data system without a registered owner and a documented approval, and every agent goes on the AI system inventory required by ISO 42001 before it runs. Fourth, add the 21 August tier expansion to your change log and your vendor register with the date attached, and check your contract for notice obligations on material feature changes. Fifth, for the workflows people genuinely want automated, route them through an API and a scoped service credential with a short lifetime and a named owner, rather than through an agent holding a session that belongs to a person. The productivity is real. The identity model is the part you have to fix yourself, because nobody is shipping it to you on the 40 dollar tier.
Editorial note: AES Tech reviews are independent. Some outbound links are affiliate links and are marked sponsored; they never change our rankings. See our disclosure.
Get the next post by email
One short email when something worth knowing ships. No spam, unsubscribe anytime.