A broad OneDrive permission scope that allows an application to read files across the account rather than a single selected document. In practice, this kind of scope can turn a routine integration into a high-risk access path, especially when sensitive business, personal, or intellectual property data is stored in the drive.
Expanded Definition
Files.Read.All is a delegated or application permission scope that grants read access across a user or tenant file set, rather than limiting access to one selected file or folder. It is broader than narrowly scoped sharing permissions because it can expose the full contents of a drive if the app is authorised and the scope is accepted.
That breadth matters because the scope changes the trust boundary of an integration. A calendar add-on, productivity app, analytics connector, or automation workflow may need only a small slice of content, yet this scope can let it inspect documents far beyond the original business purpose. The practical boundary is not whether the app is “internal” or “approved”, but whether the access granted still matches least privilege.
For that reason, Files.Read.All should be read as an access-design decision, not just a permission label. It is often confused with per-file sharing, but the security impact is different: one selected document can be reviewed, while a broad scope can reveal hidden archives, drafts, exports, and files that users did not expect an integration to see. Microsoft documents these permission families in its Microsoft Graph permissions reference, which is useful background when comparing broad and narrow file scopes.
Examples and Use Cases
Common legitimate uses include enterprise search indexing, backup and recovery tooling, eDiscovery workflows, and content classification services that need to inspect a file corpus. In each case, the business justification should be explicit because the access path is wider than a one-off document read.
- A compliance archive connector scans user drives to build retention or legal-hold inventories.
- An automated migration tool reads source files before copying them into a new repository.
- A data-loss-prevention service inspects documents for sensitive content patterns.
- An analytics app reads shared drive content to generate usage reports and document metadata.
- A file preview integration renders document summaries inside another workplace app.
The trade-off is convenience versus exposure. A broad scope can reduce repeated consent prompts and simplify integration design, but it also concentrates trust in the application and its operators. For the reader, the important question is not whether the app is useful, but whether it truly needs account-wide read access to perform its function.
Security Implications
When Files.Read.All is overgranted, the main risk is silent overexposure. A compromised or malicious app can read sensitive files at scale without needing to defeat per-document controls, which turns one integration into a repository-wide disclosure path. The damage is often broader than a single leak because documents usually contain business strategy, customer data, financial material, source code, or internal correspondence.
Misunderstanding the scope also creates governance gaps. Security teams may believe they are approving a routine integration while actually authorising durable read access across many users’ content. That can undermine approval reviews, third-party risk assessments, and consent monitoring, especially if the app is later repurposed or its permission set expands.
A common operational signal is permission drift: an app that began with a narrow workflow eventually accumulates broader scopes to avoid rework. Another warning sign is lack of visibility into which files the app has read and why. In practice, broad read scopes become especially dangerous when they are combined with weak vendor assurance, unclear ownership, or stale access that is no longer required.
Domain and Governance Relevance
Files.Read.All sits at the intersection of identity governance and file access governance. The core issue is not the file platform itself, but the delegated authority granted to the application identity that can read on behalf of a user or across content collections. That makes consent review, scope justification, and periodic revalidation central to governance.
For organisations using Microsoft 365 and similar ecosystems, the term also highlights a broader pattern in modern SaaS security: applications rarely need blanket access to remain useful, but once a broad scope is accepted, the operational path of least resistance often preserves it. That is why broad file scopes deserve stronger review than routine user permissions.
If the integration is part of an automated workflow, the governance bar rises further because the application may act continuously and at scale. The practical control question is whether the access remains proportionate to the task over time, not whether the app was initially useful. In that sense, Files.Read.All is a permission scope that should trigger lifecycle scrutiny, not just one-time approval.
Risk and Threat Considerations
Files.Read.All creates a material exposure risk because it can convert a single application trust decision into broad content disclosure. If an attacker gains control of the authorised app, or if the app vendor is compromised, the scope can be abused to enumerate and exfiltrate large volumes of sensitive files without touching individual user passwords.
Failure mechanism: The weakness is overbroad delegated or application authority combined with persistent consent. Once granted, the scope can be used through normal API access, which makes abuse look like legitimate application traffic and reduces the need for noisy privilege escalation.
Impact: Sensitive documents can be read at scale, exposing intellectual property, regulated data, internal strategy, or customer information. The same mechanism can also support reconnaissance, because file contents and naming patterns often reveal project structure, business relationships, and operational details.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Broad app file access depends on machine identity consent and token authority. |
| Recommendation — Constrain app consent and rotate or revoke overbroad access when the integration no longer needs it. | ||
| NIST CSF 2.0 | PR.AA-04 — Identity Management, Authentication, and Access Control | Files.Read.All is an access-scope governance issue for application identities. |
| GV.RM-03 — Risk Management Strategy | Broad read scopes require explicit acceptance of exposure and trust trade-offs. | |
| Recommendation — Enforce least privilege for application scopes and review access approvals periodically. Document the business justification and risk acceptance for any broad file permission scope. | ||
| CIS Controls v8 | 6 — Access Control Management | The term centers on controlling who and what can read sensitive file content. |
| Recommendation — Remove unnecessary file-read privileges and reapprove broad scopes on a defined schedule. | ||
| MITRE ATT&CK | T1213 — Data from Information Repositories | An abused app can read and collect files from connected repositories. |
| Recommendation — Hunt for unusual repository read activity and investigate bulk file access by applications. | ||
Practitioner Guidance
Why practitioners should care: Treat this scope as a high-impact access decision, not a routine checkbox. If an app cannot clearly explain why it needs broad read access, it usually needs a narrower design or a different integration pattern.
Common misunderstanding: Teams often assume that “read only” is inherently low risk. In practice, read access across many files can be as sensitive as write access when the content itself is valuable or regulated.
Practitioner takeaway: Review broad file scopes as part of consent and app-registration governance, and revalidate them whenever the app’s purpose changes.
Related resources from NHI Mgmt Group
- What breaks when an AI browser can read local files inside a user session?
- How should teams review authorization policy when business users cannot read policy files?
- What should teams do when AI tools can read files and run commands?
- What breaks when AI coding agents can read web content and write local files?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
