TL;DR: Unosecur reports that a GitHub personal access token embedded in client-side JavaScript let FulcrumSec move through hundreds of private Novo Nordisk repositories, harvest additional credentials and claim access to AI assets and clinical data. The breach shows that long-lived machine credentials become an identity graph when they are never inventoried or rotated, and blast radius matters more than initial access.
At a glance
What this is: This is an analysis of how one ungoverned GitHub personal access token in code enabled broad repository access and downstream credential harvesting at Novo Nordisk.
Why it matters: It matters because IAM and NHI programmes still miss the fact that code-resident tokens behave like identities with scope, lifecycle, and blast radius, not like harmless configuration values.
👉 Read Unosecur's analysis of ungoverned GitHub tokens and Novo Nordisk exposure
Context
A GitHub personal access token is a non-human identity when it can authenticate to systems and carry scope across repositories, build systems, and downstream services. In this case, the token lived in client-side JavaScript, which meant the organisation treated a credential as code rather than as governed access.
The governance gap is not just secret leakage. It is the absence of inventory, expiry, offboarding, and behavioural baselines for machine credentials that sit inside repositories and CI paths. Once those credentials are reachable from source, the repository becomes an identity graph, not merely a 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 code-resident machine credentials create such a large breach surface?
A: Because their risk is determined by scope, not by the line of code where they appear. A token that can read many repositories can reveal other secrets, deployment references, and service connections, which turns a single credential into a path through the wider environment.
Q: How can organisations tell whether token governance is actually working?
A: Token governance is working when every live token has a named owner, a bounded purpose, and a clear runtime signal that shows whether it is being used inside its intended context. If security teams cannot answer who owns the token, what it can access, and when it should be cut off, the governance model is incomplete.
Q: What should teams do after discovering a token has been used in a breach?
A: They should treat the incident as a credential graph problem, not a single-token problem. That means revoking the exposed token, searching every reachable repository and pipeline for related secrets, and determining which downstream identities may already have been harvested.
Technical breakdown
How code-resident tokens become a credential graph
When a personal access token is embedded in source code, it is no longer an isolated secret. It becomes a reusable non-human identity that can authenticate to repositories, services, and adjacent systems with whatever scope it was granted. If that scope is broad, every reachable repository can reveal more tokens, keys, and service credentials, which turns source control into a credential discovery surface. The technical problem is not just leakage but reach: one valid token can expose many more identities if those credentials are stored in files, build artefacts, or environment references within the same trust boundary.
Practical implication: Treat repositories and build outputs as credential-bearing assets, not just code storage, and inventory every machine identity they can expose.
Why broad repository scope creates oversized blast radius
The blast radius of a GitHub token is determined by its repository scope, lifetime, and what downstream systems those repositories can touch. A token with access to hundreds of private repositories gives an attacker a large search space for additional credentials and operational context. That matters because repositories often contain infrastructure definitions, deployment references, and service credentials that were never intended to be persistent. Once an attacker can read that material, the repository becomes a map of the environment rather than a single access point.
Practical implication: Narrow repository scope aggressively and review whether any token can see more code than its operational role actually requires.
Why conventional monitoring missed the abuse
Standard monitoring tools are built to detect unusual use of known accounts, not to understand whether a machine credential should exist in the first place. If a token behaves within its normal technical permissions, logs may classify its activity as authorised even when the credential itself is unmanaged. That is why valid access can still be a breach surface. Without an inventory of non-human identities, expiry data, and expected behaviour per token, defenders are left trying to infer risk after the access chain has already expanded.
Practical implication: Add identity inventory and behavioural baselines for machine credentials so authorised-looking activity can still be challenged when it is out of policy.
Threat narrative
Attacker objective: The objective was to turn one unmanaged token into broad access to code, credentials, and high-value development and research assets.
- Entry occurred when FulcrumSec obtained a GitHub personal access token embedded in client-side JavaScript and used it as a valid non-human identity.
- Credential access expanded as the token exposed additional secrets and machine credentials stored in hundreds of private repositories.
- Lateral movement followed as those harvested credentials were used to move through the repository and service graph over an extended period.
- Impact came from broad repository access, claimed exfiltration, and exposure of clinical and AI-related assets across the environment.
Breaches seen in the wild
- Fake Dependabot commits 2023: Stolen GitHub tokens were used to push fake Dependabot commits to hundreds of repos, adding workflows that stole Actions secrets.
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Ungoverned tokens create an identity graph, not a secret leak. This incident is not explained by a single leaked credential alone. The real failure mode is that a machine credential lived inside code without lifecycle governance, so every reachable repository became part of its access surface. That is a non-human identity governance problem, not a one-off secrets mishap. Practitioners should stop asking where the token was found and start asking what other identities it could expose.
Blast radius is the control variable that matters most. The token’s initial compromise was only the starting condition. Its scope and reach determined how far the attacker could spider into adjacent credentials, repositories, and connected systems. This is why inventory, scoping, and offboarding matter more than visibility slogans. Practitioners need to model the reach of each credential before an incident, not reconstruct it after attackers have already used it.
Secrets sprawl is a governance failure disguised as developer convenience. When credentials are treated as configuration, organisations lose the ability to recertify, expire, or offboard them. That assumption was designed for static application settings, not for identities that can authenticate and traverse systems. The implication is that NHI programmes must govern code-resident tokens as living access objects, with ownership, scope, and expiry attached.
Long-lived machine credentials are still being handled with human-era controls. Quarterly access reviews and post-hoc detection cannot keep pace with tokens that sit silently in source and are used only when an attacker finds them. The control gap is not insufficient alerting alone. It is the absence of continuous identity inventory and lifecycle enforcement for machine access that can outlive the teams that created it.
Repository security and identity governance are now the same discipline. Source control is no longer just an engineering asset because it can contain credential material, deployment paths, and machine-authentication artefacts. That means IAM, PAM, and NHI governance teams need shared ownership of repository-exposed credentials. The practical conclusion is simple: if a token can unlock more than code, it belongs in identity governance, not just secret scanning.
From our research library:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to the 2024 State of Secrets Management Survey.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Identity governance has to start at source control. The practical boundary for NHI control is no longer the secrets vault alone. Code, build outputs, and CI systems now carry machine credentials that should be inventoried, scoped, and revoked with the same seriousness as any other identity asset.
Secret sprawl becomes credential sprawl the moment access is reusable. A token hidden in code can expose many more credentials than the original developer intended, which means the real control question is lifecycle, not storage. Continuous discovery and expiry are the mechanisms that change the outcome.
Blast-radius control should replace visibility as the programme metric. Teams need to know how far a credential can reach before they know how it was obtained. When scope is broader than the business function requires, the identity surface is already too large.
For practitioners
- Map repository-exposed machine identities Build a live inventory of tokens, service credentials, and API keys that appear in source, build artefacts, and CI paths, and record their owners, scope, and expiry.
- Enforce narrow repository scope Review every GitHub personal access token and remove broad access across hundreds of private repositories unless the business case is explicit and current.
- Move credentials out of source code Block commits and builds that contain secrets in JavaScript bundles, config files, or deployment manifests, and fail the pipeline when detection hits.
- Replace long-lived tokens with expiring access Use short-lived credentials for developer and automation workflows so a copied token cannot remain useful long after it leaves its intended context.
- Baseline machine credential behaviour Define expected access patterns for each non-human identity so repository-spidering behaviour can be flagged before it reaches adjacent systems.
Key takeaways
- A single unmanaged GitHub token can behave like a broad identity graph when it is embedded in code and granted access across repositories.
- This case shows how repository-level credential sprawl can turn one token into access to more secrets, more systems, and more damage than teams expect.
- The limiting control is not just secret detection. It is inventory, narrow scope, expiry, and governance over every machine credential that lives in source or CI.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on a token embedded in code and the downstream exposure of machine credentials. |
| NHI-05 — Overprivileged NHI | The token was scoped to hundreds of private repositories, creating excessive reach for one identity. | |
| NHI-07 — Long-Lived Secrets | The article highlights a token with no expiry date that remained useful long after creation. | |
| Recommendation — Scan source, build, and CI paths for leaked credentials and revoke exposed non-human secrets immediately. Reduce token scope to the minimum repository access needed and remove broad standing permissions. Replace persistent tokens with expiring credentials and enforce rotation on all machine identities. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | IA-5 directly covers lifecycle management for authenticators such as tokens and API credentials. |
| Recommendation — Apply authenticator lifecycle controls so tokens are issued, rotated, and revoked on a governed schedule. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack relied on harvesting credentials and moving through repositories and connected systems. |
| Recommendation — Map repository-spidering activity to credential access and lateral movement patterns in detection content. | ||
Key terms
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
- 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:
- The article traces the reported timeline of the Novo Nordisk incident and the claims FulcrumSec made about repository access.
- It discusses how the token was embedded in client-side JavaScript and how that changed the attack surface.
- It outlines the claimed repository count, AI assets, and clinical data exposure in more operational detail.
- It closes with Unosecur's own mapping of the incident to machine-identity governance gaps and detection limitations.
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 programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org