Sumo Logic credential exposure exposes NHI rotation gaps

At a glance

What this is: Astrix Security analyzes a Sumo Logic credential exposure and the rotation steps required for multiple non-human identity types across the platform’s integrations.

Why it matters: It matters because NHI and IAM teams have to treat integration credentials as a shared attack surface, not a single secret to rotate once.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Astrix Security's analysis of Sumo Logic credential rotation after AWS account compromise

Context

Non-human identity governance breaks down when credentials are embedded across collectors, webhooks, APIs, and third-party integrations. In this case, the core issue is not only exposed access, but the operational difficulty of finding every credential tied to the affected Sumo Logic environment and proving that each one has been revoked, replaced, or isolated.

For IAM and NHI teams, the lesson is that integration inventory and credential lifecycle management must move together. A platform can be secured at the account level and still leave connected systems exposed if installed collectors, hosted collector sources, webhook URLs, and user accounts are handled as separate admin problems rather than one access model.

Key questions

Q: How should security teams handle rotated NHI credentials after a platform compromise?

A: Teams should treat rotation as a verification workflow, not a checkbox. Disable the exposed credential, replace it everywhere it is referenced, and confirm that the old secret no longer authenticates. Then review connected collectors, webhooks, and third-party integrations for stale trust paths that may still be active.

Q: What is the difference between rotating an API key and revoking an integration credential?

A: Rotation replaces a secret with a new one, while revocation removes the old secret from service entirely. In NHI environments, both matter because a rotated credential that remains referenced in another system can still create risk. Practitioners should prefer revocation plus reissue when they can prove the old path is dead.

Q: Why do non-human identities complicate incident response more than user accounts?

A: Non-human identities are often embedded in tools, collectors, pipelines, and third-party services, so the affected access path is distributed rather than centralized. That means one compromise can require coordinated action across multiple owners and systems. The operational burden is finding every place the credential is stored and used.

Q: Should organisations prioritize secret discovery before secret rotation?

A: Yes, because rotation without discovery leaves unknown copies behind. The safer sequence is identify where the secret exists, disable it everywhere, issue a replacement where needed, and then verify that no automation still depends on the old value. Discovery is what turns rotation from guesswork into control.

Technical breakdown

Why integration credentials create NHI rotation complexity

Integration-heavy platforms often rely on several credential classes at once. API keys may authenticate automation, installed collectors may use tokens or keys to register agents, hosted collectors may store third-party secrets for SaaS ingestion, and webhook URLs can function like bearer credentials because possession alone is enough to send data. Each type has a different revocation path, which is why incident response becomes a coordination exercise across multiple owners. The technical risk is not just exposure, but incomplete revocation that leaves dormant access in place after the original compromise is contained.

Practical implication: Map every credential type to its owner, rotation path, and validation step before an incident forces you to do it under pressure.

Hosted collectors and webhook URLs as hidden trust edges

Hosted collectors are a trust boundary because they often hold credentials for external systems that were never intended to be broadly visible inside the observability stack. Webhook URLs deserve the same treatment because they can be reused to inject malformed or malicious events into downstream tooling. In both cases, the issue is delegated trust: a secret or URL issued for one integration can silently inherit broad access to data, permissions, or workflow triggers. That makes revocation records and connector inventories essential control evidence, not administrative nice-to-haves.

Practical implication: Treat every connector and webhook as an independently governed identity with its own revoke-and-reissue procedure.

Why account lockdown alone does not close the NHI risk

Locking down infrastructure after a compromised credential is useful, but it does not guarantee that related service accounts, stored tokens, or embedded passwords have been removed from circulation. NHI compromise often persists through leftover keys, stale connectors, and credentials cached in administrative workflows. The underlying failure mode is lifecycle drift: the platform may be contained while dependent identities continue to exist outside the containment boundary. That is why post-incident remediation must include discovery, rotation, and confirmation of inactivity across every connected source.

Practical implication: Validate that every potentially affected secret is disabled, replaced, and no longer referenced in active connectors or automation.

Threat narrative

Attacker objective: The likely objective is to reuse one compromised credential path to reach additional non-human identities and sensitive data across connected systems.

1. Entry occurred through a compromised credential used to access Sumo Logic’s AWS account.
2. Escalation risk spread to API keys, installed collector credentials, hosted collector secrets, and webhook configurations tied to the platform.
3. Impact could include unauthorized access to sensitive operational data or the ability to weaken downstream systems through reused integration trust.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Credential exposure is only the first problem; unfinished lifecycle control is the real failure. Once a platform stores multiple integration secrets, containment depends on proving that each one has been found, revoked, and reissued. That is materially harder than a simple password reset because the affected identities are distributed across collectors, webhooks, APIs, and third-party platforms. Practitioners should treat the incident as a lifecycle governance test, not just a breach response task.

