Should organisations require human approval for all MCP actions?

Why This Matters for Security Teams

Requiring human approval for every MCP action sounds safe, but it usually creates false confidence rather than real control. MCP tool calls can range from harmless reads to irreversible changes, and the security question is not whether a human should be involved somewhere in the workflow. It is whether the action is high impact, time sensitive, and difficult to reverse. Over-approving low-risk requests slows operations and encourages people to bypass controls.

The real issue is that MCP expands an agent’s ability to interact with systems, data, and secrets through tool use. That makes the control point the action itself, not the label on the workflow. Current guidance in the OWASP Agentic AI Top 10 and NHIMG’s OWASP Agentic Applications Top 10 both points toward scoped, context-aware approval instead of blanket manual review. In practice, many security teams discover this only after an agent has already chained a safe-looking tool call into a harmful outcome.

How It Works in Practice

A workable MCP approval model starts by classifying tool actions into risk tiers. Read-only queries, retrieval of non-sensitive context, and narrow lookup functions can usually run automatically if they are bound to the declared task, identity, and data scope. Destructive changes, bulk exports, privilege changes, payment actions, and secrets retrieval should trigger stronger controls, including human approval, step-up authentication, or a second policy decision before execution.

That approach is more effective when paired with workload identity and runtime policy evaluation. Instead of trusting a broad session token, the agent should present a short-lived identity that proves what it is and what it is trying to do. Policy should be evaluated at request time, with context such as target system, data sensitivity, action reversibility, and current trust posture. This is why agentic guidance increasingly emphasizes intent-based controls and continuous validation rather than static RBAC alone.

Operationally, a useful pattern is:

• Allow low-risk MCP tools automatically when the request is tightly scoped.
• Require human approval for irreversible, high-blast-radius, or regulated actions.
• Issue ephemeral secrets or delegated tokens per task, then revoke them on completion.
• Log every tool invocation, policy decision, and downstream side effect for auditability.

NHIMG’s AI Agents: The New Attack Surface report is a useful reminder that 80% of organisations report agents have already acted beyond intended scope, which is exactly why approval has to be selective rather than universal. These controls tend to break down when MCP is exposed to sprawling tool catalogs, because the approval layer cannot keep pace with the number of actions that look routine but can still reach sensitive systems.

Common Variations and Edge Cases

Tighter approval often increases operational friction, so organisations have to balance blast-radius reduction against workflow latency and user fatigue. That tradeoff is especially visible in developer tooling, customer support automation, and multi-agent pipelines where one agent’s output becomes another agent’s input.

There is no universal standard for this yet, but current guidance suggests approval should be reserved for actions that are difficult to reverse, expensive, sensitive, or externally visible. For example, sending a notification may not need a human, while changing billing details, deleting records, or exposing secrets usually should. The same logic applies to chained MCP calls: a sequence of benign requests can become risky when combined.

Two edge cases deserve special attention. First, emergency operations may justify temporary policy overrides, but those overrides should be time-boxed and fully audited. Second, environments with weak tool scoping often force broader approval than necessary because the platform cannot reliably distinguish one action from another. NHIMG’s Analysis of Claude Code Security and AI Agents: The New Attack Surface report both reinforce the same point: better tool scoping reduces the need for constant human intervention, while poor scoping makes every action look like a potential incident.

Related resources from NHI Mgmt Group

• Should organisations require human approval for high-risk agent actions?
• When should organisations require human approval for an AI agent action?
• How can organisations tell whether support automation is still under human control?
• What breaks when MCP servers are allowed to initiate actions?