Grok Bot Shared Workspace Security: How Files, Browser Sessions and Credentials Expand Blast Radius

Part of the Grok Bot security series.

The vendor documentation says all of a user's Bots share one cloud computer, and that files, browser sessions and command-line credentials on it are available across the Bot roster. This article is the practical follow-up: how to inventory what that shared computer holds, and how to decide what should and should not live on it.

Four kinds of shared state

A Bot's configuration does not change this list. Whether a Bot is called "Research" or "Ops," it sees the same computer.

Visibility is not the same as usability

Platforms often protect secrets by hiding them. The Grok Bot documentation describes secrets as masked, excluded from the transcript and not shown to the model, and connector tokens as staying on Cursor's backend rather than on the computer. These are good controls against reading a secret.

They do not remove the authority behind it. A Bot that cannot read a password can still use a browser that is already logged in. A Bot that cannot read a token can still call the connector that uses it. A Bot that cannot read a key can still edit a script that a trusted process runs later. We ask six questions instead of one:

1. Can it read the secret?
2. Can it invoke something authenticated by the secret?
3. Can it modify files an authenticated process consumes?
4. Can it use a browser with an active session?
5. Can it send data outside?
6. Can another Bot reach the same state?

"The Bot can't see the password" answers only the first. For the credential-specific version of this argument, see AI agent credentials and API-key abuse.

Lateral movement inside one computer

Because state is shared, a compromise of one Bot is a compromise of the user's whole roster. An illustrative chain, which we have not tested against Grok Bot:

This is the multi-agent version of the confused deputy problem. No sandbox escape is needed. The hostile content only has to reach the Bot with the weakest judgment, and the shared computer does the rest. For how hostile content steers an agent in the first place, see indirect prompt injection.

HexTyx's own testing of cross-user memory in the Mneme app (synthetic data, tested against Claude Haiku 4.5) found a cross-user memory leak. That is a different product and a different boundary, but the lesson carries over: state shared across principals leaks unless something outside the model enforces separation.

When sharing is actually useful

Shared state is not a defect. A shared computer lets a research Bot hand a file to a writing Bot without copy-paste. It lets one sign-in serve every task. For a single user with low-consequence accounts, that convenience is the point of the product.

The risk comes from putting high-consequence authority on the same computer as low-trust tasks. Decide per account, not per Bot.

A segmentation playbook

These steps are HexTyx recommendations.

1. Inventory. List every file location, logged-in site and CLI credential on the computer. If you cannot list it, treat it as exposed.
2. Tier by consequence. Low: public research accounts. Medium: work email and docs. High: payment, production infrastructure, admin consoles.
3. Keep the high tier off the shared computer. If a Bot needs a high-tier action, route it through an approval you read, not a standing login.
4. Split trust domains by user. The vendor's guidance for separate credentials or computers is to give the workload its own Cursor user. A client-facing workload and a personal one are different domains.
5. Start read-only. Grant read access first, observe what the Bot does, and add write access one capability at a time.
6. Treat the browser like a credential store. Log out of anything the roster does not need. Log in only for the task, where practical.
7. Treat the filesystem as an authorization surface. Anything a trusted process executes or loads is a place where a Bot can plant instructions.
8. Prefer "Never allow" for local command execution unless a task needs it, as the vendor's security page recommends.
9. On Enterprise, use the controls that exist. Network Controls, action recording and audit logs are Enterprise features. The default without a network policy is allow-all.

Auto Review helps, but it is not the boundary

Auto Review evaluates tool calls and computer actions before they run. The documentation says it is model-based and should complement, not replace, least privilege and explicit approval boundaries. It also says Auto Review does not review every side effect, such as memory writes and most settings changes. Memory writes matter here because agent memory is shared state too.

The post-compromise test

For each Bot, answer in one line each: what data could be read, what credentials could be used, what tools could be called, what the browser could do, where data could be sent, and which files could be changed. Then ask whether the answer differs between Bots. If it does not, you have one blast radius, not several.

Frequently Asked Questions

Sources

• xAI docs: Grok Bot approvals, security and privacy
• Cursor docs: Grok Bot security FAQ
• Cursor docs: Grok Bot security
• Cursor docs: Grok Bot for teams

More in This Series