Leaked API keys enabled an agentic attack chain at Hugging Face

At a glance

What this is: Truffle Security describes how 14 leaked API keys became the starting point for an agent-driven intrusion that expanded from public datasets into private systems, token minting, and CI workflow abuse.

Why it matters: Identity teams should treat exposed API keys as active entry points, not dormant hygiene issues, because one valid secret can become a chain of further credential compromise across NHI and agentic workflows.

By the numbers:

• Truffle Security recorded 787 distinct Hugging Face tokens that authenticated during scanning, spread across 262 public datasets.
• Of those tokens, 237 had recorded write permissions.

👉 Read Truffle Security's analysis of the 14 leaked API keys behind the Hugging Face attack

Context

API key exposure is not just a leakage problem, it is an access governance problem: once a working secret is public, any system or agent that can reconstruct and validate it can turn disclosure into live access. In this case, the first weak point was a public dataset, but the deeper issue was that the identity boundary around the key had already failed.

This is a classic secret sprawl challenge pattern, except the downstream consumer was an agentic workflow that could search, validate, and reuse credentials at runtime. That combination turns scattered secrets into a live attack surface instead of a static hygiene issue.

Key questions

Q: What should security teams do first when sensitive API keys are discovered on cloud assets?

A: Treat the key as exposed until proven otherwise. Revoke or rotate the credential immediately, then search for where it was copied, referenced, or reused across code, configuration, CI/CD systems, and third-party integrations. Validate access logs for misuse, scope the blast radius, and document the incident for remediation and compliance follow-up. The goal is to shrink exposure fast and prevent quiet reuse.

Q: Why do leaked API keys and tokens create such a large security risk?

A: They authenticate actions directly, so anyone who finds them can act as a trusted caller. If the secret is long-lived or broadly scoped, the attacker gains standing access that may bypass normal user controls, making the leak a privilege and identity problem as much as a data exposure issue.

Q: What are the signs that an exposed API key has become a broader compromise?

A: Look for unexpected token creation, unusual repository writes, workflow execution from unfamiliar identities, and access to systems that the original key should not have reached. When one exposed secret is followed by new credentials or cross-system movement, the incident has moved from leakage into credential chaining.

Q: How should teams respond when workflow credentials are exposed in CI?

A: Contain the pipeline, revoke any secrets or tokens the job could access, rotate cloud and repository credentials, and review whether the same workflow path can still be changed without review. The response should focus on the trust path that allowed the job to run, not only on the specific malicious commit.

Technical breakdown

How public API keys become an execution path

A public API key is dangerous because it is already an authenticated bearer credential. If the secret is valid, the attacker does not need to break authentication; they only need to find a service that accepts the token and then use the resulting access scope. In this incident, the leaked credentials were not just sitting in a file. They were reconstructed, validated, and then used as working identity material. That matters because the security boundary is no longer the repository or dataset. It becomes the scope, lifetime, and revocation state of the credential itself. See the API Key Management Guide.

Practical implication: Treat every public API key as a live identity event and make revocation the default response, not investigation afterthought.

How token reuse expands the blast radius

Once a valid secret is accepted, the next risk is privilege chaining. The article shows a pattern where one recovered token enabled further access, which then exposed additional credentials and allowed the creation of new tokens. This is a credential multiplication loop, not a single compromise. In NHI terms, the problem is not only exposure but reuse across environments, integrations, and delegated systems. When a key can open one boundary and then mint access inside another, the original secret becomes a bridge into more privileged trust domains. See the NHI Authentication Guide.

Practical implication: Map every exposed credential to the next systems it can reach and revoke any token that can be used to mint further access.

Why CI workflows are a high-value credential target

Continuous-integration systems often sit at the intersection of code, build automation, and privileged service access. That makes them attractive once an attacker can write to a repository or open a pull request. Here, the reported path was to use write-capable access to trigger workflow execution and attempt to extract additional secrets from the runner. The important mechanism is trust inheritance: build pipelines often assume repository-level write actions are safe enough to trigger privileged automation. When that assumption breaks, the workflow itself becomes a credential source.

Practical implication: Separate code contribution rights from workflow-triggering rights and assume CI runners will be targeted for secret harvesting.

Threat narrative

Attacker objective: The objective was to turn public secret exposure into broader authenticated access that could reach private code, internal workflows, and additional credentials.

1. Entry occurred through publicly exposed Hugging Face API keys that were reconstructed and validated into working access.
2. Escalation followed when the agent used one token to upload a malicious dataset, causing a production worker to disclose its environment secrets.
3. Lateral movement continued through stolen repository and VPN credentials, which enabled fresh token minting and source-control access.
4. Impact was the attempted compromise of private code and CI workflows, along with further credential harvesting across connected systems.

Breaches seen in the wild

• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Public API key exposure is no longer a single-credential problem. The article shows a chain in which a leaked token led to environment disclosure, then to new tokens, then to source-control and CI access. That is a governance failure in credential containment, not a one-off leak. The practitioner conclusion is that exposed NHI credentials must be treated as chain-forming identity assets, not isolated events.

Agentic runtime changes the meaning of secret sprawl. A human operator usually needs time, context, and manual follow-through to exploit a leaked key. An agent can search, validate, reuse, and propagate access within the same operational loop. That means the old assumption that discovery and abuse are separated by meaningful human delay no longer holds. The implication is that credential governance now has to account for machine-paced reuse, not just human-paced misuse.

Ephemeral trust boundaries do not exist once a key can mint another key. The article describes a sequence in which one recovered credential created the conditions for more access, including repository tokens and workflow entry. That is the named concept here: credential multiplication loop: one valid secret becomes a path to more valid secrets, collapsing the idea that a leaked token is contained to its original scope. The practitioner conclusion is that revocation logic has to follow the chain, not the first token alone.

CI/CD remains a privileged identity zone, not a neutral automation layer. The attack path depended on workflow trust, runner access, and the assumption that repository actions were safe enough to trigger execution. Once a write-capable identity can start a build that can read secrets, the pipeline itself becomes part of the identity attack surface. The practitioner conclusion is that build-time identity and source-control identity must be governed together.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Read next: API Key Management Guide

What this signals

Credential multiplication loop: once one valid secret can create or reveal another, incident response has to shift from isolated revocation to chain interruption. That changes the programme goal from finding the leak to eliminating every identity path the leak can bootstrap.

The practical signal for identity teams is that public-secret hygiene now sits inside the same control plane as build automation, source control, and agent access. A single leaked token can cross those boundaries fast enough that recertification cadences alone will not contain the spread.

NHI programmes should assume that exposed API keys will be discovered and reused by automated systems, not just human attackers. That means the next control decision is less about discovery alone and more about how quickly revocation can be proven effective.

For practitioners

• Audit public-secret exposure paths Inventory where API keys, tokens, and private keys can appear in public datasets, logs, notebooks, and shared collaboration spaces, then classify which ones can still authenticate today.
• Revoke before you investigate When a working secret is found in the wild, revoke or rotate it first, then preserve evidence from the access logs and downstream systems that accepted it.
• Break token-minting chains Identify credentials that can create or authorise additional credentials, including app keys and integration tokens, and place them on the highest urgency revocation path.
• Separate repository rights from workflow rights Review whether write access to a repository can trigger CI execution or secret-bearing jobs, and narrow those pathways where build automation can disclose credentials.
• Track NHI offboarding as a live control Treat exposed machine identities as offboarding events, not just leaks, and require confirmation that the credential no longer works after remediation.

Key takeaways

• The incident shows how one leaked API key can become the starting point for credential chaining across datasets, workers, source control, and CI.
• The strongest evidence in the article is that Truffle Security observed 787 Hugging Face tokens across 262 public datasets, with 237 carrying write permissions.
• The control lesson is to treat exposed API keys as live identity events and to revoke them before analysing the full attack path.

Related NHI Mgmt Group resources: API Key Management Guide · Leaked Credential and Secret Incident Response Playbook · NHI Authentication Guide · Dropbox Sign breach 2024

Key terms

• API Key Leakage: API key leakage is the accidental exposure of a secret used to authenticate software calls. It occurs when keys are stored in code, logs, tickets, chat, backups, or public repositories. Once exposed, the key can be reused to access services, move data, or impersonate trusted applications.
• Credential chaining: The reuse of one credential or access path to unlock another, turning a single compromise into a wider intrusion. It is especially dangerous in NHI and agentic AI contexts because machine-scale systems can test and exploit chained access paths much faster than humans.
• Token Minting: Token minting is the act of creating a signed identity artefact that other systems accept as proof of authentication or authorization. In a compromised issuer, minting becomes the line between a backend defect and enterprise-wide impersonation.
• Deployment Workflow Trust Boundary: The point at which a CI or release workflow stops operating on verified internal inputs and starts accepting context that can be influenced by users, forks, or external integrations. In practice, this boundary determines whether deployment metadata and environment values can be treated as safe.

What's in the full article

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

• The reconstructed 14-token timeline across public Hugging Face datasets and the exact discovery sequence.
• The production worker and Jinja2 exploitation steps that expanded access from file disclosure to command execution.
• The repository, VPN, and GitHub App credential path that turned one exposed secret into several new access tokens.
• The CI workflow abuse details, including the attempted supply-chain step and why the branch was ultimately closed.

👉 The full Truffle Security post covers the token discovery timeline, worker-secret exposure, and CI abuse path.

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.