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

At a glance

What this is: This analysis says that when a platform stores customer OAuth tokens or API keys, its credential store becomes the security boundary and the primary threat model.

Why it matters: IAM and security teams need to treat delegated customer access as governed NHI scope, because inventory, revocation, and privilege controls now affect customer production environments directly.

By the numbers:

• Composio disclosed that 0.3% of its active connections were in the blast radius of its breach.
• The post estimates that if 0.3% mapped to roughly 5,000 connections, the full credential store contained approximately 1.7 million live credentials.

Context

A platform that stores customer OAuth tokens or API keys is no longer just running integrations. It is holding delegated production access on behalf of other organisations, which means the credential store itself becomes an identity governance problem, not only a security operations problem.

That shift breaks the old assumption that teams only need to protect their own accounts and service credentials. Once a product can act in a customer’s Slack, GitHub, Snowflake, Workday, or similar environment, revocation, scope, and lifecycle control move into the core of the platform architecture.

Key questions

Q: What breaks when a platform stores customer OAuth tokens and API keys without governance?

A: The platform stops being a neutral integration layer and becomes a delegated access repository with live production reach into customer systems. Without inventory, ownership, and revocation controls, the platform can expose many customer environments from a single compromise, and security teams lose the ability to contain access by customer, tool, or credential type.

Q: Why does delegated credential storage create such a large blast radius?

A: Because the tokens already authorize actions in downstream systems, an attacker does not need to break each customer environment separately. One compromise of the platform can be replayed across many connected tools, so the business impact depends on how quickly the platform can revoke and downscope those credentials after detection.

Q: How can security teams tell whether their integration platform has scope drift?

A: Look for credentials whose granted permissions are broader than the live integration use case, especially if the token still works after the original business context has changed. Dormant connections, unused scopes, and credentials belonging to former employees are the clearest signs that the store is carrying excess authority.

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 storage becomes a governance boundary

When a platform stores a customer’s OAuth token, the token is not a passive record. It is a live authorisation artefact that can be replayed until revoked or expired, and it often inherits the permissions granted during setup rather than the minimum access the platform truly needs. That creates an identity boundary problem: the platform is now administering access in another organisation’s environment, but the governance model often still treats the token as a local integration detail. In practice, the token store becomes the control plane for delegated access, whether the product team intended that or not.

Practical implication: Treat stored customer tokens as governed identities with inventory, scope, and lifecycle state.

Why blast radius depends on revocation speed, not just detection

In delegated access models, the attacker does not need to own the customer environment directly. If they reach the platform’s credential store, they can use the same tokens the platform uses to call downstream systems, which makes the platform a trust multiplier. Detection still matters, but the time between discovery and revocation is the real containment window. Every manual approval, support ticket, or partial revocation path expands the blast radius because the attacker’s access survives until the last valid token is disabled across every affected integration.

Practical implication: Design revocation as a fast, auditable control path for a customer, a tool, or the whole store.

Why scope drift is the hidden risk in integration platforms

Integration products often request broad scopes to reduce setup friction, then use only a subset of that access during normal operation. That gap creates scope drift, where the credential remains more powerful than the workload that relies on it. Over time, the store accumulates tokens for former employees, dormant connections, and integrations whose original approval context no longer exists. The architectural issue is not only excess privilege at issuance. It is the absence of ongoing validation that the stored credential still matches the intended use case and the current business relationship.

Practical implication: Continuously compare granted scopes with actual integration use and force re-authorization when they diverge.

Threat narrative

Attacker objective: The attacker wants to turn one platform compromise into broad downstream access across many customer production environments.

1. Entry occurs when an attacker reaches a platform that stores customer OAuth tokens or API keys and gains access to the delegated credential store.
2. Credential access follows because the platform already holds live tokens that can be used against customer systems without re-authentication.
3. Escalation happens as the attacker reuses those tokens across multiple downstream tools, expanding from one customer connection into many.
4. Impact is customer-side compromise across Slack, GitHub, Snowflake, Workday, and similar environments, often before the affected organisations see an alert.

Breaches seen in the wild

