New research from Apiiro uncovered 2,539 exposed credentials across 1,994 public GitHub repositories, including database passwords, cloud API keys, authentication tokens and SSH logins. Researchers identified 63 affected organizations, including startups, software vendors and IT services firms.
The exposure stems largely from Anthropic’s Claude Code, which can save approved commands, including embedded passwords and credentials, in local configuration files when developers select “Yes, and don’t ask again.” Those files can subsequently be committed to public repositories.
Researchers found that Claude coauthored commits involving exposed credentials in 539 repositories, while conventional secret-scanning tools failed to identify some of the leaks. Among the exposed credentials were production database passwords, an administrative cloud API key and credentials associated with a medical records application. Apiiro also found secrets lingering in repository histories, AI agent transcripts and memory files.
Seemant Sehgal, Founder & CEO, BreachLock
“A ‘don’t ask again’ prompt is a decision to write a credential into a file, and many developers clicking it likely don’t know that file exists. Once it lands in a repository, it sits in a place many secret scanners were never built to check, which appears to be why some of these leaks slipped through. Apiiro found Claude coauthored commits in 539 of these repositories, and it also found secrets in agent transcripts and memory files that almost no one audits. I spent years on the buying side of security budgets, and I never saw a line item for the config file an AI agent writes on a developer’s behalf. Any of these credentials that were never rotated let someone log in to a production database with no exploit required.”
ㅤ
Ryan McCurdy, Vice President of Marketing, Liquibase
“What’s concerning is how easily a routine development task can create a security exposure. A developer approves a command to save time, the AI agent retains credentials as part of that approval, and those credentials can eventually end up in a public repository. Nobody intended to expose them but the workflow made it possible.
“As AI agents become more involved in software development, organizations need to recognize that source code isn’t the only thing they need to secure. Agent configuration files, transcripts, and execution histories can contain sensitive information, and traditional security checks may not catch everything.
“The consequences become particularly serious when those credentials provide access to production databases. An exposed password isn’t just a data security issue if it also gives someone permission to modify or delete critical information. Organizations need to limit those permissions and establish independent controls over changes to production systems.”
ㅤ
John Strand, Owner, Black Hills Information Security
“What I find really exciting about these stories of AI embedding API keys and passwords in publicly accessible repositories is that this is exactly what humans do. We’ve been doing it for years. If you ask an AI agent, ‘Why did you hardcode these API keys and put them in a public GitHub repository?’ it’s going to look right back at us and say, ‘I learned it from you.'”
This again proves that AI can’t be trusted. Which means organizations have to make sure that they protect themselves accordingly.
Related
This entry was posted on November 9, 2026 at 3:08 pm and is filed under Commentary with tags AI. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
AI coding agents expose thousands of passwords and credentials on GitHub
New research from Apiiro uncovered 2,539 exposed credentials across 1,994 public GitHub repositories, including database passwords, cloud API keys, authentication tokens and SSH logins. Researchers identified 63 affected organizations, including startups, software vendors and IT services firms.
The exposure stems largely from Anthropic’s Claude Code, which can save approved commands, including embedded passwords and credentials, in local configuration files when developers select “Yes, and don’t ask again.” Those files can subsequently be committed to public repositories.
Researchers found that Claude coauthored commits involving exposed credentials in 539 repositories, while conventional secret-scanning tools failed to identify some of the leaks. Among the exposed credentials were production database passwords, an administrative cloud API key and credentials associated with a medical records application. Apiiro also found secrets lingering in repository histories, AI agent transcripts and memory files.
Seemant Sehgal, Founder & CEO, BreachLock
“A ‘don’t ask again’ prompt is a decision to write a credential into a file, and many developers clicking it likely don’t know that file exists. Once it lands in a repository, it sits in a place many secret scanners were never built to check, which appears to be why some of these leaks slipped through. Apiiro found Claude coauthored commits in 539 of these repositories, and it also found secrets in agent transcripts and memory files that almost no one audits. I spent years on the buying side of security budgets, and I never saw a line item for the config file an AI agent writes on a developer’s behalf. Any of these credentials that were never rotated let someone log in to a production database with no exploit required.”
ㅤ
Ryan McCurdy, Vice President of Marketing, Liquibase
“What’s concerning is how easily a routine development task can create a security exposure. A developer approves a command to save time, the AI agent retains credentials as part of that approval, and those credentials can eventually end up in a public repository. Nobody intended to expose them but the workflow made it possible.
“As AI agents become more involved in software development, organizations need to recognize that source code isn’t the only thing they need to secure. Agent configuration files, transcripts, and execution histories can contain sensitive information, and traditional security checks may not catch everything.
“The consequences become particularly serious when those credentials provide access to production databases. An exposed password isn’t just a data security issue if it also gives someone permission to modify or delete critical information. Organizations need to limit those permissions and establish independent controls over changes to production systems.”
ㅤ
John Strand, Owner, Black Hills Information Security
“What I find really exciting about these stories of AI embedding API keys and passwords in publicly accessible repositories is that this is exactly what humans do. We’ve been doing it for years. If you ask an AI agent, ‘Why did you hardcode these API keys and put them in a public GitHub repository?’ it’s going to look right back at us and say, ‘I learned it from you.'”
This again proves that AI can’t be trusted. Which means organizations have to make sure that they protect themselves accordingly.
Share this:
Like this:
Related
This entry was posted on November 9, 2026 at 3:08 pm and is filed under Commentary with tags AI. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.