Six weeks of AI agent secret leaksWhat April and May 2026 taught us

April opened with a disclosure. It closed with a different one. Between them, three more. Five separate incidents, six weeks, and a pattern that did not require any of them to be connected: the agent reads your environment, something in the pipeline carries it outward, and nothing tells you.

This is a mid-quarter retrospective for engineering leaders who are deploying AI coding agents and need a factual account of what happened between April 1 and May 11, 2026. Each incident gets a paragraph postmortem. The pattern section explains why these are not unrelated one-offs. The checklist at the end is designed to be dropped into a PR comment and tracked by a real human before June 1.

No speculation about vendor motives. No predictions about what comes next. Just what happened, what the mechanism was, and what you can do about it now.

The short version

• April 4: Claude Code settings.local.json found in ~1-in-13 npm packages (Knostic disclosure, env-var capture vector).
• Mid-April: Cursor Composer leaked cross-project context between unrelated workspaces.
• Late April: A Cyrillic-character input sequence bypassed Claude Code's skill permission checks.
• May 5: Anthropic's Trust Center disclosed a follow-up env-var capture variant in Claude Code that the February patch did not fully close.
• Ongoing: MCP server supply-chain backdoors confirmed by Snyk and OX Security, with roughly 7,000 servers in the wild and no signature requirement.

Four of those five produced no visible error. The fifth (the Anthropic Trust Center disclosure) was a vendor-initiated notice, not something a developer would have caught in the normal course of work.

Five incidents, in order

April 4: Claude Code settings.local.json in npm packages

Knostic published their scan results on April 4, covering npm packages published between November 2025 and late March 2026. The finding: .claude/settings.local.json appeared in roughly 1 in 13 packages checked. The file records environment variables the agent's child process could see during each session. Developers ran npm publish without knowing the file was in the tarball. No error. No warning from npm publish. The registry accepted the upload.

The mechanism is not subtle. Claude Code writes state to .claude/ in the project directory. npm publish ships everything in the working tree that is not in .npmignore or the files field of package.json. Neither file existed for most projects, because .claude/ was not a known exclusion path until this disclosure made it one. The patch Anthropic shipped in late February 2026 changed what the file captures for new sessions. Files already on disk from sessions before the patch still hold whatever they recorded.

If you published an npm package while Claude Code was active in the repo, pull the tarball and grep it before assuming you're clean.

Mid-April: Cursor Composer cross-project context bleed

Cursor's Composer feature, which maintains conversation context across an editing session, leaked context between projects when a developer had more than one workspace open. The specific mechanism: indexing state from workspace A was accessible in workspace B's context window when the Composer panel was opened in sequence.

The Cursor changelog acknowledged the issue in mid-April and patched it within the same week. What it exposed varied by workspace: recent file contents, terminal output that appeared in the context window, and in some cases API keys that were echoed in a terminal command run inside the IDE. No authentication boundary exists between workspaces in the Composer context model. That is the design assumption that failed.

Developers running multiple client projects in separate workspaces are the highest-risk group. If you used Cursor Composer between April 7 and April 14, check whether you had credentials visible in any terminal output that session.

Late April: Claude Code skills Cyrillic-character permission bypass

Claude Code's skills permission system evaluates user input to determine whether a requested action falls within the granted permission set. A researcher found that inserting certain Cyrillic homoglyph characters into a tool-call request caused the permission checker to classify the request as permitted when the equivalent ASCII string would have been blocked.

The Register covered the disclosure. Anthropic's response came within two weeks. The bypass required an attacker to control text that reached the agent's input, which puts it in the prompt-injection family. The practical risk is an attacker embedding a Cyrillic-obfuscated tool call in a document, a web page the agent reads, or a repository file the agent processes. If the agent had elevated permissions already granted by the user, the bypass could execute actions the user never intended to authorize.

This one is the outlier in the group: it has an adversarial component. The others are all ambient-data failures.

