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.
Editorial analysis by NHI Mgmt Group, based on content published by Lakera: “Your AI Coding Assistant Just Shipped Your API Keys”.
By the numbers:
- 33 files across 30 packages contained 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.
Q: Why do published package artifacts make leaked API keys more dangerous?
A: Published artifacts are durable, redistributable, and often mirrored or cached.
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.
Practitioner guidance
- 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.
Bottom line: A local AI assistant settings file can become a secret-exposure path when packaging workflows publish it with the project.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Claude Code leaks API keys through published package files