Skip to main content
The Google Drive Folder Blocker is a managed gateway rule that stops an AI client from reading — or even referencing — files inside Google Drive folders you mark as protected. It is the gateway-side guardrail for the Google Workspace MCP: once enabled, it inspects every Workspace request and response that touches Drive and blocks anything that resolves into a protected folder, no matter how deeply the file is nested, whether it is reached through a shortcut, or whether it lives on a shared drive. Like every managed engine, you add it under Rule Engines and then apply it as a detection method on a gateway rule. It is configured by pointing a custom rule engine at an MCP Manager-hosted endpoint and listing the folder IDs to protect.
The Folder Blocker is purpose-built for the Google Workspace MCP. Like all gateway rules it inspects only tools/call arguments and results (not prompts or resources). It resolves Drive folders using the calling user’s Google identity, which MCP Manager forwards to the engine automatically when you configure it — see Set up the Folder Blocker below.

​
What it protects against

The Folder Blocker enforces a folder boundary at the gateway, independent of each user’s own Drive permissions. The problem it solves: a user (or an agent acting on their behalf) often has legitimate Drive access to a sensitive shared drive — HR, legal, finance, executive — but you don’t want that content reachable through an AI client. Drive’s own sharing model can’t express “this person may open the folder, but their AI assistant may not.” The Folder Blocker can. Once active, protection applies automatically to everyone whose traffic flows through that gateway — you configure it once, not per user. An administrator sets it up inside MCP Manager; end users simply continue connecting their AI client to the gateway URL, and protected folders are unreachable through it.

​
How it works

On each Drive-touching tool call, the engine extracts every Drive file and folder ID it can find in the message — from IDs in tool arguments, URLs, and the structured fields a Workspace tool returns — and then determines whether any of them sit inside a protected folder. Because the protected set is checked against each item’s ancestor chain, a file is caught even when it is nested many levels below the folder you listed. The walk is built to leave no quiet gaps:
  • Full hierarchy. Each referenced item’s parent chain is walked upward, so a file deep inside Protected/2026/Q3/board-deck is blocked by listing Protected.
  • Shortcuts are resolved. A Drive shortcut that lives in an allowed folder but points into a protected one is followed to its target, so it can’t be used as a side door.
  • Shared drives included. Items on shared drives (formerly Team Drives) are resolved correctly, so a protected shared-drive folder is enforced just like a My Drive folder.
  • Both directions. The rule fires on the request leg (catching content-extraction tools such as get_drive_file_content and export_doc_to_pdf, where the file ID is in the arguments and no ID comes back in the result) and on the response leg (catching metadata-returning tools such as search_drive_files and list_drive_items, where the ID is only in the result). The engine pre-selects both directions, so adding it materializes a paired request + response rule (see Detection hook).
  • Fail-closed by design. If the engine can’t fully verify a request — a Drive lookup fails, the hierarchy is implausibly deep, or the payload references more items than it can check — it returns an error rather than guessing, and the rule’s failure mode (Block by default) decides the outcome. It never lets an unverified reference through silently.

​
Before you start

The Folder Blocker depends on the Google Workspace MCP already being governed by MCP Manager:
  1. The Google Workspace MCP is added as a remote MCP server and provisioned to the gateway you want to protect. MCP Manager handles the Google OAuth and proxies Workspace requests on each user’s behalf — no one manages raw tokens.
  2. End users connect their AI client to the gateway URL (not the Workspace server URL). The gateway is where the Folder Blocker and every other rule are applied.

​
Find a folder or shared drive ID

A protected entry is a Drive folder ID or shared drive ID. To get one, open the folder in Google Drive and copy the identifier from the URL — it is the segment after /folders/ (for a folder) or /drive/folders/ (inside a shared drive):
You can list as many as you need. Protecting a top-level folder automatically protects everything nested beneath it, so you usually list the few high-level folders that bound the sensitive content rather than enumerating every subfolder.

​
Set up the Folder Blocker

