Bearer token risk in AI agent strategy is now a governance issue

At a glance

What this is: This analysis argues that bearer token architecture is becoming a weak point in AI agent and SaaS integration strategy because possession still functions as authorization.

Why it matters: IAM and NHI teams need to treat token provenance, not just token validity, as part of access control when autonomous systems can act at machine speed.

By the numbers:

• ShinyHunters leveraged stolen bearer tokens to access the Salesforce environments of more than 700 organizations without triggering a single authentication alert.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Obsidian Security's analysis of bearer token risk in AI agent strategy

Context

Bearer tokens are a possession-based trust mechanism: whoever holds the token is treated as authorized until the token expires or is revoked. That model scales automation well, but it gives little help when the token is stolen, replayed, or inherited by an autonomous agent. In NHI governance, the problem is not only who issued the token, but whether the receiving system can prove the request still comes from the expected workload or integration.

The article uses the Salesloft-Drift and Gainsight incidents to show why this is no longer an abstract design issue. When bearer tokens become the connective tissue for SaaS integrations and AI agents, a single compromise can extend across many downstream environments. That starting position is increasingly typical, not exceptional, because enterprises keep adding machine-to-machine trust without adding equivalent verification controls.

Key questions

Q: How should security teams govern bearer tokens used by AI agents and SaaS integrations?

A: Treat bearer tokens as NHI credentials with explicit scope, ownership, and expiry, then add controls that verify request origin for the most sensitive integrations. Rotation alone is not enough if a stolen token can still replay successfully. The operational goal is to shrink blast radius, shorten exposure, and make impersonation detectable before it becomes a business incident.

Q: When does bearer token risk become a material AI governance issue?

A: It becomes material when autonomous agents, third-party integrations, or broad SaaS permissions can turn one stolen token into cross-system access. At that point, token abuse is not just an authentication problem. It is a governance failure because the enterprise has delegated authority without a way to prove the request still comes from the expected runtime.

Q: What is the difference between token validity and token provenance?

A: Token validity only shows that the token is real, unexpired, and accepted by the platform. Token provenance shows where the request actually came from and whether it originated in the expected runtime. Security teams need both, because a valid token can still be maliciously replayed by an attacker who stole it from a trusted integration.

Q: Should organisations prioritise runtime attestation over faster token rotation?

A: Yes, for high-value integrations, because rotation reduces dwell time but does not prove request origin. Runtime attestation answers the harder question of whether the request was made by the legitimate system or by an impersonator. In practice, organisations need both, but attestation should lead where data sensitivity and agent autonomy are high.

Technical breakdown

Why bearer tokens create blind trust in SaaS and AI workflows

Bearer tokens implement a simple rule: possession equals authorization. That is efficient for machine-to-machine communication because the system does not need a human prompt at every request. The downside is structural. A receiving platform can validate that a token exists and is unexpired, but it cannot prove who is actually presenting it. In NHI terms, the token is both identity artifact and access mechanism, which means theft collapses identity and authorization into the same failure point. AI agents amplify this because they often operate continuously and across multiple systems, so one exposed token can inherit broad access across a workflow chain.

Practical implication: Treat bearer tokens as high-value secrets whose origin must be verified, not just whose value must be rotated.

How stolen token use hides inside normal API activity

Stolen bearer tokens are difficult to spot because the requests they create look legitimate to the downstream SaaS platform. The API call arrives with a valid token, a known integration pattern, and often the right permissions, so traditional authentication alerts do not fire. This is why token theft is so dangerous in SaaS supply chains and agentic workflows. The compromise often shows up only in context, such as unusual data movement, changed behavior, or external intelligence about a vendor breach. By then, the attacker may already be operating with the same privileges as the original integration.

Practical implication: Base detection on provenance and context, not only on whether a request was authenticated.

What evidence-based access adds to token governance

Evidence-based access means the system checks whether the request originated from the expected runtime, not just whether the token is syntactically valid. That can be done through cryptographic attestation, signed requests, or other origin proofs that link activity back to the legitimate workload. The architectural value is that it separates possession from trust. For NHI governance, this matters because service accounts, AI agents, and SaaS connectors often have standing authority that outlives any single session. If the request cannot be tied to the right runtime, the safest assumption is that the token may be replayed or impersonated.

Practical implication: Require origin verification for high-trust integrations that can reach sensitive SaaS data.

Threat narrative

Attacker objective: Use stolen integration tokens to move laterally through SaaS tenants and extract data while blending into normal API traffic.

1. Entry via compromised third-party integration credentials that let attackers obtain bearer tokens tied to SaaS access.
2. Escalation through token replay against downstream environments where the platform trusts possession as authorization.
3. Impact through unauthorized access to large numbers of tenant environments without triggering standard authentication alerts.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Bearer-token trust is now an NHI governance problem, not a niche integration issue. The architecture worked when machine-to-machine access was narrow and well understood, but AI agents and SaaS connectors now multiply the number of entities that can act with standing authority. Once possession alone becomes authorization, the organisation has already delegated too much trust to the token layer. Practitioners should reclassify bearer-token governance as identity control, not just secret management.

