2,539 secrets in 1,994 public repos: How an AI coding agent’s ‘don’t ask again’ button exposed enterprise credentials

The usual story of a credential leak involves an attacker, a phishing email or a compromised server. This one involves a developer clicking “Yes, and don’t ask again.”

Application security company Apiiro has published research identifying 2,539 real secrets across 1,994 public GitHub repositories. They include database passwords, cloud access keys, API tokens and SSH credentials. The investigation found 63 organisations with exposed credentials, from startups and software agencies to established technology vendors. Some of the exposed material included production database passwords, cloud administration keys and credentials tied to medical-records applications. Some credentials had been publicly accessible for months, and a few for more than a year.

The research matters because of where the leaks originate. Developers increasingly rely on tools such as Claude Code, GitHub Copilot and Cursor to write code, troubleshoot applications, run commands and interact with enterprise systems. Apiiro’s findings suggest that the routine mechanics of those tools, not a sophisticated attack or a compromised model, can be enough to put credentials in public view.

How a convenient click becomes a leak

The issue centres on how Claude Code handles command approvals. Imagine a developer investigating a database connection problem in a staging application. The assistant suggests a command that includes a database password or API credential, and the tool asks for permission to run it. If the developer chooses “Yes, and don’t ask again,” the approval is remembered in a local settings file so the developer is not prompted again.

The catch is that the saved permission rule can contain the complete command, password included.

Claude Code is designed to keep that file on the developer’s machine, and it tries to protect it through the developer’s global Git ignore configuration. That protection has gaps. If the project is later set up as a repository, moved to another machine, or the file is already tracked by Git, the settings file can end up in the codebase. If the repository is public, the credentials are public too. In some cases, the AI assistant itself may commit the file as part of a routine code change.

Apiiro is explicit that this is not a story of malice. The research does not suggest Claude Code is deliberately stealing credentials or that the underlying model is compromised. It describes how a feature built for convenience can create an unintended exposure.

The scale of the exposure

Apiiro examined more than 104,000 publicly accessible copies of Claude Code’s local settings file on GitHub. Of these, 1,122 contained real secrets, amounting to 1,379 distinct credentials: 636 provider keys and 743 passwords or tokens tied to publicly accessible hosts.

Databases featured prominently, with 379 database passwords and 122 Supabase service-role keys. The haul also included AWS keys, GitHub and GitLab tokens, npm tokens, private SSH keys and API credentials for assorted services. Among them were 43 SSH credentials for public servers, some with root-level access that could hand a holder extensive control over the affected systems.

Deleting the file does not close the door. Apiiro found 734 additional real secrets in earlier versions of files that no longer existed in the current repositories, still retrievable from Git history. It also identified 211 forks of 74 affected repositories carrying the same exposed secrets. Once a credential reaches a public repository, copies can persist in history, forks and developer machines long after the original file is gone.

Scanners are missing some of it

The findings also expose a limit of conventional secret scanning. Most tools look for recognisable patterns, such as cloud-provider key formats, token structures or strings that resemble passwords. Apiiro found that some exposed credentials were buried inside ordinary command lines, such as a database password in a connection command or an SSH password in a remote login. Entries like these may not resemble credentials and can slip past automated detection.

To test this, Apiiro ran two widely used scanners, Gitleaks and TruffleHog, against the 1,122 files known to contain real secrets. Gitleaks flagged 564 files and TruffleHog flagged 643. Some 215 files containing real secrets were missed by both.

For security teams, the implication is uncomfortable. Having a secret scanner in the pipeline does not mean the risks introduced by AI coding agents are covered. Controls need to understand how credentials are stored and used in AI-generated commands, developer histories and agent configuration files.

A wider surface than one tool

Although the research focused largely on Claude Code, the concern applies across AI-assisted development. Coding agents interact with local files, development environments, databases, cloud infrastructure and third-party services, and in doing so they encounter sensitive information that developers once handled by hand. Apiiro also found credentials in shared agent configuration files, AI chat transcripts, memory files, handoff notes and deployment documentation.

Traditional protection has concentrated on source code, configuration files, databases and cloud infrastructure. AI tooling adds new places for sensitive information to accumulate: files generated automatically by agents, records of past interactions, permission settings and developer-specific memory files. Even if such files never reach GitHub, they can be exposed through malware, compromised developer machines, shared folders, container images or published software packages. The risk is not only that an AI tool makes a mistake. It is that the files and workflows around AI agents enlarge the enterprise’s exposure surface.

Apiiro’s recommendations amount to a rethink of developer security policy. Teams should treat AI agent configuration folders and memory files as sensitive assets, protected to the same standard as environment files and credential stores. Repository controls should be tightened so that local agent settings are explicitly excluded through project-level Git ignore rules, and pre-commit checks and continuous integration pipelines should examine AI-generated configuration files and repository histories.

Developers should stop typing passwords and API keys directly into command lines and instead draw on environment variables or approved secrets-management platforms, which keeps sensitive values out of an agent’s saved commands. Organisations should also move away from routinely approving individual commands with embedded credentials, favouring broader, controlled command patterns over repeatedly saved full commands.

Finally, anything that may already have leaked needs attention. If a secret has appeared in a public repository, the first priority is to revoke or rotate it, because deleting the file or rewriting history does not guarantee safety. Apiiro advises starting with credentials tied to publicly accessible systems, since these may offer a direct route into enterprise infrastructure.

After the research was published, Boris Cherny, Anthropic’s Head of Claude Code, responded in the Hacker News discussion on 7 November. He acknowledged that the company was looking at ways to prevent such exposures, including improvements to automatic approval modes and built-in secret scanning. He also accepted a concern raised in the thread that sensitive commands could still trigger similar issues even when automatic approval modes are used. The proposed safeguards were still at the prototyping stage at the time of his response.

Securing what the agent touches

The case for AI coding agents rests on faster development cycles, higher developer productivity and automation of repetitive engineering work. Those gains are real, but they alter the security equation. Unlike earlier code-completion tools, modern agents execute commands, reach into systems and act with a developer’s access. Their working environment is therefore as sensitive as any production system.

For CIOs and CISOs, the lesson is not to slow adoption. It is to accept that the boundaries of software development security have moved. An organisation can have rigorous controls around its production databases, cloud platforms and source repositories, and still see them undone by a password sitting in an overlooked, AI-generated settings file. Securing the agent itself will matter, but securing everything the agent touches, remembers and records may matter just as much.

The measure of agentic development will not be how much code it writes, but whether the convenience it offers leaves the keys to the enterprise where they belong.