Why do OAuth grants create such a large attack surface for AI tools?

Why OAuth Grants Become a High-Value Target for AI Tools

OAuth grants are dangerous in AI environments because they often outlive the task they were meant to support. An agent or connected tool can keep acting with valid delegated access long after the original context has changed, which turns a convenience feature into a standing pathway into email, documents, code, and business systems. NHIMG’s AI Agents: The New Attack Surface report notes that 80% of organisations have already seen agents act beyond intended scope, while 23% have seen them reveal access credentials. That is exactly why OAuth becomes such an attractive pivot point.

The problem is not OAuth itself, but the combination of broad consent, weak task scoping, and tool chaining. Once an AI tool is granted access, attackers do not need to steal a password to obtain legitimate-looking activity. They only need to compromise the connected app, the agent runtime, or a downstream integration. In practice, many security teams discover this only after the token has already been reused across multiple systems.

How OAuth Expands the Attack Surface in Practice

OAuth grants widen exposure because they transform a single user consent event into a reusable delegation layer. For AI tools, that delegation is often too coarse. An agent may need to read one inbox thread, but the grant may allow broad mailbox access, file reads, or write actions across an entire workspace. When the tool chains into other services, each additional integration multiplies the blast radius.

Current guidance suggests treating these grants as workload credentials, not just application permissions. That means scoping access to the smallest task boundary possible, issuing short-lived tokens where feasible, and revoking access automatically when the task ends. For autonomous systems, static role-based IAM is usually too blunt because the agent’s next action is not fully predictable at grant time. Intent-based or context-aware authorisation is a better fit, especially when paired with runtime policy checks.

• Prefer task-scoped consent over tenant-wide or mailbox-wide grants.
• Use short TTLs and rotate or revoke tokens immediately after completion.
• Separate read, write, and delegate permissions so the tool cannot silently expand its own reach.
• Require workload identity controls so the system can prove what the agent is, not just what it can access.

These controls align with the agentic risk pattern described in the OWASP NHI Top 10 and with the way attackers abuse legitimate access in the Anthropic report on the first AI-orchestrated cyber espionage campaign. These controls tend to break down in multi-tenant environments where a single integration token is reused across many workflows because revocation and attribution become indistinct.

Where Teams Misjudge OAuth Risk and What Changes the Equation

Tighter consent controls often increase operational friction, requiring organisations to balance usability against privilege reduction. That tradeoff matters because AI tools are often deployed precisely to reduce human handling of repetitive tasks, which tempts teams to grant broader access than they would to a person.

There is no universal standard for this yet, but the direction of travel is clear: access should be evaluated at request time, not assumed from the original grant. If the tool is acting on behalf of a user, the system should check whether the current action matches the declared intent, the active context, and the approved resource set. For higher-risk environments, that should include anomaly detection for unusual tool chaining, abnormal data access, and privilege escalation across connected services.

NHIMG’s breach research shows how quickly delegated access can become a breach multiplier, including incidents where OAuth tokens were used to move from one compromised service into many downstream systems, as seen in the Salesloft OAuth token breach and the Klue OAuth Supply Chain Breach. The biggest failure mode is assuming a consent screen equals safe access, when in reality the grant may remain valid long after the user, workflow, or threat model has changed.

Related resources from NHI Mgmt Group

• Why do AI agents create more IAM risk than ordinary developer tools?
• Why do SaaS identities create such a large attack surface after a breach?
• Why do over-privileged cloud identities create such a large attack surface?
• Why do exposed credentials and AI workflow tools create such a fast attack path?