An OAuth scope is dangerous when it grants broad, standing access to your data — the ones to watch let an app read all mail, manage every file in Drive or SharePoint, act as any user, or read your whole directory. “Read your calendar” is a low-risk scope; “read, send, and permanently delete all your mail” is not. Here’s how to tell them apart across Google Workspace and Microsoft 365.

Scopes come in tiers of risk

Low. Read-only access to a narrow resource — a user’s profile, a single calendar’s free/busy.
Medium. Read access to substantial data — all calendar events, contacts, or file metadata.
High. Full read/write to mail or files (mail.google.com, full Drive, Mail.ReadWrite), directory access, or the ability to act on behalf of users.

A useful rule of thumb: if a scope lets an app send mail, delete data, or act as a user, it belongs in the “prove this is necessary” pile.

Delegated vs application permissions

The same scope is not equally risky in every context. A permission delegated to a single user is bounded by that user. The same permission granted as an application permission (Microsoft) or via domain-wide delegation (Google) is org-wide and unattended — it runs with no human in the loop and reaches every mailbox or file. Those deserve the most scrutiny.

Red flags worth hunting for

Apps with full-mailbox or full-Drive scopes that only need to read one thing.
Org-wide consent granted in a single click, often long ago.
Scopes held by apps from unverified publishers.
High-scope tokens attached to accounts that no longer have MFA — or no longer have an owner.

Turning scopes into a decision

Reading raw scope strings across hundreds of grants is tedious and error-prone. Esmeris translates them into plain-English risk and ranks every grant, so you can see at a glance which apps are over-permissioned. It’s entirely read-only — see the sample report for the output.

Start your free audit