Claude Code leaks API keys through published package files

At a glance

What this is: Lakera shows that a local Claude Code permission file can leak secrets into published packages when build and publish workflows fail to exclude it.

Why it matters: IAM and AppSec teams need to treat AI coding assistants as part of the software supply chain, because approved commands can become persistent secrets exposure across development, packaging, and release processes.

By the numbers:

• 428 contained a .claude/settings.local.json.
• 33 files across 30 packages contained credentials.

👉 Read Lakera's research on Claude Code files shipping API keys in npm packages

Context

The security gap here is simple: a local configuration file created by an AI coding assistant can become a packaging liability when repository contents are published without explicit exclusion rules. In practice, the issue sits at the intersection of secrets management, software release hygiene, and NHI governance, because the file can contain approved shell commands with embedded credentials.

That makes this a supply-chain identity problem, not just an AppSec mishap. Teams that rely on AI-assisted development need to treat command approval artifacts the same way they treat .env files, build outputs, and other root-level content that should never leave the workstation or repository.

Key questions

Q: How should security teams prevent AI assistant files from being published in packages?

A: Teams should treat AI assistant state files as release blockers until packaging rules explicitly exclude them. Add the relevant paths to ignore lists, verify build backend selection rules, and inspect the final artifact before upload. The goal is to ensure that local approval history, command strings, and embedded credentials never leave the development environment.

Q: Why do AI coding assistants increase secrets exposure risk in software supply chains?

A: They increase risk because they persist command history that can include sensitive values, and release tooling often packages files without understanding their meaning. If a developer approves an authenticated command permanently, that command can be written into a local file and later shipped inside an artifact. The risk is workflow-driven, not intent-driven.

Q: What breaks when local development files are included in release artifacts?

A: The boundary between private workstation context and public distribution disappears. A file meant to support local execution can become a durable public record of approved commands, tokens, and credentials. That breaks assumptions about secrecy, provenance, and package integrity, especially when build systems treat every file as equally releasable.

Q: What should teams do if a package may already contain leaked credentials?

A: Treat the credential as compromised from the moment the package was published, even if the issue is discovered later. Revoke the secret, replace it, and audit downstream artifacts, caches, and mirrors that may still hold the package version. Public tarballs are permanent enough that delayed discovery does not reduce exposure.

Technical breakdown

Why permission allowlists become secret containers

Claude Code records permanently approved shell commands in a local settings file. The file is meant to remember what the assistant may run again, but the command string can include inline credentials, bearer tokens, or environment variables passed on the command line. Once stored in the project root, the file behaves like any other repository artifact unless it is explicitly excluded. The technical failure is not the assistant executing commands, but the persistence of sensitive command history in a location that packaging tools can sweep into release artifacts.

Practical implication: exclude assistant settings files from every publish path before they can be packaged.

How npm packaging turns root-level files into release risk

npm publishes what the package selection rules allow, not what the developer intended to expose. Hidden dotfiles are often overlooked because they do not trigger normal review habits, and .claude/settings.local.json is not blocked by default. If a package includes the project root, the file can be bundled into the tarball and distributed publicly. That means the exposure is not limited to one registry. Any build process that archives repository content can inherit the same mistake when file-selection rules are too broad.

Practical implication: verify the exact archive contents with dry-run or unpack checks before every release.

Why publish-time validation matters more than post-release cleanup

Once a package version is published, its tarball can persist even if the version is later deprecated. That creates a one-way exposure path for any token or credential embedded in the shipped file. The important architectural point is that publishing systems do not inspect artifacts for secret content. They only move files. Security has to happen before artifact creation, with explicit exclusion rules and inspection of the final package, not after upload or after release notes are written.

Practical implication: add secret-path checks to build pipelines, not to incident response checklists.

NHI Mgmt Group analysis

.claude/settings.local.json is a secrets-bearing release artifact: The file is not just local state, it is a persistence layer for approved commands that may include tokens, passwords, and bearer headers. That makes it a non-human identity control surface, because the exposure comes from how machine-executed commands are stored and later redistributed. Practitioners should treat command-allowlist files as publishable secrets containers until proven otherwise.

