AI Agent Permissions: Finding the 60% With Allow-All OAuth Access

Security vendor Opsin reported on 5 August 2026 that 60% of enterprise AI agents provisioned beyond default settings were granted allow-all access instead of the permissions their tasks required. That is a vendor number with no published sample size, and it is still the most specific public figure on AI agent permissions. The grants it describes are ordinary OAuth consents, and your admins can already find and narrow every one of them.

Short answer

To scope AI agent permissions, list every OAuth grant each agent holds, compare each scope with the tasks the agent actually performs, then swap broad grants for resource-scoped ones. That means Specific Google data in Workspace, Exchange RBAC for Applications or Selected permissions in Microsoft 365, and pre-authorised connected apps without the full scope in Salesforce.

This guide is written for the head of IT or operations who owns the admin consoles. It covers what each platform's own documentation says its tools can show, and it is explicit about where those tools stop.

How AI agents end up with broad OAuth scopes

OAuth is the protocol that lets one application act on data held by another without handing over a password. The user or an admin approves a list of scopes, and the application receives a token that carries them. Agents use exactly the same mechanism as any other integration.

The problem is not the protocol. It is the moment of consent. An agent builder wants the thing to work on the first try, and the broadest scope is the one that never returns a permission error. Nobody comes back later to narrow it, because nothing breaks.

Opsin's own report points at the same cause. Its release says 67% of agents are built by employees without an engineering background, in teams such as sales, customer success and operations. Its chief executive, James Pham, said most of the risk "traces back to provisioning choices that were never revisited". That sentence does not depend on the sample size.

Application permissions skip the user entirely

Microsoft's documentation draws the line clearly. A delegated permission lets an app act on a user's behalf, and the app "isn't able to access anything the signed in user couldn't access". An application permission works with no signed-in user, and the app "is able to access any data that the permission is associated with".

Microsoft's own example is Files.Read.All as an application permission, which can read any file in the tenant. An agent that runs on a schedule, with no human signed in, is the natural candidate for that kind of grant. That is why background agents deserve more scrutiny than chat assistants that act inside a user's session, a distinction covered in the analysis of agent identity and non-human access.

The grant outlives the project

Tokens do not expire when a pilot ends. Refresh tokens let an integration keep minting new access tokens until someone revokes the grant or a policy forces it out. Google documents one such policy: Workspace revokes OAuth tokens when a user changes their password, though Apps Script applications are excluded. An abandoned agent with a live refresh token is a standing credential with no owner, and in our view it is a bigger risk than an active agent with the same scopes.

What the 60% figure measures, and what it does not

Read the Opsin release closely and the headline narrows. The 60% applies to agents "provisioned beyond default settings," not to every agent in the environment. A second 60% in the same release covers agents "judged to have configured capabilities that exceeded their original stated intent," and the release does not say who did the judging.

The methodology statement is one sentence. Opsin "analyzed enterprise production environments across eight verticals between March 2025 and June 2026." There is no count of agents, no count of customers and no list of verticals. Opsin sells agent security tooling, so this is Tier 3 evidence under any reasonable sourcing standard: useful for direction, never enough on its own.

The near-90% figure does not trace

A figure of roughly 90% of agents being over-permissioned circulates in vendor marketing and security newsletters. We could not trace it to a single primary study during research for this post. The closest number is Opsin's October 2026 statement that 93% of "misaligned tools connected to agents had full, unrestricted access". That is a share of misaligned tools, not a share of agents, and the term misaligned is not defined.

So we quote the 60% with its denominator and the 93% with its caveat, and we do not quote a 90%. If you see the round number in a board pack, ask for the source and the denominator.

The Salesloft Drift tokens are the case study for agent grants

Drift is a chat and sales assistant product owned by Salesloft. It connects to Salesforce through OAuth, the same way a modern AI agent does. In August 2025 that connection became the attack path.

Google Threat Intelligence Group published its analysis on 27 August 2025. It said that "beginning as early as Aug. 8, 2025 through at least Aug. 18, 2025," a group it tracks as UNC6395 targeted Salesforce customer instances "through compromised OAuth tokens associated with the Salesloft Drift third-party application". The actor queried Cases, Accounts, Users and Opportunities, then searched the results for AWS access keys, passwords and Snowflake tokens.

