Notifications
Clear all
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.
NHIMG editorial — based on content published by Hush Security: customer-held OAuth tokens and the credential-store threat model
By the numbers:
- They disclosed that 0.3% of their active connections were in the blast radius of their breach.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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?
👉 Read Hush Security's analysis of customer-held OAuth tokens and credential-store risk →
Explore further
25/06/2026 2:12 am
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.
A few things that frame the scale:
- 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.
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
