TL;DR: A local permission file in Claude Code can ship credentials into published npm packages, according to Lakera, with 428 of roughly 46,500 monitored packages containing .claude/settings.local.json and 33 of those files holding secrets. The real issue is not the assistant itself but a packaging workflow that turns approved commands into a persistent exposure path.
At a glance
What this is: Lakera shows how Claude Code’s local permission file can travel into published npm packages and expose API keys, tokens, and other secrets.
Why it matters: IAM and NHI teams need to treat local developer allowlists as publishable identity material, because packaging workflows can turn a convenience feature into an exposure path.
By the numbers:
- 33 files across 30 packages contained credentials.
Context
Claude Code stores approved shell commands in a local settings file inside the project directory. If that directory is packaged for publication, the allowlist can carry embedded credentials into a public artifact.
The governance gap is straightforward: development-time trust decisions are being persisted in a file that packaging tools may treat as ordinary project content. For NHI governance, that turns a local command approval workflow into a secrets-distribution problem.
The article’s central finding is that the risk is not unique to one package ecosystem. Any build or publish path that sweeps repository files into release artifacts can expose the same class of credentials.
Key questions
Q: What breaks when local AI command approvals are packaged into public releases?
A: The control failure is that a convenience file becomes a secret distribution channel. Approved commands can contain bearer tokens, API keys, or login material, and packaging tools may publish the file unless it is explicitly excluded. That means local developer intent turns into external credential exposure without any new attack on the workstation.
Q: Why do published package artifacts make leaked API keys more dangerous?
A: Published artifacts are durable, redistributable, and often mirrored or cached. Once a secret appears in a package tarball or source distribution, deprecation does not erase copies already in circulation. That is why packaging-time inspection and immediate credential rotation matter more than relying on later cleanup.
Q: How can security teams tell whether a build pipeline is exposing local secret files?
A: Look at what the final archive contains, not just what the repository contains. Dry-run packaging, artifact unpacking, and file-path searches will reveal whether local identity files such as .claude/settings.local.json are being selected for release. If the file appears in the artifact, the pipeline is already exposing it.
Q: What should teams do after a secret is found in a public package?
A: They should contain the exposure by revoking or rotating the credential, tracing its downstream permissions, and reviewing every related repository, cloud account, and automation path. The correct response is lifecycle action on the identity, not just removal of the file that contained it.
Technical breakdown
How approved commands become publishable secrets
Claude Code records permanently approved shell commands in .claude/settings.local.json. That file can capture inline credentials embedded in the command itself, such as bearer tokens, API keys, or login material passed through environment variables. The problem is not the command approval prompt alone but the persistence layer behind it. Once the file exists in a project root, it behaves like any other hidden project file and can be picked up by packaging tools unless it is explicitly excluded.
Practical implication: Treat local command allowlists as sensitive identity artifacts and keep them out of any release path by default.
Why package selection rules miss .claude files
Most packaging systems assemble artifacts from a directory tree, then apply inclusion and exclusion rules. In npm, .claude/ is not excluded by default, and hidden dotfiles are easy to overlook because they do not surface in normal publish checks. Other ecosystems have similar selection logic, which means the same exposure pattern can repeat when build tooling sweeps source, manifest, or tracked files into distributable archives. The failure is structural: the packager is doing exactly what it was told, not what the security team assumed.
Practical implication: Review file-selection rules for every build artifact, not just the obvious secret-scanning controls.
Why published archives turn local mistakes into permanent exposure
Once a credential ships in a package tarball or source distribution, the exposure is no longer limited to the local workstation. Published artifacts can be mirrored, cached, and reused even after a version is deprecated, which makes recovery slower than rotation. That is why packaging-time inspection matters more than after-the-fact cleanup. The technical issue is not only leakage but persistence across distribution channels that outlive the original publish event.
Practical implication: Assume any secret in a published artifact is compromised and plan rotation and invalidation immediately.
Threat narrative
Attacker objective: Obtain reusable API keys, tokens, and login material from published packages so they can be abused outside the original development environment.
- Entry occurs when a developer approves a shell command that includes an API key, token, or other credential, and Claude Code writes that command into .claude/settings.local.json.
- Credential access happens when the local settings file preserves those secrets in plaintext form inside the project tree.
- Impact follows when the project is packaged and published, carrying the credentials into public npm artifacts where they can be harvested at scale.
Breaches seen in the wild
- OneLogin API flaw (CVE-2025-59363): A OneLogin API flaw exposed OIDC client secrets to anyone with an API key, including vendors (CVE-2025-59363); fixed with no customer impact.
- 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
Packaging-time secret leakage is now an NHI governance problem, not just a developer hygiene issue: a local allowlist file can carry machine credentials from private workflow into public distribution without any interactive warning. That shifts the control point from runtime security to artifact governance, where many IAM teams are still weakest. Practitioners should treat build outputs as part of the identity lifecycle.
Secret rotation alone does not solve publish-path exposure: the security failure here is not a stale token sitting idle, but a command approval system that writes live credentials into a file that packaging tools can ship. The broader lesson is that lifecycle controls must cover storage, selection, and distribution, not only issuance and revocation. The implication is stronger release-time exclusion, not just faster rotation.
Identity blast radius expands when developer convenience features persist credentials in project roots: a single approved command can create a reusable secret trail that survives into archives, mirrors, and caches. That is a different failure mode from classic hard-coded secrets because the exposure is generated by normal use, not just insecure coding. Teams need to map which local files can become publishable identity material.
.claude/settings.local.json is a textbook example of configuration drift crossing into secret drift: the file starts as a local convenience mechanism and becomes an ungoverned credential store once it reaches a packaging boundary. This is the kind of failure OWASP-NHI and NIST CSF both point toward: weak control over non-human identity material at the point of handling, not after compromise. Practitioners should classify these files as governed secrets, not harmless metadata.
Package ecosystems are now part of the identity perimeter: when package managers publish whatever the build system selects, the perimeter is no longer the repository alone. That means NHI governance has to extend into release engineering, with explicit exclusion rules for files that record command approvals, tokens, and service logins. The field should stop treating artifact composition as a purely DevOps concern.
From our research library:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- Read next: API Key Management Guide
What this signals
Publish-time inspection now belongs in NHI governance: the key control is no longer only secret rotation, but proving that repository files with local identity material never enter build artifacts. That shift matters because packaging systems can convert a harmless-looking settings file into a public credential leak.
When developer tooling persists approved commands, security teams need to classify the resulting file as sensitive identity material and not as routine project metadata. The practical question is whether release engineering has an enforced exclusion boundary for local secret stores.
The lesson extends beyond npm. Any ecosystem that builds release artifacts from a repository root can leak the same file class unless teams inspect the final package and search for secret-bearing paths before upload.
For practitioners
- Exclude .claude/ from every publish path Add .claude/ to .npmignore, audit package.json file rules, and verify that the directory is absent from every release artifact before publishing.
- Scan release artifacts before upload Run dry-run and unpack checks on the exact artifact that will be published, then search for .claude/settings.local.json and other local identity files.
- Treat shipped credentials as compromised If a published archive contains API keys, tokens, or login material, rotate those credentials immediately and invalidate any dependent access paths.
- Map local command approvals to secret handling Review which developer workflows write approved commands into local files and decide whether those files belong in your sensitive-data inventory.
- Extend packaging controls beyond npm Apply the same exclusion checks to sdists, wheels, gem builds, and source JARs so one project root file cannot leak through multiple release channels.
Key takeaways
- A local AI assistant settings file can become a secret-exposure path when packaging workflows publish it with the project.
- Lakera found the file in 428 of about 46,500 monitored packages, and 33 of those files contained credentials.
- The fix is to treat local command-approval files as governed identity material and exclude them from every release artifact.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set 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 is about secrets leaving a local settings file and shipping in published packages. |
| NHI-07 — Long-Lived Secrets | Approved commands persist credentials beyond the original session and can be published later. | |
| Recommendation — Exclude local secret files from release artifacts and scan published packages for leaked credentials. Remove persistent allowlisted commands from files that can outlive the development session. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The issue involves lifecycle control over API keys and other authenticators exposed in artifacts. |
| Recommendation — Apply authenticator lifecycle controls to detect, revoke, and rotate exposed keys in shipped packages. | ||
| CIS Controls v8 | CIS-5 — Account Management | Published package secrets can expose service and developer accounts that need revocation. |
| Recommendation — Review and remove any accounts tied to secrets found in release artifacts. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article shows published artifacts carrying credentials that confer access permissions. |
| Recommendation — Limit who and what can publish artifacts that may contain sensitive entitlement material. | ||
Key terms
- Secret-Bearing Artifact: A file or output that contains sensitive material inside its metadata, embedded state or hidden fields rather than in the visible content. In AI workflows this matters because the export itself can become a credential carrier, even when the visible image or document looks harmless.
- Publish path: The sequence of packaging, build, and upload steps that turns repository content into a distributable release. When this path is not tightly governed, local files that were never meant for release can become public identity material.
- Local settings allowlist: A file that records permanently approved commands or actions in a developer environment. For autonomous or assisted coding tools, the file can accumulate embedded credentials and should be treated as sensitive secret storage, not harmless metadata.
- Artifact Hygiene: The quality, completeness, and consistency of work items such as stories, defects, tasks, and release notes. In Agile environments, strong artifact hygiene improves planning, forecasting, and communication because downstream decisions rely on the clarity of the structured information teams create at the point of entry.
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 July 6, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org