AI Coding Assistants Leak Thousands of Secrets via Local Config Files

A Convenient Option Leads to Massive Credential Leaks

Security researchers recently scanning public code hosting platforms identified a worrying pattern: the “permanently approve” mechanism in certain AI coding assistants is systematically leaking sensitive credentials into public repositories.

Here is how it happens. When an AI coding assistant needs to execute a shell command, it prompts the user for permission. If the user selects an option like “Yes, and don’t ask again,” the tool—to avoid repeated interruptions—persists the full text of the approved command in a local configuration file inside the project.

The problem is that if the command itself contains sensitive information—for example:

mysql -u admin -p'S3cretP@ss!' -h db.internal mydb
curl -H "Authorization: Bearer sk-live-xxxx" https://api.example.com/deploy

—the password or API token ends up stored in plaintext in that config file. Then, when a developer habitually runs git add . and pushes to the remote, the secrets enter the public commit history.

Scale of the Leak: Sobering Numbers

A systematic scan of such local approval config files in public repositories revealed the severity:

• Roughly 104,000 publicly accessible local approval config files were found.
• About 1,122 of them contained at least one valid-format secret, totaling around 1,379 distinct credentials.
• Broadening the scope—including git commit history, shared-level config files, agent run logs, and forked repositories—yielded about 2,539 affected credentials across 1,994 repositories.

Types of Leaked Credentials

About one-third of the leaked secrets were database login credentials (roughly 379 database passwords). The rest included SSH private keys, cloud provider access credentials, and similar. Database passwords are especially dangerous: they may allow attackers to bypass the application layer and directly access core data.

Long Exposure Windows

In nearly half of the affected repositories, the sensitive file had been exposed on the default branch for more than 217 days. In other words, these secrets were publicly visible online for over half a year without the repository owners noticing.

Detection Blind Spots: Why Standard Scanners Miss These Leaks

A notable finding is that mainstream secret-scanning tools had poor recall on this batch of leaked data. Two widely used scanners identified only 564 and 643 secrets, respectively, and about 215 files were missed by both tools.

The reason is not hard to understand. General-purpose scanners rely on pattern-matching rules (regular expressions, entropy detection). But real-world command lines contain secrets in many forms: passwords embedded in connection strings, tokens wrapped in quotes, concatenated with environment variables, or even inline after base64 encoding. For credentials hidden inside command statements, pure rule-based engines naturally have coverage gaps.

This suggests that secret-leak detection cannot rely on a single tool. Teams should combine multiple scanning approaches, custom rules, and manual sampling—especially dedicated audits of local config files generated by AI assistants.

Root Cause Analysis: Three Layers of Design Flaws

Looking at the entire chain of events, the problem is not in one place. Three layers of defense all have gaps:

1. Data-Write Layer: Approval Records Are Too Granular

When persisting approval records, the tool saves the full command text instead of an abstract pattern of the command. A safer approach would be to record only the structural template of the command, for example:

{
  "permissions": {
    "allow": ["Bash(npm run:*)", "Bash(git commit:*)"]
  }
}

Using wildcard patterns instead of literal commands preserves the convenience of not asking again, while fundamentally preventing secrets from being written to disk.

2. Ignore-Policy Layer: Protection Does Not Travel with the Project

These tools typically write the config file to the machine’s global git excludes. That rule only applies on the local machine; it is not committed to the repository’s own .gitignore. The consequences are:

• On another machine, cloning the repository does not carry the global exclusion rule, so the file may easily be committed by accident.
• In a team context, other members’ repositories have no protection for that file at all.

The correct approach is to add such sensitive paths to the repository-level .gitignore so that the protection travels with the codebase itself.

3. Incident-Response Layer: Deleting a File ≠ Removing the Leak

Many developers, upon noticing an accidental commit, first delete the file and commit again. But git is a distributed version control system: the file still exists in the full history, and anyone with read access to the repository (or if the repo is public) can recover past versions using git log / git show:

# Even if the latest commit removed the file, history remains queryable
git log --all --full-history -- "*settings.local.json"
git show <commit_hash>:settings.local.json

Moreover, forks, mirrors, and clones made by others before the deletion are all outside the reach of a simple deletion.

Incident Response and Long-Term Prevention Recommendations

The Correct Order of Incident Response

1. Rotate the secrets first, then clean up the repository. The order must not be reversed—cleaning only stops new exposure, but already-leaked credentials must be invalidated by revocation and reissuance. Treat any exposed credential as “permanently compromised.”
2. Use git rm --cached to remove the file from version control while keeping a local copy:

   git rm --cached .claude/settings.local.json
   echo ".claude/settings.local.json" >> .gitignore
   git commit -m "remove local config from tracking"

3. For sensitive files already in history, use history-rewriting tools to filter them out, force-push the result, and notify all collaborators to re-clone. Also check forks and mirrors.
4. Inspect log systems (CI logs, agent run logs, etc.) for a second exposure of the same credentials.

Building Long-Term Mechanisms

• Turn approval into pattern-based whitelisting: Promote “pattern approval” instead of “command approval” at the team level, so secrets never get written down in the first place.
• Block secrets in CI/CD pipelines: Deploy secret-scanning in push hooks and pipeline steps to reject commits containing what look like credentials.
• Minimize credential exposure: Avoid inline plaintext credentials in command lines. Use environment variables, credential management services, or short-lived tokens instead.
• Shorten credential lifetimes: Set periodic rotation policies for database passwords and cloud credentials, so even an exposed secret has a limited window of usefulness.
• Include AI tools in security audits: Config files, logs, and cache files generated by programming assistants should be treated as high-sensitivity assets, just like .env files.

Broader Implications: Cloud Security Narratives vs. Local On-Premises Risks

Interestingly, the same AI tool often adopts solid security designs in its cloud-hosted sessions—e.g., encrypted storage of API keys and no plaintext visibility on the model side. This sharp contrast between the “cloud narrative” and “local on-the-ground incidents” reveals a common blind spot in evaluating AI tools: security capabilities are usually focused on the data transmission and model interaction chain, while the tool’s persistence behavior on a user’s local disk receives much less scrutiny.

For enterprises and teams adopting any AI coding tool, in addition to evaluating model capabilities and cloud compliance, they should establish a local file audit checklist: What files does this tool write inside the project? What sensitive content do those files contain? Are these files correctly excluded from version control? Answering these questions clearly is the key to avoiding the outcome where “a convenient checkbox becomes a secret vault.”