Agents Leaked 2,539 Secrets. The Fix Isn't Better Prompts.

Every developer who has used a coding agent knows the prompt: "Allow this command? Yes / Yes, and don't ask again." Apiiro scanned 104,185 public copies of Claude Code's permission file on GitHub. Of those, 1,122 contained a real secret — database passwords, SSH credentials, AWS keys, Supabase tokens. Across current files, git history, and agent transcripts, that number climbed to 2,539 distinct secrets spread across 1,994 repositories.

📖 Read the full version with charts and embedded sources on AgentConn →

This is not a story about one vendor's bug. It is a story about what happens when the permission model that makes agents productive is also the mechanism that leaks your credentials. The "don't ask again" convenience feature saves the literal command string — including whatever credential was in it — to a file that was never designed as a secret store but effectively became one. And the agent will happily commit that file, because no one told it not to.

Key Numbers from Apiiro's Research (November 2026):

• 104,185 public .claude/settings.local.json files scanned across 103,617 repos
• 1,122 files with real secrets; 2,539 distinct secrets total (including git history)
• 539 repos where Claude co-authored the commit that created or changed the file
• 379 database passwords, 225 Supabase keys, 43 SSH credentials, 23 AWS keys
• 211 forks of 74 repos carry the same inherited secrets
• 63 organizations notified by Apiiro before publication

The timing matters. This research landed as a 514-point Hacker News story on November 7, one day after Apiiro notified 63 organizations. A member of Anthropic's Claude Code team responded directly in the thread — a sign this was taken seriously, and that the fix is not as simple as adding .claude/ to .gitignore.

Developer coverage has already spread beyond HN — a detailed Dev.to breakdown walked through the Apiiro methodology and verified the numbers independently:

View on Dev.to →

How "Don't Ask Again" Becomes "Publish Forever"

The mechanism is worth understanding precisely, because it is not unique to Claude Code.

Claude Code uses a four-scope settings hierarchy: user-level (~/.claude/settings.json), shared project (.claude/settings.json), project-local (.claude/settings.local.json), and managed settings. When you run a command that requires approval — say, a database migration or an API call — the agent proposes it and asks for permission.

If you select "Yes, and don't ask again," the agent records a permanent allow rule. Here is the critical detail: the rule is the literal command string, not a generalized pattern. If the command was PGPASSWORD=hunter2 psql -h prod.db.example.com, that exact string — password included — gets saved to .claude/settings.local.json.

The file was designed to stay local. Claude Code adds it to your global git excludes file. But global excludes do not travel with the repository. A new contributor cloning the repo has no protection. A CI runner spinning up a fresh checkout has no protection. And if you git add . — or if the agent itself stages the commit — the file goes public.

As one GitHub issue reporter put it: after roughly two months of use, their settings.local.json had grown to 311 entries and held live Stripe keys, Supabase tokens, and other credentials. The file had become a plaintext credential store that nobody asked for.

View original post on ironPeak →

The Scale Nobody Expected

Apiiro's 1,122 files are the visible tip. Three other research efforts in 2026 confirm the problem runs much deeper.

GitGuardian's State of Secrets Sprawl 2026 — the industry's benchmark report — found 28.65 million new hardcoded secrets in public GitHub commits in 2025, up 34% year over year. The AI-specific numbers are worse: secrets tied to AI services rose 81%, and commits co-authored by AI coding assistants leaked secrets at roughly twice the baseline rate. A reported 3.2% of Claude Code-assisted commits contained leaked secrets, versus 1.5% for human-only commits.

GitGuardian also specifically measured MCP configuration files — the infrastructure that connects agents to external tools — and found 24,008 unique secrets exposed across public GitHub, with 2,117 confirmed valid.

View on GitGuardian →

Hush Security's October 2026 study scanned approximately 82,000 public MCP configuration files across 12 agent ecosystems. Their finding: 12% of credential slots were hardcoded rather than using environment variables or secret managers.

UpGuard's analysis of 18,470 .claude/settings.local.json files from public GitHub found that 11.4% granted wildcard or overly broad web-fetch permissions — meaning the agent could reach any URL, making prompt-injection-to-exfiltration trivially easy.

View on UpGuard →

Why the numbers keep climbing: GitGuardian found that 64% of secrets confirmed valid in 2022 were still exploitable in January 2026. Secrets that leak tend to stay leaked. Rotation discipline hasn't caught up with AI-accelerated sprawl.

The Blast Radius: From Laptops to CI Pipelines

The permission-file leak is one vector. What makes it dangerous is that it sits inside a broader pattern of agent trust failures that researchers exposed throughout 2026.

CI/CD pipeline exposure (Black Hat USA 2026): Novee Security demonstrated at Black Hat that a GitHub issue — opened by an account with zero repository privileges — was enough to reach CI runner secrets in Claude Code, Gemini CLI, and Codex. The agent reads the issue text as instructions. If the CI runner holds secrets, those instructions execute with the runner's credential scope. The Gemini CLI variant scored CVSS 10.0. The Claude Code path, tracked as CVE-2026-54316, allowed one-character-at-a-time exfiltration through the WebFetch tool.

npm package exposure (Lakera/Check Point, April 2026): Researchers scanning npm registries found 428 packages containing .claude/settings.local.json, with 33 files across 30 packages holding live credentials. The tarball is immutable once published — even after the developer discovers the leak, the secret persists in the registry.

Fork propagation: Apiiro found that 211 forks of 74 repositories carry the same inherited secrets. Fork the repo, get the credentials. The secret lifecycle extends beyond the original author's control.

