LearnGrokNew Grok Bot users usually want a list: which actions require my approval? There isn't one, and the reason matters.
The rule that governs everything else
An approval controls the action being proposed. It does not reverse work already done. A Bot that has sent three emails and is asking about the fourth is asking about the fourth.
That single sentence should shape how you set boundaries. Approval is a gate on the next step, never an undo, so the useful question is not "will it ask me" but "what will already have happened by the time it does".
Three mechanisms decide: not a list
What stops depends on the tool, the risk of the action, and your own rules. Three separate things can produce a stop:
- The model's judgement. Sensitive or consequential actions can pause on their own. Useful, but a judgement call is not a guarantee, and you should not design around it.
- Your Auto Review rules, described below: the deterministic layer.
- Boundaries in the Bot's description. Standing rules in a Bot's profile ("Never send external messages without approval") sit in its context for every task. This is the durable place for a rule, as opposed to a single message.
Categories the documentation repeatedly says to put behind an explicit boundary: sending messages or invitations, publishing, purchases and transfers, deleting or overwriting, permission changes, production changes, and accepting legal terms.
Auto Review: and the trap in it
Auto Review evaluates tool calls and computer actions before they run. It takes two kinds of rule, and the second is easy to misread:
- Require Approval: matching actions always stop.
- Always Allow: matching actions proceed only if the automated review finds no other reason to stop. It is not an unconditional bypass, which is better than it sounds: your allow rule cannot fully disarm the safety check.
Where the two collide, Require Approval wins. That is also the first thing to check when an action keeps stopping despite an allow rule: look for a matching require rule rather than assuming a bug.
Two more properties worth knowing before you rely on it:
- The rules live on the desktop you wrote them on, synced to that installation's computer. They are not account-wide policy. A second machine has its own set, and you have to verify it separately.
- It is model-based, and the documentation positions it as a complement to least privilege rather than a replacement. Broad rules like "allow everything in the browser" are called out as an anti-pattern, because the sites behind them change.
Your laptop is governed separately
Running commands or reading files on your local machine is its own setting, with three states: require approval every time, always allow, or never allow. The default asks each time; the documentation's own recommendation is to disallow it unless a Bot has a specific reason. It has no bearing on what the Bot does on its cloud computer.
Passwords: codes and CAPTCHAs
Some steps are not approvals at all; they are handed back to you. Passwords, passkeys, two-factor codes, CAPTCHAs, payment and identity checks, and sites that demand a human all work by taking over the computer yourself, completing the step, and handing control back.
Do not paste a password or a one-time code into the chat. It is stated in the docs three times over, and the reason is simple: the transcript is not the place for a credential. Where a connection supports a secure secret request, the value is masked, kept out of the transcript and not shown to the model, but that is a narrow feature, not a password manager.
Approving well
- Read the target and the arguments on the card, not just the verb. "Send email" and "send email to 400 people" look identical at a glance.
- If you cannot tell what an action will affect, ask for a plain-language explanation or a draft first. That is a normal thing to do.
- Prefer briefs that end one step earlier ("draft, don't send") until you have watched a task run cleanly several times.
What changes
Auto Review availability is conditional and team-level enforcement is evolving, including a local-execution ceiling described as coming. Check the current documentation before assuming a control exists on your plan.
