Four Settings, One Dot: How Custom Rules Actually Gate an Action

When dots launched in September, Custom Rules were described at a fairly high level: a mechanism to pre-approve, block, or require sign-off on categories of action. A third-party guide to dots' inbox and permission mechanics, cited earlier in this batch for the email-specific details, fills in the actual structure underneath that description — and it's more granular than "pre-approve or block" suggests. Per that guide, Custom Rules offer four distinct settings, applied per action, not one global switch.

The four settings

The first is act without asking — a dot performs the action and tells you about it afterward, if at all, with no gate in front of it. The second is act only if pre-approved — functionally similar, but scoped to actions you've specifically whitelisted in advance, rather than a blanket "go ahead" for everything in that category. The third is ask before acting, which puts a confirmation step in front of every instance of that action, every time, with no accumulation of trust across repeated approvals — a detail that matters, because approving one message doesn't grant ongoing permission for the next one. The fourth is hand off to you entirely — the dot stops short of attempting the action at all and routes the decision to you from the start, rather than drafting something and waiting for a yes.

That's a meaningfully different design than a single risk dial running from "cautious" to "permissive." It lets you set, action by action, exactly where on that spectrum a given category of behavior sits — sending an email might be "ask before acting," reading a file might be "act without asking," and anything touching a payment method might be "hand off to you" regardless of how comfortable you've gotten with the dot elsewhere.

Where this sits next to Auto-Review

Custom Rules aren't the only check in the stack. Auto-Review — the background process that checks a planned action against your instructions and rules before anything executes — runs on top of whatever Custom Rules setting applies, verifying the specific details of the action (who an email is going to, what a file edit actually changes) rather than just the category of action itself. The two work together: Custom Rules decide how much friction a category of action should have, and Auto-Review decides whether this specific instance of that action looks consistent with what you've asked for and approved.

Four settings per action, not one setting for the whole dot, is the difference between a permission system you configure once and one you have to keep fighting with.

The difference between "act without asking" and "act only if pre-approved" is easy to miss

Of the four settings, the first two sound similar enough on a first read that it's worth being precise about the distinction, because conflating them would misrepresent how much control you actually retain. "Act without asking" is an open-ended category permission — any action that fits the category goes ahead, with no additional check against a specific allowlist. "Act only if pre-approved" narrows that down to a specific set of actions you've named in advance; a dot can act without asking for those specific things, but anything in the same broad category that falls outside your pre-approved list gets treated differently, presumably escalating to one of the stricter settings. The first trusts a category; the second trusts a list. That's a meaningfully tighter form of autonomy, and it's the kind of distinction that's easy to flatten into "basically the same thing" if you're skimming rather than actually configuring your rules.

Why granularity is the right design here

A single global permission level — fully autonomous or fully supervised — would force an unworkable trade-off: either you accept more risk than you want on your riskiest actions to get convenience on your safest ones, or you accept friction on every low-stakes action to keep your high-stakes ones gated. Per-action granularity avoids that trade-off, at the cost of requiring you to actually think through your rule set rather than accepting a single default. That's consistent with the broader oversight philosophy this series flagged as the real test of these products over the coming year — oversight only works if someone keeps using it, and a rule system fine-grained enough to match real risk levels is a better bet for sustained use than a single dial most people would eventually just leave on "permissive" out of fatigue.

What's still unconfirmed, per the same sourcing, is whether this permission model extends cleanly to third-party plugins the way it does to native actions like email — pending testing, per that guide, rather than settled either way. The plugin ecosystem OpenAI described at launch, spanning more than 4,000 applications, is wide enough that a uniform four-setting system applying consistently across every one of those integrations would be a genuinely impressive engineering feat — and also wide enough that inconsistent behavior across plugins, at least early on, would be unsurprising. Neither outcome has been confirmed yet.

What is settled is the scope these rules are built for in the first place: a single person's standing permissions over their own dot, not a shared team configuration. A rule set this granular is also only as good as the person configuring it — a Custom Rules setup left on defaults, or set once at onboarding and never revisited as a dot takes on new kinds of tasks, provides much less real protection than the same system configured deliberately. The sophistication of the permission model doesn't do much if nobody actually uses it, which is exactly the oversight-fatigue risk this series flagged as a year-long open question — the subject of the next article in this batch.

Part 37 of 47 in the ChatGPT Dots series. Previously: No Standalone Email Address Yet: The Gap Between a Dot and a Coworker. Next: Why a Dot Isnt a Team Inbox Agent, and What That Rules Out. Browse more builder insights or explore AI skills at aiskill.market.