Agent self-propagation: In 539 of the 1,105 traced repositories with a real secret, a commit co-authored by Claude itself changed the file. About a third of handoff notes containing a secret were written by the agent, not the developer. The agent is not just failing to protect secrets — in many cases, it is the actor that creates the exposure.

A comprehensive analysis on HelpNetSecurity found that an AI agent can pass every safety check and still leak secrets — the safety evaluations that vendors run do not test for the credential persistence patterns that matter in production.

View on HelpNetSecurity →

What the Community Is Saying

The Hacker News thread (514 points, 376 comments) produced a notable exchange. Boris from the Claude Code team responded directly:

"Historically Claude Code has not done secret scrubbing (there are many good tools for that), but we are looking into what we can do to prevent this. That said... .claude/settings.local.json is meant to stay local. This is not a file you should commit."

View on Hacker News →

The top community response cut to the core issue:

"Confusing headline. They scanned for repos where people had committed their .claude/ folder and local settings and then scanned those files for commands which contained keys or passwords. So pressing 'Don't Ask Again' by itself doesn't expose passwords by itself. If you commit your local Claude [settings], that's on you."

But a third commenter offered the sharper analysis that reflects the real debate:

"I'm super paranoid about the level of access AI agents have. At the same time, I want them to take away the tedium of a bunch of tasks I'm required to do, and it sucks to have to micromanage them. The best solution I've been able to come up with is using an ephemeral VM on an isolated net..."

This tension — productivity versus containment — is the structural problem the industry has not solved. The BDTechTalks Substack analysis, The Silent Threat of Claude Code, argues that the issue extends well beyond a single vendor: every agent that persists user approvals faces the same design tradeoff.

View on Substack →

⚠️ Contrarian Corner: Is This Really the Agent's Fault?

A reasonable defense: .env files have leaked for a decade. Developers commit secrets regularly — GitGuardian counts 29 million per year. The agent did what it was told. The developer approved the command. The file was labeled "local."

Here is the counter: agents change the denominator. A human developer might run PGPASSWORD=... psql once and forget about it. An agent proposes the command, asks for permanent approval, persists the literal string, and then — in 539 documented cases — commits the file itself. The agent accelerates every step of the leak chain. And unlike a human, it does not get nervous about pushing credentials to a public repo.

The "developer should know better" argument fails on the same grounds it failed for .env: if the default path leads to exposure, the default is wrong. Security-by-naming-convention has never worked.

What This Means for You

If your team uses any coding agent — Claude Code, Gemini CLI, Cursor, Codex — here is the minimum defensive posture:

Immediate (this week):

1. Scan your repos for agent config files. Run find . -name "settings.local.json" -path "*/.claude/*" across your organization. Also check for .cursor/, .gemini/, and .mcp.json files. If any contain secrets, rotate them immediately.
2. Add agent directories to .gitignore, not just global excludes. The repo-level .gitignore travels with the project. Global excludes do not.
3. Audit your CI/CD agent permissions. If your CI runner gives a coding agent access to environment secrets, you have the Black Hat 2026 attack surface. Scope agent access to the minimum required.

Structural (this quarter):

1. Treat permission-persistence files as credential stores. Run your secret scanner (TruffleHog, Gitleaks, GitGuardian) against .claude/, .cursor/, and MCP config directories — not just source code. Apiiro's research showed that neither Gitleaks nor TruffleHog caught roughly 19% of the secrets in these files.
2. Push for runtime-scoped permissions. The "don't ask again" model persists approvals to disk, where they outlive the session. The better design — which some agent frameworks are exploring — is session-scoped or even command-scoped approval that never touches persistent storage.
3. Use ephemeral environments for agent work. The HN commenter using "an ephemeral VM on an isolated net" has the right architecture: give the agent a credential that expires when the session ends, in an environment that gets destroyed after use.

For teams building their own agent frameworks, the MCP Security Fundamentals course on freeCodeCamp covers the OWASP MCP Top 10 and provides a practical checklist. We covered the broader framework in Your Agent Has a Lethal Trifecta Nobody Shipped a Fix For and the supply-chain dimension in Agent Config Files Are the New Supply Chain Attack Surface.

The Permission Model Needs to Evolve

Here is the uncomfortable truth: the "don't ask again" feature exists because the alternative — approving every shell command every time — is genuinely painful. Developers who turn off all permission persistence report spending more time babysitting the agent than writing code. As the UpGuard analysis documented, the jump from "approve everything" to "approve nothing" (YOLO mode) happens because the middle ground is too tedious.

The industry needs a third option that has not shipped yet:

• Runtime-scoped credentials that the agent can use for a session but that never persist to disk. Think aws sts assume-role with a 15-minute TTL, injected as an environment variable.
• Pattern-based approvals instead of literal-string persistence. "Allow psql connections to *.prod.internal" is a useful rule. "Allow PGPASSWORD=hunter2 psql -h prod.db.example.com" is a credential leak waiting to happen.
• Agent-aware secret scanning that understands the permission-persistence file format, not just grep patterns. Apiiro's finding that 19% of secrets evaded both Gitleaks and TruffleHog suggests the scanners have not caught up with this vector.
• Commit-time guardrails where the agent itself refuses to stage or commit files from its own config directories. If the agent is co-authoring the commit — as it was in 539 of Apiiro's cases — it should be the first line of defense, not another vector.

GitGuardian's framing is right: credentials and permissions define the blast radius of any agent compromise. The Apiiro research quantified what that blast radius looks like when the permission model itself is the leak vector. The fix is not better prompts or more careful developers. It is a permission architecture that never writes a secret to disk in the first place.

For more on how the agent security landscape is evolving, see our coverage of sandbox architectures for untrusted agent code and who actually audits the agent.

Originally published at AgentConn