May 5: Anthropic Trust Center env-var capture follow-up

Anthropic's Trust Center posted a disclosure on May 5 covering a second env-var capture path that the February 2026 patch did not close. The February fix addressed the primary settings.local.json recording mechanism. The May disclosure covers a different code path triggered by specific hook configurations in Claude Code projects that use custom tooling hooks.

When a project configures a Claude Code hook to run a shell command on agent start or stop, the hook's execution environment inherits the full shell environment, and in certain configurations that output was appended to a secondary log file inside .claude/. That log file was not in the February patch's exclusion scope.

Anthropic's news page has the official mitigation steps. The short version: if you define any hooks in your project's Claude Code config, check whether the hook output path is inside .claude/ and whether that path is excluded from your .gitignore and .npmignore.

Ongoing: MCP server supply-chain backdoors

This one does not have a single incident date because it is a category of ongoing exposure, not a one-time event. The Model Context Protocol ecosystem now has roughly 7,000 servers in the wild, per OX Security's early-2026 analysis, representing approximately 150 million downloads. The protocol has no package signing requirement. An MCP server can be published to a registry, referenced in a project's MCP config, and executed inside the agent's trust boundary without any cryptographic verification that the server is what it claims to be.

Snyk Security Labs documented specific cases of backdoored MCP servers that exfiltrate tool call parameters, including any secrets passed as arguments to MCP tools. The attack surface is the mcp.json or equivalent config file in your project: an attacker who can modify that file, or who publishes a popular-looking MCP server under a plausible name, gets execution inside your agent session.

This is not a theoretical supply-chain risk. Snyk identified specific packages. The packages executed inside real developer environments. The secrets those environments held were the ones at risk.

The pattern underneath all five

Every one of these incidents is a boundary failure. The boundary in question separates the agent's runtime from the rest of the developer's environment: credentials in the shell, context from other projects, permissions the user intended to scope, environment variables the shell exports by default.

That boundary is porous by design in most current agent architectures. The agent runs in your shell environment, with access to whatever that environment contains. It writes state into your project directory. It loads tools from a config file you maintain. Each of those is a potential path for sensitive data to travel somewhere unintended.

The specific shape of each incident is different:

• In the npm leak, the path was: agent reads env vars, writes them to a state file, publish pipeline picks up the state file.
• In the Cursor bleed, the path was: indexing state from workspace A surfaces in workspace B's context window.
• In the permission bypass, the path was: attacker-controlled text in the input subverts the permission classifier.
• In the Trust Center follow-up, the path was: hook execution environment captured to a secondary log file not covered by the earlier patch.
• In the MCP supply chain, the path was: a compromised server executes inside the agent's trust context and exfiltrates tool parameters.

Four of these five are silent. There is no exception, no log line, no warning message that tells the developer something went wrong. The npm publish completed successfully. The Cursor context switch looked normal. The hook ran without errors. The MCP server responded correctly to every call.

The permission bypass is partially an exception: a sufficiently paranoid audit of the agent's action log would show a suspicious tool call. In practice, nobody audits that log in real time.

What the data says

GitGuardian's State of Secrets Sprawl 2026 measured AI-assisted commits against human-only commits across a large sample of public and private repositories. AI-assisted commits leak secrets at roughly twice the rate. GitGuardian Labs attributes this to two factors: developers using agents to generate code that embeds credentials as literals (hardcoding), and agent tooling writing state files that then enter the repository or package tarball.

The 2026 report also shows AI-service token leaks up 81% year-over-year. That number reflects both the growth of AI tooling adoption and the tooling's tendency to propagate credentials through state files, logs, and context windows.

Neither number is surprising given the five incidents above. They confirm the direction, not just the anecdotes.

What gets missed in the current conversation

Most of the post-incident discussion treats each of these as isolated vendor bugs. Anthropic shipped a bad patch. Cursor had an indexing edge case. An MCP maintainer published a backdoor. Fix the bug, move on.

