The failure this playbook is built to stop
Someone in operations asks an assistant to tidy a folder of signed contracts. The assistant has a Drive connector, so it moves files, and on the way it changes who can open one of them. Nobody set out to re-share anything. That is the failure worth designing against before a company-wide rollout, not after it. Here is how to set up Google Drive MCP access for Claude so sharing permissions stay intact.
Anthropic's own page says Claude's Google Drive connector writes as well as reads. It can share, move and trash files, upload files and create folders (Use Google Workspace connectors, checked October 2026). Anthropic's Google Drive connector page does not document a way to limit that connector to one folder or one shared drive (checked October 2026).
The Google layer does not offer folder scoping either. A Drive API scope that limits an app to one folder is not documented on Google's Choose Google Drive API scopes page (checked October 2026). The narrowest scopes it lists grant per-file access. A files.list query naming a parent folder is a filter, not an access control. It narrows which of the user's files the list returns (Search for files and folders, checked October 2026).
So the real boundary is two things: each person's own Drive permissions, and the set of tools the AI client can actually call. The same question comes up for other file stores, and the Box rollout answers it the same way.
How to set up Google Drive MCP access for Claude
The rollout has two halves, and both are per person. An Owner publishes Elaichi once in Claude, and then each member signs in to Elaichi and to Google as themselves. MCP is the open protocol AI clients use to call tools. Elaichi serves it at one endpoint (one address a client posts to), https://api.elaichi.ai/mcp, the same string for every organization.
- On a Claude Team or Enterprise plan, an Owner or Primary Owner adds a custom connector from Organization settings > Connectors. Click Add, hover over Custom and choose Web (Get started with custom connectors using remote MCP, checked October 2026). Give it the Elaichi endpoint.
- Each member then finds it under Customize > Connectors, usually marked Custom, and clicks Connect to authenticate (same Anthropic page, checked October 2026).
- Connecting sends the person to Elaichi's consent screen. They pick the organization, tick "Run your connected tools", and choose either all their tools or only toolboxes they name. A toolbox is a named list of tools pinned to connections.
- In Elaichi, each person connects their own Google account to the googledrive connector. Creating a personal connection is a default Member permission.
Claude reaches a custom connector's remote MCP server from Anthropic's cloud, not from the user's device (Anthropic, checked October 2026). That holds on every Claude client, including Claude Desktop and the mobile apps, so nothing runs on the employee's laptop. For the client-by-client walkthrough, see connecting Claude to Elaichi.
Which restrictions to write, and on which roles
Two restrictions cover Google Drive. A restriction in Elaichi says which connectors and tools a role or one member may reach. It is checked before a call leaves Elaichi.
Start from what the connector actually holds. Elaichi's googledrive connector carries 28 tools. Twenty-five of them read: files, folders, shared drives, search, export, permissions, labels, revisions, comments and replies, Docs, Forms and the change log. The other three are create_a_googledrive_watch, create_a_googledrive_changes_watch and delete_a_googledrive_channel_by_id. None of the 28 tools creates, edits, shares, moves or deletes a file. The re-sharing failure is off the table by construction, not by configuration.
Restriction one: block the two watch tools for every role except IT. Both ask Google to post change notifications to an HTTPS address the caller supplies. That turns a Drive change feed into an outbound stream to a URL a model chose. Write them as block rules naming those tools on the googledrive connector. A block rule matches by name or by the operation Elaichi pinned when the rule was saved. Renaming a tool cannot slip it past.
Restriction two: keep Drive apart from the rest of Workspace. Google Workspace is covered in Elaichi's catalog by separate connectors: gmail, googledrive, googlecalendar and googledocs. A rule written on googledrive does not touch gmail. If a role should reach Drive and nothing else from Google, block the other three whole for that role. Do not reach for an allow rule instead unless you mean it. Once a role carries any allow rule, every connector and tool its allow rules do not name is blocked for that role. An allow-list role therefore needs a whole-connector allow rule for every other app it uses.
Two scoping notes. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. So a company-wide rule means writing it on each role in use. For a contractor who should see less than their role allows, add a rule aimed at them personally. A member's personal rule can only narrow what their role permits.
Timing matters for the rollout plan. A role or restriction change takes effect within about two minutes. Revoking a share or disconnecting an account takes effect on the next call, and so does removing or suspending a member.
Why one shared Drive connection breaks the permission story
Every call through a connection fetches the credentials of that one connection's bound account, whoever is calling. A connection shared with a team therefore runs on its owner's sign-in to Google. One shared Drive connection across a company would give everyone the owner's Drive reach. Google's own checks would then be computed for the owner, not for the person asking.
That is why the per-person step is not optional here. Tools that run on each person's own account come from each person's own connections. That means their All tools toolbox, a toolbox they build themselves, or a template each person stamps while picking their own Google account. Share a template at use, and each teammate stamps their own copy. The per-person Dropbox rollout walks the same pattern on a different client.
With that in place, Google stays the authority. The Drive API answers 404 notFound when the user does not have read access to a file, or when the file does not exist. Google documents that in Handle errors (checked October 2026). For the narrower question of scoping one person's Drive reach, read the companion piece on scoping Google Drive in Claude to people or folders.
The audit query that proves it
Query the audit log for the assistant category, not the mcp one. In the console, that is the Audit log with the category filter set to Assistant and a free-text search for googledrive. On the REST API it is GET /audit-log?category=assistant&q=googledrive&since=2026-10-01. Connected-tool calls sit in the assistant category because their action is assistant.toolbox_tool; the mcp category holds actions such as a client's OAuth grant.
Each connected-tool row records the acting user, the connector, the connection the call reached, and the tool's advertised and catalog names. It also records the tool's classification, the outcome, the surface, and the MCP client's id. The surface reads mcp for a client such as Claude. For a list or search call it also records how many results came back. The console's detail panel renders it as a sentence naming the client and the connection. For example: "Using Claude, Emily Carter updated the page ... through the connection ...". To check one connection's Drive activity, pass its connection_id. The connection's owner, anyone with edit access on it, and anyone holding audit:view can read that.
Be honest about what the log cannot show. A call a restriction withheld writes no row, because the refusal happens before any executor runs, so a working block appears as absence. The evidence for the block itself is the restriction.created row. A search_tools result also names the blocked tool and flags it restricted, with no schema. Elaichi keeps 90 days of audit history; for longer, export to your own Datadog comes with the Black plan, which is launching soon. What belongs in these records is covered in the audit log field list.
What Claude's own tool permissions can and cannot do here
Claude connector tool permissions take one of three settings: Always allow, Needs approval or Blocked (Use connectors to extend Claude's capabilities, checked October 2026). Each setting applies to a whole connector, a category of its tools or a single tool. Against Elaichi those settings act on Elaichi's own tool names. In an MCP client's tool list, connected tools are never listed one by one, however few there are. Connected tools are found with search_tools and run with execute_tool.
So a per-tool setting inside Claude cannot single out Google Drive, and it cannot tell Drive from Gmail. Per-app and per-tool control belongs in Elaichi's restrictions. Elaichi's execute_tool is annotated destructive and open-world, never read-only. A client setting that lets read-only tools run unprompted therefore prompts for every connected-app call, reads included. The trade-off between the two layers is laid out in restricting one tool versus the whole app.
When Claude's own Google Drive connector is enough
If Drive is the only app and Claude is the only client, you do not need a second vendor. Anthropic's page says Google builds and runs the Google Drive connector, and each person signs in with their own Google account. Team and Enterprise Owners can set its tools to Always allow, Needs approval or Blocked. Anthropic's example allows Drive reads while preventing document creation or editing (Google Drive, checked October 2026). An Owner enables it once and members connect themselves.
The case for one governed endpoint starts later. It starts when Drive is one of several apps, or when ChatGPT and Cursor need the same rules as Claude. It also starts when the quarterly access review wants one audit trail covering all of them. That is the shape described in MCP governance, and the apps it reaches are listed in the connector catalog.
