Blocking AI Agents from Sharing Files Externally Through the Google Drive MCP Server

Why sharing through an MCP server needs its own control

An MCP server acts with delegated user permissions. When an agent calls a Drive tool, the call runs with the authority of the connecting user or service account. Nothing in that arrangement distinguishes a call that reads a document from one that makes the same document reachable by someone outside the organization.

MCP also uses dynamic, tool-based architectures and chained tool calls, so one manipulated step can feed later ones. Indirect prompt injection makes this concrete. Text in a document, web page or API response that the agent retrieves can carry instructions, and that content can be staged entirely outside your organization's control. An agent that reads a poisoned file and holds a sharing tool has what it needs to exfiltrate data, using permissions you granted on purpose.

The practical conclusion is that identity-level settings are necessary but not sufficient. You also need a decision point at the level of the individual tool call.

Map the tool calls that can create external exposure

Start with an inventory of the tools your Drive MCP server exposes, whichever implementation you run. Read the tool definitions and the underlying API operations, and classify each by effect. Do not rely on a tool's read or write label to judge risk. Annotations should be treated as untrusted unless they come from a server you trust, and a tool that looks like a minor update can still disclose data or make an irreversible change.

A workable classification groups tools by the exposure they can create:

• Permission creation: Adds a user, group or domain to a file or folder. Exposure depends on the recipient. Evaluate the recipient domain and role.
• Link sharing changes: Enables access by link, including public or organization-wide links. Treat as high risk by default.
• Ownership transfer: Moves control of a file to another account. Difficult to reverse, so block or require approval.
• Permission modification: Raises a role, for example from viewer to editor. Check whether the recipient is external.
• Copy or move operations: Places content in a location with different sharing. Evaluate the destination's existing permissions.
• Read and search: Does not share by itself, but supplies content that may carry injected instructions or sensitive material.

Configure the Workspace side first, and know its limits

Begin with the controls that reduce the blast radius of any call, allowed or not. Restrict external sharing and link sharing in Workspace to what the business needs. Request the minimum OAuth scopes the agent's task requires, and ask whether it needs any scope that allows permission changes at all. If the server uses a service account, give it access only to the folders and shared drives the agent works with, and avoid broad delegation that lets it act across many users.

Follow the OWASP guidance on credentials: grant the Drive MCP server the minimum permissions for its function, use scoped per-server credentials, and never share tokens across servers. Keep a sensitive server like Drive separate from general-purpose ones. Sandbox the server process, because avoiding a listening endpoint does not by itself restrict its file system, network or credential access.

These settings apply to the connecting identity. They do not evaluate what a particular tool call is trying to do, and they do not record why an action was permitted. Scope also drifts. Temporary or loosely defined permissions tend to expand over time, which OWASP lists as privilege escalation via scope creep. Review the agent's permissions on a schedule so they stay within the original grant.

Enforce policy on the tool call in the execution path

The second layer sits between the agent and the Drive MCP server. It inspects the tool name and arguments for each call and decides before execution. This is enforcement at runtime, not review after the fact, and it addresses the gap the Workspace layer leaves.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. For a Drive MCP server, that means allow, redact, block, rate limit and escalate for human approval, applied to individual tool calls. Scope matters here: this is control of interactions and tool calls, not tracing of an entire multi-agent workflow.

Whatever mechanism you choose, test it against a few criteria. Can it evaluate the call's name and arguments before execution? Can it route sharing calls to a human and bind the approval to the specific action? Does it treat tool annotations and retrieved content as untrusted? Does it produce durable records of each decision?

Define allow, redact, block and escalate rules for sharing actions

Write rules against conditions you can read from the call: tool name, permission type, recipient domain, file label or sensitivity, and whether approval exists. These fields are a practical design, so adapt them to how your organization classifies data. Evaluate the effect of the call, not only its label, and default to deny for sharing tools that no rule covers.

OWASP advises requiring explicit confirmation for data-sharing operations and never auto-approving tool calls, particularly in multi-server setups. Bind each approval to the specific action and arguments, and prevent its reuse. An approval for one file and one recipient should not cover a second call.

• Allow: Read and search calls, and sharing to internal recipients on files not labeled sensitive. Apply rate limits to bound repeated calls.
• Redact: Remove sensitive values from content or free-text arguments, such as a notification message, when the call is otherwise acceptable.
• Block: Public or anyone-with-link sharing, ownership transfer to outside accounts, and any external recipient on a sensitive file.
• Escalate for approval: Sharing with an external domain that a business owner has a reason to permit. Present the file, recipient, role and expiry to the approver.
• Rate limit: Cap permission changes per session so a hijacked agent cannot work through many files quickly.
• Default deny: Block any sharing-capable tool added later until it has been classified and given a rule.

Decide what evidence to retain

Auditors and incident responders need to know what the agent was allowed to do and what it did. OWASP recommends detailed records of tool invocations, context changes and user-agent interactions, kept in immutable audit trails, and preserving input provenance so a sharing action can be traced to what the agent read.

For each sharing call, retain the timestamp, the agent and the connecting identity, the tool name, the full arguments, the recipient and permission type, the file label, the policy rule that matched, and the decision. For escalations, add who approved, when, and which action and arguments the approval covered. Where the call followed retrieval of content, keep a reference to that input.

Trussed produces audit-ready evidence as a product of enforcement, with configurable retention and data residency and self-managed deployment in the customer cloud. Whatever system you use, store the evidence where those who administer the agent cannot alter it, and review blocked and escalated calls regularly. They show where the agent is attempting actions you did not expect.