Setup is deliberately short: once MCP Manager recognizes the managed endpoint URL, it configures the engine for you, so you only name it, set the URL, and fill in the folder list.
1

Add the rule engine and name it

Open Rule Engines in the left-hand navigation, click Add, and choose the Custom provider. Give it a clear name such as Google Drive Folder Blocker.
2

Set the Endpoint URL

Set the Endpoint URL to:
As soon as MCP Manager recognizes this as the managed Folder Blocker endpoint, it configures the rest for you: the HTTP method is set to POST, the internal access token is injected (you never see or set it), header forwarding is enabled so the calling user’s Google identity reaches the engine and it can resolve each file’s ancestor folders as the requesting user, and the mcpm-gdrive-blocked-folders header is added ready for its value. A second header, mcpm-gdrive-warn-deleted-folders, is added at the same time and pre-set to false — leave it as-is unless you want the opt-in deleted-folder alert.
3

Fill in the protected folders

In the pre-added mcpm-gdrive-blocked-folders header, paste the folder IDs from the previous section as the value. Separate them with commas, whitespace, or one per line — all three are accepted (a JSON array works too). Save the engine.
4

Apply it to the gateway

On the gateway’s Rules tab, add a rule and choose the Folder Blocker from the Detection method dropdown. It pre-selects both directions, so saving creates a paired request + response rule. There is no action picker — the engine’s verdict drives the outcome — and the rule’s failure mode defaults to Block.

​
Accepted folder ID format

Each entry must be a syntactically valid Google Drive identifier:
  • Character set — the URL-safe characters Drive uses: A–Z, a–z, 0–9, -, and _. No spaces or other punctuation inside an ID.
  • Length — roughly 19 to 44 characters. Shared drive IDs are around 19 characters; file and folder IDs are longer. The blocker validates against this range rather than a single fixed length, so both shapes are accepted.
Surrounding whitespace around each entry and a single trailing comma are tolerated and cleaned up for you. The blocker will never merge or split your tokens to “fix” them — see the next section for why that matters.

​
Supported maximum

A single Folder Blocker rule can protect well beyond any realistic list — the enforced maximum is 500 folder IDs, comfortably above the few hundred that the largest real-world deployments use. The limit is checked when you save, so an oversized list is rejected up front with a clear message rather than being silently truncated at runtime.
You rarely need a large list. Because protection is inherited down the hierarchy, listing a handful of top-level folders (one per sensitive shared drive, say) usually covers thousands of nested files.

​
Validation and failure behavior

The Folder Blocker is designed to never weaken protection silently. A misconfigured list fails loudly; a list that can’t be fully evaluated fails closed. The behavior splits cleanly between save time and request time. At save time, the list is validated before it is stored:
  • A token that isn’t a valid Drive ID — wrong characters, too short, too long, or two IDs merged by a dropped comma — is rejected with an error that names the offending token, so you can find and fix it immediately.
  • A list that exceeds the supported maximum is rejected the same way.
  • Whitespace and a single trailing comma are normalized away, but tokens are never auto-merged or auto-split — a malformed entry is reported, not “repaired” into something you didn’t intend.
At request time, the engine errs toward protecting what you asked it to:
  • If a stored list somehow can’t be parsed safely, the engine fails closed — it blocks that gateway’s Drive traffic rather than under-protecting, and it never silently ignores a token it can’t understand.
  • If the engine can’t fully verify a particular call — a Drive API error, a hierarchy deeper than it will walk, or a payload referencing more items than it can check — it returns an error. The rule’s failure mode then decides: Block (the default for custom engines, and the recommended setting here) fails closed; Allow fails open. See Failure mode.
Deleted or inaccessible folders are safe to leave in the list. A well-formed ID that points to a folder which has since been deleted — or that the requesting user can’t see — is treated as a harmless no-op: it simply matches nothing. Every other entry in the list keeps protecting normally, and the request is not errored on account of the stale entry, so it never breaks the rest of the list. By default the blocker stays quiet about such entries; if you want to be told when a protected folder has been deleted, opt in with Warn on deleted folders.

