Is Grok Bot safe for business? Permissions and approvals, explained.

Grok Bot's documentation describes real controls: Bots that act with the signed-in person's access and no more, approval cards for risky actions, an independent review model that checks them, sign-ins handed to a person, outside content marked as untrusted, and isolation between users. It is also candid about the limits: approvals do not undo completed work, the shared computer is not a security boundary between Bots, malicious content is reduced as a risk rather than eliminated, and audit logs are an Enterprise feature.

For a small business, that adds up to a clear position. It is reasonable to let a Bot read, sort and prepare drafts under approval. It is not reasonable to give it broad access, standing permission to send or spend, or regulated data, and then assume the product's controls replace supervision. The documented controls are listed below as documented; everything else is labeled as an operating practice.

Most confusion about AI assistant safety comes from mixing these up: assuming a practice is a feature, or that a feature makes a practice unnecessary. The table pairs the main risks with the documented control and the practice that completes it.

The documentation is precise about identity: Bots act as the signed-in member, and a Bot can never hold more access than the person it belongs to, with team-managed connectors as the one exception. On teams and enterprises there is no access by default. Connected apps are account-wide, so an app connected for one job is available to every Bot the user runs, and app tokens are held on Cursor's connector backend rather than on the Bot's computer.

The other side of that rule is that a Bot inherits everything its person can do. An owner with access to every system in the business has a Bot that could reach every system too, once those systems are connected or signed in. The documentation's least-privilege guidance applies directly: connect only the tools a workflow needs, and start with read-only tasks and draft outputs. Where a service offers read-only credentials, use them; the documentation's own Team Bot example configures a plugin with a read-only key.

Every Bot on an account uses the same persistent cloud computer. Its browser sessions, files and sign-ins are shared: signing in to a website for one Bot makes that session available to the others. Each Bot gets its own screen, but the documentation states plainly that the screens are separate work surfaces rather than separate security boundaries, and that separate Bots should not be used as a security boundary. Deleting a Bot does not remove the files and sign-ins it left on the shared computer.

Isolation exists between users instead: each user's computer is dedicated and hardware-isolated, according to the documentation. The practice that follows is simple: work that must not mix, such as payroll, banking or anything regulated, belongs under a separate user account, not just a separate Bot. Sign out of sites a job no longer needs, because a session left open is available to every Bot on that computer.

When an action needs approval, the conversation shows the proposed operation and its inputs, with Allow once, Always allow and Deny. Which actions stop depends on the tool, the risk and the user's Auto-review rules. Auto-review is an independent review model that evaluates risky actions before they run, covering shell commands, app calls, computer use and delegation; Cursor's help pages say it is on by default and allows up to 20 rules of each kind. The documentation describes it as model-based and as a complement to least privilege, not a replacement, and notes that it does not review every side effect.

Three properties matter in practice. An approval controls the proposed action and does not reverse work already completed. Always allow can save a matching rule that applies from then on, widening authority beyond the single action. And approvals raised by unattended work, such as a routine or another Bot's message, expire if nobody answers, and the action does not run. The two official sources currently disagree on the window, about ten minutes on docs.x.ai and thirty minutes on Cursor's help pages, so a design should treat it as short either way.

On Enterprise plans, administrators can enforce Auto-review and team rules. On other plans a member can turn Auto-review off, and Cursor's help pages say that with it off the Bot runs actions without checking them first. A business that depends on Auto-review should check that it is on.

For passwords, passkeys and two-factor codes, the documentation says the Bot should hand control of the computer to the person, who signs in; the Bot does not type credentials or see the password. CAPTCHAs may be handed back the same way. Passwords and one-time codes should never be sent in ordinary chat. When a Bot needs a secret, a secure request masks the value, excludes it from the transcript and does not show it to the model; the documentation adds that this is not a general-purpose password manager. Each use of a hardware security key asks for approval.

Cursor's help pages describe Vault, which stores logins, cards and contact information so a Bot can sign in and check out without seeing the values, and note that there is no setting requiring approval each time a saved card is used. The practice that follows: do not save a payment card for a Bot unless purchasing is one of its intended jobs.

On data, the documentation says Grok Bot follows the Cursor account's authentication and data settings, that customer data is not used for training with Privacy Mode enabled, that computers run in the United States today, and that data is deleted or returned within 30 days of written direction under the data processing terms. Give a Bot only the customer information its job needs. If the business handles regulated data, check the plan's terms and the business's own obligations before connecting it; this article does not assess any regulatory regime.

A Bot that reads email and websites reads text written by strangers, and some of that text may be written to manipulate an AI. The documentation says outside content is marked as untrusted data when presented to the model, and that its layered controls reduce, but do not eliminate, risk from malicious content. Cursor's help pages add that instructions inside an email the Bot received never count as the user's permission to send.

The operating practice is to limit exposure and test for it. Point a Bot only at the inboxes and sites its job requires, keep sending and publishing behind approval, and include a planted-instruction case in testing: a document with a hidden instruction the Bot should ignore and flag. Websites also behave unpredictably for automation; some block it, and the documentation describes the Bot handing logins and similar steps back to a person rather than working around them.

