TL;DR: Most AI agents reading Google Drive should use the Picker plus drive.file instead of drive.readonly, according to Agentic Fabriq, because the restricted scope exposes only user-selected files while corpus-wide indexing creates cross-user leak risk if permissions are not enforced at retrieval time. The real governance issue is not search power but whether your design preserves live file-level access.
At a glance
What this is: This is a technical governance analysis of Google Drive access for AI agents, arguing that drive.file plus Picker is the safer default because broad Drive scopes and shared indexes expand exposure beyond the user’s intended corpus.
Why it matters: IAM and NHI teams should care because file-level consent, scoped tokens, and live permission checks determine whether an agent answers from authorised content or becomes a cross-user data exposure path.
Context
The security gap here is simple: an AI agent that can read a user's Google Drive must not surface a file the user cannot open. That constraint looks obvious until teams centralise retrieval into a shared index and assume the index inherits Drive's permission model, which it does not.
Drive scope choice is really an access-governance decision, not a convenience choice. The article argues that drive.file keeps the corpus bounded to what the user picked, while drive.readonly and drive.metadata.readonly move the design into a broader custody and verification model that most products do not actually need.
Key questions
Q: How should teams scope Google Drive access for AI agents?
A: Use the narrowest scope that still supports the use case, and default to drive.file with the Google Picker for user-bounded retrieval. Reserve broader Drive scopes for situations where the product truly requires corpus-wide search, because those scopes expand governance burden, verification effort, and data custody risk.
Q: Why do shared indexes create Drive data leakage risk?
A: Because an index does not know who is still allowed to see the underlying file unless you teach it that rule. If chunks from multiple users are pooled together without file-level filtering, the agent can answer from content outside the caller's current entitlement set, even when the original crawl was lawful.
Q: What should teams do when Drive search returns incomplete results?
A: Treat incomplete search results as an operational signal, not proof that the document does not exist. Narrow the query, retry with better corpus targeting, and do not let the model infer absence from a partial search response.
Q: What is the difference between drive.file and drive.readonly for agents?
A: drive.file limits the agent to files the user explicitly opened or selected, while drive.readonly can expose every file the user can see. The practical difference is governance scope: one is user-bounded and easier to defend, the other turns your application into a custodian of a much broader corpus.
Technical breakdown
Why drive.file changes the trust boundary
drive.file does not mean “less useful” so much as “explicitly user-bounded.” The scope lets the app act on files opened through the Google Picker or granted through a file picker, and Google classifies it as non-sensitive. That matters because the app no longer receives a copy of the user's entire readable corpus, only the files the user has intentionally exposed to the app. For identity teams, the key design shift is that consent becomes item-scoped rather than corpus-scoped, which changes what you can safely cache, index, and search.
Practical implication: Treat the Picker grant as the authoritative boundary and design every downstream workflow around that bounded file set.
Why shared indexing breaks Drive permissions
A vector store is not an authorisation engine. Once multiple users' documents are embedded into one index, the retrieval layer must recreate Drive's per-file access checks on every query, or the system will mix authorised and unauthorised content. The article's central point is that permissions are attached to files and access can change after ingestion, so a stale index can answer from content the user no longer has rights to view. This is a classic governance failure: the storage layer remembers what existed, not what is still authorised now.
Practical implication: Bind every chunk to its source file and filter retrieval by live grants before the model ever sees candidate content.
What incompleteSearch and export limits mean operationally
Drive search and export are not perfectly complete, and the platform tells you that in the API responses if you are listening. incompleteSearch means results may be missing, while files.export has a 10 MB ceiling and does not support partial downloads for Google Workspace documents. Those limits matter because an agent that treats missing results as proof of absence, or assumes every document type can be streamed the same way, will create false negatives and brittle retrieval. Operationally, this pushes teams to separate search correctness from content extraction and to handle native files differently from binary uploads. See the AI Agent Identity Security Buyer's Guide.
Practical implication: Check search completeness, route native documents through the right export path, and do not treat quota or limit errors as empty results.
Threat narrative
Attacker objective: The objective is to obtain or expose Drive content outside the requesting user's authorised file set.
- Entry occurs when a user grants broad Drive visibility to an agent or indexer instead of a file-bounded Picker selection.
- Credential access becomes access amplification when the system caches corpus-level content without preserving per-file authorisation boundaries.
- Escalation happens when query-time filtering is absent or stale, allowing the agent to retrieve content from other users' files.
- Impact is cross-user disclosure: the agent answers from documents the requester is not currently authorised to see.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Google API Keys Exposure — Gemini AI: Google API keys exposed in client-side code via Gemini AI integrations, creating data leak risk.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Drive scope choice is now an identity-governance decision, not an integration detail. The article is right to frame drive.file as the default for most agentic Drive use cases because it keeps the authorisation boundary aligned to what the user actually selected. Once teams ask for corpus-wide visibility, they are no longer designing a simple connector, they are accepting custodianship for a broader data estate. That shifts the burden onto verification, auditability, and live permission enforcement.
Per-file consent is the only defensible baseline for most AI agents that touch Drive. Corpus-wide indexing creates a governance illusion: the agent appears to act on behalf of one user while the index quietly aggregates many users' content. That is not a search optimisation problem, it is a delegation and identity model problem, because the retrieval layer has to preserve the same access semantics as the source system. Practitioners should treat the index as an extension of authorisation, not a substitute for it.
Cross-user leakage is a control failure, not a model failure. The dangerous assumption is that a chunk inherits the file's permissions after ingestion. It does not. The moment multiple users' Drive content lands in one shared retrieval layer without a live entitlement filter, the system has created an identity blast radius that no prompt guardrail can repair. The implication is straightforward: the access decision must happen at query time, not just at crawl time.
Picker-based consent is the clearest example of least privilege working in an agent workflow. The Picker gives users a visible, bounded selection moment, and drive.file keeps the app inside that selection. That is materially different from asking for a broad read scope and then trying to justify it after the fact. For IAM and NHI programmes, the lesson is that user intent and technical scope need to match at the same granularity or the system will drift into over-collection.
Shared-drive semantics make governance even less forgiving. When shared drives are involved, the agent must respect both inclusion flags and the organisational reality that access can change independently of the original ingest event. That means operational control cannot stop at initial authorisation or initial indexing. Teams need a retrieval model that can be revoked, rechecked, and explained by file identity, not just by embedding provenance.
Read next: Agentic AI Identity Guide
What this signals
Identity-bound retrieval will become the default expectation for AI document agents. As more teams connect agents to repositories like Drive, the real design question will shift from “can the model find it?” to “can this user still see it right now?” That means retrieval, consent, and revocation will converge into one control surface rather than sitting in separate product layers.
Cross-user leakage is the named failure mode to watch. A shared vector index that ignores file identity creates a permission drift problem that looks like ordinary search success until a user sees content they should not have received. In practice, the most important control is no longer corpus size, but whether the retrieval path can prove live entitlement at the moment of answer generation.
Live entitlement filtering is the operational signal of a mature agent programme. If a system can survive revocation of one file and immediately stop answering on it, the retrieval layer is actually respecting source permissions. If it cannot, the programme has a shadow data store masquerading as an assistant.
For practitioners
- Use Picker-based consent as the default Require users to choose the files or folders the agent may access, and prefer drive.file unless the product genuinely depends on corpus-wide retrieval.
- Bind every chunk to its source file Store the Drive file id on each chunk and tie retrieval to the same user and file grant that produced it.
- Filter every query by live access Refresh grants from Drive at query time and suppress any result whose file is no longer authorised for that user.
Key takeaways
- The main risk is not that an agent can read Drive, but that it can answer from a larger corpus than the user intended or still controls.
- Shared indexing without live file-level filtering turns retrieval into a permission drift problem that Drive itself does not solve for you.
- A defensible design keeps consent, indexing, and query-time access checks aligned to the same file identity and revocation model.
Related NHI Mgmt Group resources: Agentic AI Identity Guide · AI Agent Observability, Audit and Incident Response Guide · AI Agent Identity Security Buyer's Guide · MCP Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on OAuth-based Drive access and the trust boundary created by consented scopes. |
| NHI-05 — Overprivileged NHI | Broad Drive scopes and shared indexes can exceed the minimum access the agent needs. | |
| NHI-08 — Environment Isolation | A shared retrieval index can collapse boundaries between users and their authorised Drive content. | |
| Recommendation — Use NHI-04 to verify that agent access is scoped, consented, and revocable at the file level. Apply NHI-05 to cut Drive access down to the smallest file set the agent actually needs. Separate per-user retrieval state so one user's grants cannot surface another user's documents. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about preserving current entitlements across an AI retrieval workflow. |
| Recommendation — Enforce PR.AA-05 by checking live entitlements before the agent returns any Drive content. | ||
| MITRE ATT&CK | TA0006; TA0010 — Credential Access; Exfiltration | The article's failure mode is unauthorized access to Drive content and unintended disclosure through retrieval. |
| Recommendation — Map token-backed Drive retrieval paths to credential-access and exfiltration monitoring. | ||
Key terms
- Drive Scope Bounded Retrieval: A retrieval pattern in which an application only searches and reads the files a user explicitly granted. The key governance property is that authorisation stays tied to the selected file set, rather than expanding to the user's entire readable corpus.
- Live Entitlement Filtering: A control that checks current access rights at query time before returning content to an AI agent. It prevents stale permissions from leaking into answers when a user has been removed from a file, folder, or shared drive after ingestion.
- Shared Index Leakage: A failure mode where multiple users' documents are embedded into one retrieval layer without preserving file-level access boundaries. The index can then surface content across users even when the source system would block direct access, creating a permission drift problem.
- Consent-Gated File Access: An authorisation model where the user must explicitly select the files or folders an application may use. This is stronger than broad read access because it aligns agent behaviour with visible user intent and narrows the data estate the application can touch.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org