Integration sprawl creates an identity blast radius that conventional IAM reviews often miss. A single observability platform can hold credentials for cloud services, SaaS tools, and internal collectors, which means compromise can fan out beyond the initial account. The governing problem is not only privilege, but delegated trust across systems that rarely share a common owner. Security teams should assume that the blast radius is larger than the platform UI suggests.

Static trust in operational tooling is now the weakest link in many NHI programs. Webhook URLs, long-lived API keys, and stored third-party secrets all behave like standing access even when they are buried inside automation. That makes persistent credentials the wrong default for high-value data flows. Practitioners should prioritize dynamic issuance, revocation automation, and connector-level accountability.

NHI incident response must include evidence of negative state, not just successful rotation. It is not enough to say credentials were changed; teams need proof that old keys no longer authenticate, old URLs no longer accept traffic, and no downstream integration still depends on them. That shifts the burden from cleanup to verification. Security teams should build revocation validation into their response standard.

Secret sprawl is the structural reason these incidents keep repeating. When credentials live in collectors, config files, and third-party integrations, the organisation inherits a recovery problem that is larger than any single vendor stack. The operational answer is continuous discovery plus controlled offboarding. Practitioners should design for exposure first and recovery second.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why credential sprawl so often survives incident response.
• For lifecycle controls, review the NHI Lifecycle Management Guide for provisioning, rotation, and offboarding practices that reduce stale access.

What this signals

Identity blast radius is the right lens for these incidents. Once a single platform holds multiple integration secrets, the programme risk is no longer one compromised account but the total number of systems that inherit its trust. With 80% of identity breaches involving compromised non-human identities, security teams need a control model that tracks downstream dependencies, not just the original secret.

The practical signal is that observability, SaaS integration, and IAM ownership need to be joined in one operating model. If the team cannot answer which connectors depend on which secrets, the organisation cannot prove containment after a breach. That is where continuous discovery and offboarding discipline become mandatory rather than optional.

For practitioners

• Inventory every integration credential class Classify API keys, installed collector credentials, hosted collector secrets, webhook URLs, and user passwords as separate identity types with their own owners and revoke paths.
• Validate revocation for dormant access paths After rotation, confirm that old secrets fail authentication, stale connectors are disabled, and inactive keys are removed from any system still referencing them.
• Separate connector ownership from platform ownership Assign responsibility for each hosted collector and webhook to the team that can rotate it, not only to the team that runs the observability platform.
• Move toward shorter-lived integration trust Where possible, replace static secrets with ephemeral credentials, scoped tokens, or automation that can reissue access without manual coordination.
• Build an exposed-secret response runbook Pre-approve the sequence for discovery, disablement, notification, replacement, and post-rotation verification so incident response does not stall on admin handoffs.

Key takeaways

• Compromised NHI credentials are dangerous because one secret can expose multiple integration paths at once.
• The hardest part of response is not rotation itself, but proving that every stale credential and connector is gone.
• Teams need lifecycle governance, connector inventories, and revocation validation to keep this class of incident from recurring.

Key terms

• Non-Human Identity: A non-human identity is any machine, workload, service account, token, certificate, or AI agent that authenticates to systems and performs actions. In practice, these identities often outnumber people and are harder to govern because they are embedded in automation, integrations, and infrastructure.
• Identity Blast Radius: Identity blast radius is the set of systems, data paths, and downstream workflows that can be reached if one credential is compromised. For NHIs, it is usually broader than the initial account because tokens, connectors, and shared secrets often propagate trust across multiple platforms.
• Secret Sprawl: Secret sprawl is the accumulation of credentials across code, configuration files, collectors, pipelines, and third-party tools where they are difficult to inventory and revoke. It is a governance problem as much as a technical one because hidden copies can keep an incident alive after the primary secret is rotated.

What's in the full analysis

Astrix Security's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step rotation guidance for Sumo Logic API access keys and installed collector credentials.
• Remediation steps for hosted collector sources that store third-party credentials from SaaS and cloud platforms.
• Practical handling of webhook URL regeneration for HTTP-based sources and downstream configuration updates.
• User password reset and MFA enforcement guidance for environments affected by the incident.

👉 Astrix Security's full post covers the affected credential types, rotation steps, and admin actions in more detail.

Deepen your knowledge

NHI Lifecycle Management Guide topics like credential rotation, offboarding, and lifecycle control are core to our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are dealing with the same integration sprawl described here, it is worth exploring.