Approval needs a budget of attention.

Three approval slips lie on a desk, each stamped in the same gold ink. The first let a coding agent run a project's tests. The second let it upload a file called customer_export.csv to an address outside the company. The third asked to post the project's build logs to a public website, and that one was refused. The slips are invented for this dispatch; the question they raise is not. The first two stamps are identical, and so was the attention behind them: a person glanced at a line of text and clicked. One of those clicks mattered far more than the other, and nothing on the paper shows it.

Last Thursday, April 30, OpenAI's alignment team described a feature it calls Auto-review, released the previous week in Codex, the company's coding agent. Codex normally works inside a sandbox: it can read files, edit within a designated folder and run local commands, and anything outside those limits, often something as mundane as a network call, waits for a person to approve it. Auto-review replaces that person, at that boundary, with a separate agent that grades each request against the user's intent, the environment, the security policy and the likely impact. The team's reason for building it is the interesting part. Frequent approval requests, it writes, push people toward worse choices: switching the sandbox off entirely, writing broad rules such as allowing any command that begins with the word python, or approving commands they do not fully understand, out of inexperience, fatigue or both.¹

That observation reaches well beyond coding agents. My argument is that an approval system should be judged by where it sends attention, not by how many approvals it records. Approval events are easy to count: a request, a click, a stamp, a line in a log. Effective scrutiny is harder to see: someone, or something, examined the information that mattered and reached a decision that fit the consequence. Asking a person to approve every routine action produces many events and can leave very little scrutiny, because attention spread across everything lands on nothing in particular. An automated reviewer can help put attention where it belongs. It is not a guarantee, and OpenAI does not claim one. It is a fallible control, and it needs a defined scope, honest evaluation and limits that hold whether or not its judgment does.

A click is not a decision

A control can be present and still not work. The click is the observable part of an approval, which is exactly why it gets counted. Logs record that an action was approved, by whom and when. They rarely record what the approver saw, how long they looked, or whether they could have understood the consequence if they had looked longer. So the number of approvals tends to become the measure, and a rising count reads as diligence.

The count and the scrutiny can move in opposite directions. Each routine request takes a little attention from the next one, including the next important one. In 1975, Jerome Saltzer and Michael Schroeder set out a short list of design principles for protecting information in computer systems, and one of them was psychological acceptability: the human interface should be easy to use, they wrote, "so that users routinely and automatically apply the protection mechanisms correctly."² An approval prompt that people learn to dismiss fails that test, however strict it looks in a policy document. So does a prompt that people route around, which is what OpenAI found when users wrote rules permitting whole families of commands so they would stop being asked.¹

Spend attention by consequence

If attention is scarce, it should be budgeted, and the natural way to budget it is by consequence. What follows is my own proposal, not a finding of OpenAI's study, though it has a similar shape. It has three tiers.

Routine actions inside enforced limits run without asking. Running tests, editing files in the working folder and reading documentation are permitted because the boundary makes them safe enough, not because anyone reviews them. This is Saltzer and Schroeder's principle of least privilege: every program and every user should operate with the smallest set of privileges the job needs, chiefly to limit the damage an accident or error can do.²

Uncertain actions at the boundary are reviewed. Fetching a software package, calling an outside service or changing a configuration may be fine or may not, depending on context. This is the tier where an automated reviewer can earn its place, because the volume is too high for a person to read every request carefully and the cases are too varied for a fixed rule.

High-impact actions require a named person's decision. Sending customer records outside the organization, deleting production data, moving money and changing who has access are the kinds of action where an organization should want a specific, accountable person to have seen the evidence and said yes. Which actions belong in this tier is a business decision, not a technical one, and the list will differ between a research lab and a hospital.

OpenAI's account shows how lopsided such a budget can be. In what it labels an illustrative snapshot of 10,000 actions from its internal deployment, 9,280 stayed inside the sandbox and 720 crossed the boundary. In manual mode, each of those 720 would have interrupted a person. Under Auto-review, 713 were approved, 4 were refused and continued by a safer route, and 3 stopped to ask the user.¹ The company cautions that the ratios depend on the use case, the environment and how the sandbox is configured. The shape is still the point. Three requests reached a person instead of 720, and those three arrived with a reason attached.

Show the reviewer the consequence

A tier is only as good as what the reviewer is shown. A command string is written for a machine. It can tell an engineer exactly what will run and tell a business owner almost nothing about what will happen. Asking a finance director to approve an upload command followed by a web address and a file name is asking for a click, not a judgment.

For the requests that reach a person, the request should carry five things in plain words: the purpose, meaning what the action is for; the data or system it touches; where anything is going; whether it can be undone; and what is expected to happen if it runs. The third slip in Figure 1 has those fields filled in, and it is the one where the reviewer saw enough to say no. The refusal also reflects something OpenAI reports. A denial in Auto-review comes with a rationale, and in the internal deployment Codex continues after a denial and finds an acceptable path in more than half of cases.¹ On the slip, the logs went to the project folder instead. A safe alternative will not always exist, and when it does not, the work should stop; Auto-review automatically ends a session after repeated denials, partly to keep the agent from trying to wear the reviewer down.¹

