You connected an AI tool to your email "just to draft replies." Somewhere in the setup flow was a screen you clicked past — a list of permissions, probably in grey text, probably with a button that said something like Allow. What did you actually grant?
Almost nobody can answer that from memory, and that is not a personal failing. The consent screen is designed to be clicked past. It lists API scopes, not consequences, and the gap between "read your calendar" and "read every meeting title, every attendee list, every note field on every event you have ever created" is not obvious from the checkbox.
This article is the concrete version of that gap: what access actually means for the tools most small businesses connect — email, calendar, CRM, file storage, chat — and a short procedure for finding out what you have already granted.
What the research says
- Research from the Cloud Security Alliance and Oasis Security, published January 2026, found that roughly 90% of deployed AI agents hold more access than the tasks they actually perform require.
- Entro Security's 2025 report put the broader figure — across all non-human identities, not just AI agents — at 97% carrying excessive privileges.
- Teleport's 2026 research found organisations that let AI tools hold broad, standing permissions saw a 76% incident rate, against 17% for organisations that scoped AI access to specific tasks.
- In August 2025, a threat actor tracked as UNC6395 stole OAuth tokens issued to the Drift chatbot's Salesforce integration and used them to query and export data from more than 700 organisations — without ever touching a password.
01An OAuth connection is not a peek. It's a standing key
When you connect an AI tool to Gmail, Google Calendar, Microsoft 365, Slack, or a CRM, you are not letting it look at one thing once. You are issuing it a token — a credential that sits in that vendor's systems and keeps working every time it is asked, until you revoke it or it expires. The tool does not re-ask your permission each time it reads a message. It authenticates with the token, and the token carries whatever scope you granted at setup.
That is the mechanism behind the Drift breach. UNC6395 did not guess a password or exploit a software bug in Salesforce. They stole OAuth tokens that a chatbot integration already held, and those tokens worked exactly as designed — because a valid token doesn't know or care whether the request behind it is the app you installed or someone who stole its keys. The access was real, standing, and silent, which is precisely what made it useful to steal.
The lesson for a small business isn't "avoid integrations." It's that every integration you approve is a standing credential living somewhere outside your direct control, and its blast radius is set by the scope you granted — not by what you meant the tool to do.
02What "read your email" actually includes
Take Gmail as the clearest example, because Google publishes its scope tiers openly. A tool asking for gmail.readonly — a restricted scope, Google's highest sensitivity tier — can read every message in the account: every invoice, every HR thread, every client complaint, every password-reset email that ever landed there. It is not scoped to "the emails you highlight" or "messages from the last week." It's the mailbox.
The broadest Gmail scope, https://mail.google.com/, goes further: read, compose, send, and delete, across the entire account, indefinitely. A tool that only needs to draft replies to new messages does not need that scope — but it is common for integrations to request it anyway, because a narrower scope means more engineering work to scope requests correctly, and "ask for everything, use what we need" is the path of least resistance for the vendor.
Google requires apps requesting these restricted scopes to pass a security assessment before wide production use — but that assessment applies to the vendor's practices, not to whether your business actually needed to grant that scope to that vendor. The review protects against a certain kind of bad actor. It does not protect against an ordinary vendor with an ordinary amount of access you didn't need to give them.
The three-minute version
If a tool only needs to draft and send messages, it should hold a compose scope, not a full-mailbox read/write/delete scope. If it only needs to check availability, it should hold a free/busy calendar scope, not read access to every event's guest list and notes. The gap between those two is usually invisible on the consent screen — it's visible only if you go and look at what was actually granted.
03Requested versus needed, across the tools you actually run
The same widening happens on every platform, just with different names for the tiers. Microsoft Graph splits permissions into delegated (the app acts as the signed-in user, limited to what that person can already see) and application (the app acts with its own identity, independent of any user, and typically needs an admin to approve it). Slack splits scopes into narrow, named permissions — channels:history is not the same grant as channels:read, which is not the same as a legacy full-workspace bot token. The pattern across all three: a narrow, task-specific scope exists, and a broad one exists, and the broad one is usually easier for the vendor to build against — so it's what gets requested by default.
| Integration | Scope often requested | What a narrow task actually needs |
|---|---|---|
| Email drafting assistant | Full mailbox read/write/delete (https://mail.google.com/ or Graph Mail.ReadWrite) |
Compose/send only, scoped to drafts it creates |
| Meeting scheduler | Full calendar read/write, all event details | Free/busy visibility plus write access to events it creates |
| CRM research agent | Full CRM read/write across every object and pipeline | Read on specific objects (contacts, deals) relevant to its task, no delete |
| File storage summariser | Read access to the entire drive or SharePoint tenant | Read access to a named folder or shared workspace |
| Slack assistant bot | Legacy full-workspace bot token, all channels | Granular scopes limited to the channels it's invited into |
Illustrative mapping based on the published scope tiers for Gmail, Google Calendar, Microsoft Graph, and Slack. The exact scope names differ by platform and change over time — check each vendor's current documentation before granting or auditing access.
04Why permission creep happens even to careful people
Nobody sets out to over-grant access. It happens through a handful of ordinary pressures, all pointing the same direction:
- The consent screen is a wall of text, not a risk statement. "View and manage your mail" doesn't tell you it includes deleted items, or every label, or attachments. Reading the scope name correctly requires knowing the platform's own taxonomy, which almost nobody does going in.
- Vendors default to broad because narrow is more engineering work. A scope that covers "everything in this category" means the vendor's team never has to revisit the request as their product grows. A narrowly scoped integration has to come back and ask again every time it adds a feature — so the incentive runs toward asking wide once.
- "To be safe" cuts the wrong way. A vendor asking for broad scope "in case we need it later" is optimising for their own roadmap, not your exposure. The safer choice for you is the opposite: the narrowest scope that does today's job, granted again later if the job grows.
- Approval is usually a single click by one person, often without anyone else in the business knowing the connection exists. Cloud Security Alliance and Oasis's research places the industry-wide over-permissioning rate at roughly 90% of deployed agents — not because businesses are careless, but because the default path through setup is frictionless in exactly the direction that adds risk.
- Once granted, it's rarely revisited. A token issued eighteen months ago for a tool nobody uses anymore usually still works. Nothing prompts you to check.
05What to actually do — the audit, step by step
- Pull the list of every connected app. Google Workspace: Admin Console → Security → API Controls → App Access Control (or, for a personal account, myaccount.google.com/permissions). Microsoft 365: Entra admin center → Enterprise applications. Slack: workspace Settings → Manage Apps. Do this even if you're confident you know what's connected — most owners aren't.
- For each one, read the actual scope granted, not the marketing description. "Manage your email" and "read and delete all email" are the same grant with different framing. Look up what the specific scope name covers in the platform's documentation if it isn't obvious.
- Ask what the tool is actually used for, and by whom. If nobody can answer, that's your answer — revoke it and see what breaks. Nothing breaking is informative too.
- Revoke anything unused or unrecognised. A dormant token is pure downside: no benefit to you, standing access to whoever ends up holding it.
- For tools you keep, ask the vendor if a narrower scope option exists. Some platforms offer a lower tier than what's requested by default; it's worth one email to ask before accepting the broad grant.
- Put a review date on the calendar. Quarterly is reasonable for a small business. The point isn't perfection at setup — it's that access doesn't silently accumulate for a year between checks.
- Treat a new AI feature inside a tool you already use as a new grant, not a free upgrade. Software vendors are increasingly wiring AI agents into products you already trust, and that agent inherits whatever access the underlying integration already holds — which is exactly why an embedded AI feature deserves the same scrutiny as a standalone integration.
06The honest summary
An OAuth connection is a standing credential, not a one-time look. What it can see is set by the scope you granted at setup, and that scope is very often broader than the task needs — not through malice, but because broad is the easier default for the vendor building it and the easier click for you approving it. Research puts the over-permissioning rate at roughly 90% of deployed AI agents, and the Drift breach showed what a stolen but perfectly valid token can do at scale: no password guessed, no software flaw exploited, just access nobody had gotten around to narrowing or revoking.
The fix isn't refusing to connect anything. It's knowing what's connected, what it can actually reach, and revisiting that list on a schedule instead of once, at setup, when you were focused on getting the tool working rather than on what "Allow" actually granted.
07Common questions
What does it mean when an AI tool asks for OAuth access to my email or calendar?
It means the tool receives a token — a standing credential, not a one-time look — that lets it act on that account going forward without asking again each time. What it can actually read or change is set by the specific scope granted at setup, which is often far broader than the feature you wanted. A tool that only drafts replies can still be holding a scope that lets it read, send, and delete your entire mailbox.
What's the difference between a scope that's requested and one that's actually needed?
The scope requested is whatever the vendor built the integration to ask for, which is often the broadest available option because narrow scopes require more engineering work to maintain as the product grows. The scope actually needed is the minimum required for the specific feature you use — for example, compose-only access for a drafting assistant instead of full mailbox read/write/delete. The gap between the two is usually invisible on the consent screen and only visible if you check the specific scope name against the platform's documentation.
How common is over-permissioned AI access, really?
Research from the Cloud Security Alliance and Oasis Security, published in January 2026, found that roughly 90% of deployed AI agents hold more access than their actual tasks require. A separate 2025 report from Entro Security put excessive privileges across all non-human identities — not just AI — at 97%. This isn't a fringe problem; it's closer to the default state of most connected tools.
What actually happened in the Drift OAuth breach?
Between August 8 and 18, 2025, a threat actor tracked as UNC6395 stole OAuth tokens issued to the Drift chatbot's Salesforce integration and used them to run queries and export data from more than 700 organisations' Salesforce environments. No password was guessed and no software vulnerability in Salesforce itself was exploited — the tokens worked exactly as designed, because a valid token doesn't distinguish between the app you approved and whoever else is holding it. Salesloft and Salesforce revoked all Drift OAuth tokens once the breach was disclosed.
Does limiting AI tool permissions actually reduce risk, or is it just theoretical?
Teleport's 2026 research found a measurable gap: organisations that let AI tools hold broad, standing permissions had a 76% incident rate, compared with 17% for organisations that scoped AI access to specific tasks. That's not a small difference, and it lines up with the basic mechanism — a token can only be misused for what it's scoped to reach, so a narrower grant has a narrower blast radius if it's ever stolen or misused.
How do I find out what's actually connected to my business accounts?
Each major platform has a dedicated page for this. In Google Workspace, check the Admin Console under Security → API Controls → App Access Control (or myaccount.google.com/permissions for a personal account). In Microsoft 365, check the Entra admin center under Enterprise applications. In Slack, check workspace Settings → Manage Apps. Go through the list even if you're confident you know what's connected — most owners find at least one integration they'd forgotten about or didn't know a colleague had approved.
If a vendor asks for broad access 'to be safe,' should I just grant it?
No — that phrase describes the vendor's convenience, not your risk. A broad grant made 'to be safe' or 'in case we need it later' is the vendor avoiding having to ask again as their product grows; it isn't safer for you. The lower-risk choice is the narrowest scope that covers what you use today, with a follow-up request if the tool's job genuinely expands later. If a narrower option isn't offered, it's worth one email asking whether it exists before accepting the broad one.
What should I do with a connected app nobody remembers approving or using?
Revoke it. A dormant, unused connection has no upside for your business and is pure standing exposure — every token that still works is a target regardless of whether anyone is actively using the tool behind it. If revoking it breaks something, you'll find out quickly and can reconnect with a clearer sense of what it's actually for; if nothing breaks, that itself is useful information.
Get your connected-apps list read back to you
Pull the list from your Google, Microsoft, or Slack admin panel and send it to us. We'll tell you, plainly, which scopes are broader than the feature you're using needs and what a narrower grant would look like — no sales pitch, since we don't sell OAuth scopes and have nothing to gain from what you decide to revoke.
Send your connected-apps listSources, read 18 September 2026: Google's published Gmail, Calendar, and Workspace add-on OAuth scope documentation and its sensitive/restricted scope verification requirements; Microsoft Learn's Microsoft Graph permissions overview and best-practices guidance on delegated versus application permissions; Slack's developer documentation on granular OAuth scopes and the deprecation of classic full-workspace bot tokens; the Cloud Security Alliance and Oasis Security's January 2026 research on AI agent over-permissioning; Entro Security's 2025 non-human identity report; Teleport's 2026 research on incident rates by permission scope; and reporting from Google, Salesforce, Salesloft, and multiple security vendors on the August 2025 UNC6395 OAuth token theft affecting Drift's Salesforce integration across more than 700 organisations. Related: Your Staff Are Already Using AI You Didn't Approve and Your Software Is Growing Its Own AI Agents.
Hero image from Unsplash, used under the Unsplash License.