AI coding assistants are selling a simple promise: let the agent handle the tedious work, including security chores. In practice, a convenience button on one popular tool can write the exact command you approved, password included, into a JSON settings file inside the project. Researchers later found more than a thousand public copies of that file on GitHub that still held secrets. Some of those secrets had been sitting on default branches for months.
This is not a story about a secret backdoor. It is a story about product design meeting git history. If your firm, MSP, or internal IT team has developers, contractors, or power users running AI coding agents against real databases and cloud accounts, treat it as an identity and secrets problem, not a “developer taste” problem.
How a password becomes a permission rule
When an AI coding agent asks to run a shell command and the user chooses a “yes, and don’t ask again” style approval, some tools persist that approval so matching commands run without prompting next time. If the approved string was an exact command with a database password, an SSH password flag, or a token inline, the secret is now sitting in a project-local settings file in plain text.
Nobody had to write “store credentials in a dotfile” in a design document. It is what happens when you persist a string without asking what the string contains.
Vendor documentation for at least one major tool describes a partial mitigation: the first time the local settings file is created in a git repo, the tool may add a global ignore rule on that machine. Global ignores do not travel with the repository. They do not protect a teammate’s laptop, a container, a CI runner, or a clone on a fresh machine. They do nothing for a file that was already committed. And deleting the file from the working tree does not erase it from history.
What the research found, without inventing extras
Public reporting in November 2026 summarized AppSec research that scanned public GitHub for these settings files. The headline counts, as reported:
- Over a hundred thousand copies of the local settings file across public repositories.
- Roughly one percent held at least one secret, totaling well over a thousand distinct secrets in the current copies alone.
- A large share of those secrets opened databases directly. Others included cloud keys, source-control tokens, and SSH logins.
- Older versions of the file, forks, shared settings, and saved agent chat logs pushed the total secret count higher still.
- Default scanners missed a meaningful fraction of the files because passwords typed inside ordinary commands do not look like classic key formats.
Researchers also noted that related bug reports describing the behavior had been closed as not planned by automation after periods of inactivity. Whether or not you care about the issue-tracker drama, the operational lesson is the same: do not wait for a vendor timeline to rotate what may already be public.
Separately, honeypot operators reported new probes for agent settings directories on web servers. Scanners do not need GitHub search if a project folder was ever deployed under a web root.
Why small firms should care even if they are “not a software company”
Plenty of medical, legal, and finance offices are not shipping commercial software. Plenty of them still have:
- An MSP or contractor who uses AI coding tools while writing scripts against production data.
- An internal “IT person” who keeps connection strings in project folders.
- A staging database that still holds a copy of real patient, client, or customer records.
- A WordPress, practice-management, or custom integration repo that started as a weekend project and never got a secrets review.
If that sounds familiar, a leaked admin password is not a developer embarrassment. It is a HIPAA, ethics, FFIEC, or client-confidentiality event waiting for someone to search git history.
What to do, in the order that matters
1. Rotate first. Every password, token, and key that ever appeared in an AI agent settings file, in any branch, in any commit. Cleaning the repo first and rotating later is how you end up with a tidy tree and a compromised database.
2. Search history, not just the current tree. Check every repository your team owns for agent settings paths. Look at older commits, not only HEAD.
3. Ignore the file in the repository itself. Add the local settings path to the project’s own ignore file and remove it from tracking. Global excludes on one laptop are not a control.
4. Open local copies that never left the machine. Secrets still leak through archives, container images, synced folders, and packages even when git never saw them.
5. Keep secrets out of commands. Pull credentials from a secrets manager or environment variables so an approved rule contains a variable name, not a password. Prefer pattern approvals for safe command families over pasting one-off commands that embed credentials.
6. Treat agent folders like environment files. Anything under common AI tool directories belongs in the same mental bucket as `.env`: never in the web root, never in a public repo, never in a shared zip sent to a contractor without review.
7. Add detection that looks for passwords inside commands. Format-based secret scanners miss a share of this class of leak. A custom rule for the settings paths is cheap insurance.
How DEC thinks about AI tooling risk
Dark Edge already wrote about CISA and allied guidance on AI agents that can act inside email and files. This is the sibling problem: agents that help write code can also persist the credentials used to reach production. Both belong in the same identity model. Give tools the least access they need. Keep humans approving consequential actions. Keep logs you can use when something goes sideways.
We help small professional firms and MSPs inventory where AI tools are in use, rotate exposed secrets, put continuous monitoring and alerting around unusual access, and document controls in language that is aligned with HIPAA, NIST 800-171, and similar frameworks, with management attestation available on request. We do not claim AI will secure your supply chain by itself. We also do not claim any tool makes breach impossible. We do help you stop treating “don’t ask again” as a harmless convenience.
Adapted from a post by Andrew Trainum on Cybersecsloth.
—
If your team is using AI coding tools against real systems, book a strategy call and we will help you prioritize what to rotate.