VIVUU

Guide · agent governance

When to require approval for an AI agent

Gate too much and the agent gets switched off. Gate too little and one confident mistake reaches production. The line is not about trust in the model — it is about what an action costs to undo.

Three questions, in order

1. Is it reversible, and how cheaply? A sandbox edit reverses by deleting a container. A pushed commit reverses with a revert and a public record. A sent email does not reverse at all. Cost-to-undo is the primary axis.

2. What is the blast radius? One file, one repo, one customer, every customer. An action that touches a list rather than a record deserves a gate even when each individual effect is small.

3. Does it touch money, customers, or credentials? These three carry consequences beyond the technical: a refund is money gone, an email is reputation, a credential is everyone’s problem. Credentials should not be approvable — deny them.

The sandbox boundary does most of the work

One structural decision removes most of the judgement: give the agent an isolated workspace and put the gate at its edge. Inside, it is free — clone, read, edit, install, run tests, iterate, fail, retry. Nothing it does inside can hurt you, because the workspace is discarded.

That single line turns a hard policy problem into an easy one. You are no longer asking “is this edit safe?” for every file. You are asking one question at one moment: is this finished work good enough to leave the box?

inside the sandbox ·· clone · read · edit · install · test → no gate
at the boundary ····· push · pull request · deploy · email → gate
never ··············· rotate secrets · change security controls

What the screen has to show

An approval is only real if the person can judge. In practice the failure is subtle: the agent presents a fluent summary, the human reads the sentence, and the sentence is not the change.

We watched this happen. An agent asked to fix a content-security policy proposed inverting it — replacing the live domain with a stale one from another project — and wrote a confident, wrong rationale for why. The summary was excellent. The diff was backwards. The gate caught it only because it showed the diff.

So the screen shows, every time:

action ····· repo.push + pr.create
target ····· al3dwii/suovy · branch agent/c12d2048 · base main
diff ······· 1 file changed, 4 insertions(+) ← the real one
tests ······ ran: yes · passed: yes
policy ····· APPROVAL_REQUIRED (leaves the sandbox)
expires ···· 60 minutes

And the act of approving should cost something — a hold, not a click. A decision that carries a real consequence should feel deliberate, and a single mistaken tap should not be able to ship anything.

Expiry is part of the design

An approval is judgement about a specific state: this diff, these tests, this balance, right now. Four hours later the base branch has moved and the judgement no longer describes reality. Expiring a pending request forces the agent to re-derive its plan rather than execute a decision made about a system that has since changed.

FAQ

Which AI agent actions should require human approval?
Anything that leaves the sandbox and cannot be cheaply undone. Three questions decide it: is it reversible, how far does it reach, and does it touch money, customers or credentials? Sandbox edits and test runs need no approval. Pushing code, contacting a customer or moving money do. Changing a security control should not be approvable at all — deny it.
How many approvals per day is too many?
If a person is approving more than a handful, the boundary is drawn in the wrong place. Gates belong at the edge of the sandbox, not inside the work. An agent that needs sign-off to read a file or run a test will be switched off within a week, and the gate will be blamed for the failure of the design.
What should an approval screen show?
The exact action, the exact target identity, the real diff or payload, the tests that ran and their result, the policy outcome that routed it here, and an expiry. Not a summary. A language model produces a confident summary just as easily when the underlying change is wrong, so approving a paraphrase is approving nothing.
What is dual approval and when do you need it?
Two different humans must sign off before the action executes — standard for money movement and irreversible external effects. It exists because the second person is not tired in the same way as the first, and because collusion is a much higher bar than a single mistaken click at midnight.
Should approvals expire?
Yes. An approval is judgement about a specific state of the world — this diff, these tests, this balance. Hours later the branch has moved and the reasoning is stale. Expiring the request forces the agent to re-derive rather than execute a decision made about a system that no longer exists.

see the whole flow, live

Everything on this page — the queue, the evidence, the hold-to-approve, the audit trail — is working in the VIVUU terminal as an interactive preview on realistic mock data. No sign-up.