Custom Rules: How Dots Learn What They Are Allowed to Do

An agent that only acts when you're watching doesn't need much of a permission system — you're the permission system, in real time, every time. A dot, by definition, spends most of its useful time acting when you're not watching. That's the entire premise of "always-on," and it means OpenAI had to build something a session-bound chatbot never needed: a standing rulebook a dot consults before it acts, rather than a human it asks in the moment.

That rulebook is Custom Rules — settings that let a user pre-approve certain categories of action, require explicit approval before others, and flatly prohibit the rest, all configured ahead of time rather than negotiated task by task.

What a rule actually governs

The categories OpenAI has described are broad but directionally clear: some actions can be marked as fine to execute without checking in at all (drafting a document, running a read-only search); others as requiring a stop-and-ask before execution (sending an external email, modifying a shared file); others as off-limits entirely regardless of context. The specificity of how granular these rules can get — whether you can scope a rule to a particular app, a particular type of recipient, a particular time of day — isn't fully detailed in the sources available as of this writing, and that granularity is exactly the thing that will determine whether Custom Rules feel like a genuinely useful control surface or a blunt instrument in practice.

What is confirmed is the philosophy: rather than asking a user to approve every action in real time — which would defeat the entire point of an agent that works while you're not there — OpenAI is asking users to specify their preferences in advance, then trusting the system to apply those preferences consistently across whatever situations actually come up. That's a fundamentally different interaction pattern from typical chatbot consent flows, and it puts a lot of weight on the user actually configuring rules thoughtfully rather than accepting defaults and hoping.

The floor beneath the rules: things no rule can override

Some categories of action sit outside the Custom Rules system entirely. OpenAI has said sensitive operations — changing a password is the specific example given — are reserved for a human no matter how the rules are configured. That's a meaningful design choice: it means Custom Rules aren't the only safety layer, and there's a hard-coded floor of actions a dot simply cannot be granted, regardless of how permissive a user tries to make their configuration. We think that's the correct call, and it's worth noting explicitly rather than assuming Custom Rules are infinitely flexible.

A rulebook only protects you as well as you wrote it. The floor beneath the rulebook — actions no configuration can unlock — is what protects you from the rules you didn't think to write.

How this interacts with proactive research

Custom Rules also intersect directly with one of the more distinctive dot features: proactive research, background monitoring that runs even when a dot isn't actively tasked. OpenAI has scoped that background mode specifically to read-only tools — a dot researching in the background cannot send a message, edit content, or take control of a browser or computer, regardless of what its Custom Rules otherwise permit. That's an important detail: it means the read-only restriction on proactive research functions as its own separate boundary, layered on top of Custom Rules rather than governed entirely by them. Even a user who configures very permissive rules for active tasks doesn't thereby unlock write access for a dot's unsupervised background activity.

Auto-Review as the second check

Custom Rules set the boundaries in advance; Auto-Review is the mechanism that checks a dot's actual proposed actions against those boundaries — plus the user's broader instructions and OpenAI's own built-in safety requirements — before anything potentially consequential actually executes. We cover that check specifically, and the practical question of how much friction it introduces versus how much risk it actually catches, in Auto-Review: The Safety Net Between a Dot and a Consequential Action. The short version for this article: rules and review are two different layers doing two different jobs — one defines what's allowed, the other checks whether a specific action actually complies before letting it through.

How this compares to the other two launches

This is also where OpenAI's approach looks most different from its two rivals this week. Meta's Muse runs a separate agent, Sentinel, that approves or blocks every connected-app action and outbound network request from inside an isolated VM — a more centralized, always-in-the-loop check rather than a pre-configured rulebook the agent consults on its own. xAI's Grok Bot, by contrast, doesn't appear to have an equivalent formal rules system at all in the sources checked for this series — it requires explicit approval for certain tasks, per xAI's own materials, but without the structured, user-configurable rule categories OpenAI has built out. Whether a pre-configured rulebook, a live-approving second agent, or an ad hoc approval prompt turns out to be the more resilient safety architecture is a genuinely open question, and one worth revisiting once real-world incident reports — rather than launch-day feature lists — start to accumulate across all three products.

For anyone building on Claude Code Skills rather than any of these three agents, the closest analog isn't a rules engine at all — it's the fact that a skill's entire capability surface is inspectable and scoped by design, checked in code review before it's ever installed, rather than governed at runtime by a rulebook the agent consults on the fly. Different problem, same underlying goal: know, in advance, what the thing you're trusting is actually allowed to touch.

That difference in when the safety decision gets made — up front, at install time, for a skill; continuously, at execution time, for a dot's Custom Rules — is worth sitting with as a general pattern rather than a quirk specific to either product. A skill's model is cheaper to audit precisely because the decision is made once, in a form a human can read directly. A dot's model is more powerful precisely because the decision gets re-evaluated against every new situation the agent encounters, without a human having to anticipate every scenario in advance. Neither approach is strictly superior; they're suited to different shapes of risk, and understanding which shape you're actually dealing with is a better starting point than assuming one safety architecture is simply more mature than the other.

Part 9 of 30 in the ChatGPT Dots series. Previously: Naming Your Dot: Personalization as a Trust Mechanism. Next: Auto-Review: The Safety Net Between a Dot and a Consequential Action. Browse more builder insights or explore AI skills at aiskill.market.