AI and OAuth: The Risk Report

OAuth is the quiet plumbing that makes modern AI useful. When an AI assistant reads your calendar, a coding agent opens a pull request, a meeting notetaker joins a call, or an MCP server queries a SaaS platform, it is almost always OAuth underneath: a delegated-authorization protocol that lets one application act on your behalf in another, without ever holding your password. That design is genuinely good security. It is also, in the age of AI agents, becoming one of the largest ungoverned identity surfaces in the enterprise. This report explains the OAuth risks that AI agents and MCP introduce, how each one actually happens, and the controls that contain them. It is a qualitative risk explainer, not a statistics report - where a precise figure would need a citation we do not have, we describe the pattern instead.

The short version of the risk is this: OAuth was designed for a world of a few carefully vetted integrations approved by IT. AI has replaced that with hundreds of tools, many of them adopted bottom-up by employees, each asking for access with a single click. Every one of those clicks can mint a durable, broadly scoped, long-lived grant that operates outside passwords and MFA. When those grants are the wrong size, live too long, or fall into the wrong hands, the consequences are not a login problem you can reset - they are standing access an attacker inherits wholesale.

A quick refresher: how OAuth works, and why AI stresses it

In an OAuth flow, an application (the client) asks a user to authorize access to some resource - a mailbox, a drive, a repository, a SaaS record. The user is shown a consent screen listing the requested scopes (what the app will be allowed to do), and if they approve, an authorization server issues the client an access token. Access tokens are usually short-lived, so many flows also issue a refresh token the client uses to silently obtain new access tokens without prompting the user again. Crucially, tokens are bearer credentials: possession is authorization. Whoever holds a valid token has the access it represents, no password required.

None of that is new or broken. What AI changes is the scale, the source, and the habituation. The scale: instead of a handful of integrations, an organization now has agents, assistants, browser extensions, and MCP servers each requesting their own grants. The source: many of these are adopted directly by employees rather than provisioned by IT, the exact bottom-up pattern we describe in what is shadow AI. And the habituation: users now click Allow on AI-tool consent screens constantly, which erodes the scrutiny that consent was supposed to provide. Every grant also becomes a non-human identity that persists long after the person who created it has forgotten it exists.

The AI OAuth risk landscape

The risks below are not exotic zero-days. They are ordinary OAuth weaknesses that AI adoption has amplified from occasional to pervasive. Each becomes materially more likely when tools are adopted without review and grants are never revisited.

Consent phishing and malicious OAuth apps

Consent phishing sidesteps the password entirely. Instead of tricking a user into typing credentials into a fake login page, the attacker registers a real OAuth application - often with a benign, AI-flavored name - and lures the victim to its genuine consent screen. The victim sees a legitimate authorization prompt from their real identity provider, clicks Allow, and the attacker's app receives a token carrying whatever scopes it asked for. No password is stolen, and MFA does not help, because the user completed a legitimate authorization. The access persists until someone notices and revokes the grant.

AI makes this attack more effective for one behavioral reason: employees are now trained to connect AI tools to their accounts. Approving a new assistant, notetaker, or agent that wants mailbox or drive access has become routine, and routine approval is exactly the reflex consent phishing exploits. A malicious app dressed as an AI productivity tool blends into a stream of legitimate ones. The defenses are structural rather than educational alone: require administrator consent for sensitive scopes, maintain an allowlist of approved applications, and monitor for newly registered third-party apps and unusual consent events.

Over-scoped and long-lived tokens

The two most common OAuth mistakes with AI tools are asking for too much and keeping it too long. Over-scoping happens because bundling broad scopes is the path of least resistance for a tool vendor - it is easier to request full account access than to define the minimal set, and users approve the whole request or none of it. The result is an AI notetaker that can also send mail, or an assistant that can delete files it only ever needed to read. Every unnecessary scope is blast radius waiting to be used if the tool is compromised or manipulated.

Long-lived tokens compound the problem across time. A short-lived access token that expires in minutes is a small window; a broadly scoped token that lives for months, or a refresh token that renews forever, is standing access. If it leaks, the attacker does not need to phish anyone - they simply present the token. This is the same standing-privilege failure we describe for agent identities generally: the fix is to shrink the window with short lifetimes, tight refresh policy, and periodic re-consent, so that even a stolen token expires before it can do much. The scoping discipline is covered in AI access control and least privilege and least privilege for AI agents.

Refresh-token theft

Because a refresh token can silently mint new access tokens, it is one of the most valuable credentials an AI integration holds - and one of the easiest to overlook. Refresh tokens get written to configuration files, cached on developer machines, embedded in agent environments, and sometimes logged. Any of those is a place an attacker can harvest them: a compromised endpoint, an over-broad log, or a breach at a third-party AI service that stored your tokens on its side. Once stolen, a refresh token lets the attacker impersonate the AI tool indefinitely, generating fresh access tokens as old ones expire, all without a single login event to trip an alert.

This risk overlaps directly with the theft of any AI credential. When an attacker steals model or API keys and runs up cost or exfiltrates data, the pattern is the same bearer-credential abuse - see LLMjacking and stolen-key abuse. The controls are consistent: redact and protect secrets on the endpoint so they are not sitting in plaintext, bind tokens to a client or device where the platform supports it, watch for token use from unexpected locations or at unusual rates, and make revocation fast when something looks wrong. Broader credential-handling guidance lives in secrets management for AI agents.

