Customer-held OAuth tokens turn platform credential stores into the threat model

At a glance

What this is: This is an analysis of how integration platforms, AI workflows, and SaaS tools that store customer OAuth tokens or API keys become custodians of delegated production access, with the credential store itself emerging as the primary attack surface.

Why it matters: It matters because IAM, NHI, and PAM teams must govern customer-held credentials as first-class identities, with inventory, scope, and revocation controls designed for delegated access at scale.

By the numbers:

• They disclosed that 0.3% of their active connections were in the blast radius of their breach.

👉 Read Hush Security's analysis of customer-held OAuth tokens and credential-store risk

Context

A platform that stores OAuth tokens or API keys on behalf of customers is already operating as an identity custodian, not just an application provider. In this model, the real control gap is that delegated credentials often grow one integration at a time without being treated as governed non-human identities, even though they can unlock customer production systems, data, and workflows.

The article frames that gap through the Composio incident and a wider pattern: the platform’s credential store becomes the threat model. For IAM and NHI practitioners, the problem is not merely compromise at the platform boundary, but the absence of lifecycle, scope, and revocation governance for secrets that belong to someone else but are held by the platform in production.

Key questions

Q: How should security teams govern customer OAuth tokens held by a platform?

A: Treat them as managed non-human identities with explicit ownership, scope, lifecycle state, and revocation responsibility. The platform should know who authorised the token, what it can reach, when it was last used, and how quickly it can be invalidated. Without those controls, delegated access becomes hidden production privilege rather than governed identity.

Q: Why does a breach of an integration platform create downstream risk for customers?

A: Because the attacker can use valid customer-authorised tokens to access third-party systems without breaking normal authentication patterns. The platform becomes the trusted intermediary, so compromise at that layer can reach many customer environments at once. That is why token scope, tenant isolation, and revocation speed matter as much as perimeter controls.

Q: How do organisations know whether delegated credential governance is working?

A: Look for a complete, queryable inventory, short-lived exposure windows, low scope drift, and automated revocation that does not depend on manual triage. If tokens remain active after users leave, or if teams cannot answer which integrations still use a credential, governance is not working. The control has to be measurable in runtime behaviour.

Q: What should teams do in the first 24 to 72 hours after a credential-store breach?

A: Revoke affected tokens by tenant and tool, identify which downstream systems those tokens could reach, and notify customer owners with a scoped impact summary. Then validate whether stale or over-scoped credentials remain active in the store. The first priority is to stop authorised access from continuing after compromise.

Technical breakdown

Why delegated OAuth tokens behave like governed NHI assets

When a platform stores OAuth tokens for customer integrations, those tokens function as non-human identities with delegated authority. They are not static secrets in the abstract. They are live credentials with scopes, issuers, last-used timestamps, and business impact tied to the upstream system they can reach. The technical problem is that many platforms treat them as setup artefacts rather than governed assets with lifecycle state. That breaks inventory accuracy, makes over-privilege invisible, and leaves revocation dependent on manual operations. Once tokens are reused across thousands of requests, they become part of the platform’s runtime trust fabric.

Practical implication: Model every stored token as a managed NHI with ownership, scope, and revocation state.

Why blast radius expands across customer environments

Integration platforms create an identity delegation chain: customer user to platform, platform to third-party tool, and sometimes platform to downstream customer data stores. A compromise at the platform layer therefore does not need to reach the customer’s network to create impact. The attacker can operate through valid tokens, from expected IPs, and inside ordinary request patterns. That makes traditional perimeter-based detection weaker because the action looks authenticated. The technical lesson is that delegated access must be isolated by tenant, by tool, and by permission scope, otherwise one exposed store can translate into many downstream incidents.

Practical implication: Design tenant isolation and scope boundaries so a single compromised token cannot fan out across customers.

Why revocation speed is the decisive control

A token store is only defensible if revocation is a first-class operation. If a breach requires manual workflows to revoke customer credentials, then the effective exposure window is set by human response time, not policy intent. This is especially dangerous for OAuth, because tokens can remain valid long after the original user has left, changed roles, or forgotten the connection exists. The architectural requirement is immediate, auditable, bulk revocation by customer, tool, and scope. Without that, the platform is holding a distributed set of production keys with no practical emergency brake.

Practical implication: Build revocation APIs and runbooks before scale turns every incident into a multi-hour credential exposure.

Threat narrative

Attacker objective: The attacker wants to use trusted delegated credentials to reach multiple customer environments and extract or manipulate high-value production access at scale.

1. Entry occurs through compromise of the platform that stores customer OAuth tokens and API keys.
2. Escalation happens when the attacker uses those valid credentials to access downstream customer tools without triggering normal perimeter controls.
3. Impact follows as production systems, data stores, communication platforms, and deployment environments are exposed through trusted delegated access.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• 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

