Approvals · workflow design
Human Approval for MCP Workflows
Approval is the control everyone specifies and almost nobody designs. It fails the same way every time: too many requests, too little context, and a timeout that defaults to yes.
The short answer
An MCP approval workflow holds a tool call before execution and requires a human decision. It works when three things are true: approval is triggered by consequence rather than by category, the request shows the approver the tool, the exact parameter values, the caller and the triggering rule, and a timeout results in refusal rather than approval. Approver capacity is the binding constraint — past roughly fifteen requests per person per day, approval degrades into rubber-stamping. Seven elements per request, four queue rules, and the arithmetic that tells you how many gates you can afford.
Key takeaways
- 01Approval is a budget, not a switch. Every gate you add spends approver attention, and attention is the scarcest input in the system.
- 02Trigger on consequence, not category. “All payments” is a category; “payments above £5,000 to a destination first seen this month” is a consequence.
- 03An approval request missing the parameter values is not an approval request. The destination is what catches an injected payment, and it is the field most often omitted.
- 04Timeout must mean refuse. Any control whose default is approval will, under deadline pressure, approve everything.
- 05Quorum for the top tier only — usually under five tools. Two approvers on everything halves your throughput and buys nothing.
- 06Measure approval latency at p95 and rejection rate. A rejection rate near zero means the threshold is wrong, not that the agents are excellent.
Approval is a budget
The instinct when an agent gains a dangerous capability is to require approval. It feels free: a human checks, so the risk is handled. It is not free, and the cost is paid in a currency nobody meters.
Every gate consumes approver attention. Attention is finite, non-transferable and degrades sharply with volume — not linearly. An approver reviewing three requests a day reads all three carefully. The same person reviewing fifty reads none of them, approves in batches, and has become a latency source with a compliance record attached.
This is the central design fact and it inverts the usual instinct. Adding a gate can reduce oversight. If a new gate pushes an approver from twelve requests a day to thirty, the quality of review on the eleven genuinely dangerous ones falls, and you have traded real scrutiny of important actions for nominal scrutiny of unimportant ones.
So approval is allocated, not applied. Decide how much approver capacity exists, then spend it on the actions where a human genuinely changes the outcome.
The fifteen-per-day figure is a rule of thumb, not a measurement, and it varies with how much context each request carries. Treat it as a budget to test rather than a limit to trust: instrument your own rejection rate against volume and you will see the inflection where reading stops.
Trigger on consequence, not category
The most common specification error is defining approval by tool category. All payments require approval. All deletions require approval. This is easy to write, easy to audit, and produces the volume problem immediately — because most payments are routine and most deletions are trivial.
Triggering on consequence means combining the tool’s risk class with the parameter values and the context. The same tool passes silently at one value and holds at another. This is exactly what a policy engine with parameter inputs exists to express, and it is why tool-name-only policy cannot implement approval well.
Key facts
- ▸A category trigger asks “what kind of thing is this?” A consequence trigger asks “how bad is this specific thing?”
- ▸Consequence triggers require parameter values as a policy input; tool-name-only policy cannot express them.
- ▸Actions that reduce risk — narrowing a scope, revoking a grant — should never require approval.
| Category trigger (weak) | Consequence trigger (better) | Why |
|---|---|---|
| All refunds | Refunds above £500, or to a payment method not previously used by this customer | Routine refunds are the overwhelming majority; the unusual destination is the actual signal |
| All record deletions | Deletions affecting more than 50 records, or any deletion in a retention-flagged dataset | Single-record deletion is reversible in most systems; bulk deletion is the risk |
| All external emails | External email to a domain not in the customer’s contact record, or to more than 25 recipients | Volume and unfamiliar recipients are what turn a send into an incident |
| All access changes | Any grant that widens scope, or any grant to a principal created in the last 7 days | Narrowing scope is safe and should never wait for a human |
| All production writes | Writes to a system where the credential’s scope exceeds the tool’s stated purpose | The mismatch is the risk, not the write |
Seven elements of an approval request
An approver can only make a decision as good as the information in front of them. Most approval UIs show a tool name and a Yes button, which asks the human to rubber-stamp and then blames them for doing so.
Seven elements. The third is the one that catches injected actions and the one most often missing.
What will happen, in plain language
One sentence naming the effect on the world, not the function signature. “Refund £8,400 to a bank account not previously used by this customer” — not payments.refund_issue.
Write it from the target system’s point of view. Approvers reason about consequences, not about APIs, and the translation is your job rather than theirs.
Who is asking
The agent identity and, where delegation applies, the human on whose behalf it acts. An approver needs to know whether this is the reconciliation agent doing its job or a general assistant reaching somewhere unusual.
The exact parameter values
Every value policy evaluated, shown literally: amount, currency, destination, record count, target system, date range. This is the element that catches an injected payment, because an unfamiliar destination is visible to a human in a way it is not to a model.
If you ship one thing from this article, ship this. An approval granted against a summary that omitted the destination is not oversight, and an auditor will ask what the approver was shown.
Why the agent believes this is warranted
The agent’s stated reason, plus a link to the source record it acted on — the ticket, the document, the invoice. This is what lets an approver check the premise rather than only the action.
It is also the single most valuable field during an incident investigation: knowing which document convinced the agent turns a two-week forensic exercise into a two-hour one.
Which rule triggered the hold
The rule id and the threshold that was crossed. Approvers who understand why they are being asked make better decisions and generate better feedback about mis-set thresholds.
Relevant history
How many similar actions this agent has taken this week, and whether this destination or target has been seen before. Absent this, every request looks like the first one.
This is where a runaway loop becomes visible to a human: the eleventh similar request in an hour reads very differently from the first.
What happens on each choice, including timeout
Approve, refuse, or escalate — and an explicit statement that no response by a stated time means refusal. Ambiguity here is what produces accidental approvals.
Queue design: four rules
The approval queue is a production system with a human in the critical path, and it should be designed like one. Four rules, learned by watching queues fail.
- 01Route to a role, not a person. A queue addressed to an individual stalls when that individual is in a meeting, on leave, or has left. Route to a role with a named rota and a documented escalation after a stated interval.
- 02Set the timeout per risk class, and make it refuse. A bounded write might hold for four hours; an irreversible payment holds until someone decides, then refuses. Never approve on timeout — under deadline pressure that becomes the primary path.
- 03Make refusal as cheap as approval, and require a reason on refusal only. If refusing costs a conversation and approving costs a click, the queue drains one way. Asking for a one-line reason on refusal captures the signal you need for threshold tuning without taxing the safe default.
- 04Show the queue depth and age to the people who set the thresholds. Threshold owners who cannot see the load they created will keep adding gates. One weekly figure — requests per approver per day — changes the conversation.
- 05Survive a restart without ambiguity. A pending approval when the enforcement point restarts must neither auto-approve nor silently vanish. State this behaviour explicitly and test it; it is the case nobody specifies and the one that produces a duplicated payment.
Built on this thinking
Approval that shows the approver what matters
BarzelVault holds calls above threshold and presents the tool, every parameter value, the caller, the agent’s stated reason and the triggering rule — then records the approver and what they were shown in a hash-chained trail. Consequence-based triggers, not category-based ones.
Quorums and segregation of duties
For a small number of actions, one approver is not enough — not because one person is unreliable, but because a single approver can be the same person who configured the agent, which collapses the control entirely.
Two mechanisms, applied narrowly.
Quorum
Two or more approvers must independently agree. Reserve it for the top risk tier — typically under five tools. Applied broadly it halves throughput and buys nothing, because the second approver defers to the first.
Segregation of duties
The approver must not be the agent’s configurer, and must not be the requesting party. Long-established in finance and directly applicable: whoever set the threshold should not be the one waving through the action that crossed it.
Break-glass, logged loudly
A documented path to act without the normal approver, which alerts on use and generates a review. Without one, teams invent an undocumented path; with one, the exception is visible.
Segregation of duties is where approval intersects external audit obligations, and it is worth getting right on paper before it is tested. Separation of duties for AI agents works through the role model in full.
Six failure modes
Each of these has killed a real approval flow. Five are design errors; the last is an organisational one and the hardest to fix.
| Failure | How it presents | Fix |
|---|---|---|
| Volume collapse | Rejection rate approaches zero while volume climbs | Raise thresholds until requests-per-approver-per-day is inside budget |
| Context starvation | Approvers ask “what am I looking at?” in chat | Add elements 1, 3 and 4 to the request |
| Timeout approval | Nobody can recall the last refusal; approvals cluster near the deadline | Change the default to refuse; measure the change in rejection rate |
| Queue orphaning | Requests age past their usefulness and get bulk-approved | Route to a role with a rota; escalate on age |
| Approver conflict | The person approving configured the agent | Enforce segregation of duties in the routing rule itself |
| Threshold ownership vacuum | Nobody can say who may change a threshold, so nobody does | Name an owner per threshold and expire the threshold, forcing a review |
The signal to watch is rejection rate. A flow with a rejection rate at or near zero is not evidence that agents are behaving well; it is evidence that the gate is either set above anything real or being waved through. Either way it is not a control, and it is producing an audit record that says otherwise.
What approval does not solve
Approval places a human between intent and effect. It does not make that human right. An approver seeing a plausible refund to a plausible destination will approve it, and if the premise was fabricated in a document the agent read, the approval is a well-evidenced mistake. Approval raises the cost of an attack; it does not close it.
It is also the slowest control available and should be the last one you reach for. Narrowing a credential, bounding a parameter or removing an entitlement costs nothing at runtime and eliminates the case entirely. Approval is for the residue — the actions that are legitimately sometimes correct and sometimes catastrophic, where no static rule can tell them apart.
Finally, a workflow with human approval is not the same as a workflow with human oversight. Oversight includes knowing what the agents did last week, which is an evidence question, and being able to stop them now, which is a runtime control question. Approval alone covers neither.
Frequently asked questions
What is an MCP approval workflow?
A control that holds a Model Context Protocol tool call before execution, presents it to a human for a decision, and either executes or refuses according to that decision. It works when the trigger is based on consequence rather than tool category, the request shows the exact parameter values, and a timeout results in refusal.
When should an MCP tool call require human approval?
When the action is irreversible or externally visible and no static rule can distinguish the acceptable case from the unacceptable one. In a typical estate that is under a dozen tools, which is what makes per-call approval affordable. Actions that reduce risk — narrowing a scope, revoking a grant — should never require approval.
What should an approval request show the approver?
Seven elements: what will happen in plain language, who is asking, the exact parameter values, why the agent believes it is warranted with a link to the source record, which rule triggered the hold, relevant history for that agent and destination, and what happens on each choice including timeout.
Why does human approval degrade into rubber-stamping?
Because approver attention is finite and degrades sharply with volume. Past roughly fifteen requests per person per day, review quality visibly falls. Category-based triggers such as ‘all payments’ generate that volume immediately, since most payments are routine.
Should an approval timeout approve or refuse?
Refuse. Any control whose default is approval will, under deadline pressure, become a control that approves everything. Set the timeout per risk class — a bounded write might hold four hours, an irreversible payment holds until a human decides — and make expiry mean refusal in every case.
How many approvals per day can one person handle?
Roughly fifteen before review quality visibly degrades, in our experience, though it varies with how much context each request carries. Treat it as a budget to measure rather than a limit to trust: instrument rejection rate against volume and the inflection where reading stops becomes visible.
When should an approval require two people?
Only for the top risk tier, typically under five tools. Applied broadly, a quorum halves throughput and buys little because the second approver defers to the first. What matters more widely is segregation of duties: the approver must not be the person who configured the agent or the requesting party.
What is the best metric for approval health?
Rejection rate, read alongside requests per approver per day. A rejection rate at or near zero is not evidence that agents are behaving well — it means the threshold is set above anything real, or requests are being waved through. Either way the gate is producing an audit record of oversight that did not happen.
What happens to a pending approval if the system restarts?
It must neither auto-approve nor silently disappear. State the behaviour explicitly and test it by restarting with an approval in flight. This is the case teams most often leave unspecified, and it is the one that produces a duplicated payment.
Is human approval enough to secure an AI agent?
No. Approval is the slowest control available and should be the last one reached for. Narrowing a credential, bounding a parameter or removing an entitlement eliminates the case entirely at no runtime cost. Approval is for the residue where an action is legitimately sometimes correct and sometimes catastrophic.
Glossary
- MCP approval workflow
- A control that holds a Model Context Protocol tool call before execution, presents it to a human for a decision, and executes or refuses according to that decision.
- Approval gate
- The specific rule condition that causes a call to be held rather than executed — typically a tool’s risk class combined with a parameter threshold.
- Approval budget
- The finite quantity of human attention available for reviewing agent actions, beyond which additional gates reduce rather than increase oversight quality.
- Approval quorum
- A requirement that two or more named approvers independently agree before a held call executes, reserved for the highest-consequence actions.
- Rubber-stamping
- Approval granted without meaningful review, which is worse than no approval because it manufactures an evidence record of oversight that did not occur.
Sources and further reading
Human oversight obligations and segregation-of-duties practice come from the frameworks cited below. The seven request elements, the approval-budget arithmetic and the fifteen-per-day figure are our own operating judgement, from designing approval flows in BarzelVault and watching several degrade before they were fixed.
- 01 · NISTNIST SP 800-53 Rev. 5 ↗Access control and audit control families that MCP-layer controls have to satisfy.
- 02 · OWASP GenAI Security ProjectOWASP GenAI LLM Top 10 (2026) ↗Consensus risk list; excessive agency and prompt injection are the entries governance exists to bound.
- 03 · OWASP GenAI Security ProjectOWASP Agentic AI — Threats and Mitigations ↗Threat taxonomy specific to tool-using agents rather than to chat completions.
- 04 · ISOISO/IEC 42001 — AI management systems ↗The management-system standard auditors increasingly map AI governance evidence against.
- 05 · EU AI Act (unofficial consolidated text)EU AI Act — full text ↗Obligations around logging, human oversight and traceability for higher-risk systems.
- 06 · ISACACOBIT 2019 Framework ↗Governance and management objectives, including segregation of duties.
- 07 · U.S. SECSarbanes-Oxley Act — Section 404 ↗Where segregation of duties becomes an externally audited control.
- 08 · MCP projectModel Context Protocol — specification ↗Normative source for tool schemas, capability negotiation and the authorization model.
Last reviewed 2 September 2026. External links open in a new tab; we do not control their content.
Cite this article
Alex, M. (2026). Human Approval for MCP Workflows. Real Biz Digital. https://realbizdigital.net/insights/mcp-human-approval/
Try the mechanics on a live server
To watch a real tools/list response before you point a client at anything that governs production — Barzel Scripture Intelligence is free and public at scripture-intelligence-server.mcpize.run: no signup, no key, 54 tools. Setup is in the reference.
Buy it on the marketplace
BarzelVault is the pre-execution decision point, sold as a running product
Nine tools, 12 static resources, 3 resource templates and 9 prompts. Four deterministic outcomes — allow, deny, dry-run, require approval — with approval workflow, hash-chained audit and guardrail data protection. Streamable HTTP, JSON-RPC 2.0.
| Plan | Price | Included | Right for |
|---|---|---|---|
| Dev | Free | 10,000 policy decisions/mo · 9 tools, 4 outcomes, hash-chained audit | A first regulated workflow: one agent, one high-consequence system |
| Team | $199/mo | 75,000 decisions/mo · approval workflow, spend and action limits | Several agents acting on money, records or customer-visible systems |
| Business | $799/mo | 750,000 decisions/mo · exact HTTPS execution, credential isolation, emergency controls | Enterprise-wide pre-execution enforcement with audit obligations |
| Enterprise | $3,999/mo | 5,000,000 decisions/mo · everything in Business, scaled | Group-wide rollout across many teams and systems |
Sold on the MCPize marketplace · prices as listed 2 Sep 2026 · the listing is authoritative
Written by
Mark Alex
Founder of Real Biz Digital and architect of the Barzel ecosystem — five MCP servers published and callable in public. Software developer, technology entrepreneur and mechatronics engineer, working across AI agent governance, MCP security, AI infrastructure, FinOps and intelligent operations.