Third-party AI apps with broad SaaS access

A distinct and growing category is the external AI service that employees connect to core business systems. An AI tool that promises to analyze your CRM, summarize your ticketing system, or draft from your document store needs access to that system - and OAuth is how it gets it. The moment an employee grants it, your data-access boundary now extends to a vendor your security team may never have reviewed. If that vendor is breached, or handles your tokens carelessly, or is itself a thin wrapper reselling access, the broad SaaS scopes it holds become a path into your data.

This is where AI OAuth risk and shadow AI meet. The tool was adopted for a real productivity reason, the grant was a single click, and no one balanced the benefit against the fact that a third party now holds standing read (or write) access to sensitive systems. The mitigation is a vendor and app review process feeding an allowlist of approved AI applications, least-privilege scopes on whatever is approved, and an inventory of which external services can reach which data. The exposure this creates is the same one covered in shadow AI data exposure.

Non-human identity sprawl

Step back and the individual risks share a root cause: every AI OAuth grant creates a durable non-human identity, and these identities accumulate far faster than anyone retires them. An agent gets a grant, an MCP server gets a grant, a browser extension gets a grant, each connected SaaS tool gets a grant. Some are approved centrally; many are not. Each is trivial to create and, in practice, almost never revoked. Over time the organization holds a large, poorly mapped population of tokens and app authorizations - the sprawl that makes least privilege and revocation impossible to enforce, because you cannot minimize or retire what you have never inventoried.

Sprawl also produces orphaned grants: authorizations that outlive the employee who created them, the project that needed them, or the tool that has since been uninstalled but whose grant still stands. Each orphan is standing access with no owner watching it. Governing this is the domain of non-human identity governance and AI identity security: assign an owner to every grant, recertify access on a schedule, expire what is unused, and revoke on offboarding.

Detection and controls that actually work

The good news is that the controls are well understood; the hard part is applying them at AI scale and to grants nobody centrally approved. Pull them together into a program:

1. Minimize scopes. Grant the narrowest, most resource-specific, and read-only-where-possible scopes an AI tool needs. Scrutinize any request for administrative or organization-wide access.
2. Keep tokens short-lived. Prefer short access-token lifetimes, tight refresh-token policy with rotation, and periodic re-consent, so a leaked token expires quickly.
3. Allowlist applications. Maintain a list of approved AI apps and require administrator consent for sensitive scopes, so a malicious or unvetted app cannot be authorized on a whim.
4. Monitor grants continuously. Watch for newly registered third-party apps, broad or admin scope requests, consent from unusual locations, and token use that does not match the tool's normal pattern.
5. Protect tokens at rest. Redact and secure secrets on the endpoint, avoid logging tokens, and bind tokens to a client or device where the platform supports it.
6. Recertify and revoke. Assign an owner to every grant, review access on a schedule, expire dormant grants, and revoke on offboarding or tool removal.
7. Inventory first. None of the above works on grants you cannot see, so discovery of AI tools and their credentials is the precondition for the rest.

For MCP specifically, the modern authorization model already encodes several of these controls - audience-restricted, short-lived tokens acquired through current OAuth flows rather than static keys. The full walkthrough is in OAuth for MCP servers explained and the wider MCP server security guide.

How Anomity fits

Most OAuth governance advice assumes you can see every grant in your identity provider and SaaS admin consoles. That view is essential, but it is only half the picture, because it does not show you which AI tools are actually installed on endpoints, what credentials they hold locally, or which unmanaged agents and MCP servers are quietly using tokens. That endpoint side is where Anomity sits. Its category is agentic endpoint security, built on a simple principle: you can't govern what you can't see.

A lightweight, unprivileged Endpoint Sensor on every managed endpoint (Windows, macOS, and Linux) discovers eight AI artifact types - AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs - and maps the tokens and secrets those tools rely on, with secrets redacted on the endpoint before any metadata leaves over HTTPS. That inventory turns over-scoped, long-lived, and forgotten AI grants from an invisible population into an owned, reviewable one. On agents that expose a hook, Anomity evaluates each tool call before it runs and returns allow, deny, or log, and violations route to your SIEM, Slack, email, or Jira with a 90-day queryable audit trail behind them. Anomity is SOC 2 Type II and complements your identity provider, SaaS admin tooling, DLP, and GRC program rather than replacing them - it adds the endpoint-side visibility into AI non-human identities that those tools were never built to see.

You can't govern what you can't see.The Anomity principle

The bottom line

OAuth is not the problem; ungoverned OAuth at AI scale is. The protocol does exactly what it was designed to do - delegate access without sharing passwords - and that is precisely why over-scoped, long-lived, and forgotten AI grants are so dangerous: they hand out durable, MFA-bypassing access that an attacker can simply present. Consent phishing, over-scoping, refresh-token theft, and broad third-party access are all ordinary OAuth weaknesses that AI adoption has turned from rare into routine, and every one of them leaves behind a non-human identity that outlives the moment it was created. The controls are known and effective - minimize scopes, shorten token lifetimes, allowlist apps, protect and monitor tokens, recertify and revoke - but they all depend on the same precondition: seeing every AI OAuth grant across your fleet. Start there. To see your own AI identity posture, book a 30-minute demo.