A convenience feature in Anthropic's Claude Code has quietly been storing developer secrets — database passwords, API keys, cloud credentials — in a plain-text file that thousands of developers have committed to public GitHub repositories. Security firm Apiiro published findings on November 8 showing 2,539 exposed credentials across 1,994 public repositories. GitGuardian followed with deeper commit-history analysis finding 31,088 distinct secrets across 23,276 repositories, with 5,343 confirmed live. The gap between those numbers tells you something important: standard secret scanners missed most of them.
This isn't a vulnerability in the traditional sense — no CVE, no patch needed. It's a trust architecture problem: a tool that holds credentials on behalf of developers, without making the credential exposure risk visible at the moment it matters.
How the Exposure Happens
Claude Code asks for permission before running most shell commands. When a developer clicks "Yes, and don't ask again," Claude Code saves that approved command as an allow rule in .claude/settings.local.json inside the project folder. If that command contains a credential — a database connection string, an API key passed as a flag, an AWS access key — the credential is stored verbatim in that file.Claude Code does attempt to protect against this. The first time it creates the file inside a git repository, it adds **/.claude/settings.local.json to the developer's global git excludes file. The protection is real. The problem is where it lives: in the developer's local machine configuration, not in the project's own .gitignore. When a developer clones the project on another machine, sets up CI/CD, or collaborates with a team, that machine-local protection doesn't travel with them.
There are several additional exposure paths beyond the primary one. Forks spread secrets further: 211 forks of 74 repositories carried the same exposed credentials as their originals. The shared .claude/settings.json — which teams intentionally commit for shared tool configuration — contained secrets in 298 of 76,011 public copies. Apiiro also found credentials in saved agent conversations, memory files, handoff notes, and deployment documentation that developers committed alongside code.
The Numbers and What They Mean
| Source | Scope | Secrets Found | Repositories |
|---|---|---|---|
| Apiiro (Nov 1–3, 2026) | Active files + git history + forks + shared settings | 2,539 | 1,994 |
| GitGuardian (full commit history) | Public commits 2025–2026 | 31,088 (5,343 live) | 23,276 |
The difference between 2,539 and 31,088 is methodology, not noise. Apiiro searched default branch files and recent history. GitGuardian ingested full commit history — including secrets that were committed and then removed, but remain in the git log. Removal from a branch doesn't remove a secret from history. Rotation does.
The most common secret types in the active files: database passwords (379), Supabase service-role keys (122), and cloud access credentials. These aren't low-privilege tokens — database passwords and service-role keys carry significant blast radius in a production environment.
One more data point worth flagging: standard secret scanners missed 215 of the exposed files. AI agent configuration files and memory files aren't in the detection patterns that most CI/CD pipelines use. Developers who assume their secret scanning covers Claude Code settings files should verify that assumption explicitly.
The Known Issue That Wasn't Fixed
This isn't a surprise finding. A Claude Code issue was opened in August 2025 reporting that approved commands containing credentials were stored verbatim in the local permissions list. That issue was automatically closed in January 2026 after inactivity.Security firm ironPeak documented the same exposure in February 2026, found a committed Claude settings file containing database passwords and API keys from their own testing, and published a tool for detecting secrets in AI configuration files and their history.
Anthropic's response to the Apiiro findings, via engineer Boris Cherny on Hacker News, pointed to the global gitignore protection and suggested the exposed copies were manually created and checked in. That's technically accurate for some cases. It doesn't account for the structural gap: machine-local protection doesn't travel with projects, and developers sharing repositories across machines or with collaborators are exposed even when they did everything the tool suggested.
What This Means for Healthcare
Healthcare development teams using Claude Code — or similar agentic coding tools — have a specific exposure profile that makes this finding worth taking seriously.PHI-Adjacent Credentials Are in Scope
Healthcare developers routinely work with database connection strings, API keys for HL7/FHIR integration endpoints, EHR vendor credentials, and cloud service tokens that touch PHI. Any of these passed as command-line arguments — in a database migration, a data pipeline test, a vendor API call — can end up in.claude/settings.local.json if the developer clicks "don't ask again."
Under HIPAA, exposed credentials that could grant access to PHI-containing systems constitute a potential breach event. The analysis required under the HIPAA Breach Notification Rule doesn't require that access was actually gained — it requires assessing whether unauthorized access was possible. A public GitHub repository containing a database password for a system with PHI is not a theoretical risk; it's a notification analysis trigger.
The Shared Settings File Is the Higher-Risk Vector for Teams
Individual developer machines are one exposure path. But in team environments, the shared .claude/settings.json — the file teams intentionally commit for consistent tool configuration — is higher risk because it's deliberate. Healthcare development teams that have standardized Claude Code usage and committed a shared settings file should audit it now for credentials that may have been embedded in allow rules.Secret Scanning Gaps in Regulated Development Pipelines
Healthcare development environments in regulated settings (those touching ePHI under a HIPAA-compliant development pipeline) often include secret scanning as a control. If that scanning doesn't cover AI agent configuration files, it has a gap. The same applies to CLAUDE.md files — GitGuardian found 6,155 distinct secrets with 2,537 valid credentials in those files. Instruction files for AI coding agents are now a credential exposure surface that most SDL programs haven't mapped.The NIST AI RMF and Zero Trust Alignment
Anthropic's own Zero Trust for AI Agents guide (May 2026) recommends treating agent folders as holding secrets — the same way development teams treat.env files. The guide's core test applies here: does the current control make the exposure impossible, or just tedious? Machine-local gitignore is tedious. Project-level gitignore plus organizational gitignore templates is closer to impossible. Healthcare security teams building SDL programs for AI-assisted development should add agent configuration files to their secret management requirements explicitly.
What to Do Now
The immediate actions are straightforward:- Search your GitHub organization for
.claude/settings.local.jsonand.claude/settings.json— including git history on repositories where the files may have been removed. - Add
.claude/settings.local.jsonto your organization's gitignore templates so the project-level protection exists independent of any individual developer's machine configuration. - Rotate any credentials found — removal from a repository doesn't invalidate an already-exposed credential. Assume anything in a public git history has been seen.
- Extend secret scanning coverage to AI agent configuration files:
.claude/,.cursor/,.gemini/,.specstory/, CLAUDE.md, and agent memory files. - Audit shared settings files that teams have deliberately committed — the
.claude/settings.jsonthat teams check in for consistent configuration is not the same as the local file, and may contain allow rules with embedded credentials.
The Bigger Picture
This exposure class — credentials stored in AI agent configuration and memory files — is new enough that most security programs haven't mapped it. It's not a vulnerability in the conventional sense; it's the predictable result of agentic tools that hold state, receive credentials as inputs, and persist that state in files that live inside project directories.The pattern will recur. Claude Code is the highest-profile example right now because Apiiro and GitGuardian chose to study it, but the same structural issue applies to any agentic coding tool that saves approved commands or conversation history inside project directories: Cursor, GitHub Copilot in auto-approve mode, Gemini CLI. The 2026 explosion in AI coding tool adoption has outpaced the security community's ability to map the new credential exposure surfaces these tools create.
For healthcare security teams, the ask is specific: treat AI agent tool folders as credential-holding infrastructure, the same way you treat .env files and SSH config directories. Add them to secret scanning scope. Add them to gitignore templates. And audit what's already in your organization's repositories before someone else does.
This is an entry in the AI Security series. For related coverage, see GPT-6 Cyber Is Here — And OpenAI Called It Critical and AI Pivots and Supply Chain Risk: Inside the DPRK Binance Attack Chain.