What a separate Bot does not separate

The official overview states that Bots on one account share computer files, sessions, and logins. Separate Bot names do not create separate access boundaries. The approval documentation describes model-based Auto Review and explicit action approvals; it recommends combining them with least privilege. Neither a prompt nor an automated review should be treated as an absolute guarantee.

The permission worksheet below is an original operating suggestion. Apply your organization's actual access policies when relevant. For the security model behind it, including the October Secure Form issue, see Is Grok Bot safe?.

Documentation: Shared computer model ↗ Official approvals and privacy guide ↗

The controls that enforce a boundary

A boundary written in a brief is a request. These settings are what actually stop a Bot. The rows paraphrase the docs, Cursor's help and the changelog as of October 14, 2026.

Documentation: Official approvals and privacy guide ↗ Cursor help: how-tos (Custom Rules, approval expiry) ↗ Grok Bot changelog ↗

ControlWhat it doesSuggested starting point
Approval cardShows the proposed action and its inputs: Allow once, Always allow (saves a rule) or DenyAllow once while you learn a workflow
Custom RulesYour saved approval rules, renamed from approval rules in 0.68.0. Ask first always stops a matching action; Allow automatically lets it through only if Auto Review finds no other reason to stop; Ask first wins when both matchAsk first for sending, purchasing, deleting and publishing
Auto ReviewA review model that checks tool calls and computer actions before they run; an admin can require itLeave on
Draft cardsEmail and Slack messages arrive as editable drafts you send or discard; since 0.64.0 you can disable drafts for a Bot so it sends directlyKeep drafts on until a Bot has sent several messages correctly
Execution on Local ComputerWhether Bots may run commands on the computer in front of you: Ask every time (default), Always allow or Never allowNever allow unless a Bot needs local files
StopSince 0.68.1, ends a Bot stuck on an unresponsive step within about 30 secondsUse it, then check what already ran; Stop does not undo completed actions
Built-in checks (October 11)The 0.69.0 to 0.70.2 changelog says a Bot checks your own messages for approval before an action it cannot undo (sending, posting, buying, deleting), and asks before sharing data a bank or brokerage connector returnedCount them as a backstop, not a rule: they are Bot behaviour you cannot configure

Rules that behave differently than you expect

Personal rules are stored on the desktop where you made them and synced to that Grok Bot computer, so another desktop needs its own. Rules your team locks cannot be edited, and your own rules can only make behavior stricter than the team's. Keep each rule narrow: ask first before sending external email, not allow everything in the browser.

Approvals raised by routines, triggers or other Bots expire after about 10 minutes and the action does not run; approvals in a chat you are in wait for you. That is a safe failure, but it can stall unattended work, so turn on notifications for Bots that own routines rather than broadening Always allow. Your starred primary Bot can offer to take work off your plate since 0.66.0; an offer is not an approval, and the same rules apply to whatever it does next.

Three changes in the October 11 changelog entry (0.69.0 to 0.70.2) affect where a boundary should sit. Bots can now pay with X Money or Stripe Link, so purchases are no longer only a browser checkout you would take over; put an Ask first rule on them. On a Team Bot, teammates can approve Auto-review requests, including Always allow, from their own DM with it, so an Always allow there can come from anyone on the team; Cursor's Team Bots help, checked October 14, still says a Team Bot asks only in its owner's chat. And passwords still belong on the Bot's screen: the notes do not mention the October 5 report of a Secure Form password appearing in a page snapshot, and Cursor had posted no update in that thread by October 14.

Documentation: Official approvals and privacy guide ↗ Cursor help: how-tos (Custom Rules, approval expiry) ↗ Grok Bot changelog ↗ Cursor help: Team Bots (approvals) ↗ Forum: password filled by the Secure Form shown in a page snapshot (staff reply, October 5) ↗

Write boundaries around verbs and targets

'Be careful with email' leaves too much open. 'Read the approved folder and draft replies; do not send, forward, archive, or change labels' identifies observable behavior. Do the same for a database, repository, or publishing system: name the resources and the permitted operation.

For a recurring job, consider three stages. First, gather evidence. Next, prepare a proposed change. Finally, apply a specific approved change if authorized. The evidence and proposal should be useful on their own so a human can decline execution without losing the value of the work.

When credentials are needed, take over the Bot's screen and type them yourself, or use a secure secret request where a connection offers one; the docs say not to paste passwords or one-time codes into chat. Do not put secret values in the brief, a reusable skill, or an example intended for sharing. The shared-computer guide explains why every Bot can reach a login once any Bot has used it.

Documentation: Official approvals and privacy guide ↗

  1. List the systems the task needs and the smallest usable account permissions.
  2. Write allowed operations and prohibited operations in plain language.
  3. Define what an approval request must show: exact target, before/after values, and likely effect.
  4. Use a harmless sample to check that the workflow pauses at the intended point.
  5. Revisit access when you add a Bot, connection, or new responsibility.

A preparation-only brief

Adapt the allowed actions to your actual task. This template does not configure or replace technical permissions.

Try this brief

Work only with [approved sources]. You may read and produce a separate draft artifact. Do not send messages, publish, purchase, delete, modify permissions, accept terms, or alter the source systems. For each recommended change, show the exact target, current state, proposed state, rationale, and uncertainty. Finish the analysis and draft before asking for a decision. If the task requires additional access, explain the specific missing operation; do not broaden access yourself.

Original editorial template. Replace placeholders and review access before running.

Review the effect, not just the explanation

A persuasive rationale cannot compensate for the wrong destination or account. Compare the actual operation with the approved scope. For batch work, check the count and selection rule as well as a sample record. Keep approval narrow enough that you can tell what you authorized later.

  • The target account and resource are recognizable.
  • The proposed change can be inspected before execution.
  • The scope does not silently include unrelated records.
  • Completed changes will be reported separately from pending ones.

Bots for this job

Directory listings that match this guide, read from each creator's public share page. They are not tested picks: check what a Bot can reach before you add it.

Browse: Bots for admin work

  • Paperwork by Liam: Works out what a boring document is and what you have to do about it
  • Done by Paulo Vitor Justino Pereira: Closes everyday errands from comparison through booking, confirmation, and calendar proof
  • Security Warden by Mayur Darji: Gates another bot's risky moves like outbound messages, deletions, and shell, checking for secrets and personal data before they run

Sources & next steps

Capabilities are grounded in the documentation below. The workflow design and acceptance checks are editorial suggestions.

Build your own workflow brief ↗