• Snowflake breach: Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.
• Slack GitHub breach 2022: Slack employee tokens stolen via a compromised vendor were used to download private GitHub repositories over the 2022 holidays.

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 access is now an identity governance problem, not a feature detail. Once a platform stores OAuth tokens or API keys on behalf of customers, it is operating a credential store that governs external production access. That changes the security boundary from protecting local secrets to governing third-party authorisation state. Practitioners should stop classifying these systems as ordinary SaaS integrations and treat them as delegated access platforms with lifecycle obligations.

Blast-radius control is the primary security variable in credential-holding platforms. The Composio example shows that compromise is no longer bounded by the platform alone when stored tokens reach into customer tools. The relevant governance question is how quickly access can be revoked across customers, tools, and credential types once exposure is suspected. That makes inventory quality and revocation orchestration the operational centre of gravity.

Scope drift turns setup-time consent into long-lived overreach. Integration platforms often collect broad scopes to make connections work and then never re-evaluate whether those permissions still match the live workload. That creates a durable mismatch between intended use and actual authority. The result is a credential estate that can outlive employee changes, product changes, and customer expectations, so the governance model must follow the credential after issuance.

Credential stores need first-class lifecycle governance because they are shared trust infrastructure. A platform that holds thousands or millions of customer credentials is not storing isolated secrets. It is maintaining a trust fabric across many organisations, each with different risk tolerance and offboarding triggers. The field should recognise delegated credential storage as its own governance category, with explicit ownership, service-level revocation expectations, and auditability as baseline requirements.

Delegated access changes the meaning of least privilege. In this model, least privilege is not only about what the platform requests at setup. It is about what continues to exist in the store after business context changes. That means governance must account for dormant tokens, orphaned approvals, and downstream access that no longer has a valid business owner. The practitioner conclusion is simple: access that is not continuously owned is access that is already drifting out of policy.

From our research library:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• 69% of organisations still authenticate machine identities with long-lived API keys, according to the 2026 State of AI Agent Identity Security Report.
• Read next: Ultimate Guide to NHIs — What are Non-Human Identities

What this signals

Credential-store governance is now part of IAM architecture. Platforms that hold customer OAuth tokens or API keys are functioning as delegated access systems, which means lifecycle and offboarding logic have to be designed into the product rather than bolted on afterwards. If your platform cannot inventory, segment, and revoke stored credentials quickly, you have a customer access problem, not just a security control gap.

Shared trust infrastructure needs shared ownership. Security, product, and engineering teams all influence how delegated access is created, but only one operating model can answer who owns revocation when a customer leaves, a user departs, or a breach hits. That ownership model should be explicit before the store scales further, because waiting for the first incident usually means the trust boundary is already too large.

For practitioners

• Define the credential store as a governed asset Inventory every OAuth token, API key, and similar delegated secret by customer, tool, scope, issuing user, creation date, and last use. Assign explicit ownership for revocation and audit responses so the platform can answer what it is holding at any moment.
• Build revocation as an operational control path Make customer-, tool-, and estate-wide revocation a single auditable operation with no manual sequencing hidden in support workflows. If containment depends on ticketing or human approval chains, the blast radius is already too large.
• Continuously reassess granted scope Compare the scope originally granted to each stored credential against the permissions the integration actually uses in production. Trigger re-authorization or downscoping when broad permissions remain in place without matching operational need.
• Offboard dormant and orphaned credentials Detect credentials tied to users who have left the customer organisation, integrations that no longer run, or tokens unused for defined periods. Revoke or quarantine them before they become invisible long-lived access paths.

Key takeaways

• Platforms that hold customer OAuth tokens or API keys are managing delegated production access, so the credential store becomes the real security boundary.
• The breach story in the article shows that a small exposed fraction can still affect many downstream systems when the platform is trusted to hold live credentials.
• The control that matters most is fast, auditable revocation coupled with continuous scope review and accurate credential inventory.

Key terms

• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• 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.
• Scope drift: Scope drift is the gradual mismatch between what an integration was meant to do and what its credentials still allow it to do. It happens when permissions are not revalidated as business needs change, creating hidden over-privilege across SaaS and API-connected systems.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

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 building or maturing an IAM programme, it is worth exploring.