

The secrets sprawl problem has a new accelerant: AI coding tools are creating local permission files that record developer commands verbatim (credentials included) and a design gap means the per-machine protection built into those tools does not carry over to the repositories teams share. Security teams that have invested in secrets scanning for application code are largely not scanning the configuration layer that AI tools are now generating.
Security researchers have identified 1,122 public copies of Claude Code's .claude/settings.local.json file on GitHub that contain a real secret, out of 104,185 total public copies found. The count extends to 2,539 exposed secrets across 1,994 repositories when git history, shared settings.json files teams commit intentionally, and agent chat transcripts saved in repos are included [1].
.claude/settings.local.json Is and How Credentials End Up in ItClaude Code's .claude/settings.local.json is a local permissions file created when a developer clicks "Yes, and don't ask again" in response to a tool use prompt during a session. When Claude Code asks permission to run a shell command, the developer can approve it once or permanently; the permanent choice saves that command pattern as an allow rule in settings.local.json. According to Anthropic's settings documentation, the file is scoped as Local (specific to the project directory on that machine, in contrast to shared project settings and user-level settings [2]).
Claude Code does enforce protection on the developer's own machine: it registers settings.local.json in the user's global git exclude file, preventing the developer from accidentally committing it. The gap opens when the file reaches a repository that another developer then clones. The repository's own .gitignore has no corresponding entry; the global exclude lives only on the original developer's machine. Any team member who clones the repository and runs git add . will stage and commit the file without warning.
The credential exposure path is a consequence of how allow rules are stored. When a developer approves a command that happens to include an inline credential (a database password, an API key, an access token typed directly into a command), the exact command string is written into the allow rule, credential and all, in plain text. It does not need to be a deliberate act: testing a database connection, running a deployment command, or passing a service key on the command line may leave credentials in the file without the developer noticing.
The 1,122-file finding fits a broader pattern that annual secrets sprawl research has now quantified. Claude Code-assisted commits leaked secrets at approximately 3.2%, roughly double the 1.5% baseline rate for non-AI-assisted commits [3]. Less experienced developers enabled by AI coding tools may lack security awareness and can ignore warnings or explicitly prompt AI tools to include sensitive information in configuration files, making secret leaks a human factor problem as much as a tooling failure [3].
Annual secrets sprawl findings from 2025 show three figures worth isolating [3]:
settings.local.json (credentials embedded in tool configuration that gets committed), contributed to 24,008 unique secrets being exposedGitGuardian’s 2026 State of Secrets Sprawl report confirms 28.65 million new hardcoded secrets detected in public GitHub commits in 2025, a 34% year-over-year increase and the largest single-year jump in the report’s five-year history [3]. The 2026 edition reprocessed historical data back to 2021 under a consistent methodology to ensure the trend line is not distorted by tooling changes [3].
AI coding tools did not create the secrets sprawl problem, but they appear to have broken the growth ceiling by introducing a new leak vector that operates outside developers' normal mental model of what constitutes sensitive code. The addition of tools that generate and commit credential-laden config files by design has provided a structurally different pathway.
Exposed secrets in AI tool configuration files are not sitting uncollected. A 2026 AI security assessment documents the "Bissa Scanner" campaign, which stole AI credentials from 30,000+ exposed .env files, with AI accounts being the most stolen credential type [4]. High-risk generative AI prompts doubled over the past year within enterprise environments [4], and the average organization now runs ten AI applications per month, many outside formal approval processes [4].
LLMjacking, in which stolen AI account access is resold to obscure attacker identity, has emerged as a criminal market specifically targeting the AI credential type [4]. The Bissa Scanner campaign demonstrates that automated tooling targeting AI-tool config files is already operational. The 1,122 .claude/settings.local.json files holding live credentials represent exactly the kind of target that campaign-style harvesting tools are built to find.
A leaked AWS key in a normal source file is bad. A leaked key in a permissions file where the credential was stored silently, by the act of clicking a convenience button, is worse, because the developer may never know the file holds a credential at all.
There is a specific architectural behavior in GitHub that makes the 1,122-file figure an undercount of actual exposure. Cross Fork Object Reference (CFOR) behavior means that any code committed to a public repository may remain accessible indefinitely as long as at least one fork of that repository exists, even if the original repository is deleted [5]. When a public repository is deleted, GitHub reassigns the root node role to one of the downstream forks, meaning all commits from the original remain accessible via any fork [5]. CFOR is an intentional design feature of GitHub's repository architecture [5].
This has a direct implication for the Claude Code settings file exposure: developers who realize they committed credentials and delete the repository have not revoked the exposure unless they also rotate the credentials. The 2026 secrets sprawl findings make the remediation gap explicit: 64% of valid secrets leaked in 2022 remained unrevoked as of 2026 [3]. 4 years after the initial leak, nearly two-thirds of those credentials were still valid. Among the developers who deleted repositories rather than rotating keys, CFOR behavior means those commits are still reachable.
Even without the fork persistence issue, 90% of exposed valid secrets remain active for at least 5 days even after the author is notified [6]. That window is more than sufficient for automated harvesting tools.
NIST Special Publication 800-204D establishes that developer workstations and their environments present a fundamental risk to software supply chain security and should not be trusted as part of the build process [7]. That principle applies directly here. Developer machines running Claude Code are generating permission files that can carry credentials into public repositories. Treating the developer workflow as an untrusted input channel is what NIST recommends for CI/CD (Continuous Integration/Continuous Deployment) pipeline security [7].
Add .claude/settings.local.json to the repository's .gitignore as a project standard before any developer installs the tool. Claude Code protects this file on the developer's own machine via a global git exclude, but that protection does not follow the file into shared repositories and is absent for every other team member cloning the project. Adding it to the repository's .gitignore closes the gap at source. This is preventive and costs nothing.
Deploy pre-commit hooks that scan for secrets patterns before any push reaches the remote. Research on large language model-based credential detection shows GPT2-based classifiers can achieve an F1 score of 0.985 on benchmark datasets [8], and both LLM-based and pattern-based tools are designed for sub-10ms CI/CD pipeline integration [8]. Traditional tools like Detect Secrets and git-leaks already support this use case at lower accuracy. Either approach is better than no gate.
Integrate secrets scanning into CI/CD pipelines per NIST SP 800-204D guidance [7]. A pre-commit hook can be bypassed; a server-side CI check cannot be skipped without the pipeline failing.
Rotate immediately and unconditionally any credential that has touched a public repository, regardless of whether the repository was subsequently deleted. Treat the deletion as confirmation that the commit existed, not as remediation. CFOR behavior means the commit may remain permanently accessible as long as any fork of the repository exists; credential rotation is the only reliable remediation [5].
Audit which AI coding tools are running in your development environment and what configuration files they generate. The 10-applications-per-month figure [4] reflects a real operational reality: developers are adopting AI tools faster than security teams are inventorying them. Claude Code is documented here, but the same design pattern applies to any AI tool that writes persistent, committed configuration files. Security controls need to be structural, not advisory.
Claude Code settings file leaks exposing credentials in public repositories are exactly the exposure class Anomali Credential Monitoring, Digital Risk Protection, and ThreatStream dark web feeds are built to surface.
Can your current stack detect Claude Code configuration file credential leaks before attackers find them first?
FEATURED RESOURCES


