Scoping the Google Drive MCP Server to Approved Folders Only

Define the boundary before choosing controls

A Google Drive MCP server typically exposes a handful of tools, such as search, list, read and write, behind one credential. The agent never sees Drive permissions directly. It sees whatever the server and credential allow. That makes the boundary a design question first and a configuration question second.

Start with an approved-folder list written as explicit policy. For each entry, record the folder identifier, the permitted operations (for example read only, or read and write), whether child items are included, and the business rationale. NIST ties zero trust access policies to acceptable risk for the business process they serve, and a recorded rationale per folder gives reviewers the same anchor.

The model for the policy is the one NIST describes for access control generally: mediation between subjects and objects, limited to allowable operations by allowable subjects. Here the subject is the agent or MCP credential, the objects are Drive items, and the operations are search, list, read and write. Set the default decision to deny, so anything not named in the list is refused. This follows the same least-privilege and default-deny principle NIST applies to network traffic, applied here by analogy to Drive content.

Compare the four scoping layers

No single layer is a reliable folder boundary on its own. Each narrows exposure in a different place, and each can be misconfigured independently, which is why they are combined. Confirm the exact behavior of each layer against current Google and MCP server documentation and in a test environment before relying on it.

• Credential and OAuth scope design: Limits what the credential can do at all. Scopes describe categories of access, so treat them as a ceiling on capability rather than a list of folders. Choose the narrowest scope that supports the tools you actually expose.
• Service account or shared-folder permissions: Limits which content the identity can reach. Grant access only to approved folders and review what is inherited or shared in from elsewhere. This is the strongest native control, but it depends on Drive hierarchy staying as you designed it.
• Server-side configuration: Limits which tools exist and, where the implementation supports it, which locations they accept. Disable write or search tools that the use case does not need. Restrictions vary by implementation.
• Policy enforcement on tool calls: Evaluates each request against the approved-folder list before it reaches Drive. It does not depend on the upstream layers being perfect, and it is where denials are recorded.

Bypass paths to design against

Most scoping failures are not attacks on a control. They are legitimate calls that resolve to content nobody meant to include. Treat the paths below as a test matrix rather than assumptions, because each can behave differently depending on the credential, the Drive layout and the specific MCP server.

Search is the first concern. If a credential can see content outside the approved folders, a search tool can return it, and a list tool can enumerate it. Controlling this means either removing that visibility at the permission layer or filtering results and parameters at the policy layer.

Direct file-ID calls are the second. An agent that obtains an identifier from a prior result, a document body or a user prompt can request the item without browsing to it. The decision therefore has to resolve the item to its parent chain and compare that with the approved list, not just inspect the request text.

Shortcuts, shared drives and inherited permissions complete the set. A shortcut can place a pointer inside an approved folder to content stored elsewhere. Shared content can appear through a route you did not grant. Inheritance can extend access to child items you did not intend. For each, decide explicitly whether it is in or out of scope, and write that decision into the policy.

Enforce the list on every tool call

Native permissions and server configuration are set up once and drift over time. A runtime layer decides each request as it happens, which matches the NIST position that access decisions should be least-privilege, per-request and context-based, with authorization strictly enforced. In zero trust terms, a policy decision point evaluates the request and an enforcement point in the execution path applies the result.

Trussed enforces policy in the execution path across agents, tools and MCP servers, at the level of individual interactions and tool calls. For a Drive MCP server, that means each search, list, read or write call is evaluated against the approved-folder policy and receives an allow, redact or block decision before it completes. Policy is enforced at runtime, not reviewed after the fact. Because the decision sits outside the server and the credential, a permissive scope or a misplaced shared folder does not by itself widen what the agent can do.

The policy design still matters. Rules should evaluate the operation, the resolved target and its parent folders, and default to block. Redaction suits cases where a call is in scope but a result contains content that should not reach the model. Write operations usually deserve a narrower rule set than reads.

Test the boundary and keep the evidence

An approved-folder boundary is only credible if you can show that out-of-scope requests were refused. Build the enforcement test from the bypass matrix and repeat it after any change to the policy, the Drive layout, the credential or the server version.

Each record should state the identity that made the request, the tool and its parameters, the resolved target item and parent folder, the policy version applied, the decision (allow, redact or block), the reason for it, and a timestamp. For denied calls, include the rule that matched or the default-deny fallthrough. Records of allowed calls matter too, since they show the agent stayed within scope during normal use. Which fields you retain, and for how long, is your own design decision and should reflect your audit obligations.

For control mapping, the Access Control family in NIST SP 800-53 Rev. 5 is the natural reference for access enforcement, and its refinement language is a useful way to document how a general control is narrowed to the approved-folder scope. Trussed generates audit-ready evidence from enforcement, mapped to frameworks including NIST, so the denial record is a by-product of the decision itself rather than a separate reconstruction. The platform has run in continuous production in a regulated enterprise for more than 18 months, and its deployment can be self-managed in the customer cloud with configurable retention and data residency.