Securing Grok Bot: A Hardening Guide to X’s Personal AI Assistant

Grok Bots are Cursor’s persistent personal AI assistants. A Bot works from a cloud computer shared with the user’s other Bots and, when allowed, reaches the employee’s own machine, connected tools and Cloud Agents.

This guide to Grok Bots security answers one question: what should a security team configure and verify before employees use them?

Who this is for

Grok Bots may already be in use by the time security gets a look at them. This guide is for whoever owns the team setup, whether in security, IT or the team itself. Inside Personal AI Agents explains the underlying boundaries, and Cursor’s Grok Bot security guide has the full settings list.

The threat model

Cursor assigns one persistent cloud computer to each user, not to each Bot, so a user’s Bots share its files, browser sessions, command-line credentials and installed connectors. A Bot acts as the signed-in user with no credentials of its own, so nothing separates one Bot from the next. It also reads web pages, plugin results and command output as it works, and Cursor states that any of those can try to steer it. Three things start out wider than they look:

• Egress is allow-all for a team with no network policy.
• Allow Sudo on Bot Computers ships on, so Bots run as root.
• Deleting a Bot leaves its files and sign-ins behind. Its profile, conversation and routines go; the computer keeps the rest.

1. Draw a boundary around the computer every Bot shares

Cursor runs each user’s cloud computer as its own Firecracker microVM. That microVM is the real boundary, and every Bot the user creates works inside it.

Risk: with no network policy, a user’s cloud computer can reach any destination, and every Bot on the account works there as root.

1. Admin, Enterprise: set Grok Bot Network Access to Team Allowlist Only (Cursor dashboard → Grok Bot → Network). The default is allow-all: with no network policy, the computer can reach any destination. Add only the domains and IP ranges your workflows need. Result: Bots reach only listed destinations, within about a minute.
2. Admin, Enterprise: turn off Allow Sudo on Bot Computers, then restart existing computers (Cursor dashboard → Grok Bot → Bot Computers). Result: Bots no longer run as root.
3. Admin, Enterprise: pass Team Setup credentials as Team Secrets only. Result: they exist only while the script runs, unless it writes them to disk.
4. User: run Update Bot's Computer (Settings → Computer → Bot’s computer). Updating the desktop app does not update the cloud computer. Result: the latest software is installed and your files are left alone.
5. User: after sensitive work, sign the browser out and delete temporary files. Result: the user’s other Bots can no longer use them.

Check: have a Bot open a site that is not on the allowlist, and run sudo -n true. Both should fail.

2. Decide whether a Bot touches the user’s machine at all

Risk: while the desktop app runs, a Bot can run commands on the user’s own machine and move files between it and the cloud computer. The default, Always allow, leaves that decision to each user.

1. Admin: set the team ceiling for Execution on Local Computer to Never allow (Cursor dashboard → Grok Bot). Result: no user’s machine is reachable, since the stricter value wins.
2. User: set Execution on Local Computer to Never allow. Settings → General → Bot. Once the account has registered computers this moves to Settings → Computer → Computers, where each computer carries its own Execution on this computer value. Result: the machine stays closed if the ceiling is raised later.
3. User: if a workflow needs it, set Ask every time instead and read each card before allowing. The card shows the exact command, so check its target and arguments, then return to Never allow when the work is done.

Protect the desktop app like other credential-holding software, because its session reaches the user’s Bots, cloud computer and connected tools. At offboarding, revoke the person’s Cursor access: uninstalling the app does not end the session.

Check: confirm the team ceiling and each registered computer’s value, then ask a Bot to list a folder on the user’s machine. It should be refused.

3. Make consequential actions stop for review

Risk: Auto-review checks each action against each user’s own rules until an admin enforces team rules. It is an independent model that can allow, ask or deny an action before it runs.

1. Admin, Enterprise: turn on Enforce Auto-review, then add narrow Ask first rules under Configure Rules. Cover external messages, publishing, deletions, permission changes, purchases and production changes. Result: users see locked rules and can only add stricter ones.
2. Admin: add Team Rules scoped to Grok Bot, such as “never move company data to personal accounts.” Result: always on; users cannot turn them off. Team Rules guide what a Bot does; enforced Auto-review rules decide when it stops.
3. User: add personal Ask first rules (Settings → General → Auto-review), each tied to a known action, and avoid broad Allow automatically rules. They live on the current desktop, so a second installation needs its own. Result: the user’s risky actions wait for them.

