Your AI agent doesn't need to see your whole Drive

Every AI rollout we've watched stall has stalled on the same question. Not "is the model good enough," not "what does it cost." The question that stops the meeting is the one the security team asks: what can it access?

For most Google Drive AI connectors, the honest answer is: everything the user can. And most users have no idea what that means.

What "full Drive access" actually grants

The common broad scopes — drive and drive.readonly — don't grant access to "the user's files" in the way people picture it. They grant access to everything the user's account can resolve: every folder shared with them in the last decade, the comp spreadsheet someone over-shared in 2021, the board deck they were cc'd into once, the M&A folder nobody remembered to unshare. Your users don't have an inventory of what they can see. The agent inherits all of it anyway, silently, on the day they click "Allow."

That would be uncomfortable even if agents only did what they were told. They don't, reliably. An agent that reads documents can be steered by documents — a shared file containing adversarial instructions is a real and demonstrated attack path, and an agent with broad read access turns one poisoned document into a lever against everything else it can reach. The blast radius of a single bad file becomes the whole Drive.

Promises are not boundaries

The usual mitigation is prompt-level: the vendor instructs the model to only touch relevant files, to decline suspicious requests, to be careful. Before we built AI tooling, we spent years building SIEM software — and watched organizations learn one lesson over and over at considerable expense: a control that depends on the good behavior of the thing being controlled is not a control. It's an expectation. Expectations don't hold under adversarial pressure, and they leave nothing behind to audit when they fail.

A security boundary is something that holds when the thing inside it misbehaves. If your enforcement lives in the prompt, you don't have a boundary — you have a request.

No amount of prompt engineering can bypass an OAuth scope restriction, because the scope isn't evaluated by the model. It's evaluated by Google, at the API layer, on every call. That's the property you want: enforcement by an infrastructure the agent cannot talk its way around.

The scope that fixes the default

Google ships a scope built for exactly this: drive.file. Under it, an application can access only the files it created or files a human explicitly handed to it — through Google's picker, or Drive's “Open with” menu. Not "files matching a query." Not "the folders the user probably meant." Files a person deliberately selected, one grant at a time, enforced by Google's API — not by the vendor's code, and certainly not by the vendor's prompts.

This inverts the trust model. Broad scopes make the agent's access the default and rely on good behavior to narrow it. drive.file makes no access the default and requires recorded human intent to widen it. The worst case stops being "everything the user could see" and becomes "the specific files someone chose to share" — a list you can read, reason about, and revoke.

The friction is the feature

The standard objection: under drive.file, the agent can't rummage through your whole Drive to find things. Correct. That's not a limitation of the design — it is the design. "The AI can't touch files nobody gave it" is a sentence a CISO can approve. And each explicit grant is an auditable act of human intent, which is what makes the next section possible at all. When access is granted file by file, an audit log becomes a record of decisions rather than a firehose of ambient access.

What your audit trail should answer

Here's a bias we earned in our SIEM years: access control without audit is half a product. When — not if — someone asks "what did the AI touch last Tuesday," your logs need to answer, specifically:

• Who — the human user, not a shared service account that flattens attribution.
• Via what — which client (chat, CLI, API) performed the action.
• What, exactly — file, operation, bytes transferred, duration.
• Under which policy — the full evaluation chain that allowed it.
• What was denied — blocked attempts, with the layer that blocked them and why. Denials are the most interesting events in the log, and most connectors don't record them at all.

And those events should stream to the SIEM your SOC already lives in. A vendor console your security team must remember to log into is where audit trails go to be ignored.

Where this leaves you

The pattern is simple to state: scope access at the OAuth layer, require explicit human grants, log everything including denials, and ship the events to where your security team already looks. None of this is exotic — it's the same discipline we've applied to every other class of software that touches sensitive data. AI agents don't get an exemption because they're impressive.

Obvious disclosure: we believe this strongly enough that we built ShareWatch around it — drive.file for all file access, per-user tokens, deny-wins policies, and an audit log designed by people who spent years on the consuming end of bad ones. You can see exactly what an agent sees under each model. But even if you never touch our product, ask your current vendor the seven questions. Your security team will thank you, and your rollout might actually clear the meeting.