Six 2023 secrets leaks show where NHI controls failed

At a glance

What this is: This is a roundup of six 2023 cybersecurity leaks that show how exposed secrets, over-privileged tokens, and stale passwords turned routine workflows into access failures.

Why it matters: It matters because NHI, IAM, and PAM teams have to govern secrets as identities with lifecycle risk, not as one-time credentials hidden inside code, containers, and email.

By the numbers:

• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations.

👉 Read Entro Security's roundup of six infamous cybersecurity leaks from 2023

Context

Secrets security breaks down when credentials are treated as static text instead of governed identities. In these 2023 leaks, access tokens, API keys, passwords, and storage credentials surfaced in code, containers, datasets, and even email, which turned ordinary collaboration paths into exposure paths.

For IAM and NHI programmes, the problem is lifecycle control. If a secret can be created once, copied widely, and left active for months or years, then the access model is already out of step with how modern software is built and shared.

The article’s examples are typical of the current environment, not edge cases. Public code, AI datasets, container registries, and internal communications are now all part of the secret exposure surface.

Key questions

Q: How should security teams stop secrets from leaking through code and collaboration tools?

A: Teams should treat code repositories, container registries, package indexes, email, and chat as one continuous secret exposure surface. Use automated scanning, block promotion of exposed credentials, and revoke anything found before it can be reused. Manual review is not reliable enough for high-volume software delivery or collaboration workflows.

Q: Why do leaked secrets create such a large security impact?

A: A leaked secret often carries more privilege than the task actually needs, so one exposed credential can open storage, code, or operational systems at scale. The impact depends on scope, not just on exposure. That is why least privilege, limited audience, and revocation discipline matter together.

Q: What do organisations get wrong about secret rotation?

A: They often treat rotation as an occasional cleanup activity instead of a lifecycle control. Secrets should expire or rotate when ownership changes, work ends, or access reviews identify stale trust. If a credential remains valid for months or years, it has already outlived the trust that created it.

Q: Who is accountable when a leaked secret exposes sensitive data?

A: Accountability sits with the programme that issued, stored, shared, and failed to retire the secret, not just with the person who first typed it. IAM, NHI, platform, and application owners all need clear ownership for discovery, rotation, and revocation. Without assigned accountability, exposed credentials persist.

Technical breakdown

Hardcoded secrets turn source control into an identity store

A hardcoded secret is a credential embedded directly in code, configuration, or a repository. Once it is committed, every clone, backup, fork, and integration inherits the same access path. That makes source control a distribution channel for identity material, not just a development system. The real issue is not whether the secret was hidden at rest, but whether it was ever meant to survive beyond a single deployment or developer workflow. When repositories are public or broadly shared internally, exposure becomes permanent unless the credential is revoked and replaced.

Practical implication: scan every commit and repository for secrets before code leaves a trusted boundary.

Over-privileged tokens create blast radius far beyond their purpose

An over-privileged token grants more access than the task requires, which means any leak immediately widens impact. In the Microsoft example, an Azure SAS token exposed access to tens of terabytes of internal material because the token effectively behaved like broad storage-account access. The same pattern appears in AI datasets, where tokens are placed near training or collaboration assets and then reused across workflows. Privilege scope and secret location must be evaluated together, because a secret with a wide audience or broad rights is already a security incident in waiting.

Practical implication: classify every token by scope and enforce least privilege before it is distributed.

Stale secrets fail because lifecycle governance never catches up

A secret that remains valid long after its original purpose has expired is a lifecycle failure, not just a hygiene issue. The Poland defence example showed that a password shared in an email can stay active for years and still expose sensitive operational data. That is the same governance problem seen across NHI programmes: credentials are issued, copied, and forgotten. If rotation, expiry, and offboarding are not tied to the business relationship or workload lifecycle, the secret outlives the trust that justified it.

Practical implication: tie secret expiry and rotation to ownership changes, project closure, and access reviews.

Threat narrative

Attacker objective: The attacker’s objective is to convert leaked credentials into broad, durable access to internal systems and sensitive data.

1. Entry occurred when secrets were embedded or shared in repositories, AI datasets, container images, package indexes, and email threads.
2. Escalation followed when those credentials carried excessive rights, allowing broad access to storage, code assets, or sensitive operational records.
3. Impact came from the ability to read, copy, or exfiltrate internal data at scale, including passwords, API keys, backups, and defence information.

Breaches seen in the wild

• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

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 are still being governed like static text, not identities. The article shows the same failure across code, containers, datasets, and email: a secret is created once and then assumed to remain safe unless someone notices otherwise. That assumption is no longer defensible in NHI programmes, because the exposure surface now includes collaboration systems and AI workflows as well as source control. The practitioner conclusion is simple: if the secret has a lifecycle, it needs identity governance.

