OAuth was designed for human-mediated authorization. AI agents broke every assumption it was built on. Today, most enterprise AI agents carry excessive OAuth privileges, and most security teams cannot tell you which tokens those agents hold, how long they have been active, or whether any of them have already been abused.
Security teams deploying AI agents on top of existing SaaS stacks assume OAuth handles authorization the way it always has. That assumption is the root of the AI agent OAuth token security problem.
OAuth 2.0 was designed around four assumptions that agents violate by design.
Assumption 1: A human is present at consent time. The authorization code flow requires a user to review requested scopes, authenticate, and explicitly approve access. When an agent developer configures a connector, they click through that consent screen once. The agent then operates on those granted scopes indefinitely, without any human reviewing whether those scopes still make sense for the tasks the agent is actually performing. The consent event and the usage event are permanently decoupled.
Assumption 2: Token TTLs are session-bound. Access tokens were designed to expire quickly because human sessions end. A user logs out, closes the browser, or finishes a task. Agents do not have sessions in that sense. They run continuously, refresh automatically, and treat token expiration as a technical inconvenience to route around rather than a security boundary to respect.
Assumption 3: Refresh tokens trigger periodic re-authentication. The refresh token pattern assumes that when an access token expires, the system will prompt for re-verification. In practice, agent platforms store refresh tokens in credential vaults, environment variables, or workflow configurations and use them silently. No human re-authenticates. The refresh cycle continues until someone manually revokes the token, which rarely happens without an incident to trigger it.
Assumption 4: The granting user understands what they are authorizing. OAuth scope strings like files.readwrite.all or mail.send are technical labels. When a business user builds an agent in Copilot Studio or n8n, they click through OAuth consent without a clear understanding of the blast radius those scopes represent. The agent inherits whatever was granted, and that grant persists long after the original use case has changed.
The result is that every agent in your environment is operating with credentials that were approved once, by someone who may no longer work at the company, for a purpose that may no longer be accurate. That is not a configuration problem. It is an architectural one.
Most security teams cannot answer a simple question: what credentials does each agent in our environment actually hold? Before you can manage AI agent credential exposure, you need to understand the full credential inventory.
OAuth access tokens are the primary runtime credential. They grant specific scopes to specific resources and are presented with every API call the agent makes. Short-lived by design, but only if rotation is enforced.
OAuth refresh tokens are the persistence mechanism. A refresh token allows the agent to obtain new access tokens without human re-authentication. In most agent platforms, refresh tokens are stored indefinitely. A refresh token that was issued 18 months ago and never rotated is a long-lived credential that bypasses every session control you have.
Bearer tokens are the transport layer. Any system that receives a valid bearer token treats the holder as authorized. There is no verification of who is presenting the token. This is the mechanism the attackers exploited in the Salesloft-Drift compromise: stolen bearer tokens from a third-party integration gave attackers access to Salesforce environments across 700+ organizations, and the traffic was indistinguishable from legitimate agent activity.
Service account keys and API keys are static credentials that do not expire unless explicitly rotated. They are common in Amazon Bedrock and Google Vertex deployments, where agents are assigned IAM roles or service accounts with permissions that often exceed what the workflow actually requires.
Hardcoded secrets in workflow configurations are the most immediately dangerous category. In n8n, Salesforce Agentforce flows, and custom automation scripts, developers embed credentials directly in workflow definitions. Those definitions are stored in databases, version control systems, and exported configuration files that may be accessible to anyone with read access to the workflow platform.
Embedded creator credentials in maker mode are the category most specific to modern agent platforms. In Copilot Studio and similar low-code builders, an agent can be configured to use the creator's credentials for all connector calls, regardless of who invokes the agent. A user without Salesforce access can invoke an agent built by a Salesforce administrator and retrieve CRM records at the administrator's privilege level. The agent did exactly what it was designed to do. Your IAM controls were bypassed without a single policy violation. This is the maker mode privilege escalation pattern, and it is one of the highest-severity risks in the Salesforce Agentforce security landscape.
Security teams ask the right question: if a token is stolen, how would we know? The honest answer is that structural detection is very hard, and the Salesloft-Drift incident is the clearest public proof.
Attackers obtained bearer tokens from the Salesloft-Drift integration chain. Those tokens were valid. They carried the correct scopes. They were presented to the correct endpoints. Every API call looked exactly like legitimate agent activity. The breach propagated across 700+ Salesforce environments before anyone identified the pattern as malicious. The traffic was not anomalous because the tokens were not anomalous.
This is the core detection problem for AI agent OAuth token security. A stolen token that matches the expected scope, the expected endpoint, and the expected call frequency produces no alert in any system designed to flag unexpected behavior. The token itself is the authorization. Possession equals permission. There is no secondary verification of who is actually presenting it.
The third-party integration vector amplifies this problem. AI agents connect to dozens of SaaS applications through OAuth grants. Each integration is a potential token exposure point. When a third-party vendor in that chain is compromised, the attacker inherits valid tokens for every downstream system the vendor's integration was authorized to reach. The agent continues operating. The logs show normal activity. The breach is invisible until someone correlates the vendor compromise with downstream access patterns.
The key detection signal is not the token itself. It is the relationship between the token, the identity that should be using it, and the actions being taken. Runtime AI security approaches that map effective authority, not just theoretical configuration, can surface the gap between what a token should be doing and what it is actually doing.
Ghost chasing theoretical configurations does not close the AI agent credential exposure gap. These are the controls that actually reduce risk.
Scope minimization at consent time. Before an agent is authorized, review the requested scopes against the actual workflow. If the agent summarizes documents, it needs files.read, not files.readwrite.all. Scope minimization is the highest-leverage control because it reduces blast radius before any incident occurs. The Microsoft Copilot security deployment guide covers scope review as the first governance step.
Token rotation policies. Access tokens should expire on short cycles. Refresh tokens should be rotated on a defined schedule and after any security event. Critically, verify that revocation actually worked. Post-incident reviews have found cases where teams believed they rotated a leaked token but revoked the wrong credential, leaving the original token active.
Owner-bound expiration. Every agent credential should be tied to the identity of the agent's creator or owner. When that person is offboarded, the credential should expire automatically. Orphaned agents, those whose creator accounts are disabled but whose credentials remain active, are one of the most common findings in enterprise AI agent inventory assessments. The AI agent governance framework addresses this as a lifecycle management requirement.
Vault integration for service account keys. Static credentials should never live in workflow configurations or environment variables. They belong in a secrets vault with access logging, rotation automation, and break-glass procedures. This applies to every platform, but especially to Bedrock and Vertex deployments where IAM role keys are commonly stored in agent definitions.
Detection signals for compromised tokens. Since token-level anomalies are hard to detect, focus on behavioral signals: an agent accessing resources outside its normal workflow pattern, a token being presented from an unexpected IP range, a refresh cycle occurring at an unusual frequency, or an agent making API calls to endpoints it has never reached before. These signals require runtime visibility into what agents are actually doing, not just what their configuration says they should do. The AI agent security monitoring layer that produces this visibility is the prerequisite for meaningful detection. Runtime guardrail enforcement is generally available on Microsoft Copilot today, with expanded platform coverage on the roadmap.
The fundamental shift is from theoretical configuration review to runtime truth. Knowing that an agent has a refresh token is not the same as knowing that the refresh token is being used appropriately, by the right agent, for the right purpose. Deterministic guardrails for probabilistic agents require that distinction to be visible in real time.
OAuth was not broken by AI agents. It was stress-tested by them, and the structural assumptions it was built on turned out to be human-centric in ways no one fully anticipated. The credential categories agents hold today, from persistent refresh tokens to hardcoded secrets to embedded maker mode credentials, each require controls that existing IAM programs were not designed to provide.
The five exposure vectors covered here are not edge cases. They are the default state of most enterprise agent deployments in 2026. Closing them requires scope minimization before authorization, rotation policies enforced at the platform level, owner-bound expiration tied to identity lifecycle, vault integration for static credentials, and runtime detection signals that surface behavioral anomalies rather than waiting for token-level alerts that may never come.
Start with inventory. You cannot govern credentials you do not know exist. Map every agent in your environment, the credentials each one holds, and the effective authority those credentials represent inside each connected SaaS application. That map is the foundation for every control that follows.
If your team is ready to move from theoretical configuration to runtime truth, explore Obsidian's AI agent security platform or request an AI agent risk assessment to see exactly what your agents are holding and what they can actually do.
An OAuth access token is the short-lived credential an agent presents with each API call. It typically expires in minutes to hours. A refresh token is the long-lived credential the agent uses to obtain new access tokens without human re-authentication. In AI agent deployments, refresh tokens are the higher-risk category because they persist indefinitely unless explicitly rotated, and most agent platforms store them without any automatic expiration policy.
Standard OAuth token risk involves an agent using its own granted scopes. Maker mode credential exposure means the agent is using the creator's credentials for all operations, regardless of who invokes the agent. A user without any Salesforce permissions can invoke a maker mode agent built by a Salesforce administrator and retrieve data at the administrator's privilege level. The OAuth token is technically valid. The authorization model is structurally bypassed.
When Agent A passes its OAuth token or API key to Agent B as part of a multi-step workflow, that credential is now exposed to Agent B's full attack surface. If Agent B connects to more systems, has weaker security controls, or is accessible to a broader set of invokers, the original credential's blast radius expands beyond what was authorized at consent time. This is why agent-to-agent communication requires the same credential hygiene controls as direct human-to-agent interactions.
A stolen token that carries valid scopes and is presented to expected endpoints produces no anomalous signal in systems designed to flag unexpected behavior. The Salesloft-Drift compromise demonstrated this at scale: stolen bearer tokens from a third-party integration generated traffic that was indistinguishable from legitimate agent activity across 700+ Salesforce environments. Detection requires correlating token usage against identity context, behavioral patterns, and runtime actions, not just validating token authenticity.
Build a complete credential inventory before implementing any controls. Map every agent in your environment, identify what credential types each one holds, determine which credentials are shared across agents, and flag any hardcoded secrets in workflow configurations. Without that inventory, scope minimization, rotation policies, and detection signals have no baseline to operate against. Inventory is the prerequisite for every other control in the token lifecycle management framework.