Identity blast radius is the right mental model for AI agent integrations. A single compromised token can fan out across many systems because autonomous workflows are built to reuse credentials at speed. That means the main question is no longer whether a token is valid, but how far that token can reach if it is replayed. Teams should map token reachability and privilege depth before they connect agents to production SaaS.

Runtime proof of origin is a better control objective than simple token rotation. Rotation still matters, but it does not answer whether a live request came from the correct runtime. The more the enterprise depends on autonomous systems, the more security must verify provenance at request time. That shifts governance from static entitlement review toward continuous trust validation, which is where NHI control design needs to move.

AI agents inherit the weakest assumptions of legacy automation. Many agentic programs are being built on top of the same integration patterns that made SaaS automation easy but opaque. If the underlying credential model cannot distinguish a real workload from an impersonator, the agent layer simply scales the weakness. Security leaders should assume that every unmanaged bearer token is a future agent governance issue.

Possession-based access is no longer adequate for high-value SaaS workflows. The field needs a clearer separation between credential validity and request authenticity, especially where sensitive data, autonomous execution, and third-party integrations intersect. That is the direction NHI governance is moving: from blind trust in shared secrets to evidence-backed authorization decisions. Practitioners should design for proof, not assumption.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records including chat histories, backend credentials, and API keys.
• For a broader incident pattern, see 52 NHI Breaches Analysis for the recurring ways compromise spreads through machine identities and integrations.

What this signals

Identity blast radius is now a programme-level risk metric. As AI agents inherit bearer-token-based access, security teams need to measure how far one compromised credential can travel across SaaS tenants, data pipelines, and delegated workflows. With the average organisation believing more than 1 in 5 of their non-human identities are insufficiently secured, according to the 2024 ESG Report: Managing Non-Human Identities, this is a structural governance gap rather than an edge case.

Runtime proof should become part of your exception process. If a request cannot be tied back to the expected workload, the organisation should have a defined containment step, not an open-ended investigation. This is where NHI policy, incident response, and SaaS admin controls need to meet, because the response window is getting shorter while the blast radius is getting wider.

AI agent programmes should be designed to survive token replay. That means separating standing integration permissions from the ability to execute sensitive actions, especially in systems that hold customer data or support automation at scale. Teams that delay this change will keep inheriting legacy trust assumptions into autonomous workflows, and those assumptions will fail under pressure.

For practitioners

• Map bearer token blast radius Inventory every integration, service account, and AI agent that relies on bearer tokens, then document which SaaS tenants, data sets, and workflows each token can reach. Focus on the paths that can touch Salesforce, support systems, or data warehouses, because those are the easiest places for replay to become material. Use the 52 NHI breaches Report as a reference point for how fast unmanaged trust can compound.
• Add origin verification to critical integrations Require cryptographic proof of origin or equivalent attestation for high-trust machine-to-machine requests so downstream systems can distinguish the real runtime from replayed credentials. Prioritise integrations that support business-critical SaaS access and delegated AI agent actions. The OWASP NHI Top 10 is useful here because token misuse and agent privilege abuse are already converging.
• Shorten token lifetime where runtime proof is absent Reduce standing exposure by tightening token TTLs, limiting scopes, and revoking dormant integrations that no longer need broad access. This is not a substitute for provenance checks, but it lowers the window in which replay can succeed. Pair the policy with the Ultimate Guide to NHIs , Why NHI Security Matters Now to keep the board discussion anchored on risk.
• Build a replay-investigation runbook Define how analysts will compare API logs, vendor disclosures, and integration ownership records when bearer token abuse is suspected. Make the runbook specific to SaaS environments, because the logs often live in the customer tenant and can take time to interpret. If token provenance cannot be established quickly, isolate the integration before impact spreads.

Key takeaways

• Bearer tokens remain efficient for automation, but they also collapse identity and authorization into a single point of failure when stolen.
• The scale of exposed NHI risk is already visible in real breaches, where hundreds of downstream environments can be reached through one compromised integration.
• Practitioners should prioritise provenance checks, blast-radius mapping, and tighter token governance before AI agents multiply legacy trust assumptions.

Key terms

• Bearer Token: A bearer token is a credential that grants access to a system purely by possession. If the token is valid and unexpired, the platform treats the request as authorized, which makes automation easy but creates serious replay risk when the token is stolen.
• Token Provenance: Token provenance is the ability to verify where a request actually originated, not just whether a credential was accepted. In NHI governance, provenance helps distinguish legitimate machine activity from impersonation, replay, or abuse inside trusted integrations.
• Identity Blast Radius: Identity blast radius is the amount of access, data, and workflow reach a single credential or NHI can expose if compromised. It is a practical measure of how far one stolen token can spread impact across connected systems and autonomous agents.
• Runtime Attestation: Runtime attestation is a control that cryptographically proves a request came from the expected system or workload. It adds evidence to machine-to-machine access decisions, which is especially valuable when bearer tokens alone cannot distinguish a real integration from an attacker replaying credentials.

Deepen your knowledge

Bearer token governance for AI agents is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to reduce replay risk across SaaS integrations, the course gives you a practical starting point.

This post draws on content published by Obsidian Security: The bearer token problem hidden inside your AI Agent strategy. Read the original.