Auto-review reduces prompt-injection risk without eliminating it, and it does not cover memory writes or most settings changes, so keep the network and connector limits in place.

Check: ask a Bot to do something on your Ask first list, such as sending an external message, and confirm it stops for approval. Repeat for each group, because a group can lift team enforcement.

4. Choose what the Bot gets to know

Risk: each Bot builds its own memory (working preferences, important facts, summaries of past work) inside one continuous conversation, and you cannot open, edit or clear it. The only levers are what goes in and replacing the Bot.

1. User: give the Bot only the material its role needs, and put standing limits in its description. Keep unrelated sensitive files and credentials off the computer. Result: nothing outside the role shapes later work.
2. User: require the source of record for consequential decisions. Tell the Bot to reopen and cite the current system rather than answer from memory. Result: no decision rests on stale memory.
3. User: at the end of a project, clean up in this order: pause or delete routines, sign out of websites, uninstall connectors and revoke them in the source service, remove sensitive files from /workspace, then delete or hide the Bot. Result: nothing stays behind. Deleting the Bot alone leaves the computer’s files and sign-ins.
4. User: to clear what a Bot has learned, duplicate it and delete the original. The copy keeps its configuration but, as Cursor documents, not its conversation history or learned memory. Result: a clean Bot with the same configuration.

Check: after cleanup, ask another Bot on the same account to list /workspace and open a site the old Bot was signed in to. Neither should show the old work.

5. Keep authority from growing at a handoff

Risk: a connector keeps the access it was given at setup, is available to every Bot on the account, and holds that access until someone revokes it, so a small request can reach far more than it needs.

1. Admin: turn off Cloud Agents unless Bots need to delegate coding work (Cursor dashboard → Grok Bot). It is on by default. Result: no handoff to coding agents. If you keep it on, delegated work runs under your Cloud Agent controls, so review those too.
2. Admin: allow only reviewed MCP servers (Cursor dashboard → Plugins & MCPs (Team Marketplace)), and on Enterprise maintain the MCP allowlist alongside. Grok Bots inherit this policy and have no separate list. Result: blocked servers show as Disabled by team admin.
3. Admin: scope the provider account before connecting it. Connect only the tools a workflow needs, prefer read-only or scoped service accounts, and revoke access in the service itself when it should end. Result: a connector can do only what its workflow needs.

Personal connectors act as the signed-in user; team-managed ones may carry team or service-account credentials, so review what those can reach.

Check: as a user, try to enable an MCP server that is not on the reviewed list. It should show as Disabled by team admin.

What you can see afterwards

Risk: Cursor keeps two records, and only one shows what a Bot did. The audit log tracks account and configuration changes, such as Bot creation. Action Recording captures the Bot’s actions, which never appear on the Audit Log page. Turning on the first gives you none of the second.

1. Admin, Enterprise: turn on Action Recording, then send its events by OpenTelemetry Export to a collector you operate (Cursor dashboard → Grok Bot). Recording is off by default and keeps events for 90 days internally. Result: sanitized events, which may include the user’s email, reach your own systems. Nothing is exported for teams on Privacy Mode (Legacy), which also forces recording off.
2. Admin: enable conversation content export only if someone will read it. It can send prompts, responses and MCP tool calls, and Cursor notes that its redaction cannot catch every secret. Result: sample the output and protect the destination like the source.

Check: run one task in a Bot, such as opening a page and running a command, then find it in your exported events. Every action in the conversation should have a matching event; any that does not marks where your visibility stops.

Bottom line

Cursor separates users, not Bots. Bound each user’s cloud computer, decide on local access, make consequential actions stop, and limit what connectors can reach. Then turn on the record of what a Bot actually did.

This analysis is part of Pluto Security’s ongoing research into the security of the AI ecosystem. Pluto provides workspace security platforms engineered for the AI era, giving enterprise security teams real-time visibility and governance over agents, extensions, tools, and autonomous workloads. To learn how to secure AI assistants in your environment, contact us at pluto.security.