​
Warn on deleted folders

A protected entry whose folder has since been deleted keeps behaving as a safe no-op — it matches nothing and never errors a request. Confirming that a listed folder no longer exists, though, means issuing a Drive get for the folder on every request the rule inspects, which adds latency to all of the gateway’s Drive traffic. Because most lists are stable, that check is off by default and must be explicitly opted into. To enable it, set the mcpm-gdrive-warn-deleted-folders header to true. Like the mcpm-gdrive-blocked-folders header, MCP Manager adds this header for you — pre-set to false — when it recognizes the managed endpoint, so you only change the value:
  • false (default) — no extra lookup. Deleted entries stay silent no-ops, and Drive traffic keeps the lowest latency.
  • true — each protected folder is resolved on every inspected request, and when one is found to have been deleted the blocker raises an alert (an McpAlertMessage) so you can prune the stale entry. Turn on the rule’s Alerts toggle as well to actually be notified.
Enabling this trades latency for visibility: it performs an extra Drive get on every inspected request to confirm the listed folders still exist, which slows all of the gateway’s Drive traffic. Switch it on when you actively want to catch removed folders — for example while cleaning up a large list — and consider turning it back off once the list has settled.

​
Validating it works

The standard rule-engine Test action can’t meaningfully exercise this engine: a test runs outside a live gateway session, so there is no forwarded Google identity for it to query Drive with (and a real test would forward live Google credentials on every check). Validate it live from an AI client instead:
  1. Ask the assistant to open or summarize a file you know is inside a protected folder — it should be blocked.
  2. Ask it to open a file outside every protected folder — it should work normally.
Confirm both before relying on the rule. Each result is also visible in your logs.

​
Security characteristics and limitations

  • Identity-aware, gateway-enforced. The boundary is enforced at the gateway using the user’s own forwarded Google identity, so it holds regardless of how the file is reached — and applies uniformly to every user on the gateway without changing anyone’s Drive permissions.
  • Defense against indirect access paths. Nesting, shortcuts, and shared-drive placement are all resolved during the ancestor walk, closing the obvious ways a protected file could be reached without naming its folder directly. The engine’s threat model is maintained as a catalog of closed circumvention paths.
  • Fail-closed posture. Combined with the default Block failure mode, an unverifiable or misconfigured state errs toward blocking rather than leaking — consistent with the rest of MCP Manager’s runtime protections.
Residual exposure: Drive search can leak existence. The Folder Blocker stops protected files from being read or referenced — their contents and metadata never leave Drive. It does not, however, hide the signal that something matching a query exists: Drive search (search_drive_files) can still return a non-empty result indicating that a file matching the query lives somewhere the user can see, including inside a protected folder, even though the matched content stays blocked. This is inherent to allowing search at all.If that inference is in scope for your threat model, close it completely by disabling the Drive search tool (search_drive_files) on your gateway, so it is never exposed to clients in the first place. You control exactly which of a server’s tools a gateway offers through Feature Provisioning.

​
How it appears in logs and alerts

The Folder Blocker behaves like any custom rule engine in your logs: each run records the engine, its verdict (pass / block / error), and a comment explaining the decision — for example, which protected folder a blocked file resolved into, or which Drive lookup failed. A block is also recorded as a policy_enforced_abort entry. Turn on the rule’s Alerts toggle to be notified whenever it acts, including fail-closed warnings and — when Warn on deleted folders is enabled — alerts that a protected folder has been deleted. See Audit & Observability for what each leg stores.

​
Further reading

Gateway Rules Overview

Detection methods, hooks, failure modes, actions, and rule ordering.

Custom Rule Engines

How managed and custom engines are added, configured, and applied to rules.

Runtime Protections

Where in-path enforcement fits in MCP Manager’s security model.

Feature Provisioning

Control which Workspace tools — including Drive search — a gateway exposes.