Salesloft and Salesforce revoked all active access and refresh tokens for the Drift application on 20 August 2025. By our count that is 12 days from the first observed activity to revocation, with the attacker active for at least 10 of them. No Salesforce vulnerability was involved. The tokens worked because they were valid.

Google's 28 August update widened the scope. It advised Drift customers to treat "any and all authentication tokens stored in or connected to the Drift platform as potentially compromised". It also said a very small number of Google Workspace accounts were accessed on 9 August. One integration, two suites. The lesson for agents is direct: every connector an agent holds is a token someone else stores, a supply chain point developed further in the post on MCP server supply chain risk.

Google's remediation list reads like a least-privilege checklist. It says to "ensure that applications have the minimum necessary permissions and avoid overly permissive scopes like full access". It also says to enforce IP restrictions on the connected app and to grant the API Enabled permission only through a permission set. We use that list as the Salesforce half of the procedure below.

AI agent permissions in Google Workspace: what admins can see and restrict

Workspace puts third-party and internal app access under API controls in the Admin console. The controls are better than most admins assume, and the defaults are looser than most admins assume. Out of the box, users can grant any third-party app access to their own data.

Accessed apps and the OAuth log show you the grants

The Accessed apps list shows each app with the number of users accessing it and the Google service APIs, which means OAuth scopes, it requests. The CSV export adds verification status, organisational unit and the scopes per service. Google notes that details "typically appear 24 to 48 hours after authorization," so a grant made this morning may not be visible yet.

The OAuth log events report records each time a third-party app is authorised, with the client ID, scope, user and IP address. It includes a field that marks events performed by an agent. The default view covers the last 7 days, and API call events are only logged on Enterprise Plus, Enterprise Standard, Education Plus, Education Standard and Cloud Identity Premium. On a Business edition you see the grant but not what the app did with it.

Restricting access is graded. A Trusted app can reach every service, including restricted ones. Limited apps reach only unrestricted services. Specific Google data limits an app to the scopes you set, and Blocked denies everything. Gmail and Drive also carry a predefined list of high-risk scopes, and Google lists 9 for Gmail alone, starting with the full https://mail.google.com/ scope. You can stop untrusted apps from requesting any of them.

Domain-wide delegation is the worst case

Domain-wide delegation lets a service account act as any user in the domain without their consent. Google's own help page says that with it "the app has access to the data belonging to all of your users," and recommends a regular review of service accounts. Its best-practice page is blunter: use delegation "only when you have a critical business case that requires an app to bypass user consent". An agent vendor that asks for domain-wide delegation as a setup step should have to justify it in writing.

Scoping agent OAuth grants in Microsoft 365

Microsoft 365 permissions live in Microsoft Entra ID. The review starts at Enterprise apps, where each application has a Permissions page split into Admin consent and User consent tabs. You can revoke admin consent there. Microsoft's documentation is explicit that "you can't revoke permissions in the User consent tab using the portal," so user grants need Microsoft Graph or PowerShell.

The Graph calls are short. List delegated grants with GET /servicePrincipals/{id}/oauth2PermissionGrants and application permissions with GET /servicePrincipals/{id}/appRoleAssignments. Export both for every agent's service principal and you have your inventory. The difference between the two grant types, and why it matters for agents acting as a user, is examined in the comparison of agent credentials and user impersonation.

One trap is worth stating plainly. Microsoft notes that revoking a granted permission "doesn't stop users from re-consenting to the application's requested permissions". If you revoke without also tightening user consent settings, the agent can ask again and get the same scope back. Microsoft recommends allowing user consent only for apps from verified publishers, and by default all users can consent to permissions that do not need admin approval.

Exchange RBAC for Applications scopes mailbox access

An application permission such as Mail.Read lets an app read email in all mailboxes. That is the default, and it is far too much for an agent that triages one shared inbox. RBAC for Applications in Exchange Online lets you pair a grant with a resource scope that names which mailboxes the app can reach. It replaces the older Application Access Policies.

The catch is in Microsoft's FAQ. Permissions are "a union operation" of the Entra grant and the Exchange grant. If you add a scoped Exchange role but leave the unscoped Mail.Read consent in Entra, the agent still reads every mailbox. You must remove the organisation-wide grant for the scoping to mean anything, and changes can take 30 minutes to 2 hours to apply.

Selected permissions do the same for SharePoint and OneDrive

