Restricting Google Drive MCP Search to Approved Shared Drives for Wealth Management Agents

How Drive search reaches an agent, and where over-broad retrieval starts

A Google Drive MCP server exposes file search as a tool. The agent supplies a query and optional parameters. The server calls the Drive API with a stored credential and returns file metadata or content to the model. The agent never touches Drive directly, so the server's credential defines the outer boundary of what any search can reach.

Over-broad retrieval arises because that boundary is set by the identity, not by the task. If the connected account is a member of many shared drives, an unconstrained search can match files in all of them. For a wealth management agent, that can include client records, advisor notes, and compliance files that sit well outside the agent's business purpose. A prompt that asks for "recent suitability documents" can return material from drives the agent was never meant to use.

The agent's own instructions are not a control here. The model decides which parameters to send, and prompt text can be overridden or manipulated by content the agent reads. Scoping has to be enforced outside the model.

What identity and permission controls can and cannot do

Drive permissions, shared drive membership, and OAuth scopes determine what the connected identity can see. They are necessary, and they set the ceiling. NIST SP 800-207 states that least privilege applies to both visibility and accessibility, so the first step is to ensure the agent's identity cannot see what the agent should never touch.

They are not sufficient. An identity is usually a member of several shared drives because its owner has more than one legitimate use. Once a credential is bound to an MCP server, every agent and every search that uses it inherits the same reach. NIST zero trust guidance notes that purely identity-based enforcement should be augmented by other factors when authorizing access, and that service-identity policies are hard to administer consistently across environments. Splitting identities per purpose helps, but it multiplies credentials to manage and still does not describe which drives a particular search may query.

NIST SP 800-53 Rev. 5 points at the missing layer. Its information sharing enhancement for search and retrieval calls for services that enforce organization-defined sharing restrictions. The search and retrieval path itself should apply the restriction, not only the account behind it.

Designing the layered restriction

Build the restriction in layers, each reducing what the next layer must catch. Treat the allowlist as organization-defined policy, written per agent business purpose rather than per account.

• 1. Give each agent purpose its own identity: Separate agent identities from human users and from each other. Grant membership only in the shared drives that purpose requires. Treat agent authorization as its own design problem, consistent with current NIST NCCoE work on AI agent identity and authorization using OAuth 2.0.
• 2. Write the allowlist as policy: For each agent, list the approved shared drives by stable identifier, not by name. Express the rule as attributes of the subject (agent), data asset (shared drive), and application (MCP tool), in line with the policy definition in NIST SP 800-207.
• 3. Constrain query parameters: Have the tool or a layer in front of it set the shared-drive scope parameters from the allowlist and reject requests that name other drives or request a broader corpus. Do not let the model choose scope.
• 4. Verify with a test matrix: Test each parameter combination against the current Drive API behavior and your MCP server build. Include searches with no scope, with an unapproved drive, and with a mix. Record which combinations actually limit results.
• 5. Check results, not just requests: Compare each returned item's drive against the allowlist before it reaches the model. A request that looks scoped can still return items outside it if a parameter is ignored or behaves differently than assumed.

Evidence examiners and model risk reviewers will ask for

In financial services, supervisors and model risk reviewers focus on two questions about any system that touches client documents: what was the system permitted to do, and what did it actually do. Agent file search should be able to answer both for any call, without reconstructing events from scattered application records. This page makes no claim about specific regulatory text. It describes evidence that supports those questions under any reasonable reading.

Evidence of allowed scope is the policy and allowlist in force for each agent, with a version and change history. Evidence of actual retrieval is a per-call record: the agent identity, the tool, the requested scope, the policy decision, and the items returned or withheld. Keeping both in one record per call lets a reviewer compare intent with outcome directly. Blocked and escalated calls belong in the record too, since they show the control working.

Trussed generates continuous audit-ready evidence from enforcement itself, so the record is a product of the decision and not a separate reporting step. Retention period and residency should follow the firm's own recordkeeping requirements, which compliance teams need to define.

• Policy version: The allowlist and rules applied to the call.
• Requested scope: Query and scope parameters as submitted and as enforced.
• Decision: Allow, redact, block, or escalate, with any approver.
• Items returned: Which files and drives the agent actually received.