Human-in-the-loop approval

Why agents need a person in the loop

An agent picks its own tool calls. Most are harmless, and asking a person about every read would make the agent useless. A few are expensive to get wrong: a DELETE on a customer table, a refund above some amount, an email to every user. Human-in-the-loop approval sits on those few. The agent asks, the call waits, a person looks at the exact tool and arguments, and only then does anything run.

The Model Context Protocol asks for this too. Its tools page says there “SHOULD always be a human in the loop with the ability to deny tool invocations”, and that applications should show which tools are exposed and present confirmation prompts.¹ Its security considerations add that clients should show tool inputs to the user before calling the server.¹

Client prompts and policy approvals

There are two common ways to put a person in the loop, and they are different tools.

• A confirmation prompt in the client. An MCP client can ask before it runs a tool, as the specification suggests. That works when the person at the keyboard is the right approver and is watching. It doesn’t help when the agent runs unattended, in CI or overnight, and it lives in the same process the agent controls.
• An approval rule outside the agent. A gateway or policy layer decides which calls need a person, holds them, and asks someone named in the rule, wherever they are. The agent can’t skip the step, because the call never reaches the tool until the rule is satisfied.

What a good approval step needs

• The exact call. The tool, the arguments and, for SQL, an estimate of the rows it would touch. “The agent wants to update orders” isn’t enough to decide on.
• A frozen snapshot. If the request changes after the person looks, the old approval shouldn’t count. Deedglass refuses a vote when anything the decision depends on has changed since the approval opened (source 4).
• The right people. Name who may approve, how many must agree, and stop the person the action runs for from approving their own request. Deedglass supports two-person approval (required: 2) and that self rule (source 5, source 4).
• An expiry. A call nobody answers should end, not run a day later in a different context.
• A record. Who approved, when, and what they saw, kept where the agent can’t edit it.

Where it falls short

• Approval fatigue. If every write needs a click, people click without reading. Keep approvals for the calls that matter and let rules allow or refuse the rest.
• It doesn’t check what happened. An approval says a person agreed to a request. It doesn’t show what the system did afterwards, so a one-row UPDATE that a trigger turns into 301 rows was still approved as one row. A check of the result is a separate step.
• It can’t be taken back. Once the approved call runs, the approval is spent. Recovering from a bad one needs undo or a backup.