Ungoverned tokens in code create the real NHI breach surface

At a glance

What this is: This analysis shows how a single ungoverned GitHub token embedded in code enabled broad repository access, credential harvesting, and prolonged lateral movement across a large environment.

Why it matters: It matters because IAM, PAM, and NHI programmes still miss machine identities hidden in code, which leaves blast radius, rotation, and inventory controls blind to the real attack surface.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 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.

👉 Read Unosecur's analysis of the Novo Nordisk token exposure and repository breach

Context

A non-human identity is any credentialed machine actor such as a token, API key, certificate, or service account. In this case, a GitHub personal access token was effectively treated as code, not as an identity, which allowed it to persist outside normal governance controls.

The governance failure is familiar to IAM and NHI teams. Credentials embedded in source files, build systems, and repository history do not behave like ordinary configuration because they carry scope, longevity, and reach. Once an attacker finds one, the repository becomes a map of other identities and permissions rather than a simple codebase.

Key questions

Q: What breaks when a GitHub token is embedded in client-side code?

A: The token stops behaving like a controlled identity and starts behaving like an unmanaged bearer credential. Anyone who copies it can use its privileges until it expires or is revoked. That creates hidden blast radius, because the code that exposed the token may also reveal other secrets, connected systems, and downstream access paths.

Q: Why do machine credentials in repositories increase lateral movement risk?

A: Repositories often expose more than code. They reveal service endpoints, environment names, deployment patterns, and sometimes other credentials that attackers can harvest after gaining one valid token. That turns a single leak into a discovery layer for broader access, especially when tokens are long-lived and broadly scoped.

Q: How should security teams measure whether NHI secret controls are working?

A: Measure how many credentials are discovered before merge, how quickly they are revoked after exposure, and how much access each credential can reach. If secrets still appear in code history, build artifacts, or repository forks, the control is not working. The key signal is reduced exposure time and narrower reachable scope.

Q: Who is accountable when a non-human identity is never offboarded?

A: The owning engineering or platform team is accountable, with IAM and security providing the control model and enforcement. A machine credential should have an owner, lifecycle, and revocation path just like any other identity. If those roles are unclear, the organisation has created an ungoverned identity by default.

Technical breakdown

GitHub personal access tokens behave like machine identities, not configuration

A GitHub personal access token is a bearer credential, which means whoever holds it can act as that identity until the token expires or is revoked. When such a token is embedded in client-side JavaScript, it can be copied without compromising the system that issued it. That distinction matters because the token may have access to many repositories, automation workflows, or downstream secrets. The core failure is not visibility alone. It is treating a reusable credential as if it were harmless code, which removes it from rotation, review, and scoping discipline.

Practical implication: inventory every token that can reach source, build, or deployment systems and treat it as a governed identity.

Secrets sprawl turns source code into an identity graph

Source repositories often contain hardcoded secrets, references to internal services, and configuration that reveals where credentials live next. That makes code review and repository access a rich starting point for attackers. Instead of scanning ports, they read dependencies, harvested tokens, and service endpoints. This is why secrets sprawl is more dangerous than a single leak. One credential can expose many others, especially when repositories, CI systems, and environment files all reuse the same trust assumptions and lack expiry controls.

Practical implication: scan code, commit history, and CI artifacts continuously, and block merges when secrets are detected.

Blast radius is the right metric once a machine credential is exposed

When a valid machine credential is compromised, the key question becomes what it can still reach. A token with broad repository access can unlock more credentials, production systems, and sensitive data long after the original entry point is understood. Conventional monitoring often records this as legitimate access because the token is valid. That means defenders need scope visibility, behavioural baselines, and revocation paths that work at the identity layer, not just the network layer.

Practical implication: map each credential's reachable systems before an incident so containment can target the full access chain.

Threat narrative

Attacker objective: The attacker objective was to turn one exposed machine credential into broad, persistent access across source code, AI assets, and sensitive operational data.

1. Entry occurred when FulcrumSec used a GitHub personal access token embedded in client-side JavaScript to access private repositories.
2. Credential access expanded as the attackers read repository contents, harvested additional secrets, and built a wider credential graph from the code itself.
3. Impact followed through prolonged lateral movement, with claims of repository theft, model exposure, and access to clinical and employee data.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

Ungoverned machine credentials create identity blast radius, not just access risk. This incident worked because the token was allowed to exist outside an identity control model. Once a token is embedded in code, its scope becomes operationally invisible while its reach remains fully real. The practitioner conclusion is that the breach surface is the credential graph, not the first repository that exposed it.

Secret sprawl is the failure mode that turns repositories into privilege discovery tools. Source code, CI artifacts, and environment files often reveal other credentials faster than defenders can inventory them. That means the attacker is not merely stealing code but reading the organisation's identity map from the inside. The practitioner conclusion is that repository governance must be treated as identity governance.