Conversations show what a Bot did and handoffs between Bots are visible, routines keep their 20 most recent run records with the reason for any failure, and a per-Bot notification can report when a Bot finishes or needs input. Audit logs and action recording are Enterprise-only features; the documentation gives action recording a 90-day retention.

For a small business without Enterprise controls, the practice is to make outputs their own record: have each job save its result to a dated file in a shared folder, and check completion by evidence, such as the draft itself or the changed record, rather than by the Bot's report that it finished. A weekly look at run history and a short log of anything that went wrong cost little and answer the question an incident always raises: what happened, and when?

Approvals do not reverse completed work. Deleting a routine is immediate and cannot be undone. Updating the Bot's computer keeps files and sign-ins but removes installed apps and packages. No automatic retry of failed routines is documented, and Cursor's help pages say runs that fail on a rate limit are not retried. None of these are unusual for software, but together they mean recovery is the business's design work.

For each job, write down three things before it runs unattended: what the job changes, how to tell whether it ran, and how to put things back if it ran wrongly. The documentation's own routine guidance supports the same habits: idempotent retries where possible, a stated place to report partial completion, and a policy for missing or stale data.

A routine's test run performs real work: the documentation warns it can navigate websites, change files and call connected tools. Test against a sandbox account, a copy of the data or a prepare-only version of the job. Use invented customer details, write the expected result first, and include the cases built to fail: an action that should stop for approval, a request outside the Bot's job, and a planted instruction. The guide to testing an AI assistant sets out the full method.

Money, commitments, access changes and irreversible changes come from the documentation's recommended approval boundaries; licensed judgment and regulated data are this article's additions. They are reasons for a person to make the decision, not reasons to avoid the product.

• MONEY

  Payments, refunds, transfers and purchases, especially with a saved card that does not ask each time.

• LICENSED JUDGMENT

  Diagnoses, safety calls and anything a license holder must decide.

• COMMITMENTS

  Prices, schedules promised to customers, contracts and acceptance of legal terms.

• ACCESS CHANGES

  Granting or removing permissions in any business system.

• IRREVERSIBLE CHANGES

  Deleting records or changing live systems without a tested way back.

• REGULATED DATA

  Information the business has specific legal duties about, unless those duties have been checked first.

Each item is an operating practice drawn from the documented behavior above. A business that can tick all twelve has done more for its safety than any single product setting can.

• 1 / ACCOUNT

  The Bot runs under the supervising person's own account, not a shared login.

• 2 / SEPARATION

  Sensitive work, such as payroll or banking, is on a separate user account.

• 3 / APPS

  Only the apps the current jobs need are connected, read-only where possible.

• 4 / SIGN-INS

  Sign-ins are done through takeover, and sessions no longer needed are signed out.

• 5 / NO SECRETS IN CHAT

  Nobody pastes passwords, codes or card numbers into a conversation.

• 6 / AUTO-REVIEW ON

  Auto-review is on, with Ask first rules for sending, publishing, money, deletion and permissions.

• 7 / ALLOW ONCE

  Always allow is used only for patterns proven over many runs, never for sending or spending.

• 8 / NO CARD

  No payment card is saved for a Bot unless purchasing is its job.

• 9 / TESTED

  Each job has been tested on invented data, including approval stops and a planted instruction.

• 10 / RECORDS

  Each job saves dated outputs, and someone checks routine run history weekly.

• 11 / RECOVERY

  Each unattended job has a written note of what it changes and how to undo it.

• 12 / OWNER

  Every Bot, skill and routine has a named person responsible for it.

The documentation states that Anysphere, the company behind Cursor, holds ISO/IEC 27001 and ISO/IEC 42001 certifications with Grok Bot in the current scope. It mentions no other certification. A management-system certification is evidence about how a provider runs its own controls; it says nothing about how a particular business has configured its accounts, which apps it connected or which actions it allowed. That part of safety does not transfer, and this article is no substitute for a review of the business's own setup.

Based on the Grok Bot documentation at docs.x.ai as checked on 26 October 2026. Details attributed to Cursor's help pages come from cursor.com/help/grok-bot, checked the same day. The product changes often; check the linked pages before relying on a specific limit. Aevrion Ops is an independent consultancy. It is not affiliated with, endorsed by or a partner of xAI, SpaceXSI or Cursor. Grok Bot is named here only to describe it.

1. A Bot acts as the signed-in person and, team-managed connectors aside, never exceeds that person's access, so least privilege starts with what that person connects.
2. All of a user's Bots share one computer and its sign-ins; separate sensitive work by user account, not by Bot.
3. Approvals and Auto-review stop risky actions before they run but do not undo completed work; unattended approvals expire if nobody answers.
4. The documentation sends sign-ins through takeover; Cursor's Vault can also sign in and use a saved card without asking each time, so save a card only if purchasing is the job.
5. Outside content is marked untrusted and the risk is reduced, not eliminated: limit what Bots read and test with a planted instruction.
6. Audit logs are Enterprise-only; on other plans keep dated outputs, check run history weekly and write the undo for each job.