Many AI tools for operations now promise a human in the loop. That is good news. It also means the promise alone tells you very little. The question a security reviewer should ask is the one engineers ask on forums: how is it enforced?
An approval gate that lives in the model’s instructions is a request. An approval gate that lives in the platform is a control. This piece covers what the second kind takes, where its honest limits are, and how to check whether a tool you are evaluating has one. It is a core part of zero-trust AI operations, an open specification.
Why isn’t “ask the AI to be careful” enough?
Because the instruction is text, and the model weighs it against all the other text it reads. A ticket, a log line or a web page can carry instructions that compete with yours. The OWASP Top 10 for LLM applications says of prompt injection that “it is unclear if there are fool-proof methods of prevention”.
Models also misjudge. A model that is sure a change is safe will not ask for approval it has decided it does not need. So the decision about whether a change needs a person cannot belong to the model. OWASP’s guidance on excessive agency puts it as complete mediation: enforce authorization in the downstream system instead of relying on the model to decide whether an action is allowed.
Who should be allowed to approve?
Only a signed-in person, verified by the platform at the moment of approval. In practice that means the approve and execute actions check the caller and refuse:
- the AI and any token issued to an AI run;
- agents running on hosts;
- scheduled jobs and unattended routines;
- service accounts and other machine credentials.
Test this yourself when you evaluate a tool. Take a token the AI uses and call the approve endpoint with it. It should fail. If the tool cannot tell a person from its own automation, its approval gate is a convention.
How do you make sure what runs is what was approved?
Approval is only meaningful if the thing approved is the thing that runs. Three properties make that true.
- The proposal carries the exact content. The reviewer sees the actual API change, playbook or pull request, not a summary of it.
- The content is fingerprinted at approval. The approval binds to that fingerprint.
- The fingerprint is checked again at execution. If anything changed between approval and execution, the run is refused and a new proposal is needed.
Without the last step, a proposal can be edited after approval and still run as approved.
Where can the approval happen, and what does each channel prove?
Approvals usually happen in one of two places: the tool’s own console, or a prompt inside the AI client the person is already using, such as an MCP client.
The console is the stronger channel. The person signs in, sees the proposal and clicks approve, and the platform verifies their session.
An in-client prompt is convenient, and it has a limit you should know about. When a person accepts a prompt in their AI client, the platform learns that the client accepted it. It does not learn that a person pressed the key. For low-risk changes that may be acceptable. For the rest, add a step-up: a second factor, such as a push to the approver’s phone, that binds the approval to a person. And keep your most sensitive change types console-only.
What should the approval record hold?
At minimum: who approved, over which channel, what the requirement was, whether a step-up happened, when, and what ran as a result. That record is what you show an auditor and what you read after an incident.
Be clear about what kind of record it is. Most are ordinary database rows. They are useful evidence, and they are not tamper-proof unless the tool says how they are protected. Ask, and ask how long they are kept.
Won’t approving every change slow us down?
Only if the gate is designed badly. Three things keep it fast.
- Reads do not wait. Investigation is mostly reading, and reads inside the person’s scope need no approval. Only changes do.
- Proposals carry their evidence. When the reviewer can see why the change is proposed, review is a read rather than a hunt.
- Related changes travel together. One approval can cover the same change across a batch of hosts, with each host still recorded.
The real risk is fatigue: people approving without reading. Approval fatigue and the human in the loop covers how to keep reviews meaningful as volume grows.
A checklist for evaluating any AI tool
- Does the approve action refuse the AI’s own tokens? Try it.
- Does it refuse agents, schedules and machine credentials?
- Is the approved content fingerprinted and checked again at execution?
- Which approval channels exist, and what does each one prove?
- Is a second factor available on approvals, and is it on by default?
- What does the decision record hold, and how is it protected?
How GAEZLA does it
In GAEZLA, the approve, execute and retry calls accept only an operator. Agents, AI run tokens, routines and machine tokens are refused, and nothing in GAEZLA can approve. An operator approves in the console or answers the approval prompt in their own MCP client. Mail and jobs that use a secret can be approved only in the console.
The proposal is fingerprinted at approval and checked again at execution, and many changes can be approved as one decision, sealed together. With multi-factor authentication on approvals, every approval needs a push on the approver’s phone, on every channel. It is off by default and part of the Complete plan. Without it, an in-client accept counts as an approval by your policy, and it proves the client accepted, not that a person was present.
Each decision records who approved it, over which channel, under which requirement, the multi-factor result, when, and what ran. These are ordinary database rows that are deleted with their case. One approval can cover the same playbook on many hosts, with a signed queue item for each.