Standing token exposure window: this breach exploited the assumption that a machine credential will be reviewed before it can be abused at scale. That assumption fails when the credential is long-lived, broadly scoped, and embedded in distributed code because it can be used and re-used without any human review cycle catching up. The implication is that access review cadences are too slow for credentials that behave like persistent bearer identities.

Blast-radius governance is now the decisive control plane for NHI security. The article shows that the critical failure was not entry detection but reach containment. Once a token had repository-wide access, the question became what else it could unlock and how quickly it could be revoked. The practitioner conclusion is that scope mapping, expiry, and automated revocation must sit above traditional monitoring.

OWASP NHI controls and zero-trust identity assumptions align directly to this pattern. This is the kind of incident OWASP Non-Human Identity Top 10 is meant to expose: overprivileged credentials, poor lifecycle management, and weak discovery of machine identities. The broader lesson is that NIST Cybersecurity Framework 2.0 only works here if identity visibility extends to non-human actors. The practitioner conclusion is to align NHI governance to both scoping and lifecycle enforcement.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase that shows how quickly secret sprawl outpaces manual review.
• For practitioners, the next step is lifecycle control: see 52 NHI Breaches Analysis for patterns that show why discovery, scope, and revocation must be linked.

What this signals

Secret sprawl is now a governance problem, not a hygiene problem. Once tokens, keys, and certificates live inside code and pipelines, IAM teams need discovery, ownership, and revocation to operate as one control loop. The practical signal is that any programme still relying on periodic review will miss the exposure window that matters most.

With 28% of secrets incidents now originating outside code repositories in Slack, Jira, and Confluence according to GitGuardian, the control boundary has already moved beyond developer branches. Teams that only scan source code are protecting the wrong surface.

Identity blast radius: machine credentials should be measured by what they can reach, not by where they were found. That makes inventory quality, scope mapping, and automated rotation the real indicators of NHI maturity, especially when a single token can expose both source and runtime assets.

For practitioners

• Inventory every machine credential in code and pipelines Build a live register of tokens, API keys, and certificates found in repositories, CI systems, and deployment artifacts. Include owner, scope, expiry, and last-used data so you can identify credentials that outlive their purpose.
• Block secret-bearing commits before merge Add secrets scanning at commit and build time, and fail the pipeline when a credential appears in source, documentation, or generated artifacts. Review historical branches and tags as part of the same control.
• Map the reachable systems for each token Document what every non-human identity can reach across source, build, storage, and production layers. Use that reach map to decide containment scope the moment a credential is suspected compromised.
• Replace long-lived tokens with short-lived credentials Move to credentials that expire automatically and are scoped to the narrowest practical use case. Where possible, remove static bearer tokens from client-side code and enforce issuance through controlled runtime paths.
• Rotate and revoke based on blast radius, not discovery alone When a credential is found exposed, revoke every downstream credential it could have revealed and rotate connected secrets in the same workflow. Discovery without coordinated revocation leaves the attacker with a usable access chain.

Key takeaways

• A single ungoverned token can create a breach path that looks like code exposure but behaves like identity compromise.
• The scale of the problem is measurable in credential sprawl, not just incident reports, which is why discovery and revocation must be continuous.
• Teams that cannot inventory, scope, and retire machine credentials quickly will keep repeating the same failure mode under different names.

Key terms

• Non-Human Identity: A non-human identity is any credentialed machine actor such as a token, API key, certificate, or service account. It is an identity because it can authenticate, carry scope, and be revoked. In modern environments, it must be governed by ownership, lifecycle, and least privilege just like a human account.
• Secrets Sprawl: Secrets sprawl is the uncontrolled spread of credentials across code, pipelines, tickets, chat, and configuration files. It becomes a governance problem when no one can confidently inventory, scope, or retire those secrets. The result is hidden access that survives long after the original use case has ended.
• Blast Radius: Blast radius is the amount of systems, data, and privileges an attacker can reach after compromising one identity. For non-human identities, it is usually larger than teams expect because tokens are reused across services and environments. Measuring blast radius is the fastest way to understand how dangerous a credential really is.
• Credential Graph: A credential graph is the network of identities, permissions, and dependencies that one token can reveal or reach. It helps defenders understand how a single secret can open multiple systems and expose other credentials. In incidents, attackers use the graph as an access map rather than treating each repository as isolated.

What's in the full article

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

• A step-by-step breakdown of how the GitHub token was discovered in client-side JavaScript and how the repository graph enabled further access.
• The incident mapping that links initial token exposure to repository cloning, credential harvesting, and prolonged lateral movement.
• Operational guidance on continuous secrets scanning, behavioural baselines, and token scope reduction in development environments.
• The vendor's own remediation framing for where repository governance, CI controls, and identity inventory should intersect.

👉 The full Unosecur post covers the token path, credential graph, and containment gaps 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.