Secret sprawl is now reaching AI-assisted development workflows: This pattern shows how developer tooling can turn normal approval behaviour into hidden credential leakage. The problem is not exotic exploitation, but routine workflow drift between interactive use and packaging. The implication is that secrets governance must extend into AI coding assistants, repository hygiene, and build artifact review, not stop at vault policy.

Packaging rules are the real enforcement boundary: Build systems decide what gets released, and release systems do not understand the sensitivity of a file name. That means the governing assumption is file exclusion by convention, which fails as soon as a new tool writes sensitive state into a new path. Practitioners need to re-evaluate how trust is assigned to root-level dotfiles in software supply chains.

Command approval memory creates identity blast radius: A command approved once can keep its embedded credential long after the original interaction ends. The result is a wider blast radius than the user expects, because the assistant preserves operational context that later becomes distributable content. Security teams should view AI coding assistants as identity-adjacent systems that can expand secret exposure if their artifacts are not controlled.

Runtime convenience and release safety are now in conflict: AI developer workflows optimise for speed by remembering approvals, but packaging systems optimise for completeness by including files. Those two defaults collide unless governance intervenes. The practitioner takeaway is that release engineering, IAM, and AppSec now share responsibility for the same control gap.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which helps explain why packaging hygiene and secret handling so often diverge.
• That same research shows organisations maintain an average of 6 distinct secrets manager instances, so the next control conversation is not just rotation but consolidation and release-path governance.

What this signals

Secret persistence is the hidden failure mode: Approved commands become durable artifacts when AI assistant state is stored inside project directories. Teams should assume that any tool which remembers privileged actions can also amplify exposure unless its output paths are tightly governed.

With 43% of security professionals concerned about AI systems learning and reproducing sensitive information patterns from codebases, the issue is no longer limited to accidental file inclusion. The programme question is whether AI-assisted development is covered by the same release controls, secrets controls, and code review expectations as every other identity-bearing workflow.

For practitioners

• Exclude assistant state from every publish path Add .claude/ to npmignore, exclude it in build backend rules, and treat the file as non-release content in every packaging workflow.
• Inspect artifacts before upload Use dry-run and unpack checks to verify that tarballs, wheels, gems, and JARs do not contain local assistant settings files or other hidden secrets.
• Rotate any credential that may have shipped If a published artifact contained tokens, keys, or passwords, revoke and replace them immediately across every affected service and registry.
• Move command approvals out of shareable directories Review where assistant-generated state is stored and prevent sensitive approval records from living inside project paths that packaging tools can collect.

Key takeaways

• The central risk is not Claude Code execution, but the way approved commands can be persisted in files that packaging tools later distribute.
• The scale matters because 33 credential-bearing files across 30 packages show this is a repeatable release hygiene failure, not a one-off mistake.
• The practical fix is to hard-exclude assistant state, inspect artifacts before upload, and rotate anything that may already have shipped.

Key terms

• Command Allowlist File: A local file that records commands a tool is permitted to run again without asking. In AI coding assistants, that memory can become sensitive because the command text may include tokens, headers, or environment variables that should never leave the developer machine.
• Packaging Boundary: The set of files and directories that a build or publish process is allowed to include in a release artifact. When this boundary is too broad, hidden local files can be shipped unintentionally, turning internal workflow state into public distribution content.
• Secret Sprawl: The uncontrolled spread of credentials across files, tools, environments, and teams. It becomes more dangerous when developer workflows, build systems, and release packaging all preserve or copy the same sensitive value into multiple places.

What's in the full article

Lakera's full research covers the operational detail this post intentionally leaves for the source:

• The scanner design used to monitor npm registry changes and inspect package tarballs for hidden .claude/settings.local.json files
• The exact credential types found in shipped files, including registry tokens, GitHub tokens, Telegram bot tokens, and plaintext login data
• Platform-by-platform packaging guidance for npm, PyPI, RubyGems, and Maven or Gradle source artifacts
• Concrete shell and archive checks practitioners can use to validate releases before publication

👉 Lakera's full post covers the scanner findings, packaging edge cases, and prevention steps in 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.