Topic starter
23/06/2026 9:04 pm
TL;DR: Platforms that store customer OAuth tokens and API keys are now governing delegated production access, not just their own credentials, according to Hush Security’s analysis of the Composio incident. The governance problem is architectural: once a platform holds live customer secrets, blast-radius control and revocation speed become the critical security variables.
Editorial analysis by NHI Mgmt Group, based on content published by Hush Security: “You Didn’t Sign Up to Protect Your Customers’ Credentials”.
By the numbers:
- Composio disclosed that 0.3% of its active connections were in the blast radius of its breach.
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Continuously reassess granted scope Compare the scope originally granted to each stored credential against the permissions the integration actually uses in production.
Bottom line: Platforms that hold customer OAuth tokens or API keys are managing delegated production access, so the credential store becomes the real security boundary.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
25/06/2026 2:12 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Customer-held OAuth tokens turn platform credential stores into the threat model
This post was modified 1 day ago by NHI Mgmt Group