# Scope Google Drive in Claude to people or folders

> Google Drive in Claude has two honest shapes: each person connects their own Google account, or one dedicated account whose shared folders draw the line.

**TL;DR** Google Drive in Claude works in two shapes, both served through Elaichi's one organization-wide MCP endpoint. To leave each person's Drive permissions intact, share a template with the team at use so every member stamps a toolbox bound to their own Google connection. To hold a team to a fixed set of folders, connect a dedicated Google account that has only those folders shared to it and share that connection at use, because no Google OAuth scope limits an app to a folder.

## Google Drive in Claude: the two shapes that work

Someone in finance asks for Claude to read the board folder. Someone in support asks for Claude to search whatever they can already open in Drive. Those are two different builds. Treating them as one request is how a connection ends up reaching every file in the company.

Google Drive access from an AI client reduces to two honest shapes, regardless of which vendor's connector you use:

1. **Per-user OAuth**: each person connects their own Google account, so their existing Drive permissions bound every call.
2. **Dedicated account**: one Google account, with only the target folders shared to it, draws the folder line, and the team shares that one connection.

These are not Elaichi inventions. They are the two access patterns any OAuth-based Drive integration can offer. A Drive call made with a person's OAuth token is bounded by that signed-in account. Elaichi serves both through one organization-wide MCP endpoint. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi writes and runs its own connectors, 600+ of them. So Drive is served from Elaichi's infrastructure rather than a server someone on your team has to stand up and patch.

The same address answers ChatGPT and Cursor. The folder question does not change per client, and neither does the answer below.

**Simplest case first.** You just want Claude to read whatever one person can already open in Drive, with no folder boundary and no shared account. Shape 1 is it: connect your own Google account, done. The rest of this post is for the harder case. One version: the AI needs to see *less* than one person's full Drive. The other: the access needs to be shared across a team without multiplying individual logins.

## How does each person keep their own Drive permissions?

Each member connects their own Google account (shape 1). The way to hand that out at team scale is a template, not a shared toolbox. This part is Elaichi-specific plumbing. It is described here because it's the mechanism, not because it's the only way to think about the problem.

A template holds a tool list with renames, defaults and frozen arguments, and never holds a connection. Share it with the team at `use`. Each member then stamps their own toolbox from it. Stamping binds every entry to a connection that person can use, so their own Google account runs the call. Stamping copies once, so a later template edit leaves already-stamped toolboxes alone. A member who has not connected Google yet sees that entry marked "needs connection" until they do.

Sharing a toolbox does the opposite: every grantee's call then runs on the connection pinned in its entries, which belongs to the owner. Never pair "each person connects their own account" with "share one toolbox with the team". That silently runs everyone's calls on the owner's own Google account, with the owner's full Drive access.

