Requiring human approval before the Google Drive MCP server deletes or moves files

Which Google Drive MCP tool calls need an approval gate

Start from the effect of a call, not its name. Tool names and parameters differ between Google Drive MCP server implementations, so a list copied from one server will not hold for another. Review the tool list of the server you actually deploy and sort each tool into four groups: read (list, search, fetch content or metadata), relocate (move, rename), destroy (trash, delete, permanent removal) and change access (sharing and permission changes).

NIST SP 800-209 says access rights such as read, write, modify, delete and change ACLs should be assigned individually based on need to know. That is a useful basis for the classification: delete and access changes are separate rights from read, and they should be treated as separate decisions. Moves deserve a gate as well. A move can break references, take a record out of the folder a retention or review process expects, or change who can see it, even though no bytes are destroyed.

Treat any tool you have not classified as gated by default. Servers add tools over time, and an allow-list of known reads is safer than a deny-list of known deletes.

Why client prompts and OAuth scopes are not enough

A confirmation prompt in the MCP client is a courtesy inside one application. It only protects calls that pass through that client, it depends on each client implementing it correctly, and it can be skipped in headless or automated runs. It also rarely establishes who approved the call. A user who clicks through repeated prompts has not necessarily reviewed the specific file.

OAuth scoping helps with least privilege but operates at a different level. A token authorizes a server to act, not each individual call. Where one grant covers both reading and modifying files, scope alone cannot separate a harmless read from a destructive call made moments later by the same agent. Descriptions or hints that a server supplies about its own tools are self-declared metadata. They can inform classification, but they are not an enforcement mechanism.

The stakes of getting this wrong are practical. NIST IR 8006 identifies deletion in the cloud as a forensic challenge: recovering deleted data and attributing it to a specific user can both be difficult. If a destructive call has already run, you may not be able to reconstruct who caused it. The approval record therefore needs to exist before execution.

Where approval can be enforced

There are three realistic enforcement points. They differ in how easily they are bypassed, what they add to latency, and how well they bind a decision to a named person. In the execution-path option, Trussed is one way to enforce policy on MCP tool calls at runtime, with escalation for human approval as one of the available actions alongside allow, redact and block.

• MCP client confirmation: Lowest effort. Bypass risk is high because any client or automation path that omits the prompt skips the control. Latency is bounded by the user. Approver identity is usually the local session user, with little evidence kept.
• Custom server wrapper: You wrap or fork the Drive MCP server and add an approval step before destructive handlers run. Bypass risk is lower if nothing can reach the underlying server directly. You own the build, the maintenance and the approval workflow, and you must repeat the work for each server.
• Policy enforcement in the execution path: A policy layer sits between agent and tool, evaluates each call, and escalates matching calls for human approval. One rule set can cover several servers. It adds a hop, and it needs a defined approver channel and a rule for failure.

Implementation outline

The steps below apply whichever enforcement point you choose. The order matters: classification and identity decisions come before any approval workflow is built.

• 1. Inventory and classify tools: List every tool the server exposes, assign read, relocate, destroy or change-access, and default unknown tools to gated.
• 2. Write the policy: Allow reads. Escalate relocate, destroy and change-access calls. Add parameter conditions, such as a protected folder or a bulk operation, that always require approval.
• 3. Route to a named approver: Define approval authorities per tool or folder. Exclude the requesting user from approving their own agent's call.
• 4. Confirm approver identity: Use a secondary channel tied to an authenticated person, in the spirit of the out-of-band approval pattern in NIST SP 800-63B-4.
• 5. Bind approval to the call: Make each approval single-use and tied to the exact tool, parameters and file identifiers. A changed parameter needs a new approval.
• 6. Test the bypass paths: Try calling the server directly, through another client, and with altered parameters. Confirm the gate holds in each case.

Timeouts, denials and least-privilege scoping

Timeout and denial handling is a design choice, and the safe default is to block. If no approver responds within a defined window, the call should not run. Return a clear, structured result to the agent stating that the action was denied or expired, so it does not retry in a loop or look for another route to the same outcome. Cap retries, and require a fresh request, with a fresh approval, rather than extending an expired one.

Pick the window to match the work. A short window suits interactive sessions. Unattended jobs may need a queue with an owner and an expiry, so that stale requests do not accumulate and get approved later without context.

Scope the credentials as well. Where possible, give the agent a read-only grant by default and keep any credential that can modify or delete files separate, available only to the path that sits behind the gate. This follows the need-to-know principle that delete and access-change rights are assigned individually. Scoping reduces what a mistake can reach, and the approval gate decides whether a specific call goes ahead. Use both, and do not treat either as a substitute for the other.