Keep the gate apart from the judgment

The most important structural choice is easy to overlook. The reviewer's judgment and the mechanism that enforces the boundary are different things, and they should stay different. A reviewer can recommend; the boundary decides what is possible. If the main agent could obtain the credentials it needs by persuading the reviewer, or if an approval quietly granted new standing permissions, the judgment would have become the boundary, and a fallible judgment would be holding up the whole structure.

OpenAI explains its separation in terms of incentives. The main agent is optimized to finish the user's task, which creates pressure to treat an approval boundary as one more obstacle. The reviewer has a narrower job: decide whether one proposed action should run.¹ That is sound reasoning, but it is not independence. Two model calls are not two independent checks merely because they are separate calls. A reviewer can share the main agent's blind spots, and it can be misled by the same untrusted text that misled the agent. The team says so directly. In red-teaming it found cases where Auto-review could be misled into approving commands, and it writes that "Auto-review should not be treated as a guarantee of security."¹

Saltzer and Schroeder's principle of complete mediation holds that every access to every object must be checked for authority.² An automated reviewer is not complete mediation; it sees only what is brought to the gate. A model that is hiding its intent, OpenAI's team notes, may produce a request that looks harmless, or may act inside the sandbox in ways Auto-review never sees.¹ That is why Figure 2 draws the monitoring record as its own sheet, apart from the gate, and why some controls must stay deterministic. A database the agent holds no credentials for cannot be deleted by a persuasive argument.

Measure the misses, not the stamps

If the number of approvals is the wrong measure, four others matter more. The first is dangerous actions that were approved anyway. It is the failure the control exists to prevent and the hardest to observe, because finding it means testing with cases where the right answer is already known. The second is unnecessary interruptions, because they are what drains attention from the important ones. The third is overrides: how often people reverse the reviewer, in which direction, and on what kinds of action. The fourth is the set of actions outside the reviewer's view, which no approval rate can describe.

OpenAI's evaluation follows roughly that shape. It measures usability through acceptance rates on internal traffic, and safety on synthetic datasets built to include dangerous scenarios that ordinary internal traffic rarely contains: an agent that overreaches to finish a task, an agent hijacked by injected instructions, and a model deliberately trying to carry out a malicious task covertly. On the synthetic overreach cases, which cover unintended data transfer, weakened security settings and irreversible operations, the reviewer correctly denied 90.3 percent.¹ In production, the team says it monitors how often actions are escalated, approval and rejection rates, added delay, user overrides and the commands most often flagged.¹

A figure like 90.3 percent should be read for what it is: the share of one developer-built test set, for one category of threat, that the reviewer caught. It is not the probability that a given deployment is safe, and it does not carry over automatically to another organization's systems, data or attackers. An organization adopting a reviewer of this kind should build its own version of the test: a set of actions it already knows should be refused, run through the reviewer on its own configuration, and run again whenever the model or the policy changes.

Objections, considered

An automated reviewer can be fooled. It can, by the same untrusted content that fools the agent it reviews, and it can share that agent's blind spots. That is the reason it belongs behind an enforced boundary rather than in place of one, and the reason the highest tier still goes to a person. The fair comparison is not with a perfect human reviewer. It is with the tired one who approves the upload after two seconds.

Some decisions need a person regardless. Yes. Law, contracts and plain accountability will require a named human for particular decisions, whatever a reviewer's record. A budget of attention does not remove people from approval. It moves them to the decisions where their judgment can change the outcome, and gives them enough information to use it.

If friction is the problem, remove the controls. Friction is a cost, not proof that a control is useless. OpenAI's own account is that friction pushed people toward running with no sandbox at all, which is worse than either option it was choosing between.¹ The answer to friction is to spend it better, not to stop spending it.

Some controls should not be judgments at all. Agreed, and this is the most important qualification. A model-based reviewer trades determinism for flexibility, as OpenAI's team acknowledges.¹ Where an action must never happen, such as an agent reaching a payment system it has no business touching, the right control is a missing credential or a closed network path, not a reviewer that usually says no.

The results will not transfer. Probably not exactly. They come from internal traffic at an AI laboratory, with its own tools, sandbox settings and threat models. The design lesson transfers more readily than the numbers do, and the numbers are a reason to run one's own tests rather than a substitute for them.

Attention is a control only when the decision receives it.

Before the next approval policy

• Which approvals change outcomes? List the actions that require a named person, and write down why each one does.
• What does the approver see? Make sure each request states its purpose, data, destination, reversibility and expected consequence in plain words, not only a command.
• What stops the action if judgment fails? Name the enforced limit behind every review, and keep approvals from granting new standing permissions.
• What does the reviewer miss? Test it with actions known to be dangerous, track overrides and unnecessary interruptions, and name the actions it never sees.

Back to the stack of slips. Count the gold stamps and you learn how busy the approvers were. Read the blue notes and you learn which approvals were decisions. The second slip, the upload, should never have been in the same pile as the first. Under a budget of attention, the test run would not have needed a slip at all. The upload would have arrived by itself, with the file, the destination and the consequence written out, in front of a named person with time to read it.