What Is OAuth Scope? Choosing AI Access Permissions

Conclusion first

An OAuth Scope is a value describing the extent of access delegated to an external application.

An AI application searching documents may need read access but not permission to modify them. The OAuth Client requests scopes and the authorization service decides which to grant based on policy, application configuration and user approval when needed.

Scopes do not replace file-by-file or user-by-user permission checks. The destination service must still decide whether a particular operation is allowed.

For the underlying protocol, see What Is OAuth?.

Definition

OAuth uses a scope parameter to request specific access permissions.

Example Scope	Intended capability	Use case
documents.read	Read documents	Search and summarize
documents.write	Modify documents	Edit meeting notes
calendar.read	Read events	Check availability
calendar.write	Create or update events	Schedule an appointment

These names are illustrative, not universal OAuth scopes. Each provider defines the names and their meanings. RFC 6749 specifies case-sensitive scope values separated by spaces.

How it works

Example: AI searches meeting notes

If a user asks an AI to “find last week’s meeting notes and summarize them,” search and read access are the capabilities needed. Deleting or modifying documents is not part of the request.

Where a provider supports separate read and write permissions, requesting only the read scope makes sense.

If the task changes to “add action items to the meeting notes,” write access may be necessary. Even then, the individual document permissions and the user’s intention must also be respected.

Choose the permissions needed for a task, rather than granting everything at the beginning.

Requested versus granted scopes

1. The Client requests permissions, such as read access.
2. The authorization service evaluates the request against policies, application settings and any required user consent.
3. A token is issued with an authorized scope. Not every requested permission must be granted.
4. The API validates access before performing the operation.

RFC 6749 requires the authorization service to tell the Client which scope was granted when it differs from what was requested.

Why operations still fail with a valid scope

Control	Purpose	Example
OAuth Scope	Delegated permission range	Read documents
Provider access control	Access to particular content	Team folder only
Tool configuration	Operations available to the AI	Search Tool enabled
Execution conditions	Whether the action can succeed now	File exists and is accessible

Increasing scopes does not fix every authorization or execution error.

A document search may succeed while an update fails because write access is missing. But an update can also fail because the file is read-only or an update Tool is unavailable.

Conversely, a read scope does not automatically grant permission to read another user’s private file.

Choosing scopes for AI applications

The usual principle is least privilege:

• Search and summarize: consider read-only permissions.

• Create or edit: consider the specific required write permissions.

• Delete: carefully evaluate whether deletion access is necessary.

• Multiple services: evaluate permission requirements separately for each.

Excessive granularity can complicate normal use. The goal is permission boundaries aligned with actual tasks.

Commonly confused concepts

An MCP Tool name is not an OAuth Scope

MCP standardizes connection to external capabilities; OAuth Scope expresses delegated access rights.

An MCP Tool called search_documents does not itself determine the OAuth permissions needed to run it. The provider defines those requirements.

A missing Tool does not necessarily indicate insufficient scope. See the Complete Guide to MCP and MCP Tools Not Showing in ChatGPT.

Scope is not resource-level authorization

Even if an application is granted a document-read scope, the connected service may restrict the user to certain folders and documents. The permissions of the resource remain important. This authorization is separate from user authentication, and the Resource Server enforces resource-level access.

How this relates to OGINAU

While developing OGINAU Remote and OGINAU Browser, OGINAU has evaluated authorization for AI access to external environments.

One general lesson is to distinguish permission to connect, availability of a Tool, and permission to execute a particular operation.

A functioning connection does not mean all files or actions are allowed. OAuth scopes alone do not provide every product-specific access control.

This article does not disclose OGINAU’s internal scope definitions, permission evaluation sequence or execution controls.

Frequently asked questions

Who defines OAuth scopes? The service provider defines their names and meaning. A Client requests them and the authorization service decides what to grant.

Can AI do everything if scopes are broad enough? No. User permissions, available Tools and runtime conditions also apply.

Should every scope be granted after an insufficient-scope error? No. Identify the failed operation and the permission actually required.

Can the granted scope differ from the requested scope? Yes. Check the authorization result and provider documentation.

Sources and primary information

• RFC 6749 Section 3.3: Access Token Scope: scope syntax, requests and grants.

• RFC 9700: OAuth 2.0 Security Best Current Practice: OAuth security practices.

• MCP Authorization (2026-07-28): OAuth authorization in MCP.

• OGINAU Remote and OGINAU Browser development verification records: distinguishing connections from permitted operations.

Summary

OAuth Scope describes the permissions delegated to an external application.

Read and write permissions may differ; requested and granted scopes need not match; and scope is distinct from permissions on a specific resource.

Give an AI-connected application only the access needed for the task, and enforce the actual permission at the destination.