Grok Bot vs a Dot: both have a cloud computer. What do you approve before each one acts?

Before Grok Bot acts, you approve the action it just proposed, or a rule you already saved that matches it. The conversation shows the operation and its inputs. On the approvals page the choices are Allow once, Always allow, and Deny, and that page says the controls are the same on iPhone. Before a Dot acts on something sensitive, an automatic review checks your instructions, app permissions, custom rules, and built-in safety, then it either proceeds, asks, or hands the step to you. Changing a password or transferring money is in the hand-off pile: the privacy FAQ says you take over and finish those yourself. A cloud computer is not permission. Each product still has a separate yes for the accounts and the machine it may touch.

The two yeses are not interchangeable. Grok Bot’s card is about one proposed operation on a computer every Bot on the account shares. A Dot’s rule is an instruction about a kind of action, and it cannot grant an app or remove a confirmation OpenAI kept for itself.

What is on the Grok Bot card?

The proposed operation, and the inputs. Read the target, the scope, and the values before you tap anything. Allow once lets that action continue. Always allow can save a matching rule so a later action that matches does not ask again. Deny blocks it. The security page describes the phone differently: on iPhone and Android it says the controls are Approve once and Deny. I am not going to collapse those into one label. The approvals page says the desktop trio is also what iPhone shows. The security page names a shorter pair and includes Android. Look at the card in front of you. If Always allow is not on it, you do not have a saved rule from that tap.

An approval covers the action on the card, not work the Bot already finished. The security page says nobody should approve an action whose target or effect they cannot identify. That is the useful test. “Send the note” is not identifiable if the card does not show who receives it. “Run this” is not identifiable if the command is a blob you did not read. Deny is the right control there. Allow once is for an action you can point at. Always allow is for a narrow match you are willing to see again, not for a mood.

Auto Review sits behind the card. With it on, Grok Bot evaluates tool calls and computer actions before they run. The security FAQ lists what that review covers: shell commands, plugin calls, computer use, automation writes such as changes to routines and event triggers, and delegation such as a Cloud Agent or a subagent launch. It can let the action proceed, require approval, or deny it. It does not review every side effect. Memory writes and most settings changes are named as examples it skips. Enforcement is on for users as of the security page, and each member’s own Auto Review setting is the off switch. An organization-wide lock exists for Enterprise, not as a personal default I would assume.

Rules you add are under Settings, then General, then Auto-review. The approvals page calls the two kinds Ask first and Allow automatically. Ask first always stops a match for you. Allow automatically lets a match proceed only when the review does not find another reason to stop. If both match, Ask first wins. The security page uses Require Approval and Always Allow for the same split, and it says Require Approval wins. Same idea, two vocabularies, both on official pages. Write the rule around one action and one place. The docs’ own examples are the right size: ask first before sending any external email, ask first before changing a production dashboard, allow automatically when running a status command in a specific folder. The example they tell you to avoid is a broad “allow everything in the browser.” Personal rules are stored on the current desktop and synced to its Grok Bot computer. Another desktop needs its own.

What do you approve for the computer itself?

The cloud computer and your computer are different approvals. Bots work on a shared cloud computer by default. Local execution is separate. In Settings, under General, then Bot, then Execution on Local Computer, the choices are Ask every time, Always allow, or Never allow. The default is Ask every time. Once the account has registered computers, the choice moves to Settings, then Computer, then Computers, and each computer has its own Execution on this computer setting. These settings do not stop the Bot from using the cloud computer. Never allow is the setting the docs suggest unless a Bot has a specific reason to touch your files. A team admin can cap it. When the team’s policy is stricter, the team’s applies.

The first time a Bot wants a command on your machine, the conversation shows a specific question: Allow Grok Bot and all Bots to run commands on your local computer? The choices are Always allow, Allow once, Never, and Deny once. Always allow and Never set Execution on Local Computer for every Bot. You can change that later in Settings. If a team ceiling is stricter, Always allow is unavailable. Read the “all Bots” part. You are not approving the one conversation. You are deciding whether every Bot on the account may run on that machine.

That shared machine is why a second Bot is not a second approval boundary. Your Grok Bots share one cloud computer and its logins. Allowing a browser action, or leaving a site signed in, is visible to the other Bots on the account. Approving a careful Bot does not fence off an eager one. If the job should stay with one actor, keep the login off that computer.

