Neho’s exposed secrets show how weak NHI governance fails

At a glance

What this is: Neho’s exposed secrets incident shows how a misconfigured cloud environment can expose API keys, credentials, and third-party service access in one failure chain.

Why it matters: It matters because IAM, NHI, and PAM teams need to treat secrets sprawl, rotation, and third-party exposure as one governance problem, not isolated controls.

By the numbers:

• 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.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.

👉 Read Entro Security's analysis of the Neho secrets exposure incident

Context

A secrets exposure incident is not just a leakage problem. It is an identity governance failure, because API keys, tokens, and service credentials are the mechanisms that let non-human identities act inside cloud environments, SaaS tools, and messaging systems.

In Neho’s case, a misconfigured environment file reportedly exposed database credentials, email service access, and other secrets in one place. That is a typical cloud-native failure pattern, not an edge case, because secrets are often distributed across code, collaboration tools, and CI/CD paths rather than governed as a single lifecycle.

For a broader view of how those credentials should be governed across discovery, rotation, and offboarding, see the Ultimate Guide to NHIs.

Key questions

Q: How should security teams handle exposed API keys and service credentials?

A: Treat exposed credentials as active identities, not as misplaced text. Revoke or rotate the secret immediately, identify every service it can reach, and then confirm which workflows break. A credential leak is only resolved when the identity is no longer valid anywhere it was trusted, including third-party integrations and automation paths.

Q: Why do service accounts and API keys increase breach impact so quickly?

A: Because they usually carry persistent, reusable access across multiple systems. Once stolen, they can authenticate through normal channels and move from one service to another without triggering the same scrutiny as a human login. The more places a single credential works, the larger the blast radius becomes.

Q: What do teams get wrong about secrets rotation?

A: They often treat rotation as a periodic housekeeping task instead of a response to exposure, ownership, and scope. If a secret is copied into code, chat, or a file share, rotation alone is not enough unless the underlying distribution path is removed and every dependent system is checked.

Q: How can organisations reduce risk from third-party service credentials?

A: Inventory them as part of the same identity perimeter as internal secrets. Third-party email, messaging, and marketing credentials should have explicit owners, limited scope, and revocation procedures tied to offboarding and vendor change. Otherwise, the trust boundary extends far beyond the team that issued the key.

Technical breakdown

Why third-party service credentials widen blast radius

Neho’s exposed secrets reportedly included access to services such as Postmark, Mailgun, Twilio, and other cloud-linked tools. That matters because each integration extends the organisation’s identity perimeter into another provider’s control plane. When those credentials are leaked, attackers may send email as the company, trigger calls or texts, or sign software using the compromised identity. The technical problem is not only exposure but trust delegation across services that were never lifecycle-governed as a single set. Practical implication: inventory third-party credentials together, not by platform, and govern them as one exposure domain.

Practical implication: inventory third-party credentials together and govern them as one exposure domain.

Threat narrative

Attacker objective: The attacker’s objective is to reuse legitimate-looking secrets to impersonate the organisation, reach connected systems, and expand abuse across email, cloud, and messaging channels.

1. Entry occurred through a misconfigured public-facing environment file that exposed live secrets and service credentials.
2. Credential abuse followed when attackers could reuse API keys, SMTP access, and other secrets through legitimate service interfaces.
3. Impact included phishing, software-signing abuse, and broader misuse of cloud-linked systems using the exposed identities.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

Secrets exposure is an identity governance failure, not a file hygiene issue. The Neho incident is best understood as non-human identity drift across a cloud environment, where credentials were left in a place that could be read, copied, and reused outside their intended lifecycle. OWASP-NHI and NIST-CSF both frame this as an access and asset governance problem, not just a data-leak event. The practitioner takeaway is that secrets must be governed as live identities, not static strings.

Persistent credentials create identity blast radius when one leak reaches many services. The article’s exposed keys touched databases, email, messaging, and marketing systems, which is exactly how a single NHI compromise becomes a cross-platform incident. Identity blast radius: the number of services, channels, and privileges that become reachable once one secret is exposed. The implication is that entitlement scope, not just secret storage, determines how far the breach can travel.