This part is universal, not vendor-specific: Google enforces access at the API layer, not the AI client. The Drive API bounds every call by the signed-in user. It returns 404 `notFound` where the person has no read access, and 403 where they have no write access ([developers.google.com](https://developers.google.com/workspace/drive/api/guides/handle-errors), checked October 2026). A support agent asking about a folder nobody shared with them gets nothing back, for the same reason they see nothing in Drive itself. The same per-person shape is what keeps [each rep inside their own Salesforce sharing rules](/blog/sales-team-chatgpt-salesforce-accounts/).

## Can an OAuth scope limit Drive access to specific folders?

No. Stated flatly: **no Google Drive OAuth scope confines an app to a folder.**

- `drive.file` reaches only files the app created or opened, or that the user picked via Google Picker, a per-file consent pattern, not a folder boundary.
- `drive`, `drive.readonly`, and `drive.metadata.readonly` reach the user's entire Drive (and any shared drives they belong to).
- There is no `drive.folder` scope and no documented scope parameter that recurses into a folder tree.

(Source: [developers.google.com](https://developers.google.com/workspace/drive/api/guides/api-specific-auth), checked October 2026.)

A query such as `'FOLDER_ID' in parents and trashed = false` narrows a *search*, and Google does not document it as recursive into subfolders. A search filter is not a permission, and a model calling the tool can omit or alter the filter on its own.

So the only real folder line is drawn at the account level, not the scope level: the Google account the connection signs in with. The working pattern is:

1. Create a dedicated Google account.
2. Share only the folders that team should reach, to that account, in Drive's own sharing UI.
3. Connect that account to the MCP server (Elaichi or otherwise).
4. Share that one connection with the team.

A shared connection runs on its owner's credential. So every call reaches Drive as that account and sees exactly what was shared to it, nothing more. The dedicated account itself has nothing more. Anthropic recommends the same dedicated-account pattern for Claude Tag's Google connection. The account starts at no access and gains specific folders one at a time ([claude.com](https://claude.com/docs/claude-tag/admins/connections/google), checked October 2026). Before relying on the line, open Drive as that account and check what it can already see, such as files shared with your whole domain.

Two trade-offs come with this pattern:

- **Ownership:** the dedicated connection has an owner in Elaichi. Pick an owner who is staying, and transfer the connection during their offboarding. The credential is the dedicated Google account, not the owner's own, so a transfer keeps it working.
- **Scope only narrows the connection it's on.** A member who *also* connects their personal Google account reaches Drive under "All my tools" with their own full Drive access. That is shape 1 running beside shape 2, for that person only.

## Which tools can the Google Drive connector actually run?

Elaichi's `googledrive` connector connects over OAuth and carries 28 tools; 25 of them read. Files, folders, shared drives, drive items, search, export, permissions, labels, revisions, comments and replies, Docs, Forms and the change log are all reads. Names run like `list_all_googledrive_files` and `get_single_googledrive_file_by_id`. The full list is on the [Google Drive connector page](/connectors/googledrive/).

The other three are `create_a_googledrive_watch`, `create_a_googledrive_changes_watch` and `delete_a_googledrive_channel_by_id`. The first two ask Google to post change notifications to an HTTPS address the caller supplies. The third stops a channel. None of the 28 creates, edits, shares, moves, or deletes a file.

A team that only reads blocks those three tools. Blocks, not allows, are the right instrument here, for a structural reason:

- An **allow** rule becomes that role's *entire allowlist across every connector*, so the role loses every other app it had.
- A **block** removes exactly the named tools and leaves everything else untouched. Three blocks leave 25 reads.

In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A restriction change takes effect within about two minutes. Restrictions are applied before search, so a withheld tool reaches neither the tool list nor `search_tools`. The model cannot discover a tool it's been blocked from, let alone call it. The case-by-case version of this choice is in [restrict one AI tool or the whole app](/blog/per-tool-vs-per-app-restrictions/).

One thing the OAuth consent screen does **not** do: leaving "Create and change data" unticked does not make a connected app read-only in Drive. That checkbox governs Elaichi's own internal operations, not what the Drive API will accept from the connected account. Read-only access to Drive is a restriction you apply explicitly (the three-tool block above), not a side effect of a consent checkbox. It is the same way [QuickBooks has to be held to reads](/blog/finance-team-claude-quickbooks-read-only/) when the vendor ships no read-only scope.

## What does a Google Workspace admin set before any of this?

The Workspace control is **Manage App Access**, under Security, then Access and data control, then API controls. An app, found by name or OAuth client ID, is set to Trusted, Limited, Specific Google data, or Blocked. Unconfigured apps fall under "Allow users to access any third-party apps" ([knowledge.workspace.google.com](https://knowledge.workspace.google.com/admin/apps/control-which-apps-access-google-workspace-data), checked October 2026).

Order matters, and getting it backwards breaks working connections:

1. Mark the app **Trusted** first.
2. Restrict afterward (e.g., set Drive to Restricted for the org).

Setting Drive to Restricted *before* trusting the app revokes untrusted apps' tokens, including ones that were working that morning. Google's high-risk Drive scope list includes `drive`, `drive.readonly`, and `drive.metadata.readonly`, but does not include `drive.file`. Elaichi's console does not show which Google scopes its Drive connector requests. So find the app by name or OAuth client ID, rather than inferring it from the high-risk scope list.

Shared drives need a separate argument entirely. The Drive API returns shared-drive items only when a call sets `supportsAllDrives=true` and `includeItemsFromAllDrives=true`. The `corpora` argument takes one of `user`, `domain`, `drive`, or `allDrives` ([developers.google.com](https://developers.google.com/workspace/drive/api/guides/enable-shareddrives), checked October 2026). Google also states admins have no control over individual folders inside users' My Drives. That is another reason the dedicated-account pattern, not a central Workspace policy, is how a folder boundary actually gets drawn. Per-tool arguments are on the [Google Drive connector page](/connectors/googledrive/).

## Claude native connector vs. ChatGPT Drive app vs. an MCP endpoint

| | Claude's built-in Google Drive connector | ChatGPT's Google Drive app | Elaichi (MCP endpoint) |
|---|---|---|---|
| Permission model | Mirrors the connecting user's existing Drive permissions | Live access as the user, or admin-managed sync via domain-wide delegation | Per-user OAuth or dedicated-account, admin's choice |
| Folder-level restriction | Not documented | Admin-managed sync can include or exclude shared drives; no folder restriction documented | Dedicated Google account + Drive sharing (account-level, not scope-level) |
| Per-tool control | Always allow / Needs approval / Blocked, set by Owner | Actions switched per app on the Admin Console's Plugins page | Per-role/per-user restrictions on any of the 28 tools |
| Cross-app consistency | Claude only | ChatGPT only | Same endpoint, same restrictions, across Claude, ChatGPT, Cursor |
| Audit trail | Compliance API events on Enterprise | Compliance Logs Platform on Enterprise and Edu | One trail across every connected app |
| Availability | All plans; Team/Enterprise admin enables org-wide | Enterprise/Edu/Business, Admin Console managed | Any client that takes a custom MCP connector |

Sources: Anthropic states Claude "mirrors your existing permissions" ([support.claude.com](https://support.claude.com/en/articles/10166901-use-google-workspace-connectors), checked October 2026). OpenAI documents live access for a personal connection, and admin-managed sync through a domain-wide delegation service account. Individually authorized sync is retired ([help.openai.com](https://help.openai.com/en/articles/10929079-google-drive-app-and-setup-in-chatgpt), checked October 2026). Drive actions start off on Enterprise and Edu and on for Business ([help.openai.com](https://help.openai.com/en/articles/11509118-admin-controls-security-and-compliance-for-plugins-and-apps), checked October 2026).

**When to just use Claude's native connector and stop.** Drive is the only app the team needs. They need to upload, share, move, or trash files from the chat, not just read. Use it. It's on all plans; an Owner or Primary Owner enables it under Organization settings, Connectors. No folder or shared-drive restriction is documented for it, and each person connects their own Google account. So a folder boundary needs the dedicated-account pattern, through a connector that can share one connection.

**The caveat on the Elaichi row:** to ChatGPT, Elaichi presents as one custom app whose tools are `search_tools`, `execute_tool` and Elaichi's own operations. ChatGPT's own per-action approval switches therefore cannot distinguish Drive from any other app behind Elaichi. That granularity has to be enforced inside Elaichi's restrictions, not in ChatGPT's UI. The broader trade-off is in [Claude and ChatGPT connectors vs one MCP endpoint](/blog/elaichi-vs-native-ai-connectors/).

## Adding the endpoint, approving the scopes, and the record afterward

The address is `https://api.elaichi.ai/mcp`, the same for every organization. In Claude Team and Enterprise, an Owner adds it under Organization settings, Connectors, Add, Custom, Web. Members then connect it under Customize, Connectors ([support.claude.com](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp), checked October 2026). There is no client ID, secret, or header to type, because the client registers itself through OAuth dynamic client registration.

On Elaichi's consent screen the person picks the organization first. Then come the checkboxes: Read your organization's data, Create and change data, Run your connected tools, and Delete data and remove access. Delete is never pre-ticked. With "Run your connected tools" ticked, a second step asks for All my tools or only chosen toolboxes. For the dedicated-account shape, picking just the Drive toolbox is the tighter choice: All my tools also reaches every other connection that person holds personally.

Afterward, the record is plain. Elaichi writes one entry per tool-call attempt, succeeded or failed. Argument *names* and counts are recorded; argument *values* are not, so the log shows that a `fileId` was passed, not which one. That answers the first question in an incident: who reached which Google account, through which client. The entry carries the surface (`mcp`), and the OAuth client it came through, marked verified for Claude, ChatGPT, and Cursor. The audit trail inside Elaichi is on the Gold plan; forwarding it to your own Datadog comes with the Black plan, launching soon.

If you're still deciding whether any of this machinery is warranted, start with [what an MCP control plane is for](/blog/what-is-an-mcp-control-plane/). If you've decided, [the Claude connection walkthrough](/blog/connect-elaichi-to-claude/) covers sign-in, and the [team use cases](/use-cases/) show what other teams set up next.

## FAQ

### Can you limit an AI assistant's Google Drive access to specific folders?

Not with an OAuth scope. Google publishes no Drive scope that confines an app to a folder, and an 'in parents' query is a search filter rather than a permission. The practical boundary is the Google account the connection signs in with: create a dedicated account, share only those folders to it, and connect that account. In Elaichi, sharing that connection at use means every call reaches Drive as that account, because a shared connection runs on its owner's credential.

### Does Elaichi's Google Drive connector let an AI agent edit or delete files?

No. The connector carries 28 tools, 25 of which read files, folders, shared drives, search results, permissions, revisions, comments and the change log. The other three are create_a_googledrive_watch and create_a_googledrive_changes_watch, which ask Google to post change notifications to an HTTPS address the caller supplies, and delete_a_googledrive_channel_by_id, which stops a channel. None creates, edits, shares, moves or deletes a file, and a team that only reads blocks those three.

### What happens when someone asks an AI assistant for a Drive file they cannot open?

Google answers the call, not the assistant. The Drive API bounds every request by the signed-in user and returns 404 notFound where that user has no read access, and 403 where they have no write access. So a connection made with a person's own Google account can never surface a document that person could not already open in Drive.

### How quickly does a Google Drive restriction take effect in Elaichi?

A restriction or role change takes effect within about two minutes, on every surface. Revoking a share of a connection, or disconnecting the account, takes effect on the caller's very next request, because grants and connections are read fresh on every call. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change.

### Should a Google Workspace admin mark an app Trusted before restricting Drive?

Yes, and the order matters. In Manage App Access an app is set to Trusted, Limited, Specific Google data, or Blocked. Setting Drive to Restricted revokes the tokens of apps that are not trusted, so mark the app Trusted first and restrict afterward. Google's high-risk Drive scope list includes drive, drive.readonly and drive.metadata.readonly, and does not include drive.file.

## Read next

- [QuickBooks read-only for a finance team in Claude](/blog/finance-team-claude-quickbooks-read-only/) — QuickBooks has no read-only OAuth scope, so QuickBooks read-only has to be enforced by whatever calls the API. Here is how to do it with one restriction.
- [Each rep's own Salesforce access, in ChatGPT](/blog/sales-team-chatgpt-salesforce-accounts/) — Salesforce access in ChatGPT works per rep: each call runs on the rep's own connection, so Salesforce's sharing rules decide which accounts they see.
- [Intune in Claude for help desk lookups only](/blog/it-team-claude-intune-devices/) — Intune in Claude for a help desk is one allow rule, not six blocks: the msintune connector carries 198 tools and only 69 of them read.