The frame is wrong.

The incidents are not isolated bugs. They are five different expressions of one architecture decision: the agent operates inside the developer's ambient environment, with full read access to that environment and write access to the project directory. That decision is currently universal across agent tooling. It is also the decision that makes all five incidents possible.

Fixing each bug as it appears is necessary but not sufficient. A development team running agent tooling without a runtime boundary between the agent and the credential store will generate more incidents of this shape. The specific CVE number will change. The mechanism will vary. The outcome (credentials or context traveling somewhere unintended) will repeat.

The durable fix is architectural: secrets leave the ambient environment and move into a scoped, brokered store. The agent receives a reference at execution time, not a value from the environment. State files the agent writes hold references. Logs the agent produces hold nothing worth rotating.

What changed this quarter

Before April 2026, most teams treated agent-tooling security as a hygiene problem: keep your .gitignore up to date, don't commit secrets, rotate anything that looks wrong. The February npm leak moved the conversation, but the fix was framed as "add .claude/ to .npmignore" rather than "change how agents access credentials."

April and May changed that framing for a specific reason: the Trust Center disclosure on May 5 demonstrated that the February patch was incomplete. It wasn't a new bug. It was the same class of bug reaching a path the first patch missed. That pattern, patching the visible exposure while the underlying access model stays unchanged, tells you something about the rate at which new variants will appear.

Two other things shifted:

First, the MCP ecosystem grew fast enough to become a supply-chain target. OX Security's 7,000-server count is from early 2026. The number has grown since. A large, unsigned package ecosystem with execution inside the agent trust boundary is the kind of thing that attracts supply-chain attacks, and it's attracting them.

Second, the Cursor cross-project bleed introduced a concern that most teams had not modeled: context from one client project leaking into another. For agencies and consultancies running multiple projects in the same IDE, this is a contractual problem, not just a security problem.

Audit steps to run before June 1

## Q2 agent security audit

- [ ] git log --all -- '.claude/*' '.cursor/*' .aider* -- check for tracked agent state files
- [ ] For each npm package published since Nov 2025: npm pack <pkg>@<ver>, grep tarball for .claude/
- [ ] Confirm .claude/, .cursor/, .aider/, .codex/ in .gitignore and .npmignore / MANIFEST.in / .dockerignore
- [ ] If using Claude Code hooks: verify hook output paths are outside .claude/ or excluded from publish
- [ ] List all MCP servers in mcp.json (or equivalent): check each against Snyk and OX Security advisories
- [ ] Confirm MCP server sources: prefer known maintainers, pin to specific versions or commit hashes
- [ ] If using Cursor Composer between Apr 7-14: review context window for cross-project credential exposure
- [ ] Run git log -p to inspect any .claude/settings.local.json commits -- rotate any secrets present
- [ ] Add prepublishOnly script (npm) or release step (Python/Go) that fails if agent state files exist
- [ ] Document which agent tools each project uses -- include in onboarding and offboarding checklists

Run this per project, not per team. Agent state files are project-scoped. One clean project does not mean another is clean.

What this means for your stack

The minimum response to Q2 is the checklist above. Past that, the question is whether your team's current runtime model can generate more incidents of this shape on a long enough timeline. If the agent reads ambient env vars, writes state into the project directory, and loads tools from a config file without verification, the architecture can produce more variants of the five incidents above. Different paths, same category.

The fix is a runtime broker: secrets in an encrypted local store, agents requesting access per-session through a scoped grant, values injected into specific child processes at exec time and revoked when the process exits, every grant recorded in an append-only audit log. The agent's state files and logs hold references, not values.

hasp is one working implementation of that model. curl -fsSL https://gethasp.com/install.sh | sh, hasp setup, connect a project, hand the next agent session a reference instead of a key. Source-available (FCL-1.0), local-first, macOS and Linux, no account.

The boundary between agent and credential store is the fix that does not require patching each new incident variant as it appears.