AI Agents and the OAuth Trust Problem at Scale

At Infosecurity Europe 2026, Netskope Threat Labs presented research on how OAuth authorization abuse has evolved from third-party supply chain breaches into a structural crisis for the agentic era. This post summarizes the key findings: How the authorization model already fails at scale, why AI agents make it exponentially worse, and what enterprises can do about it today.

Broken trust

The Salesloft/Drift AI Chat Agent breach compromised over 700 Salesforce customers from a single stolen OAuth token (FINRA). In a separate incident, Gainsight tokens stolen in August 2023 went undetected for three months before discovery. These are not outliers: The Verizon DBIR 2025 found third-party involvement in 30% of all breaches, exactly double the prior year’s 15%.

These breaches all use the same mechanism. MFA fires once, at the moment a user consents to an OAuth grant, and after that, the token operates silently. MFA is the authentication, governing who gets in. OAuth tokens are the authorization, governing what can be done, indefinitely, with no further human checkpoint. That is why Proofpoint found 59% of taken-over accounts had MFA enabled: The attackers had already moved past the layer where MFA applies.

When agents become 50,000 tokens

We estimate that every agent that a user launches potentially holds around 10 OAuth grants. Scale to 1,000 employees with five agents each, and the enterprise is managing the exposure of 50,000 active tokens, most issued months ago and never reviewed.

Across the major enterprise platforms that agents are connecting to, the default is for credentials to persist until someone explicitly revokes them, and not until a timer expires. Where expiry exists, it is typically opt-in, and token rotation must be deliberately enabled, per application, by the developer or admin who set the integration up. Where platforms enforce limits, the mechanism is often inactivity-based (a token stays valid as long as it keeps being used). In short, a token issued at agent deployment will, in most environments, still be active a year later with no review nor rotation.

Five structural properties make agents worse than conventional third-party apps:

• Persistent tokens create long-lived credentials in agent memory or config, rarely rotated.
• Broad scopes requested at deployment “just in case,” are never reviewed again.
• No human-in-the-loop so autonomous actions have no gate for user approval.
• Opaque runtime gives no visibility into what the agent reads or acts on at execution time.
• Arbitrary execution means agents work in the same way as Remote Code Execution (RCE) vulnerabilities due to their open-ended workflow.

Users can have monolithic identities, agents must not

Traditional IAM was built on a monolithic model: One person, one identity, and one permission set granted. That model works for humans because supervision, accountability, and periodic review are assumed. Applied to AI agents (which act autonomously, run continuously, and consume untrusted external data) the same model becomes a liability. An agent granted the same broad permissions as its owner holds those permissions indefinitely, often with no supervision and no concept of the task it was deployed to perform.

The correct model is different: each agent needs its own narrow credential, scoped to its specific task and expired when that task ends.

The confused deputy

These properties create a specific and dangerous attack pattern. An adversary plants a malicious instruction in data that the agent legitimately consumes (a poisoned document, a booby-trapped issue comment in a code repository) and the agent follows the injected instruction and uses its own valid token to execute the attacker’s intent. Every resulting API call carries valid credentials and authorized scopes.

Token placement and blast radius reduction

The problem is architectural and the defenses are too. Four principles guide the approach: isolation, short-lived tokens, strict scoping, segmentation. These can be supported through multiple design choices available today:

• MCP-mediated access: The agent requests access through a controlled Model Context Protocol layer. Credentials are issued per tool call and the MCP layer enforces boundaries the agent cannot override. Achieving true least-privilege access still depends on the implementation assigning only the minimum permissions necessary to each tool invocation. Netskope One Agentic Broker addresses the gap the MCP specification (November 2025) currently leaves open whereby the spec recommends OAuth 2.1 for HTTP deployments but leaves per-tool scoping to implementers.
• Agent segmentation: Separate agents for separate functions, each with minimal task-specific credentials. A compromised agent’s blast radius is contained to its own narrow scope and lateral movement requires compromising an entirely different identity.
• Gateway: Gateways exist in many forms and generally allow for better governance and token lifecycle management. Many work as a SWG/web request proxy, dropping disallowed traffic, and detecting and preventing exfiltration of tokens and data. Netskope’s AI Gateway provides access control, policy enforcement, and more.

The choices above can be combined. For instance, MCP services can flow through gateways. Also, securing tokens on secrets manager is a recommended design choice.

Call for governance

A system of practice can be deployed towrap these patterns in a lifecycle: 

The following table shows the difference between an agent’s configuration today (without governance) and the ideal future state with governance. 

Agent observability: Audit trail allows for agent observability and provides visibility into how AI agents interact with models, tools, and enterprise data. By integrating with platforms such as Claude through the Compliance API, organizations can monitor agent misconfigurations, track tool usage, and gain visibility into interactions with OAuth third-party applications and services connected to the Claude workspace. Netskope One AI Command Center allows for visibility across the entire AI environment.

Detection and response: Establishing behavioral baselines for agents and tool usage allows anomaly detection and response, such as “block a session” and revoking OAuth grants in real time.

Where standards are landing

Every major framework now addressing agent security converges on the same four mandates. The following table shows each framework, its core mandate, and its publication date. 

The technical underpinning is also solidifying. DPoP (RFC 9449) sender-constrains tokens so a stolen token can’t be replayed from a different client. Rich Authorization Requests (RFC 9396) enable per-call scoped permissions instead of broad upfront grants. OAuth 2.1 consolidates both and is in active working group refinement.

If you operate in Europe, under the EU AI Act, autonomous agents with OAuth access will likely qualify as high-risk systems under Annex III, triggering mandatory oversight and audit obligations (Articles 14 and 26). Enforcement starts 2 August 2026. The governance model above satisfies what the Act requires so building it now is both the security play and the compliance play.

Start here

The question is no longer who logged in. It is: Which entity, authorized by whom, did what, with which token, for how long? Start with inventory. Know what tokens exist, what scopes they hold, and which agents use them. Everything else follows from there.

Find out more about Netskope’s AI Security products.