Requiring Human Approval Before an MCP Server Deletes or Overwrites Files

Approval is an enforcement problem, not a prompt

An MCP server that exposes file tools gives an agent the ability to delete or overwrite data using the permissions of the user or service account behind it. OWASP describes MCP servers as operating with delegated user permissions and chained tool calls, which raises the impact of any single mistaken or manipulated call.

OWASP's MCP guidance says never to auto-approve tool calls, especially in multi-server setups, and not to assume that a tool being available means the user consented to a particular invocation. It also reports that the MCP specification expects hosts to obtain explicit user consent before invoking a tool and lets a human deny invocations. That establishes the expectation. It does not tell you where the check runs, who the approver is, or what happens when nobody answers. Those decisions belong to the implementer.

Treating approval as a user-interface prompt leaves those decisions to each host. Treating it as enforcement means the gate sits where the call is executed, in a component the agent cannot talk its way past. NIST's draft SP 800-228A describes the same idea for high-stakes API calls: a manual confirmation step outside the AI agent's control.

Classify which file tool calls are destructive

Start with reversibility. OWASP Cornucopia recommends classifying each action as read-only, reversible, externally reversible, or irreversible, and letting that class decide what runs unattended and what needs approval. Its example is deleting invoices, an irreversible action that must route to a human.

Apply that to file tools. Deletion is destructive. Overwriting an existing file is destructive unless a versioned copy exists that you control. Moving a file onto an existing path is an overwrite in practice. A write with a replace or truncate mode is also an overwrite, even if the tool is named "write". Creating a new file at an unused path is usually reversible. Reading is not destructive, though it may need separate controls.

Do not rely on tool annotations. OWASP says a read/write label alone may not establish risk and that clients must treat annotations as untrusted unless they come from trusted servers. Parameter names and modes differ between servers, so build a mapping for each file tool you permit. Evaluate the arguments: the operation requested, whether the target path already exists, whether a replace or recursive mode is set, and whether the path falls in a protected location. Where a tool's behavior cannot be determined from its arguments, treat the call as destructive.

Compare the three approval patterns

Each pattern can be useful. They differ in whether a determined or deceived agent, or a careless configuration, can get around them.

• Client-side confirmation: The host asks the user before a call. It is simple and close to the user, but behavior varies by host, settings can auto-approve, and a persuasive tool description or injected text can shape what the user is shown. It usually leaves no durable record of who approved what.
• Server-side checks: The MCP server refuses certain operations unless an approval flag or token is present. This sits nearer to the action, but every server must implement it consistently, and a server you do not control may not implement it at all.
• Policy enforcement in the execution path: A policy component evaluates each tool call before it reaches the file system and holds destructive calls for approval. One rule set covers every host and server behind it, and the decision can be recorded centrally. It adds a component to operate.

What an approval decision record should contain

A prompt that was clicked is not evidence. OWASP Cornucopia recommends audit trails for approval of security-critical actions, with human oversight events captured so they can be independently audited and reconstructed. OWASP's prompt injection guidance adds that policy decisions (allow, block, or human review) should be recorded as structured data, separate from whether the legitimate task completed.

A practical record includes the requesting user or service identity, the agent and MCP server involved, the tool name, the full arguments including the resolved target path, the policy rule that triggered escalation, the approver's identity, the decision, the timestamps of request and decision, and the outcome of execution. Record timeouts and denials with the same fields as approvals, since a blocked call is also a decision. Store records somewhere the agent and the MCP server cannot modify.

This field list is a design recommendation. Check it against the audit expectations that apply to your organization before you finalize it.

Pair the gate with least privilege. Restricting the server process's file access and keeping agents away from credential stores limits what a mistaken approval can damage.

Where Trussed enforces policy

Trussed enforces policy in the execution path on MCP tool calls, so a file operation is evaluated at runtime, not reviewed after the fact. Each call can be allowed, redacted, blocked, or escalated for human approval, which maps to the workflow above: routine reads proceed, destructive calls pause for an approver, and calls outside policy are stopped. Scope is individual interactions and tool calls.

Enforcement produces audit-ready evidence for each decision, mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act, and NIST. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency, which matters when decision records contain file paths and arguments.

Whatever you use, test the gate with questions that do not depend on any vendor. Is approval enforced where the call executes? Is it bound to the exact arguments? Does an unanswered request block the call and get recorded? Are destructive calls detected from parameters rather than annotations?