Token theft has always been a risk. But two recent breaches have made the scale of the impact much harder to ignore. In the Salesloft-Drift and Gainsight incidents, the ShinyHunters threat group leveraged stolen bearer tokens to access the Salesforce environments of more than 700 organizations, without triggering a single authentication alert.
Bearer tokens function like universal keys: if you have the token, the system assumes you’re authorized, no questions asked. This trust-based model has powered machine-to-machine communication across enterprise systems for years.
Now, AI agents are inheriting the same design. As enterprises race to deploy autonomous agents across their environments, every new integration expands the potential blast radius of a single token compromise. The bearer-token model that made enterprise automation possible was never built for the scale of what’s coming.
That’s why Obsidian is introducing runtime defense for SaaS supply chain token compromise, shifting security away from blind trust and towards evidence-based access.
Bearer tokens: the architecture of blind trust
Bearer tokens operate on a simple principle: possession = authorization. If a valid token is presented, the receiving platform automatically authenticates the request. There’s no verification of the user or system actually holding it.
This design is what makes automation possible. Bearer tokens allow systems to communicate with each other, without a human in the loop. For example, a Salesforce integration syncing data to a data warehouse every hour would be impractical if it required a person to re-authenticate each interaction. Bearer tokens solve that problem elegantly.
This convenient design also introduces a tradeoff. When attackers steal a bearer token, they inherit the same access as the legitimate system, creating, reading, uploading or deleting data, until the token is revoked or expires. The platform receiving these requests has no way to tell the difference.
Another way to think about it: Imagine bearer tokens like a house key. Frodo gives Sam, whom he trusts, a key to his house. Sam can come and go freely. But if that key is stolen, the front door has no other verification method to tell who’s holding it. No face recognition, no fingerprint scanner, no alarm. Just a key that fits the lock.
This model worked reasonably well when automation was limited to a handful of integrations. But today, enterprises are deploying AI agents and automated workflows across their entire ecosystem. Each agent relies on bearer tokens to access business systems, and most are granted broad permissions within them. If a single agent or integration is compromised, the attacker may inherit access to every application connected to it.
The blast radius of a single compromise has never been larger.
What a bearer token breach actually looks like
The Salesloft-Drift breach is worth examining closely.
Salesloft’s Drift is a conversational AI chatbot that commonly integrates with Salesforce. During the initial setup, Salesforce issues bearer tokens that allow Drift to access customer data going forward. When ShinyHunters gained access to Drift’s infrastructure, they were able to steal those tokens, and with them, pathways into the Salesforce environments of more than 700 organizations.
For affected companies, detection wasn’t straightforward. Every API request looked legitimate: it was authenticated and signed by a known integration. Teams were hearing reports of a vendor compromise, but even Salesloft-Drift itself didn't have visibility into the token usage logs, as those lived in each customer's own SaaS tenant.
That left security teams facing an impossible call: combing through logs that could represent either legitimate integration activity or malicious use of stolen tokens, with no clear signal to distinguish between them. Acting too fast risked disabling a business-critical integration. Waiting too long meant attackers might still be in the environment and had full access to export data.
The logs could only verify the token. They couldn’t verify the system that generated the request.
Some investigations took weeks to resolve. And others, for those organizations without the logs or context to trace the activity back to the original compromise, were never resolved at all, leaving teams uncertain whether the threat had passed or simply gone quiet
Obsidian Security’s integration attestation: prove that a request is exactly what it claims to be
Integration Attestation addresses the architectural flaw that makes token theft hard to detect, by adding cryptographic proof of origin to API requests made with bearer tokens. Let’s unpack what that means.
Before a vendor sends an API request to access a third-party application, their system stamps the request with a unique, unforgeable signature. Think of it like a wax seal on a letter. The secret used to generate that signature is stored inside secure hardware, where it cannot be copied or extracted. Only the vendor’s real systems can produce a valid signature.
Obsidian continuously verifies these signatures as API requests occur. If a request arrives with a missing or invalid signature, it’s immediately flagged for investigation. Security teams can now answer a question bearer tokens alone can never resolve: Did this request actually originate from the vendor’s environment, or is someone impersonating them?
Critically, this verification signal appears directly in the existing SaaS activity logs that organizations already use. Security teams don’t need a new monitoring system to deploy, no separate logging pipeline to maintain. The proof is embedded alongside normal integration activity, giving analysts immediate, in-context visibility during investigations.
What security teams can do now that they couldn't before
For the first time, teams have a reliable, real-time signal that distinguishes legitimate integration activity from stolen-token use, without waiting for behavioral anomalies to accumulate or for a vendor to issue a disclosure.
That changes the mat on three things that have historically made bearer token compromise so damaging.
- Detection intrusion at the moment of SaaS supply chain token compromise: Because signatures are verified continuously and appear in standard SaaS logs, suspicious activity is flagged in near-real time. The window attackers rely on, operating undetected inside a trusted integration, shortens significantly.
- Operate independently of vendor disclosures: Organizations no longer have to wait for a vendor to investigate their own infrastructure before they can understand whether their environment is affected. The evidence is in their own logs, immediately accessible.
- Reduce containment time for supply chain incidents to minutes: With clear proof of origin, analysts can escalate and revoke compromised tokens quickly, or confidently confirm that activity is legitimate. Either way, they have the evidence to support the decision to the rest of the business.
A foundation built for the autonomous future
The enterprise automation model wasn’t designed for the scale of machine activity we’re about to see. As AI agents and autonomous workflows expand across business systems, bearer tokens will increasingly become the connective tissue holding applications together. The underlying assumption – that possession of a token equals trust – will be tested in ways the original architecture never anticipated.
Integration Attestation introduces a missing layer of verification. Instead of trusting the token alone, organizations can now verify where a request actually originated. That additional signal gives security teams what they’ve never had: the ability to detect stolen-token activity, investigate incidents with confidence, and respond quickly before damage compounds.
The bearer token era isn’t over. But the era of blind trust in them is!
.jpg)
