Auto-Review: The Safety Net Between a Dot and a Consequential Action

Writing a good rulebook is only half the safety problem for an always-on agent. The other half is enforcement: something has to actually check a proposed action against that rulebook, in real time, before the action executes — and do it reliably enough that the rulebook means something in practice. OpenAI's answer is Auto-Review, described as checking a dot's "potentially consequential actions" against the user's own instructions, their Custom Rules, and OpenAI's built-in safety requirements — all before that action is allowed to run.

Three things it checks against, not one

It's worth being precise about the three-part check, because each piece is doing a different job. Checking against the user's own instructions catches actions that might be technically permitted by the rules but still don't match what the user actually asked for in this specific task — a dot correctly avoiding a rule violation while still doing something the user didn't intend. Checking against Custom Rules is the more literal compliance check — does this action fall into an approve, ask, or block category the user configured. Checking against OpenAI's own built-in safety requirements is the floor beneath both of those — a backstop that exists regardless of what the user's instructions or rules say, presumably covering the same category of hard-blocked sensitive actions (like password changes) that sit outside Custom Rules entirely.

That layered structure means Auto-Review isn't simply "did this violate a rule." It's closer to a three-part sanity check, run automatically, on anything a dot is about to do that clears some threshold of consequence.

What counts as "potentially consequential"

OpenAI hasn't published a precise, exhaustive definition of what triggers Auto-Review versus what a dot can simply execute without a checkpoint. The examples that have surfaced — sending an external communication, taking an action that affects a shared resource, modifying something other people depend on — suggest the threshold is roughly "anything with an effect outside the dot's own sandbox that would be hard to quietly undo." That's a reasonable design principle, but it's also a judgment call the system has to make on a case-by-case basis, and the specifics of where that line actually falls aren't detailed publicly as of this writing.

The value of a review gate isn't that it exists. It's whether it correctly identifies the 5% of actions that actually needed a second look — and Auto-Review's real track record on that is something no one outside OpenAI can verify yet.

The honest limitation here

This is worth stating plainly rather than glossing over: OpenAI has not published independent testing, error rates, or failure-mode analysis for Auto-Review. We don't know, from public sources, how often it correctly flags something that should have been stopped, how often it lets through something it shouldn't have, or how often it over-triggers on genuinely benign actions in a way that would frustrate users into disabling stricter settings. That's not a criticism unique to OpenAI — none of the three companies covered in this series has published that kind of rigorous, third-party-verifiable safety data for their new agent products — but it means Auto-Review, right now, is a described mechanism rather than a benchmarked one. Treat claims about its effectiveness, including implicitly optimistic ones in this article, with that caveat attached.

Where a human still has to look: the Activity View

Auto-Review handles the automated check; the Activity View is where a human can actually inspect what a dot has been doing and intervene directly, rather than relying entirely on the automated gate. Together, the two form a reasonable defense-in-depth structure: rules define the boundaries, Auto-Review checks specific actions against them, and the Activity View gives a human a way to catch anything that slipped through or that they simply want to review after the fact. We look at how much oversight that actually amounts to in practice — and whether checking an Activity View regularly is a realistic habit for most users — in The Activity View: How Much Oversight Is Actually Practical?

How this stacks up against Sentinel and Grok Bot's approach

The closest analog among this week's launches is Meta's Sentinel, a dedicated separate agent that approves, blocks, or escalates every connected-app action and outbound network request a Muse agent attempts, running inside the same isolated VM. That's a more continuous, always-in-the-loop model than Auto-Review's threshold-triggered checkpoint — Sentinel checks essentially everything with external effect, while Auto-Review appears scoped specifically to actions crossing a "potentially consequential" bar. xAI's Grok Bot, by contrast, requires explicit approval for certain tasks per its own materials, but doesn't have a comparably formalized, named review layer in the sources available for this series — a gap worth flagging rather than filling in with assumption.

Whichever architecture proves more robust in practice, all three converge on the same underlying admission: none of these companies is comfortable letting an always-on agent act entirely unchecked, and all three have built some form of automated second look before consequential actions actually execute. That convergence, more than any single feature, might be the most reliable signal in this entire product category about where the real risk is understood to live — squarely at the moment an agent's judgment turns into an action nobody can quietly take back.

The tradeoff a review gate always makes

It's worth naming the cost side of Auto-Review plainly, because every review gate makes the same fundamental tradeoff: catching more genuinely risky actions almost always means adding friction to some legitimate ones too. A gate tuned aggressively toward caution will occasionally stop a dot from completing something entirely reasonable, forcing a user to manually approve something that, in hindsight, never needed a second look. A gate tuned loosely toward convenience will let more through without a checkpoint, including, eventually, something that should have been caught. OpenAI hasn't published where Auto-Review sits on that spectrum by default, or whether users get any control over how aggressively it triggers — a genuinely useful lever to have, if it exists, and a genuine gap if it doesn't.

That tradeoff is also why the honest framing for Auto-Review isn't "solved" versus "unsolved" — it's an ongoing calibration problem that will likely need real-world tuning based on actual usage patterns, complaints, and incidents, the same way spam filters and fraud-detection systems needed years of iteration before their false-positive and false-negative rates stabilized into something users could live with. Anyone deploying a dot for genuinely important work should expect Auto-Review's behavior to shift over the coming months as OpenAI gathers exactly that kind of feedback, rather than assuming the launch-day version is the final one. It's also the exact moment where the next dot use case in this series — a developer's dot watching feedback and filing pull requests overnight — puts Auto-Review to its first genuinely practical test.

Part 10 of 30 in the ChatGPT Dots series. Previously: Custom Rules: How Dots Learn What They Are Allowed to Do. Next: The Developer's Dot: Watching Feedback and Filing PRs While You Sleep. Browse more builder insights or explore AI skills at aiskill.market.