TL;DR: Bearer tokens let systems authenticate by possession, which is why stolen tokens in the Salesloft-Drift and Gainsight incidents gave attackers access to Salesforce environments at scale without triggering authentication alerts, according to Obsidian Security. That same trust model is now being inherited by AI agents, making token compromise a governance problem, not just an incident-response problem.
At a glance
What this is: This is an analysis of how bearer-token trust breaks down when AI agents and SaaS integrations rely on possession-based authentication, with recent token theft incidents showing how access can be abused at scale without triggering authentication alerts.
Why it matters: It matters because IAM, PAM, NHI, and agentic-AI programmes cannot treat bearer tokens as proof of identity when governance, containment, and incident response all depend on distinguishing legitimate automation from stolen-token use.
By the numbers:
- Stolen bearer tokens in the Salesloft-Drift and Gainsight incidents gave attackers access to more than 700 organizations’ Salesforce environments without triggering a single authentication alert.
Context
Bearer tokens are credentials that grant access based on possession rather than on a fresh interactive authentication step. In this article, the governance problem is not token use itself, but the fact that a stolen token can still look legitimate inside a SaaS activity trail.
That matters for NHI and agentic AI programmes because integrations and agents increasingly depend on the same trust model. When the actor is a machine or agent, identity governance has to account for request origin, delegation, and revocation, not just authentication success.
The article’s central claim is that AI agent strategy is now inheriting a control model that was acceptable for limited automation but fragile at enterprise scale. As more systems and agents chain through bearer tokens, the blast radius of one compromise becomes a governance issue, not only an incident-response issue.
Key questions
Q: What breaks when bearer tokens are stolen or logged?
A: Bearer tokens become immediately reusable because possession is enough to authorize the request. If the token is exposed in logs, browser storage, or interception, an attacker can replay it until expiry and act as the original caller. That is why bearer semantics create replay risk even when the rest of the system is correctly configured.
Q: Why do bearer credentials create extra risk for AI agents?
A: Bearer credentials create extra risk because possession alone is enough to act. If a token is copied from logs, prompts, code, or orchestration tools, the attacker can often inherit the agent’s access path without defeating a second proof of legitimacy. That makes runtime binding and rapid revocation more important than static secret storage.
Q: How can security teams tell whether token-based activity is legitimate?
A: Security teams need evidence that the request originated from the expected runtime environment, not just that the token was valid. That means looking for origin assurance, ownership, and revocation context in addition to logs, so investigators can separate normal automation from replayed credentials.
Q: What should organisations do immediately after a token theft incident?
A: Revoke refresh tokens, force reauthentication, and review any privileged changes made during the token’s remaining validity window. Then check whether admin roles, security configurations, or mail flow rules were altered before the session was terminated.
Technical breakdown
Why bearer tokens behave like universal keys
Bearer tokens are authorization artifacts, not proof-of-operator artifacts. The platform checks whether the token is valid and scoped, then accepts the request if the possession test passes. That makes them useful for machine-to-machine communication, but it also means any party that steals the token can act with the same rights until revocation or expiry. In a SaaS environment, the receiving system cannot tell whether the request came from the intended integration or from an attacker replaying the credential. That is why bearer-token compromise is so difficult to detect from authentication logs alone.
Practical implication: treat bearer-token possession as a weak trust signal and build controls that verify request origin, not just token validity.
How SaaS supply-chain token compromise spreads across integrations
In a delegated SaaS integration, one token can open a path from a third-party application into the customer’s business systems. The token may be issued during setup, then reused repeatedly by automated workflows, agents, or sync jobs. If attackers compromise the issuing environment, they inherit the downstream access path and can blend into normal API activity because requests are signed and authenticated. That is why the blast radius grows quickly in interconnected environments: the token does not just unlock one app, it can become the bridge between multiple cloud services, tenants, and data stores.
Practical implication: map each delegated integration to its downstream access paths and identify where one stolen token could fan out into multiple systems.
Why AI agents make the bearer-token model harder to govern
AI agents increase the number of non-human actors that can legitimately hold and use bearer tokens, often across dynamic workflows. That does not automatically make them autonomous in the identity-model sense, but it does widen the governance surface because more runtime actions depend on delegated credentials. The underlying assumption in older automation models was that possession implied an acceptable operator boundary. With agents, that assumption weakens because execution paths are broader, faster, and less predictable than fixed service workflows. Governance has to follow the token lifecycle and the delegation chain, not just the human owner of the programme.
Practical implication: classify which agents, integrations, and service identities can initiate token use so governance can follow the actual delegation chain.
Threat narrative
Attacker objective: The objective was to use compromised bearer tokens to reach downstream Salesforce data and operate inside trusted integrations without raising authentication alarms.
- Entry occurred when the ShinyHunters threat group compromised the Salesloft-Drift environment and obtained bearer tokens tied to Salesforce access paths.
- Credential abuse followed as the stolen tokens were replayed against customer Salesforce environments, making malicious requests look like legitimate integration traffic.
- Impact came from broad data access across more than 700 organizations, while defenders struggled to distinguish valid automation from stolen-token use.
Breaches seen in the wild
- Gainsight Salesforce breach 2025: Stolen OAuth tokens for Gainsight's Salesforce app, some eight years old, were used against customer orgs; Google saw 200+ instances at risk.
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Bearer-token governance has become a blind-trust problem, not a token hygiene problem. The issue is not only whether a token is expired or rotated, but whether the control model assumes possession is enough to authorise action. That assumption was workable in narrow automation but breaks when machine actors and SaaS chains multiply. Practitioners should now treat bearer-token trust as a governance boundary, not just a credentials issue.
Possession-based authorisation was designed for simpler delegation chains. That assumption fails when AI agents and third-party integrations can act across many systems with no human review at each request. The implication is that identity programmes cannot rely on authentication events alone to establish legitimacy. They have to reason about runtime origin, delegation scope, and the lifetime of non-human credentials.
Bearer-token compromise is now a blast-radius question. Once one token can unlock multiple connected services, the security problem shifts from single-application exposure to cross-platform propagation. That changes the prioritisation model for NHI governance and SaaS security because revocation speed, integration inventory, and dependency mapping become central controls. Practitioners should reframe token risk as an enterprise containment issue.
AI agents inherit the weakest assumptions in today’s machine-identity stack. If an agent’s operation depends on bearer tokens, the agent is only as governable as the origin assurance behind those tokens. The important point is not that agents are inherently autonomous, but that their delegated access can outpace traditional review and alerting models. Security teams should examine where agent deployment expands token trust beyond what the original automation model can support.
Integration attestation illustrates where the market is heading: from possession checks to evidence-based access. That direction matters because the next generation of NHI and agentic controls will be judged on origin verification, not just authentication success. For practitioners, the lesson is clear: governance must move upstream to the request itself, because that is where token theft becomes visible or invisible.
From our research library:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Bearer-token governance now needs an origin-assurance layer. Possession alone is no longer a sufficient trust boundary when AI agents, third-party integrations, and SaaS workflows all rely on the same credential model. Programmes that still certify access only at issuance will miss the point where the request itself needs verification.
Ephemeral execution changes the trust problem even when the actor is not autonomous. Many agents are still constrained systems, but they can amplify token risk because they move faster and touch more services than a human operator would. The practical result is that NHI and agentic governance have to move closer to the request path and further away from static review cycles.
For practitioners
- Inventory all bearer-token-dependent integrations Map every SaaS integration, agent workflow, and service account that can act through bearer tokens, then document where one credential unlocks multiple downstream systems.
- Add request-origin checks to token handling Require evidence that an API request came from the expected runtime environment before allowing sensitive actions, especially for third-party integrations and agent-driven workflows.
- Bound the blast radius of delegated access Reduce the number of applications, tenants, and data stores reachable from any single integration token, and separate high-value workflows from broad sync jobs.
- Prioritise rapid token revocation paths Make revocation a containment action that can be executed quickly when token theft is suspected, with ownership and escalation paths defined before an incident.
- Classify agent and integration ownership Assign clear ownership for each non-human credential so teams know who can approve use, who can revoke it, and who must investigate when activity looks abnormal.
Key takeaways
- Bearer tokens can make malicious requests look legitimate, which is why compromised integrations are hard to distinguish from normal automation.
- The article shows that token theft can affect hundreds of organisations at once when one delegated integration sits in the middle of many SaaS connections.
- Practitioners need to shift from token possession checks to request-origin verification, faster revocation, and tighter control over downstream blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Bearer tokens rely on possession-based authentication that breaks under token theft. |
| NHI-02 — Secret Leakage | Stolen bearer tokens are leaked credentials that can be replayed in trusted integrations. | |
| NHI-03 — Vulnerable Third-Party NHI | The incidents described stem from compromised third-party integrations and downstream trust chains. | |
| Recommendation — Apply NHI-04 controls to add origin assurance to token-based access paths. Scan and contain exposed bearer tokens as secrets, then revoke any compromised credential immediately. Inventory third-party NHI dependencies and constrain the access each integration can inherit. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent-driven access expands the ways delegated identity can be abused at runtime. |
| Recommendation — Map agent workflows to ASI03 and restrict delegated privileges to the smallest viable runtime scope. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Bearer tokens are authenticators whose lifecycle and revocation determine exposure duration. |
| Recommendation — Use IA-5 to govern token issuance, rotation, revocation, and expiry across SaaS integrations. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about whether token-based entitlements remain trustworthy after compromise. |
| Recommendation — Apply PR.AA-05 to review delegated permissions and remove unnecessary token reach. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Stolen bearer tokens enable credential-based access followed by movement across connected systems. |
| Recommendation — Map token theft to TA0006 and TA0008 to improve detection of replay and downstream spread. | ||
Key terms
- Bearer Token: A bearer token is a credential that grants access to whoever possesses it, without requiring strong proof that the holder is the intended client. In NHI environments, that makes theft and replay the main risk, especially when tokens are long-lived, broadly scoped, or stored in local files.
- Integration Attestation: Integration attestation is proof that an API request came from the expected system and not an impersonator. In practice, it adds origin verification to delegated access so security teams can distinguish legitimate automation from replayed or stolen credentials.
- Delegated access path: A delegated access path is the chain of identities, tokens, connectors, and approvals that lets one system act through another. It becomes a governance concern when the path outlives the original approval or can be reused for actions beyond the intended business purpose.
- Request-Origin Verification: Request-origin verification checks where a request actually came from before allowing sensitive actions. For non-human and agent-driven access, it closes the gap between token validity and true operational trust by requiring evidence about the runtime source.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on May 26, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org