Two threads, one conclusion. We spent this series looking at the approval window from both ends — and the answer turns out not to live in the window at all.
It lives in the org chart. Accounting wrote it down before software existed.
This series ran in two languages and, honestly, in two directions.
One thread was about naming. Polish had no term for the thing that happens when a person clicks approve without reading — the phenomenon is documented across three separate fields under three separate names, none of which is Polish. So we named it: zeszklone zatwierdzanie, from the glazed look that passes through a screen without stopping on the content.
The other thread was about what survives. When something goes wrong and someone reconstructs the incident, what remains is a line in a log: 14:32:07 — action approved by user@company. That line is produced identically by a considered judgement and by a reflex. It records a click and describes it in the language of a decision.
Different starting points, and I did not expect them to converge. They did, and both ended on the same unfinished sentence. I wrote it at the close of the last essay:
Whether that is the right exchange depends on what the agent can reach — which is a question about permissions, not about dialogs.
I left it there because I did not yet have the answer. I have it now, and it is older than every system in this series.
Why the dialog can never be the answer
Worth compressing the case, because it took three essays to build.
An approval window fails in five ways. It can show the wrong thing — the label instead of the resolved target. It can be truncated. It can describe a dangerous operation in routine language. It can batch so many actions that none gets read. And it can fire so often that a person correctly learns it carries no information.
Fixing the first three is engineering work and it works. Fixing the fourth and fifth is a losing game, because the better your window gets, the more edge cases it catches, the more often it fires, the less any single firing means.
But there is a sixth failure, and it is the one that closes the argument. Sometimes the window tells the truth, fires rarely, is read carefully — and the person still cannot answer, because answering requires knowledge they do not have and should not be expected to have. Convert lost clusters to files, or free them? You needed to understand a file allocation table. Agent wants to run npm install left-pad@1.3.0 — you need to know whether that specific version was compromised last night.
Call it a competence failure. It cannot be fixed by asking better, asking less often, or asking more clearly. It can only be fixed by asking someone else — or by not asking a person at all.
Once you accept that, the whole frame shifts. The question stops being how do I write a good approval dialog and becomes who should be deciding this, and when. And that question has an answer with about a century of practice behind it.
Accounting solved this before computers
The principle is called segregation of duties, and it is a cornerstone of internal control. The COSO framework — the reference model for internal control over financial reporting — splits any transaction into three functions that must not sit with the same person: authorization (deciding it should happen), custody or execution (carrying it out), and recording or reconciliation (logging it and later verifying it).
The logic is simple and brutal. If one person can both perform an action and record it, they can conceal an error or a fraud without anyone's help. Split those functions and concealment requires collusion, which is harder, slower, and more likely to surface.
A detail worth noting, because it says something about how deep this runs: the Sarbanes-Oxley Act never uses the phrase. Yet auditors treat weak segregation of duties as a standard driver of material weakness under Section 404, and unresolved conflicts are among the most common findings in a SOX audit. The principle is not a regulation. It is what regulation assumes you already do.
And note what it is not. It is not a technology, a dialog, a permission model, or a piece of software. It is a shape imposed on an organisation, which happens to be enforced by software. That distinction is the whole point of this essay.
What it fixes that a dialog cannot
Go back to the log line.
The uncomfortable observation from the last essay was that an approval gate nobody reads does not reduce risk — it makes an outcome attributable. Risk moves from the organisation that deployed the agent to the individual who clicked. And that individual clicked because the system trained them to. We build mechanisms that manufacture accountability out of behaviour we caused, and then we point at the record.
Segregation of duties addresses exactly this, and it does so by changing three things about the approval at once.
Who decides. The approver is not the operator. They have different competence, different incentives, and different exposure. The clerk processing invoices does not get a dialog asking whether this one exceeds the customer's credit limit — they simply cannot push it through, and it routes to someone whose job that judgement is.
When they decide. The decision is made once, during configuration, in a quiet moment, by someone thinking about a class of transactions. It is not made forty times a day by someone with a queue to clear. Fatigue never enters, because there is nothing repetitive to become habituated to.
What the record means. When authorization sits with a role that was assigned deliberately and separately from execution, the log line stops being a signature harvested from a reflex. It becomes a reference to a decision that genuinely happened — just earlier, and elsewhere.
That is the difference between a system that produces a defensible paper trail and a system that produces control.
Three mechanisms worth stealing
Enterprise systems implement this in ways that are almost embarrassingly applicable to agents, and almost entirely absent from the conversation about them.
A role instead of a question. The warehouse operator does not see a warning about releasing goods below cost. They lack the right. If the situation genuinely calls for it, the document escalates to someone who has it. No dialog exists to be clicked through, because the constraint is not made of pixels.
A lock instead of a dialog. A closed accounting period does not ask whether you are sure you want to post to it. It refuses. There is no proceed anyway, no advanced link, nothing to develop a reflex around. An entire class of operations is off, rather than fenced with a warning — and that is precisely why nobody becomes habituated to it.
A limit instead of a confirmation. A customer credit limit does not fire on every order. It fires on the one that crosses it. The prompt is rare, always means the same thing, and therefore still carries information after the thousandth order.
Common thread: the decision has been moved out of the moment of execution and into configuration, and out of the operator and into someone accountable.
Translating this to agents
The mapping is direct, and mostly consists of things the current tooling does not do.
An agent should be an account, not a feature of your session. It needs its own identity, its own role, and its own permission set — not your permissions borrowed for the duration of a task. Everything below depends on this one.
Configuration and operation should be different people. This is the largest gap. Today we assume a developer sets their own agent's boundaries and then approves their own agent's actions — supervisor and supervised collapsed into one human in one session. No finance system would accept that architecture for a moment. In a team, the person who defines what the agent may reach should not be the person racing it through a task at 4pm.
Prefer removing the right over adding the question. If the agent should never write outside the working directory, do not ask — deny at the filesystem level. A question can be clicked through. A missing permission cannot.
Close periods, not just paths. Production, payment rails, the customer mailing list: treat them as closed accounting periods. Not gated, closed — with reopening as a deliberate, logged, separately-authorised act.
Do not let the agent hold the recording function. This one is subtle and I think it is the sharpest transfer of the whole principle. If the agent executes the action and writes the log describing what it did, you have handed one party both custody and recording — the exact combination internal control exists to prevent. A compromised or confused agent narrates its own history. The audit trail must be produced by something the agent cannot reach.
What this does not solve
Three limits, stated plainly.
It assumes there is someone to separate from. A solo developer has no second person, and a two-person startup has one who is asleep. COSO is honest about this: where segregation is impractical, you use compensating controls — independent review after the fact, dual authorisation above a risk threshold, tamper-evident logging inspected by someone outside the process, time-boxed exception access that expires on its own. For a solo operator, the realistic version is a machine playing the second role: a scanner, a policy, a hard limit, a log they read on a schedule rather than in the moment. Weaker than a colleague. Much stronger than a dialog.
It assumes agent identity is real. Roles are only as good as the answer to who is acting. If an agent can act under a human's credentials, segregation is decorative. This is an identity problem before it is an authorisation problem, and it is not solved.
It does not tell you where the threshold is. I said last time that I did not know how many daily prompts a person can absorb before attention collapses, and I still do not. Segregation of duties reduces how many prompts exist, which is the right direction, but it does not produce a number. I would rather leave that open than invent one.
The last line
The previous essay ended with a test: if you want to know whether your oversight is real, do not count the gates — count how often somebody says no.
I would extend it by one clause now, and it is the clause the whole series was walking towards.
Count how often somebody says no — and check whether that somebody is the same person who was in a hurry.
If it is, you do not have oversight. You have a signature, collected under conditions you designed, from someone you trained to provide it.
This closes a series that ran across three sites. The design side — how to build an approval that survives repetition, and the four decades of attempts that came before ours — is on webflux.pl, in Polish. The naming of the phenomenon, and why Polish needed a term for it, is here. The previous essay in this thread is We didn't invent this problem with agents.
Sources: COSO Internal Control — Integrated Framework (segregation of duties as a control activity; compensating controls where separation is impractical) · Sarbanes-Oxley Act, Section 404, and standard audit practice treating inadequate segregation as a material weakness driver · A. P. Felt et al., "Improving SSL Warnings: Comprehension and Adherence", CHI 2015 · Aza Raskin, "Never Use a Warning When You Mean Undo", A List Apart, 2007 · Y. T. Shen, K. Toyoda, A. Leung, "MCP-38: A Comprehensive Threat Taxonomy for Model Context Protocol Systems", arXiv:2603.18063, March 2026 — one of several competing MCP threat taxonomies published that quarter.