For files, Microsoft Graph offers Selected scopes, starting with Sites.Selected and now extended to lists, list items and files. An app consented for a Selected scope "would initially have no access." An admin must then assign it to specific sites or lists with a role such as read or write. For an agent that summarises one project site, this is the correct shape. Files.Read.All is the wrong one.

Scoping agent OAuth grants in Salesforce

Salesforce agents and integrations connect through connected apps, and each connected app requests OAuth scopes. The broadest is full, which Google's Drift guidance names directly as the scope to avoid. Most integrations that read and write records need the api scope plus a refresh scope, and not more.

The useful controls sit in the connected app's OAuth policies. Setting permitted users to admin-approved users who are pre-authorised means only profiles or permission sets you choose can use the app. Setting IP relaxation to enforce IP restrictions means a stolen token fails from an unknown network, which is exactly the control that would have blunted the Drift reuse. Google also recommends removing API Enabled from profiles and granting it only through a permission set.

Uninstalled connected apps and Event Monitoring

Salesforce tightened use of uninstalled connected apps from early September 2025, according to notices published by several of its software partners. Users are blocked from connecting through an app the org has not installed unless they hold one of two bypass permissions, Approve Uninstalled Connected Apps or Use Any API Client. Check who holds those two permissions before anything else, because each one quietly reopens the gap.

For evidence of what an agent actually did, Google pointed Drift victims to Event Monitoring and the UniqueQuery events, which log executed SOQL queries. Event Monitoring is a paid add-on in many editions. If you do not have it, you can see that an agent connected but not what it queried, which is the same blind spot Workspace Business editions have.

Compiled from Google Workspace Admin Help, Microsoft Learn and Google Threat Intelligence Group guidance, read October 2026. Edition limits apply on all three platforms, so confirm which controls your licence includes.

A least-privilege agent access review in six steps

The procedure below runs on any of the three platforms. It assumes no new tooling. A spreadsheet and admin access are enough for a first pass across a few dozen agents.

The order matters. Inventory comes before restriction, because blocking an app you have not identified breaks a workflow someone depends on and teaches the business to route around IT. Tighten consent before revoking, or the agent asks again and gets its scopes back.

Step 2 is where most reviews stall, and it is the step we would never skip. An agent with no owner cannot have a stated task, and an agent with no stated task cannot be scoped. Treat ownerless agents as abandoned and block them after notice. The 30-day window is our recommendation, not a platform rule.

Step 3 is a judgement call that the platforms cannot make for you. Write down the reasoning for each retained broad scope. That written reason becomes your audit evidence. The record format that holds up best is set out in the agent audit log specification.

Where this argument is weakest

The case for scoping is strong. The case that scoping alone makes agents safe is not, and three objections deserve a straight answer.

First, narrow scopes break agents. Resource-scoped grants in Exchange and SharePoint take admin work for every new mailbox or site, and the 30-minute to 2-hour propagation delay in Exchange will generate support tickets. Many agent vendors do not support Selected scopes at all and ask for tenant-wide permissions as the only setup path. In those cases the honest choice is between accepting the broad grant with compensating controls and not deploying the agent.

Second, an agent can do damage entirely inside a correct scope. An inbox agent with read access to one shared mailbox can still be steered by a malicious email in that mailbox. Scoping limits the blast radius. It does nothing about what the agent decides to do inside it, which is why the Microsoft-specific controls in the review of agent controls in Microsoft 365 treat scoping as one layer of several.

The evidence base is mostly vendors selling the fix

Every over-permission statistic in this post comes from a company that sells agent security tooling. Opsin publishes no sample. The figures may be accurate, and they are still drawn from customers who bought a security product, which skews toward organisations that already suspected a problem. We would not put any of them in a board paper without that caveat attached. The only hard evidence of harm here is the Drift case, and Drift was a sales chat integration, not an AI agent in the 2026 sense. The mechanism is identical. The population is not.

Frequently asked questions

Where to start this week

Pull one export from each platform you run: Accessed apps from Workspace, oauth2PermissionGrants and appRoleAssignments from Graph, and connected app OAuth usage from Salesforce. Sort by scope breadth and circle every grant that covers the whole tenant or every mailbox. That list is your real exposure, and it is usually shorter than people fear.

Then pick the single broadest grant on that list and find its owner. If nobody claims it within a week, block it. One revoked tenant-wide grant does more for your agent security than any policy document, and it tells the business that grants now get read.

Related reading