Delegated customer credentials should be governed as first-class non-human identities. The security failure is not that a platform stores secrets, but that it often stores customer-authorised secrets without the same lifecycle discipline applied to internal service accounts. Scope, ownership, expiry, and revocation must be treated as identity attributes, not onboarding metadata. That is the core NHI governance gap, and practitioners should close it before a breach forces the issue.

Credential-store compromise is a blast-radius event, not a single-system event. When a platform holds third-party tokens, one incident can expose many downstream tenants without the attacker ever touching those tenants directly. That shifts the control objective from perimeter hardening to containment, segmentation, and tenant-scoped revocation. Security teams should assume the credential store is a shared trust boundary and design accordingly.

Credential inventory quality becomes a security control, not a reporting exercise. If a platform cannot answer what it holds, for whom, and under what scope, it cannot govern access in any meaningful way. Lifecycle state, last-use telemetry, and customer ownership are the minimum viable inputs for managing delegated access at scale. Practitioners should treat incomplete inventory as active risk, not administrative debt.

Speed of revocation is now a board-relevant identity metric. In delegated access models, the time from breach detection to credential invalidation determines how far an attacker can move. That makes revocation latency more important than many traditional hygiene metrics. Teams should measure it, test it, and make it part of incident readiness.

Identity blast radius: a platform’s maximum downstream exposure when its stored credentials are compromised. In delegated-access architectures, blast radius is determined by token scope, tenant isolation, and the speed of emergency revocation. Practitioners should design to shrink it continuously, not assume it can be contained after the fact.

From our research:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• For a broader view of delegated-access risk, see Guide to the Secret Sprawl Challenge, which connects discovery, rotation, and revocation into a single governance model.

What this signals

Delegated credential governance is becoming a baseline operating requirement, not a niche platform concern. The moment a SaaS product stores customer OAuth tokens, it inherits responsibility for lifecycle control that most IAM programmes were not built to handle. With 28.65 million new hardcoded secrets detected in public GitHub commits in 2025 alone, per The State of Secrets Sprawl 2026, the broader signal is that secret sprawl is already large enough to make inventory quality a business issue.

Teams should expect customers, auditors, and incident responders to ask for evidence that delegated access can be located and revoked quickly. That means proving ownership, scope, and offboarding logic for every stored credential, not just documenting policy. The operational benchmark is whether the platform can answer those questions without a manual hunt through application logs and database tables.

Credential blast radius will increasingly shape vendor selection and architecture reviews. Security teams should scrutinise whether a platform can isolate tenants, downscope access, and invalidate credentials at speed before expanding integration footprints. If those controls are missing, the business should assume delegated access will become the weakest link in the trust chain.

For practitioners

• Inventory every delegated credential Maintain a live register of every OAuth token, API key, certificate, and connected tool, including owner, tenant, scope, creation date, and last-use timestamp.
• Downscope what the integration actually uses Compare granted scopes to observed runtime access and remove excess permissions through re-authorization or per-tool scope redesign.
• Make revocation a single auditable action Support immediate revocation by customer, by tool, and across the full store, with automation that removes the manual steps from incident response.
• Segment customer credential storage Isolate tokens by tenant and connector so one compromised record cannot be reused to traverse multiple customer environments.
• Test offboarding and inactivity handling Revoke stale connections when a user leaves the originating company or when a credential goes unused beyond the review threshold.

Key takeaways

• Platforms that store customer tokens are operating as identity custodians, and their credential stores are now part of the attack surface.
• The decisive controls are complete inventory, tight scope, tenant isolation, and fast revocation, not just perimeter security.
• If a platform cannot revoke delegated credentials quickly and prove who each token belongs to, it does not have governed access.

Key terms

• Delegated Access: Delegated access is permission that one system or user grants to another platform to act on its behalf. In practice, it creates a trust chain that must be governed like any other identity relationship, including scope limits, lifecycle tracking, and fast revocation when the original trust is no longer valid.
• Credential Store: A credential store is the system or datastore that holds secrets such as OAuth tokens, API keys, certificates, and access tokens. When it contains third-party production credentials, it becomes a high-value identity asset that needs ownership, segmentation, monitoring, and emergency invalidation paths.
• Blast Radius: Blast radius is the amount of downstream damage that can occur when a credential, system, or platform is compromised. For delegated access models, it depends on token scope, tenant isolation, and how quickly the organisation can revoke or contain the affected identities.

Deepen your knowledge

Delegated credential governance and lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your platform stores customer OAuth tokens or API keys, the course helps you map that reality to a governable identity model.

This post draws on content published by Hush Security: customer-held OAuth tokens and the credential-store threat model. Read the original.