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.
Why the permission choice changes the agent’s security boundary
For agents, the practical difference is not just how much data they can read, but what governance boundary they inherit. AI Agent Authorisation Guide is a useful reference point here because the core question is whether the agent is constrained to a task-scoped slice of the user’s workspace or can act against the user’s broader visible corpus.
drive.file is the narrower model. It is designed for workflows where the agent only needs files the user explicitly opened, selected, or otherwise made available through the app flow. That keeps the agent’s effective authority closer to the current task and makes review, audit, and user expectation much easier to align.
drive.readonly is materially broader. It allows the agent to inspect every file the user can see, which increases the chance that a single integration becomes a high-value concentration point for sensitive content, personal data, and internal documents. For agent builders, that changes the trust model from “this helper sees what the user chose” to “this helper can read across the user’s visible Google Drive surface.”
When the question is framed around agents, the control issue is scope, not just API semantics. The permission you choose determines whether the agent can remain bounded to a small, user-initiated work set or whether it becomes a standing reader for a much larger information estate. That distinction matters even if the agent never writes, because broad read access can still create material exposure through indexing, summarisation, caching, logging, or downstream tool calls.
Where drive.readonly becomes materially harder to defend
drive.readonly is easier to overreach with because it decouples access from the user’s immediate action. Once granted, the agent can observe files the user did not intend to surface to that workflow, which raises the blast radius of any prompt injection, compromised session, abusive tool call, or overly curious agent behaviour. Browser and Computer-Use Agent Security Guide is relevant in the same way, because broad session-backed access tends to widen the damage when an agent is steered off course.
By contrast, drive.file is easier to justify when the agent performs bounded assistance such as drafting from an opened document, transforming a selected sheet, or attaching a chosen file to a workflow. The important practitioner difference is that the authority follows the user’s explicit selection, so you can explain and audit why the agent had access to each object it touched.
This distinction also affects incident response. With drive.file, the review question is usually “what did the user select in this task?” With drive.readonly, the review question becomes “what else in the user’s Drive may have been readable by the agent during the entire grant period?” That broader question is slower to answer and more expensive to contain.
How to choose the smaller scope without breaking the workflow
Use drive.file when the agent can complete the job with user-chosen artifacts, temporary working sets, or a deliberate open-and-process interaction. Use drive.readonly only when the product requirement genuinely depends on searching, comparing, or summarising across the user’s broader Drive content and you are prepared to govern that access accordingly. Zero Trust for AI Agents fits this decision because the safer pattern is to verify the principal, the request, and the action before granting broader reach.
If you do need the wider permission, treat it as a higher-governance tier: minimise how long the grant remains active, record what the agent read, and make user intent explicit in the UI and consent flow. The permission choice should be based on the smallest data surface that still supports the use case, not on convenience for the integration.
Good practice is to design the agent so that a narrower permission is the default and broader access is an exception justified by the task. That makes it easier to keep the agent’s behaviour understandable, limits unintended retention of sensitive material, and reduces the number of places where broad read access can become a hidden dependency.
Risk and Threat Considerations
A broader read scope increases exposure if the agent is compromised, misled, or simply over-collects data. The main risk is not only exfiltration, but secondary handling of data the user never meant to route through the agent in the first place.
Failure mechanism: drive.readonly turns a task-specific helper into a general reader for the user’s visible Drive, so any misuse, prompt injection, malicious instruction, or logging path can reach a much larger corpus than the task requires.
Impact: Sensitive documents, internal plans, and personal records can be exposed, summarised, cached, or forwarded beyond the original intent, which raises confidentiality risk and complicates containment after a suspected compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent file-scope choice directly changes delegated access breadth. |
| Recommendation — Limit each agent to the smallest file scope needed and approve broader access only per action. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The question is about constraining agent read authority to the minimum needed. |
| IA-5 — Authenticator Management | The scope choice affects how long and how broadly a granted access path can be reused. | |
| Recommendation — Grant the agent only the minimum file access required for the workflow. Rotate or revoke credentials and tokens when broader read access is no longer needed. | ||
| OWASP ASVS | V8 — Authorization | The distinction is fundamentally about what an agent is authorised to access. |
| Recommendation — Enforce per-request authorisation so the agent only reaches explicitly permitted files. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | An agent with drive.readonly can accumulate broader read privilege than the task needs. |
| Recommendation — Reduce the agent’s file scope to the minimum necessary and avoid persistent overprivilege. | ||
Practitioner Guidance
What to prioritise: Choose drive.file wherever the workflow can be satisfied from user-selected content, and treat drive.readonly as a deliberate exception that needs a stronger business justification.
What to verify: Confirm that the agent truly needs corpus-wide visibility, not just convenience for search or enrichment, and verify that your logging, retention, and downstream processing do not widen the read scope further than intended.
Decision rule: If the agent only needs to operate on the file the user just opened, stay with drive.file; if the feature requires multi-file or cross-drive inspection, use drive.readonly only with explicit governance and a containment plan.
Practitioner takeaway: The safest permission is the narrowest one that still completes the task, because agent risk rises sharply when read access stops being user-bounded and becomes corpus-bounded.
Related resources from NHI Mgmt Group
- What is the difference between managed identities and hardcoded secrets for AI agents?
- What is the difference between workload identity and API keys for AI agents?
- What is the difference between logging actions and logging intent for AI agents?
- What is the difference between human identity governance and AI agent governance?