> ## Documentation Index
> Fetch the complete documentation index at: https://docs.mcpmanager.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Google Drive Folder Blocker
> How the Google Drive Folder Blocker protects sensitive Drive folders from being read or referenced through the Google Workspace MCP: what it inspects, how the folder-hierarchy walk works across shortcuts and shared drives, how to find folder IDs and configure the rule, the accepted ID format and supported maximum, the deleted-ID behavior and the opt-in per-request check that alerts when a protected folder has been deleted, and its fail-closed validation and failure characteristics.
The **Google Drive Folder Blocker** is a managed [gateway rule](/features/gateway-rules/overview) 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](/features/gateway-rules/custom-rules-engines) 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](/features/gateway-rules/overview) 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](#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.
```mermaid theme={null}
%%{init: {'theme':'base','themeVariables':{'fontFamily':'Lato, sans-serif','lineColor':'#6a6b76','primaryColor':'#e0e2e8','primaryTextColor':'#12141d','primaryBorderColor':'#6a6b76','edgeLabelBackground':'#ffffff','textColor':'#12141d'}}}%%
flowchart TD
A["🗂️ Tool call or result references Drive"] --> B["Extract every Drive file / folder ID"]
B --> C{"Is any ID — or one of its
ancestor folders — protected?"}
C -->|"Yes"| BLOCK["🚫 Block"]
C -->|"No — fully verified clean"| PASS["✅ Allow"]
C -->|"Couldn't fully verify"| FM{"Rule failure mode"}
FM -->|"Block (default)"| BLOCK
FM -->|"Allow"| PASS
classDef ok fill:#80cbc4,color:#062b4c,stroke:#00796b,stroke-width:1.5px;
classDef bad fill:#ec9c9d,color:#12141d,stroke:#eb5757,stroke-width:2px;
class PASS ok;
class BLOCK bad;
```
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](/features/gateway-rules/overview#detection-hook-when-a-rule-fires)).
* **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](#validation-and-failure-behavior) (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](/mcp-gateway-concepts/mcp-servers/remote) 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):
```
https://drive.google.com/drive/folders/1aBc-Defg_Hij1234567890KLMNOPQRSTu
└──────────────┬──────────────────┘
the folder ID to protect
```
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.
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`.
Set the **Endpoint URL** to:
```
https://app.mcpmanager.ai/api/v1/mcpm/rule-engines/gdrive-folder-blocker
```
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](#warn-on-deleted-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.
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](#validation-and-failure-behavior) 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](#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](/features/gateway-rules/overview#failure-mode-what-happens-when-a-detection-method-fails).
**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).
## Warn on deleted folders
A protected entry whose folder has since been **deleted** keeps behaving as a safe [no-op](#validation-and-failure-behavior) — 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](#how-it-appears-in-logs-and-alerts) 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](/features/viewing-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](/security/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](/features/feature-provisioning).
## How it appears in logs and alerts
The Folder Blocker behaves like any [custom rule engine](/features/gateway-rules/custom-rules-engines) in your [logs](/features/viewing-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](#warn-on-deleted-folders) is enabled — alerts that a protected folder has been deleted. See [Audit & Observability](/security/audit-and-observability) for what each leg stores.
## Further reading
Detection methods, hooks, failure modes, actions, and rule ordering.
How managed and custom engines are added, configured, and applied to rules.
Where in-path enforcement fits in MCP Manager's security model.
Control which Workspace tools — including Drive search — a gateway exposes.