Everyone agrees that some actions deserve a second pair of eyes. Moving money. Exporting a customer list. Anything that touches production. The security review says so, the auditor says so, and nobody argues.
Then somebody asks which system it goes in, and the room goes quiet. The system in question was written by a team that has moved on, or bought from a vendor who will not prioritise it, or is one of forty internal services nobody has the budget to revisit. Adding an approval step means adding a screen, a callback, a waiting state, an audit trail, and a way to handle the person who never responds. That is a project, in software nobody wants to open.
So the control does not get added. It appears on a slide as a policy, and the policy is enforced by people remembering.
The action already leaves the building
Here is the thing about the actions you want to gate: they leave the building. Moving money calls a payment provider. Exporting data calls a storage service. Touching production calls an interface somewhere. That call is already crossing a boundary you control.
Squidder asks there, at the boundary the call already crosses, so the software being gated never has to learn that it is being gated.
So put the question there. When a request needs a human it is refused — cleanly, immediately, with a refusal that says this is not final — and the question goes to the right person's phone. They see what is being asked, in readable terms, and they approve it or they do not. When the software tries again, it either works or it is told no.
The software needed no new screen, no new state machine, no integration. It needed to handle a refusal and try again, which is behaviour it almost certainly already has, because networks fail and every reasonable client retries. That the whole control rests on that one property is not incidental, and it is worth understanding why refusing beats waiting: asking a human without holding the connection.
What you are left with is a control that covers software you do not control, that names a person rather than a role in the record, and that lives in one setting rather than in forty deployments.
What this does not do
Somebody has to be reachable. If the action needs a person and no person is available, the action does not happen. That is the correct behaviour and it is still an operational fact you have to plan for. Decide in advance which actions genuinely deserve it, because gating everything produces an organisation that approves reflexively, which is worse than not asking.
It gates the action, not the intent. A person approving a payment is confirming that this payment, to this destination, should happen. They are not auditing the reasoning that produced it. Do not oversell it internally as a substitute for getting the software right.
A machine with no human behind it cannot be asked. Scheduled work and background jobs have nobody to prompt. Those need a different answer, and pretending otherwise produces a control that quietly fails on exactly the traffic that runs at 3am.
Where to start
Find the one action everybody agrees deserves approval and nobody has got round to gating. It is usually a payment, an export, or a privileged write.
Gate that one. Do not touch the application. Then show the security review the refusal, the phone and the retry going through, and ask them what else they would like covered.
That conversation goes very differently when the answer to "how long would it take" is "it is done".