# SharePoint API Permissions Explained: Scopes, Admin Consent, and Scoped Connectors

SharePoint API permissions control how automated integrations and users interact with files across Microsoft 365. High-privilege application permissions like Files.Read.All expose entire corporate tenants, while Sites.Selected requires manual PowerShell provisioning. Scoped workspace connectors allow organizations to keep primary files in SharePoint while isolating project data into an intelligent workspace accessed by autonomous agents.

Source: https://fast.io/resources/sharepoint-api-permissions/
Author: [Tom Langridge](https://fast.io/authors/tom-langridge/)
Last reviewed: 2026-09-29

## Why Tenant-Wide SharePoint API Permissions Create an Excessive Blast Radius

Granting an automated application broad permissions like Files.Read.All turns a single integration into a tenant-wide security liability, because any compromised token exposes every document across all SharePoint sites and OneDrive accounts in the organization.

Organizations store their most sensitive corporate knowledge inside Microsoft 365: board presentations, human resources investigations, financial projections, intellectual property disclosures, and acquisition plans. Connecting internal software tools, indexing pipelines, and artificial intelligence agents directly to this document estate is a standard requirement for modern engineering teams. However, the default authorization paths provided by Microsoft Graph present an immediate architectural dilemma.

SharePoint API permissions define the level of access an application has to files and sites across Microsoft 365, ranging from delegated user permissions to high-privilege application permissions like Files.Read.All. When engineers begin developing tools that read or write files in SharePoint, developer documentation and community tutorials frequently recommend granting broad scopes such as Files.Read.All, Files.ReadWrite.All, or Sites.Read.All in the Microsoft Entra ID app registration portal.

In a sandboxed development environment, this approach works without friction. The application obtains an OAuth token and queries document libraries across any site collection without encountering HTTP 403 Forbidden errors. In an enterprise production environment, however, this pattern fails security review. Corporate security officers and IT administrators routinely block applications requesting tenant-wide read or write scopes. If a script holding Files.Read.All credentials suffers from token leakage, hardcoded secrets in source control, or prompt injection vulnerability, an attacker gains unrestricted access to every file in the company.

Fastio publishes a head to head comparison of agent file work across Fastio and the major cloud storage providers at [Fast.io Benchmarks](/benchmarks/). The same agent runs the same multi-document audit against each connector over an identical corpus, scored on completion time, connector calls, tokens consumed, and cost. Fastio was measured the fastest and the lowest cost of the providers tested (note that SharePoint was not measured in that test, and accuracy was parity across tested providers).

Teams that keep their primary storage in SharePoint, OneDrive, Google Drive, Box, or Dropbox face a fundamental challenge: how to allow automated systems and agents to interact with specific project documentation without giving those systems the keys to the entire corporate file repository.

## Compare Delegated Versus Application Permissions in Microsoft Graph

Understanding how Microsoft Graph enforces security boundaries requires distinguishing between the two primary identity contexts available in Microsoft Entra ID: delegated permissions and application permissions. Choosing the wrong identity model leads to either non-functional automation or excessive security exposure.

Each permission model operates under distinct identity mechanics and governance rules:

* **Delegated Permissions.** Delegated permissions execute within the security context of a signed-in human user. The client application acts as an agent on behalf of that user. Crucially, the application can never access more data than the signed-in user is authorized to see. If an engineer who lacks access to HR payroll folders signs into an internal dashboard with Files.Read delegated scope, the dashboard cannot read payroll files. Delegated access relies on OAuth 2.0 authorization code flows, often supported by OpenID Connect.
* **Application Permissions.** Application permissions execute without a signed-in user. The application authenticates as its own autonomous identity (an enterprise service principal) using the OAuth 2.0 client credentials grant. Because there is no human in the loop, application permissions operate globally by default across the entire Microsoft 365 tenant. When an app registration receives Files.Read.All as an application permission, it bypasses individual user access control lists and can read every file across every SharePoint site and personal OneDrive in the organization.

For background automations, scheduled ingestion jobs, and autonomous AI agents, delegated permissions introduce severe operational friction. Delegated tokens require interactive user authentication or complex refresh token management. If the user who authorized the token leaves the organization, changes their corporate password, or has their account disabled, the background automation halts immediately. Long-running agent workflows operating in headless cloud containers or developer terminals cannot present interactive browser authentication prompts to refresh expired tokens.

Because of these session constraints, development teams building automated systems gravitate toward application permissions. Yet because application permissions bypass human access checks, they require tenant administrator consent and trigger extensive infosec scrutiny.

### The Mechanics of Admin Consent in Microsoft Entra ID

Microsoft Entra ID enforces administrative consent gates for permissions that present tenant-wide risk. While regular users can sometimes consent to low-privilege delegated scopes (such as User.Read), any application scope that touches organizational data requires explicit approval from a Global Administrator or Privileged Role Administrator.

When an application requests application permissions in Microsoft Graph:

1. A developer registers the application in the Microsoft Entra admin center and adds the required Graph permissions.
2. The permissions remain in an unapproved state until a tenant administrator reviews the registration.
3. The administrator inspects the requested scopes, evaluates the application purpose, and clicks Grant admin consent for your organization.
4. Entra ID updates the service principal in the tenant directory, allowing the application to obtain access tokens containing the approved roles claim.

Because granting admin consent to Files.Read.All or Sites.ReadWrite.All establishes a permanent, organization-wide bypass of site permissions, security policies at most regulated enterprises explicitly forbid approving these scopes for custom scripts or third-party tools.

## What Common SharePoint API Permission Scopes Actually Access

Selecting permission scopes in Microsoft Graph involves balancing developer velocity against corporate compliance. Microsoft organizes SharePoint and OneDrive permissions under two primary API namespaces: Files and Sites.

Here is a breakdown of the standard scopes used for document operations:

* **Files.Read.** Delegated scope. Allows the app to read files that the signed-in user can access. Does not require admin consent in most tenant configurations. It cannot run headlessly without user credentials.
* **Files.Read.All.** Available as delegated or application scope. In Microsoft Graph, the Files.Read.All application permission allows the application to read all files in all site collections without a signed-in user. This scope carries an extreme blast radius, as it exposes all OneDrive accounts and SharePoint libraries.
* **Files.ReadWrite.** Delegated scope. Allows the app to read, create, update, and delete files that the signed-in user has permission to modify.
* **Files.ReadWrite.All.** Available as delegated or application scope. Grants full read, write, and deletion access across all tenant files without user intervention.
* **Sites.Read.All.** Available as delegated or application scope. Grants the ability to read documents, lists, libraries, and site metadata across all site collections in the tenant.
* **Sites.ReadWrite.All.** Available as delegated or application scope. Grants read and write access to all SharePoint document libraries, lists, and pages across the entire tenant.
* **Sites.Selected.** Available as delegated or application scope. The Sites.Selected application permission allows an application to access a subset of site collections without a signed-in user. Access to specific sites must be explicitly provisioned by an administrator.

The table below contrasts these permission scopes across their operational dimensions:

| Permission Scope | Scope Type | Admin Consent | Access Scope | Tenant Risk Profile |
| :--- | :--- | :--- | :--- | :--- |
| Files.Read | Delegated | Optional | User-accessible files | Low: bounded by user ACLs |
| Files.Read.All | Application | Mandatory | All tenant files and drives | Critical: tenant-wide file exposure |
| Files.ReadWrite.All | Application | Mandatory | All tenant files and drives | Critical: tenant-wide write/delete |
| Sites.Read.All | Application | Mandatory | All SharePoint site libraries | High: all site documents visible |
| Sites.ReadWrite.All | Application | Mandatory | All SharePoint sites and lists | Critical: tenant-wide data modification |
| Sites.Selected | Application | Mandatory | Explicitly granted sites only | Controlled: isolated to target sites |

The security trade-off is stark. Broad application permissions provide immediate API access at the cost of unacceptable security exposure. Conversely, restricted scopes protect tenant data but introduce administrative friction.

Fast.io provides predictable workspace subscriptions that eliminate complex API metering. Rather than managing unpredictable per-query costs, teams deploy governed workspaces with clear seat, storage, and AI credit boundaries. Creating an account is free; doing real work requires an organization on a paid subscription. Monthly plans start with a 14-day free trial, which requires a credit card.

| Plan | Monthly Price | Included Seats | Included Storage | Workspaces | Monthly Credits |
| :--- | :--- | :--- | :--- | :--- | :--- |
| Starter | $9.99/mo | 3 | 250 GB | 5 | 100,000 |
| Business | $49.99/mo | 10 | 5 TB | 50 | 600,000 |
| Enterprise | $199.99/mo | 30 | 25 TB | 200 | 3,000,000 |

Credits meter generative AI work and document intelligence, while seats, workspaces, and storage come bundled with the plan. This model allows teams to run extensive semantic search and document extraction pipelines without facing unexpected infrastructure charges.

## Steps to Restrict Access to Specific Sites with Sites.Selected and PowerShell

To solve the blast radius of tenant-wide permissions, Microsoft introduced the Sites.Selected permission scope. Under this model, an application granted Sites.Selected has zero access to any SharePoint site collection upon receiving admin consent. An administrator must explicitly grant permissions to individual site collections using Microsoft Graph or PowerShell.

Configuring Sites.Selected requires a multi-step administrative workflow:

* **Step 1: Register Application with Sites.Selected.** In Microsoft Entra ID, open App registrations, select your application, and open API permissions. Add Microsoft Graph > Application permissions > Sites.Selected. A Global Administrator must click Grant admin consent for your organization.
* **Step 2: Obtain the Target Site Collection ID.** The administrator must determine the unique Graph identifier for the target SharePoint site. You can query this via Graph Explorer or HTTP GET request:

```http
GET https://graph.microsoft.com/v1.0/sites/contoso.sharepoint.com:/sites/EngineeringSpecs
```

The response returns a site ID formatted as `contoso.sharepoint.com,{guid},{guid}`.

* **Step 3: Grant Site Permissions via Microsoft Graph API.** Using an administrative account or management script, issue a POST request to the target site's permissions endpoint:

```http
POST https://graph.microsoft.com/v1.0/sites/contoso.sharepoint.com,{guid},{guid}/permissions
Content-Type: application/json
Authorization: Bearer <admin-access-token>

{
  "roles": ["read"],
  "grantedToIdentities": [
    {
      "application": {
        "id": "YOUR_APPLICATION_CLIENT_ID",
        "displayName": "Documentation Analysis Agent"
      }
    }
  ]
}
```

Alternatively, administrators using PowerShell with the PnP.PowerShell module can run:

```powershell
Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/EngineeringSpecs" -Interactive
Grant-PnPAzureADAppSitePermission -AppId "YOUR_APPLICATION_CLIENT_ID" -DisplayName "Documentation Analysis Agent" -Permissions Read
```

While Sites.Selected is an improvement over tenant-wide access, it introduces major operational limitations:

* **Site-Level Boundary Only.** Sites.Selected cannot isolate an individual document library or folder. If the EngineeringSpecs site contains sensitive budget subfolders or human resources notes alongside technical manuals, the application reads everything in that site collection.
* **Search API Failures.** Microsoft Graph search endpoints frequently fail to return documents when queries run under Sites.Selected, because Graph search relies on tenant-wide search schemas that do not always resolve granular resource-specific consent.
* **Ongoing Administrative Burden.** Every time a project team needs an agent to inspect a new folder or site, an IT administrator must write PowerShell commands or issue custom REST calls. This bottleneck halts developer momentum.

## How to Architect Scoped Workspace Connectors with Fast.io and Remote MCP

Engineering organizations can resolve this architectural bottleneck by adopting scoped workspace connectors. Instead of granting direct API access to corporate SharePoint tenants or maintaining complex PowerShell provisioning scripts, teams keep their primary storage in SharePoint, OneDrive, Dropbox, or Box, and sync only relevant project directories into an intelligent workspace.

Fast.io provides this coordination layer. [Cloud Sync](/product/cloud-sync/) connects to OneDrive (including SharePoint document libraries accessed through the [OneDrive connector](/alternatives/onedrive/)), Google Drive, Dropbox, and Box, offering one-way or two-way synchronization on a schedule or on demand (never continuous, live, or real-time).

Setting up a scoped agent connector follows a clean architecture:

* **Step 1: Synchronize Target Folders.** In Fast.io, configure Cloud Sync to pull the specific project folder or library from SharePoint or OneDrive into a dedicated workspace. The rest of the SharePoint tenant remains untouched and inaccessible.
* **Step 2: Enable Intelligence Mode.** In workspace settings, toggle Intelligence Mode on to enable [workspace intelligence](/product/ai/). Fast.io automatically indexes incoming files for hybrid search, combining exact keyword matching with high-dimensional vector embeddings. Documents become searchable by meaning without setting up an external vector database.
* **Step 3: Connect Agents via Remote MCP.** Point AI tools to Fast.io's hosted Model Context Protocol server over Streamable HTTP. Claude Desktop and other Claude apps connect at `https://mcp.fast.io/mcp/tools`, while coding agents such as Claude Code and Cursor connect at `https://mcp.fast.io/mcp/code` using browser OAuth (headless code sends `Authorization: Bearer <api key>`):

```json
{
  "mcpServers": {
    "fastio": {
      "url": "https://mcp.fast.io/mcp/code"
    }
  }
}
```

Connecting through a scoped MCP workspace provides critical governance advantages over raw SharePoint API integration:

* **Precision Search Without Folder Walking.** When an AI agent connects directly to SharePoint via Graph API, finding information requires recursive folder traversal and downloading entire multi-megabyte files into the model context window. This causes tool-call sprawl, token exhaustion, and Graph throttling. With Fast.io MCP search, an agent issues a single hybrid search query that returns exact relevant excerpts, page citations, and file IDs.
* **Granular Permissions.** Access is granted per organization, workspace, and share through member roles. Teams issue scoped API keys that restrict an agent strictly to its assigned workspace.
* **Per-File Version History.** Every file keeps full version history. If an agent writes an updated document or edits project notes, human teammates can inspect the diff and restore earlier versions.
* **Detailed Activity Log.** Uploads, edits, moves, deletions, and permission changes are recorded in a detailed activity log, providing clear evidence for security reviews.
* **Shared Notes.** People and agents can write markdown notes inside a workspace, indexed for AI grounding. An agent analyzing synchronized specifications can record project summaries, technical outlines, and action items directly into shared workspace notes.
* **Metadata Views.** For structured documentation like invoices, statements of work, or technical datasheets, Fast.io provides [Metadata Views](/product/document-data-extraction/). Metadata Views turn documents into a queryable database. Users describe fields in natural language, and AI populates typed schemas across Text, Integer, Decimal, Boolean, URL, JSON, and Date & Time without manual OCR templates. Agents can query these structured attributes via MCP before reading complete files.
* **Agent-to-Human Ownership Transfer.** An agent can build an organization, ingest documentation, and execute setup tasks, then hand the organization to a person with a claim link.

By decoupling agentic document search from raw tenant-wide cloud storage APIs, organizations preserve the integrity of their Microsoft 365 environment while giving AI teams immediate access to project files.

## Frequently asked questions

### What permissions are needed for SharePoint API?

The permissions needed for SharePoint API depend on the operational task and identity model. For reading files with user credentials, the delegated Files.Read scope is common. For background services, applications require Files.Read.All, Sites.Read.All, or the restricted Sites.Selected scope. Write operations require Files.ReadWrite.All or Sites.ReadWrite.All. Application scopes require Microsoft 365 tenant administrator consent.

### What is the difference between delegated and application permissions in SharePoint?

Delegated permissions execute in the context of a signed-in user, meaning the application can only access SharePoint files that the specific user has permission to see. Application permissions run without a signed-in user, authenticating via OAuth 2.0 client credentials. Because application permissions operate globally by default, granting scopes like Files.Read.All provides access to all document libraries across the tenant.

### How do I grant access to only a single SharePoint site or folder?

To restrict access to a single site in Microsoft Graph, assign the application the Sites.Selected permission scope and grant tenant admin consent. Next, use the Microsoft Graph permissions API or PowerShell PnP commands to grant the application service principal read or write rights on that specific site collection. Microsoft Graph does not natively support folder-level application permissions; folder isolation requires syncing target directories into an intelligent workspace.

### Why do enterprise security teams reject Files.Read.All?

Enterprise security teams reject Files.Read.All because it creates an enormous blast radius. Unlike user accounts bounded by department access lists, an application with Files.Read.All can read every file in every SharePoint site and personal OneDrive across the tenant. A single compromised API secret or token leak exposes executive communications, financial data, and confidential intellectual property.

### What are the limitations of the Sites.Selected permission scope?

Sites.Selected only restricts access at the site collection level, not at the document library, folder, or file level. If a site contains multiple document libraries with varying sensitivity, the application accesses all of them. In addition, Microsoft Graph search endpoints often fail to index or return documents properly under Sites.Selected, and administrators must manually script permissions for every new site.

### Can AI agents connect to SharePoint libraries using the Model Context Protocol?

AI agents can connect to SharePoint content using the Model Context Protocol (MCP) by synchronizing target SharePoint libraries into a Fast.io workspace using Cloud Sync for OneDrive. Fast.io auto-indexes files for hybrid search, allowing agents like Claude Code or Cursor to query indexed documents via a remote MCP server without needing tenant-wide SharePoint API credentials.

## Sources

- [Microsoft Learn: Microsoft Graph permissions reference](https://learn.microsoft.com/en-us/graph/permissions-reference): In Microsoft Graph, the Files.Read.All application permission allows the application to read all files in all site collections without a signed-in user.
- [Microsoft Learn: Microsoft Graph permissions reference](https://learn.microsoft.com/en-us/graph/permissions-reference): The Sites.Selected application permission allows an application to access a subset of site collections without a signed-in user.

## About Fast.io

Fast.io provides shared workspaces where people and AI agents work on the same files, with built-in semantic search and citation-backed chat over what they hold. Agents reach it through a remote MCP server, a REST API at https://api.fast.io/current/, and a command line client published on npm as @vividengine/fastio-cli. MCP setup is at https://mcp.fast.io/docs: Claude and most MCP clients connect to https://mcp.fast.io/mcp/tools, ChatGPT to https://mcp.fast.io/mcp/operations, and coding agents to https://mcp.fast.io/mcp/code.