Table of Contents
If your platform holds OAuth tokens or API keys on their behalf, you already are.
This post is for you if your platform stores OAuth tokens or API keys on behalf of customers, provides integrations that act on users’ behalf (Zapier, Make, Nango, Composio, or similar), runs AI agents or automated workflows using customer credentials, or connects to tools like Slack, GitHub, Snowflake, HubSpot, or Workday. If none of those apply – this isn’t your problem yet. If one does – keep reading.
Think about the security team’s job description from five years ago.
You were responsible for your company’s credentials. Your service accounts.
Your API keys. Your team’s access to production systems. The perimeter was clear: protect what belongs to us.
Then something shifted – quietly, gradually, without a formal handoff.
AI agents started acting on behalf of users. Integration platforms started storing tokens to connect customer tools. Automation workflows started holding API keys to call third-party APIs on your customers’ behalf. Every new product feature that required access to a customer’s Slack, their GitHub, their Snowflake, their Workday – created a credential your platform now owned, stored, and was responsible for.
Nobody rewrote the security team’s mandate. Nobody drew a line in the org chart between “our credentials” and “credentials we hold for others.” It happened as a product decision, not a security one. The credential store grew one integration at a time, one customer at a time, and now it contains something nobody explicitly signed up to protect: the production access keys of every company that trusted you enough to connect their tools.
This is the new reality for security engineers and CISOs, mainly with integration platforms, AI analytics companies, automation tools, and any SaaS product that acts on behalf of its customers. Your threat model doesn’t start and end with your own environment anymore. Your credential store is the threat model.
Most security teams at platforms like these don’t have a complete picture of what they’re holding until something forces them to look: at a compliance audit. A penetration test. A breach.
By the time an attacker forces that moment, it’s too late.
That’s the challenge this post is about – and why Composio’s May 2026 incident report is required reading for anyone building in this space.
Think of it like an earthquake.
The most destructive quake in a sequence is rarely the first one. There are foreshocks – smaller tremors nobody takes seriously. Then the main event hits. And then the aftershocks keep coming, spreading outward, each one weakening structures that were already cracked.
The Composio breach is that earthquake. And the fault line runs through every company that trusted them with credentials.
Each company in that second column had done nothing wrong. Their security controls hadn’t failed. They didn’t appear in the attacker’s initial target list. They were downstream – connected to Composio the way buildings are connected to the ground.
When the ground moves, they move with it.
And look at the third column (the customers of the customers). The blast radius doesn’t stop at Composio’s customers. It reaches their customers too – the end users, the employees, the data. Every level of the chain absorbs a shock it never felt coming and had no way to prepare for.
That’s what makes this threat model different from a standard breach. The earthquake happened in one place. The damage is affecting everywhere else.
The companies in that list didn’t feel the tremor. They felt the aftershock.
The math nobody is running
Every integration platform, AI agent infrastructure layer, and analytics connector that requires access to customer data operates on the same model: collect credentials at setup, store them, use them to service requests on the customer’s behalf. The secret store is how the product works.
The problem is what happens when that store becomes a target.
Composio’s May 2026 incident report gave a rare and unusually transparent window into what that exposure looks like in numbers. They disclosed that 0.3% of their active connections were in the blast radius of their breach. That 0.3% contained:
Now ask the question nobody in the post-incident coverage asked:
What does 100% look like?
If Composio’s 0.3% maps to roughly 5,000 connections, their full credential store contained approximately 1.7 million live credentials across hundreds of tools – each one a valid key to a real customer’s production environment.
That’s not a vulnerability in the traditional sense. That’s architecture. And it’s not unique to Composio. It’s the default state of every platform that holds customer credentials at scale.
Read the connector list differently
Security people instinctively reach for the big number. 5,001 GitHub tokens – that’s the headline. Source code, CI/CD pipelines, GitHub Actions secrets, private repos. Real damage.
Lets take a closer look on the 1 digit row exposed secret, and what it could affect
Workday. One token. Workday is an HR system. A single compromised Workday OAuth token gives read access to employee records, compensation data, org charts, PII for an entire company’s workforce. One token. One company’s HR database. Entirely accessible.
Gong. One token. Gong records and transcribes every sales call. A compromised Gong integration exposes every recorded customer conversation, every deal discussed, every competitive intelligence shared on a call. For a sales-led company, that’s the whole game.
Metabase. One token. Metabase is a business intelligence tool that runs directly against production databases. A Metabase single token isn’t access to a dashboard – it’s often access to the underlying data. Depending on configuration, it’s a query interface to your customer’s entire data warehouse.
Sentry. One token. Sentry captures exceptions and stack traces from production applications. That means function names, file paths, line numbers, and sometimes variable values at the moment of failure. It’s a map of application internals that an attacker with time can use to find the next vulnerability.
Vercel + Render. Deployment infrastructure. One token each. These aren’t data stores – they’re the keys to production deployments. Depending on permissions, a compromised Vercel token can trigger new deployments, pull environment variables, or access build logs that contain secrets.
Gmail × 12. Twelve email accounts. Email is the root of trust for almost everything else – password resets, 2FA codes, vendor communications. Twelve Gmail tokens in a compromised credential store aren’t twelve email inboxes. They’re twelve master keys.
That’s what 0.3% contains. Not a database of user records. Not a payment system. A set of live credentials with access to HR systems, communication infrastructure, BI tools, deployment pipelines, error monitoring, and source code.
The breach doesn’t stay inside your perimeter
Here’s what makes the integration platform threat model fundamentally different from a standard enterprise breach.
In a typical breach, the attacker gains access to your data. That’s serious. You do incident response, you notify affected parties, you remediate.
When an integration platform is breached, the attacker gains access to credentials for your customers’ environments. They never touch your customers’ networks. They never trigger an alert in your customers’ security tooling. The requests come from tokens that customers authorized. From IPs their tools have seen before.
The affected company finds out when someone tells them – or when the data is already being sold.
In the Anodot incident, a threat actor breached an AI analytics platform and used authentication tokens stored there to access Snowflake environments across a dozen customer organizations. The affected companies had done nothing wrong. Their security controls hadn’t failed. They were downstream victims of a breach they never experienced.
This is the domino effect . The first tile is your platform. The rest of them belong to your customers.
The governance questions that should keep a security architect awake
The instinct after reading an incident report is to think about controls at the point of breach: Tighter access to production systems, improved detection. Those matter.
But the deeper question is about the credential store itself – not how the attacker got in, but what they found when they arrived.
Most integration platforms can’t answer these questions with confidence:
How many credentials are you holding right now, and for whom? Not an approximation from your database. A live, queryable inventory with credential type, connected tool, scope, issuing user, creation date, and last-used timestamp.
Which of those credentials belong to users who no longer work at the company that authorized them? OAuth tokens don’t expire when employees leave. The token a developer granted to your platform in 2024, for a GitHub repo they managed, is still valid today if it was never explicitly revoked. Your system is holding a credential that the issuing company almost certainly doesn’t know about.
What do the scopes on your stored credentials actually allow – and how much of that do you use? Platforms typically request the scopes that make the integration work, or accept whatever the customer’s tool offers. Those scopes are rarely audited after issuance. A GitHub token with admin:org scope, stored because the integration needed repo:read, is sitting in your database right now.
What’s your revocation SLA? If you detect a breach at midnight, how long does it take to revoke all credentials associated with a specific customer? All credentials for a specific tool across all customers? All credentials in your system? If the answer involves any manual steps, the SLA is measured in hours, and the exfiltration window is measured in the same units.
Composio’s response to their May 2026 incident involved revoking OAuth tokens across ~100 tool integrations and asking customers to handle the rest. That’s an honest response. It’s not a fast one. And speed is the variable that determines blast radius.
What a governed credential store looks like architecturally
The solution isn’t fewer integrations or simpler architecture. It’s building the credential store with the security posture appropriate for what it actually is: a centralized store of third-party production access credentials that grows more valuable – and more dangerous – with every customer you add.
Credentials as first-class entities with lifecycle state. Every stored credential should have a lifecycle model: issued → active → dormant → expired/revoked. Transitions between states should trigger events. A credential moving from active to dormant after 90 days of inactivity should generate an alert. A credential that has never been used after 30 days should prompt a review.
Scope as a governed attribute, not a setup artifact. The scope granted at authorization time should be validated against what the integration actually requires, on an ongoing basis. Overprivileged credentials should be flagged and, where the tool supports it, downscoped via re-authorization.
Revocation as a first-class API operation. Revocation should be a single, fast, auditable operation – scoped to a customer, a tool, or the entire credential store. If it’s not, it’s a design debt that will cost you in your incident response window.
The uncomfortable truth about scale
There’s a tension that every integration platform security team lives with: the product gets better as connections deepen, and security gets harder as the credential store grows.
A platform with 10,000 connections has a manageable problem. A platform with 1.7 million has a different order of magnitude – one that requires automated governance, not periodic audits.
And the threat model shifts with scale. At 10,000 connections, you’re an interesting target. At 1.7 million connections across hundreds of tools, you’re one of the highest-value credential repositories in the systems of every company that uses your product.
The security architecture needs to reflect that. Not because something has gone wrong – but because of what you’ve built.
You’re not just holding an API key for a customer’s Slack integration. You’re holding the credential that unlocks their HR system, their deployment pipeline, their source code, their recorded sales calls, their production database – depending on which of your connectors they’ve enabled.
That’s a responsibility that deserves a dedicated security discipline. Not bolted onto standard SaaS security practices. Built for the specific problem of governing delegated credentials at scale.
At Hush Security, we work with platforms on exactly this problem – the discovery, lifecycle management, and governance of non-human identities that exist on behalf of your customers.