Passwords, passkeys, two-factor codes, CAPTCHA prompts, and payments stay on the computer screen. The mobile docs say to open the computer and take control for a password, a two-factor code, or a CAPTCHA. Do not type those into the ordinary chat. The teams page says the same thing as a habit: never paste credentials into chat, and prefer Allow once over Always allow for actions that touch accounts, money, or shared resources. Taking control is you doing the secret step. It is not a mode that teaches the Bot the secret for next time.

What does a Dot ask you to approve?

The app, first, and then the action. Connecting a plugin is what lets the Dot touch that service. Custom rules do not grant the app, and they do not remove a confirmation OpenAI kept. The learn page says a saved custom rule can permit a particular action, require a check, or tell the Dot not to take an action, and that rules are instructions it tries to follow and can get wrong. They do not grant access to an app or a computer, they do not override built-in safety, and they do not remove required confirmations such as approval to use a saved login.

The rule labels are not identical on every official page, so I will quote both. After setup, the learn page says you open Settings, then Personalization, then Custom rules, describe the action, and choose one of four: Take action without asking, Take action when you say so, Ask before taking action, or Hand off to you. “When you say so” means it proceeds when you explicitly request that action and otherwise asks immediately before acting. The getting-started help article, on the mobile path Customize then Custom rules, lists Take action without asking, Take action if pre-approved, Ask before taking action, and Hand off to you. It defines pre-approved as an action you explicitly requested in your prompt. If your screen says one of those middle labels, use that definition. I am not going to tell you a fifth label exists.

Built-in safety is stricter than the menu. The privacy FAQ says the most sensitive actions, like changing a password or transferring money, require you to take over and complete them yourself. Other actions, like permanently deleting data or installing software, may require approval each time. Some cases, such as sending recurring messages, can be approved in advance instead of each time, and that advance approval stays limited to what you authorized. Approving one message does not give ongoing permission to send. Custom rules cannot turn off the takeover for a password change. They also cannot turn off the separate safety review, which the FAQ calls Autoreview, or the restrictions on proactive research.

Before the Dot takes an action that could affect your accounts or share information, the learn page says an automatic review checks it against your instructions, permissions, custom rules, and built-in safety. The review decides whether the action can proceed, needs your approval, or includes a step you must do yourself. The example it gives is that you must change a password yourself. That review is not the same object as a Grok Bot Allow once card. You may never see a three-button bar. You may see a request to take over, or the action may simply wait. If you cannot tell what is about to happen, do not treat silence as a yes. Open the task and look.

What should stay a human step on both?

Anything that spends money, changes a password, or sends on your behalf to a person you did not name. For Grok Bot, that means Deny or Allow once after you have read the recipient and the body, and it means taking control on the computer for the secret rather than pasting it. For a Dot, that means Hand off to you, or simply doing it yourself, because a rule that says take action without asking is an instruction the Dot can misread and a rule that cannot override a takeover anyway. Drafting is not sending. If you only wanted a draft, say that the send is yours. A connected mailbox that includes send is a loaded app. Connect read when the job is reading. Leave send off until a specific message is one you intend to approve.

Leave the local computer disconnected unless the files are there and nowhere else. Grok Bot’s cloud computer already runs with the laptop shut. The local prompt is an extra door, and the first yes can cover every Bot. A Dot’s local access starts off, needs the ChatGPT app open on that machine, and is revoked by Revoke access, not by closing a chat. Neither product needs your laptop in order to act on its own cloud computer. Approving the laptop is a separate, larger yes.

Do not approve a card, or save a rule, in order to make an agent ignore a boundary you wanted. If a prompt inside a page or a message is pushing the agent toward a send, a payment, or a password field, the approval is the stop, not a step to complete. You can read the proposal. You do not have to make it true.

Which yes do you actually owe each one?

For Grok Bot, owe a read of the operation and its inputs, then Allow once, Always allow only for a narrow match, or Deny. Owe a separate decision for your own computer, defaulting to asking every time or to never. Owe the secrets to the takeover screen. For a Dot, owe the app connection with the smallest actions on it, then a custom rule only where you want a standing boundary, and owe password changes and money transfers to yourself. A rule is not a grant. A shared cloud computer is not a private one because you approved a single Bot.

Both will still make mistakes inside the permission you gave. The docs on each side say so. The approval is how you keep the mistake in a draft instead of in someone else’s inbox.