Claude Code secrets exposure has revealed a significant security risk associated with AI-assisted software development. According to research published on November 5, 2026, by Apiiro, 2,539 secrets were identified across 1,994 public GitHub repositories, including database passwords, API keys, cloud credentials, and SSH access information. The incident demonstrates why code exposure monitoring and external threat intelligence are increasingly important for organizations adopting AI coding assistants.
The findings highlight an unexpected vulnerability in everyday development workflows: a seemingly harmless permission setting can unintentionally preserve sensitive credentials in files that later become publicly accessible.
For CISOs, developers, SOC teams, and managed security providers, understanding how this exposure occurred is essential to preventing similar incidents.
What Happened in the Claude Code Secrets Exposure?
Security researchers Shmulik Cohen and Matan Giladi from Apiiro investigated how Claude Code stores command permissions during software development.
Their research identified a potential security weakness involving the assistant’s “Yes, and don’t ask again” option.
When developers approve certain commands, Claude Code can save the complete command inside a local configuration file named .claude/settings.local.json.
If that command contains a password, authentication token, or API key, the sensitive information may be saved in plaintext alongside the permission rule.
When the configuration file is subsequently committed to a public GitHub repository, the credentials can become accessible to anyone.
The researchers examined 104,185 publicly accessible copies of this configuration file across 103,617 repositories.
Their findings included:
- 1,122 configuration files containing at least one apparent secret.
- 1,379 distinct secrets identified in those files.
- 2,539 secrets across 1,994 repositories when historical commits, shared settings, and agent transcripts were included.
- 63 organizations associated with exposed credentials.
- 734 secrets found in historical versions but absent from current file versions.
These figures come from Apiiro’s original investigation into AI coding agent credential exposure.
Importantly, researchers did not attempt to authenticate using the discovered credentials. The findings establish exposure, not confirmed unauthorized access to every affected system.
How Claude Code’s “Don’t Ask Again” Feature Exposes Credentials
Claude Code is an AI-powered coding assistant developed by Anthropic that helps developers write code, execute commands, and interact with development environments.
To protect users, certain operations require explicit permission before execution.
However, the convenience of persistent authorization can introduce unexpected risks.
1. Developers approve commands containing secrets
A developer might ask Claude Code to connect to a database, troubleshoot an API request, or execute an administrative command.
Some operations require credentials stored in environment variables or configuration files.
If a command includes the actual credential value, that information may appear inside the command requiring approval.
2. Claude Code saves the approved command
When the developer selects “Yes, and don’t ask again,” Claude Code can store the command as a persistent permission rule.
The problem occurs when the saved rule contains the literal command and its sensitive values rather than a generalized permission pattern.
The resulting configuration file may retain credentials long after the original task has finished.
3. Configuration files enter public repositories
Claude Code attempts to exclude its local settings file from Git tracking.
However, machine-specific exclusions do not necessarily apply when projects are moved, cloned, or modified in different environments.
If the file becomes tracked and is pushed to a public repository, its contents become publicly accessible.
4. Git history preserves previously exposed information
Removing a sensitive file from the latest commit does not automatically erase earlier versions.
Credentials may remain accessible through Git history, repository forks, or previously cloned copies.
This makes credential rotation essential even after the visible configuration file has been deleted.
What Types of Credentials Were Exposed?
The research identified several categories of secrets that could provide access to enterprise services if still valid.
| Credential type | Reported findings |
|---|---|
| Database passwords | 379 |
| Supabase service-role keys | 122 |
| Supabase account tokens | 103 |
| SSH credentials for public servers | 43 |
| GitHub, GitLab, and npm tokens | 42 |
| AWS access keys | 23 |
| Private keys | 6 |
The researchers also identified AI service credentials and other application tokens.
These categories represent different security risks.
A database password could provide access to sensitive records, while a cloud credential might enable unauthorized infrastructure operations depending on its permissions.
An exposed AI service API key could create unauthorized usage costs or access to associated resources.
The severity depends on credential validity, permissions, available security controls, and whether suspicious activity actually occurred.
Why Traditional Secret Scanners May Miss These Exposures
One particularly concerning finding involves the limitations of conventional secrets detection.
Apiiro tested two widely used security tools, Gitleaks and TruffleHog, against the exposed configuration files.
Of the 1,122 files containing apparent secrets, 215 were not flagged by either scanner under the researchers’ testing conditions.
The challenge lies partly in how credentials are represented.
Many scanning systems recognize structured API keys through recognizable prefixes, patterns, or character sequences.
However, passwords embedded inside ordinary commands may not match these signatures.
For example, a database password supplied as a command argument can resemble normal configuration text rather than a recognizable API token.
This does not mean secret scanners are ineffective. Instead, it highlights the need to combine automated scanning with contextual analysis, repository governance, and external exposure monitoring.
Organizations should also recognize that sensitive information can appear in AI-generated transcripts, project memory files, and development documentation.
How External Monitoring Helps Identify Exposed Credentials
The Claude Code incident demonstrates that sensitive information can leave an organization’s controlled environment without a traditional network intrusion.
A developer may inadvertently publish credentials through an otherwise legitimate workflow.
Once credentials appear in public repositories, they can potentially be discovered, copied, or reused by unauthorized parties.
This creates a practical role for external cyber threat intelligence.
Identify publicly exposed secrets
DarknetSearch provides code exposure detection capabilities designed to identify secrets associated with organizations in public code repositories.
Security teams can use this visibility to investigate exposed credentials alongside internal repository scanning and security alerts.
A finding should be validated before being classified as an active compromise.
Correlate different sources of exposure
Credentials discovered in repositories may also appear in leaked datasets, infostealer logs, or other monitored sources.
DarknetSearch’s article on LLM-jacking and stolen AI accounts explains how exposed AI credentials can create opportunities for unauthorized resource consumption.
However, there is no evidence that the credentials identified in the Claude Code investigation were systematically distributed through dark web marketplaces.
Public repository exposure and dark web circulation are different events and should be investigated separately.
Improve employee security practices
Technical monitoring is only part of the solution.
Developers also need to understand how approval settings, configuration files, and source-control operations can unintentionally disclose secrets.
Targeted security awareness training can reinforce safer habits around credential handling, suspicious requests, and responsible use of AI development tools.
What Organizations Should Do After a Claude Code Credential Leak
Security teams should establish a clear process for investigating suspected exposure and reducing associated risks.
The following actions provide a practical starting point.
1. Review Claude Code configuration files
Inspect .claude/settings.local.json and shared .claude/settings.json files across relevant development environments.
Look for authentication tokens, passwords, connection strings, and commands containing sensitive values.
2. Check repository history
Examine current files and historical commits to identify information that may have been published previously.
Include public forks and other accessible copies where appropriate.
3. Rotate potentially exposed credentials
Revoke compromised or publicly exposed API keys, passwords, and access tokens.
Prioritize high-privilege credentials associated with production databases, cloud administration, and remote server access.
4. Investigate possible unauthorized activity
Review authentication logs, cloud activity, database access records, and unusual API usage.
A publicly exposed credential warrants investigation but does not automatically establish that an attacker used it.
5. Strengthen development policies
Use centralized secrets management, least-privilege credentials, and repository-wide ignore rules.
Avoid inserting literal passwords into commands that may be recorded by AI assistants.
6. Monitor for recurring exposure
Introduce scanning into development pipelines and periodically reassess publicly accessible repositories.
Organizations can combine internal controls with external intelligence to identify credentials that have escaped normal security boundaries.
For teams evaluating ongoing monitoring, DarknetSearch provides information about threat intelligence and monitoring plans for organizations and managed security providers.
What the Claude Code Incident Means for Enterprise AI Security
The incident raises broader questions about how organizations govern AI-assisted development.
Traditional application security policies often focus on source code vulnerabilities, third-party dependencies, and software supply chain risks.
AI coding agents introduce additional considerations because they can execute commands, retain configuration information, and participate in repository operations.
Security teams should therefore evaluate not only the code these assistants produce but also the information they store during development.
Important controls include secure default configurations, restricted permissions, secret-safe automation, repository review, and appropriate logging.
Organizations should establish clear ownership for AI development security across engineering, DevSecOps, identity management, and incident response.
The objective is not to eliminate productivity-enhancing AI tools. It is to ensure that their operational convenience does not undermine credential protection.
Frequently Asked Questions
What caused the Claude Code secrets exposure?
The exposure resulted from approved commands containing sensitive credentials being stored in plaintext configuration files.
When developers subsequently committed those files to public GitHub repositories, their contents became accessible.
The issue involves configuration handling and repository practices rather than evidence that the Claude language model itself was compromised.
Were all 2,539 exposed credentials active?
No. Apiiro identified 2,539 apparent secrets through its research methodology but did not test them against the associated services.
One notified organization confirmed that its exposed key had been active.
The findings therefore demonstrate a substantial exposure problem without proving that every credential remained valid or had been exploited.
Can deleting an exposed GitHub file protect credentials?
Deleting a file from the current repository version is insufficient when sensitive information remains in Git history, forks, or external copies.
Organizations should first revoke or rotate exposed credentials, then investigate historical exposure and remove sensitive material where appropriate.
Can dark web monitoring detect exposed GitHub credentials?
Some external threat intelligence platforms provide code exposure monitoring alongside dark web and credential leak detection.
These capabilities may help identify relevant secrets in monitored public repositories and leaked datasets.
However, monitoring coverage varies, and no platform can guarantee detection of every exposed credential.
Strengthen Visibility Into Exposed Credentials
The Claude Code secrets exposure demonstrates how easily sensitive information can escape through legitimate development workflows. Organizations need effective credential management, secure coding policies, repository scanning, and visibility into external exposure.
DarknetSearch helps security teams investigate exposed credentials, monitor external threats, and identify risks associated with publicly accessible information.
Explore its capabilities and request a DarknetSearch demonstration or free trial to understand how external threat intelligence can complement your existing security controls and support faster, evidence-based investigations.