Short-lived storage did not protect this environment because the governance window was already open. The article says the exposed file held outdated data alongside inactive services, which shows the operational assumption that old secrets are harmless once a team believes they are no longer in use. That assumption fails when cleanup is not enforced as a lifecycle control. Practitioners should treat dormant secrets as active risk until proven otherwise.

Third-party integrations are part of the identity perimeter, whether teams model them that way or not. Services such as email delivery, phone, and marketing tools become extensions of the organisation’s authentication surface once they accept the same credential set. The governance implication is that vendor access, service ownership, and offboarding discipline must be aligned across the full integration chain. That is the standard NHI control posture, not an extra layer.

Secrets management without continuous discovery is only partial control. The article emphasises discovery, monitoring, anomaly detection, and access control because any one of those alone misses the full problem. In practice, organisations fail when secrets are copied into code, chat, wikis, and CI/CD systems faster than they are found and revoked. The field lesson is that governance must track where secrets live, who uses them, and when they expire.

From our research:

• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
• Another finding from the same research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• For a broader lifecycle lens, see Ultimate Guide to NHIs for guidance on discovery, rotation, and offboarding across non-human identities.

What this signals

Identity blast radius is the right lens for incidents like Neho, where one exposed file can touch databases, email, messaging, and marketing services at once. Once teams model those services as a single trust chain, they can stop treating each leaked credential as a standalone issue and start tracking what the credential can actually reach.

The programme signal is clear. NHI governance cannot be built around periodic review alone when secrets live in code, files, and collaboration tools. If a team cannot answer where a secret exists, who owns it, and how quickly it can be revoked, it does not yet have control over the identity perimeter.

With 97% of NHIs carrying excessive privileges, according to Ultimate Guide to NHIs, least privilege becomes a leakage containment strategy as much as an access design principle. That shifts the operational question from whether a secret exists to how far it can travel if exposed.

For practitioners

• Remove secrets from environment files Move credentials out of .env files and into a controlled secrets manager, then block secrets from being committed to code, shared docs, chat systems, and CI/CD logs.
• Assign each secret a named owner and expiry path Record the business owner, technical owner, scope, and rotation requirement for every API key, SMTP credential, and service token so no secret can sit without accountability.
• Revoke exposed credentials before validating service continuity If a secret is found in a public or semi-public location, rotate or revoke it first, then test each dependent application, email flow, and API integration for breakage.
• Map third-party integrations as one NHI perimeter Track credentials used by email, messaging, marketing, and database services together so that a leak in one tool is evaluated against the full trust chain, not a single product.

Key takeaways

• Neho’s incident shows how a single exposed configuration file can become a multi-service identity breach.
• The scale of the problem is established: secrets leaks are common, and most organisations still store credentials in risky locations.
• The control that matters most is lifecycle governance, meaning discovery, ownership, rotation, and revocation must work together.

Key terms

• Non-Human Identity: A non-human identity is any machine- or software-based account, credential, or token that can authenticate and act inside an environment. In practice, this includes API keys, service accounts, certificates, workload identities, and automation tokens that need lifecycle governance, not just storage.
• Identity Blast Radius: Identity blast radius is the amount of access and number of systems that become reachable when one credential or token is exposed. It is a useful way to measure the harm potential of a leak because it links secret scope, privilege, and downstream service trust into one operational view.
• Secrets Lifecycle: The secrets lifecycle is the full path from creation and storage through use, rotation, revocation, and offboarding. It matters because a credential is only safe while its ownership, location, and validity are all actively controlled, especially when it is embedded in code or distributed across tools.
• Standing Privilege: Standing privilege is persistent access that remains valid until someone explicitly removes or rotates it. For secrets and machine identities, this creates ongoing exposure because leaked credentials can keep working long after the team that created them has moved on or forgotten them.

What's in the full article

Entro Security's full blog covers the operational detail this post intentionally leaves for the source:

• How the exposed .env file was discovered and what specific secrets were visible in the environment
• The vendor’s description of real-time discovery, anomaly detection, and context enrichment across secret stores and collaboration tools
• Operational examples of how the platform identifies excess privilege and misconfiguration across vaults, CI/CD, and third-party tools
• The vendor’s framing of how secrets, access control, and lifecycle management fit together in its product workflow

👉 Entro Security's full post covers the exposed credential types, service impact, and cleanup narrative in more detail.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.