Blast radius, not mere exposure, is the real control gap. The Microsoft and SAP examples show that a leaked secret becomes materially worse when it inherits broad repository, storage, or cluster permissions. In practice, the decisive question is not whether a secret exists, but how much of the environment it can touch if copied. This is where over-privilege turns a leak into a breach-class event. The practitioner conclusion is to treat privilege scope as part of secret risk from the moment of issuance.

Secret rotation is a governance obligation, not a cleanup task. The Poland defence example is the clearest proof that one-time secret creation creates long-tail risk when ownership changes or the original sharing context disappears. A credential that remains valid after the business need ends is already outside policy. This aligns with OWASP-NHI and NIST-CSF thinking on lifecycle control. The practitioner conclusion is to govern secret expiry as part of the access model, not as an after-the-fact patch.

AI and open-source ecosystems are multiplying secret exposure paths. The article’s AI dataset and PyPI examples show that secrets now travel through training data, package ecosystems, and developer collaboration channels before they ever reach production. That broadens the problem beyond traditional appsec into identity and lifecycle governance. The named concept here is collaboration-driven secret sprawl: credentials spread through the systems people use to build software, not just the systems that run it. The practitioner conclusion is to widen discovery to every place secrets can be copied.

Manual review cannot scale to the speed of modern secret creation. The article repeatedly argues for automated scanning because humans cannot reliably inspect every repository, container, or message thread. That is not a tooling preference, it is a scale constraint. Once secrets are embedded into high-volume delivery paths, governance depends on machine-assisted discovery and response. The practitioner conclusion is to design detection and rotation as continuous controls, not periodic audits.

From our research:

• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which shows how far governance lags behind exposure.
• That visibility gap is why teams should pair discovery with Ultimate Guide to NHIs , Key Challenges and Risks when building controls for secrets and workload identities.

What this signals

Collaboration-driven secret sprawl is now a programme-level problem, not a code-review problem. When secrets move through repositories, chat, email, and package ecosystems, discovery has to become continuous and cross-platform, with owners assigned to every credential class before it can be rotated or revoked.

The governance model also needs to shift from locating secrets to tracking their trust window. If a credential can survive after the task, project, or vendor relationship has ended, then lifecycle control is failing regardless of how quickly a scanner detects it. That is the practical boundary teams should measure.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, the market is moving toward lifecycle-heavy control models rather than isolated secret hygiene. Teams that keep treating secrets as incidental text will keep inheriting the same exposure patterns.

For practitioners

• Scan every code commit for embedded secrets Inspect each new commit, branch, and pull request before it reaches public or broadly shared repositories. Prioritise automated detection for API keys, tokens, certificates, and passwords, then block promotion until confirmed clean.
• Map secret scope before distribution Review whether a token, SAS key, or service credential grants only the minimum access needed for the task. Remove broad storage, write, and repository permissions before the secret is copied into any workflow.
• Automate rotation for long-lived credentials Set expiry and replacement windows for secrets that survive beyond a single deployment or project. Tie rotation to ownership changes, offboarding, and access review cycles so stale credentials do not remain valid after trust has shifted.
• Extend discovery into chat and email Search Slack, email, Jira, and other collaboration tools for exposed secrets, not just source code and registries. Treat internal message paths as part of the secret attack surface because humans often paste credentials there during troubleshooting.

Key takeaways

• The core failure is governance, not simple disclosure: secrets become dangerous when they remain valid, over-privileged, or widely copied across modern delivery workflows.
• The article’s examples show scale across AI data, containers, open source, and email, which means secret exposure is now a cross-domain identity problem.
• Continuous discovery, least-privilege scoping, and lifecycle-based rotation are the controls that change the outcome when secrets are already in circulation.

Key terms

• Secret sprawl: Secret sprawl is the uncontrolled spread of credentials across code, tools, documents, and collaboration systems. It becomes a governance problem when no team can reliably say where a secret lives, who can see it, or whether it is still valid. That uncertainty increases exposure and slows revocation.
• Over-privileged token: An over-privileged token is a credential that can do more than the task that created it requires. In practice, this means a single leak can expose storage, repositories, or administrative functions far beyond the intended use. The wider the scope, the larger the blast radius.
• Secret lifecycle governance: Secret lifecycle governance is the set of controls that manage creation, distribution, rotation, expiry, and revocation for credentials. It treats secrets as living access artefacts rather than static text. That approach is essential when the same credential may travel through code, email, and automation.

What's in the full article

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

• The specific leak examples and the exact secret types exposed in each case
• The article’s breakdown of how much access some of the leaked credentials actually granted
• The practical examples of repository, container, and package scanning paths
• The defence-sector email case and the long-lived password exposure timeline

👉 The full Entro Security post covers the breach examples, leaked secret types, and detection lessons 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 building or maturing an IAM or identity security programme, it is worth exploring.