Grok Bot approval rules: why require-approval wins
Require Approval beats Always Allow when both match in Grok Bot. How to scope an approval, why one computer per account matters, what never to delegate.
Grok Bot approval rules come in two kinds, and one always wins. xAI’s security page says “Require Approval rules always stop matching actions for you,” “Always Allow rules let matching actions proceed only when the automated review does not identify another reason to stop,” and “if both kinds of rule match, Require Approval wins.” The docs then tell you how to write them: “narrow rules around a known action and scope,” never “allow everything in the browser.”
That is the platform. What follows is how a template should use it, and what a template should refuse to delegate at all.
Which rule wins when two match?
Require Approval. The docs say so in one sentence, and it changes how you write the rest. Because the stop rule beats the allow rule on conflict, you can write allow rules narrowly and leave broad deny rules standing. An Always Allow for “post the Monday forecast to #revops” and a Require Approval for “anything that sends outside the company” coexist, and the second one wins whenever both match. The broad rule protects; the narrow rule saves clicks.
The reverse design, broad allows with narrow denies, fails the moment an action matches an allow and no deny. The docs’ own example of what not to write is “allow everything in the browser.”
| Rule | What it does | How to write it |
|---|---|---|
| Require Approval | Always stops matching actions | Broad. Anything external, anything that spends, anything that alters a production record |
| Always Allow | Proceeds only if automated review finds no other reason to stop | Narrow. One known action, one known scope |
| Both match | Require Approval wins | So the broad deny can stay |
Scroll sideways for the third column on a narrow screen.
What is the approval-scoping rule?
The approval-scoping rule is one sentence that belongs in every Grok Bot template: approval applies only to the exact action, target, scope, version, configuration, connection, permission and schedule it was given, and is never inferred from silence, vague agreement, a previous approval, another version, or an example. xAI’s docs point the same way when they ask for rules “around a known action and scope,” but the sentence does the work inside the bot’s own instructions, where the model reads it before every consequential step. Without it, a bot that was allowed to email one customer on Tuesday reasons that it may email a similar customer on Thursday. With it, Thursday’s email is a new approval. It is the single best sentence in the free ecosystem, because it turns “the human said yes once” into “the human said yes to this.” Every Botemplate bot carries it, and the release gate checks that the whole block survives the paste.
Why does one computer per account change the rules?
Because a permission is not per bot. xAI’s computer page says “the computer is assigned to your user account, not an individual Bot,” that “browser cookies and signed-in sessions are shared,” “files are visible to every Bot,” and “installed connectors are account-wide.” The FAQ says it plainly: “Every Bot on your account uses one persistent cloud computer. They share its files, browser sessions, and logins.” And the security page draws the conclusion: “Do not use separate Bots as a security boundary.”
Two consequences for anyone running more than one bot.
First, if you need an access boundary between two jobs, run them under different accounts. Botemplate’s collaboration edges between Ledger and Backstop work only when one account owns both, and the pack says out loud that sharing a computer is not a security boundary: bots on one computer share every session and connector that computer holds.
Second, a file another bot wrote is untrusted input. Any bot on the computer can write it, including one you did not install, and a well-formed lie is undetectable. So a consumer bounds what such a file may change rather than pretending to catch a bad one. In the pack, sibling data may never cause an external action, never remove a finding from a human’s view, and never widen a bot’s audience or authority. The only thing an edge is permitted to do is add one advisory row to a decision a human already owns.
What should a template never delegate?
Some actions stay with a person at every authority level, and the docs name the first set: “for passwords, passkeys, two-factor codes, CAPTCHAs, and payment confirmations, the Bot should hand you control of the computer.” A template that promises to handle any of those is promising something the platform is built to refuse.
The pack adds its own list, and it is a term of the license rather than a default. Every Botemplate bot requires human approval before it contacts a customer or vendor, spends money, or alters a production record. Beyond that, each bot has actions it never takes at all:
- Bellwether writes to the CRM only with approval and reads Gmail only.
- Ledger holds no write scope on any source system, and never contacts a customer about an invoice it has not reconciled in the last 24 hours.
- Quartermaster never speaks to a vendor. The owner sends every message from their own mailbox.
- Backstop builds the change-order case and stops. It never sends one.
- Waterline returns a price floor and a recommendation. It never returns a price change.
Removing a gate is the buyer’s right, in their own account, on their own authority. Selling a template with the gates already removed is the one thing this catalogue will not do, no matter who asks, because the gates are what make a bot safe to run against real money.
Where do the rules live in a template?
In three places, and the order matters. The bot’s instructions carry the authority boundary as three lists, never, needs approval, may do alone, plus the scoping sentence, and they sit early in the block so that truncation loses procedure before it loses permission. Each skill’s sixth section, what requires approval, names the stops for that skill; the skills guide covers the format. Each routine’s fifth field, the approval boundary, names them for that run. Then the account-level Require Approval rules stand behind all of it, and win on any conflict.
Two of the acceptance tests every Botemplate bot ships are about exactly this. Contradictory source data must escalate rather than reconcile. And an attempt to talk the bot past an approval boundary must fail. A buyer runs both on day one, with sending disabled, before the bot is anywhere near a customer. How it works describes that hour, and the Operator Pack is the five bots, with their gates, for $69.