If your developers, or your operations people who build automations on the side, are using Claude Code, Cursor, or GitHub Copilot, how many live API keys have those tools already put somewhere they should not be? Most leaders cannot answer that, and the 2026 research suggests the number is not zero.
AI coding assistant secrets leaks are real and measurable. GitGuardian found that Claude Code-assisted commits on public GitHub leaked secrets at 3.2 percent, roughly twice the 1.5 percent baseline across all public commits. The fix is not banning the tools. It is short-lived credentials, a secrets manager, and habits that keep keys out of prompts and config files.
GitGuardian's State of Secrets Sprawl 2026, published in March 2026, counted 28.65 million new hardcoded secrets added to public GitHub commits in 2025, a 34 percent increase over the prior year and the largest single-year jump the firm has recorded. Secrets for AI services specifically reached about 1.28 million, up 81 percent.
The headline number for this article is the comparison. Claude Code-assisted commits showed a 3.2 percent secret-leak rate, versus a 1.5 percent baseline across all public GitHub commits. Note what the baseline is: every public commit, not human-only commits, so it already includes some AI-assisted work. The report also found 24,008 unique secrets in MCP-related configuration files, the files that connect AI assistants to databases and cloud services, of which 2,117 were confirmed valid.
GitGuardian adds a caveat that matters for how you respond. It says the gap should not be read as a simple tool failure, because developers still decide what gets accepted, edited, or pushed. In its words, the leak still happens through a human workflow.
The instinctive response to a number like this is to buy or switch on a secrets scanner. Scanning is worth doing, but it treats the symptom. The same GitGuardian report found that when it retested credentials confirmed valid in 2022, more than 64 percent were still valid in January 2026. Detection is not the bottleneck. Rotation is. A leaked key that still works years later is a standing invitation, regardless of how quickly someone noticed it.
The report also shows how much of the problem sits outside public code. Internal repositories were roughly six times more likely than public ones to contain hardcoded secrets, and about 28 percent of incidents originated entirely outside repositories, in tools like Slack, Jira, and Confluence. A scanner pointed at public GitHub sees the visible edge. The durable fix is credentials that expire on their own and a workflow where keys never reach a prompt, a chat thread, or a config file in the first place.
AI coding assistants raise leak rates for two reasons: they speed up a workflow whose review steps were built for human pacing, and the tools themselves run with broad trust on developer machines. The second reason has produced real vulnerabilities. In February 2026, Check Point Research disclosed critical Claude Code flaws, assigned CVE-2025-59536 and CVE-2026-21852, that allowed remote code execution and API key theft through malicious repository configuration files, triggered simply by cloning and opening an untrusted project. Anthropic resolved the reported issues before public disclosure.
Cursor had a related problem. Infosecurity Magazine reported in April 2026 that LayerX researchers found Cursor stored API keys and session tokens in a local database any installed extension could read, with no special permissions required. The flaw was rated CVSS 8.2, and Cursor reportedly said defining trust boundaries was the user's responsibility. Whatever the current status, the lesson holds: a coding assistant inherits whatever trust you give its extensions and configuration files.
That is why extension and plugin approval belongs in your security process, a point we covered in asking whether that AI plugin was ever scanned before you installed it. The MCP configuration finding above is the same issue from another angle; our guide to what to ask AI vendors about MCP governance covers the connector side.
It reaches the companies with the most reason to get it right. In November 2025, Wiz examined the Forbes AI 50 and found that 65 percent of the companies analyzed had verified secret leaks on GitHub, with the affected companies valued at more than $400 billion combined. Examples included a Hugging Face token in a deleted fork that allowed access to about 1,000 private models, Weights and Biases API keys that exposed training data for private models, and an enterprise-tier ElevenLabs API key sitting in plaintext in an MCP configuration file.
None of these were obscure startups caught off guard. Their core product is AI, and several of the exposed credentials sat in places standard scans never check, such as deleted forks, gists, and personal developer repositories. If organizations with that much at stake miss these exposures, a mid-market company adopting the same tools without a dedicated security team should assume it has some too.
The deleted-fork example is the one to remember. Teams assume that removing a file or a repository removes the secret. It does not, if the history or a fork is still reachable. The only reliable cleanup for an exposed key is revoking and rotating it.
You do not need an engineering department for this to apply. AI coding assistants now build internal automations, spreadsheet scripts, website edits, and small integrations, often by whoever on staff is comfortable prompting. Those projects rarely get a security review, which makes them a new form of shadow IT, and the person building them may not know that a key pasted into a chat window can end up stored, logged, or committed somewhere unintended.
A marketing coordinator who asks an assistant to pull data from a billing platform needs the same credential habits as a software engineer. The job title does not change what happens when a live key lands in a prompt or a shared document. It only changes how likely anyone is to notice. Our never-paste list for general AI tools is a good starting point for that conversation.
You stop most of it by changing where credentials live and how long they last. A secrets manager with short-lived, scoped credentials means a leaked key expires before it is useful, and it gives the assistant a reference to call rather than a value to copy. That is the same principle behind using a password manager for people, applied to machines.
| Risky habit | Safer habit |
|---|---|
| Pasting a live API key into a prompt to debug an error | Redacting the key, or rotating it immediately if it was shared |
| Putting keys directly in MCP or project config files | Referencing a secrets manager or environment injection at runtime |
| Installing a coding extension because a teammate recommended it | Checking the publisher and permissions against an approved list |
| Opening an unfamiliar repository in an AI coding tool | Treating untrusted projects as untrusted, and keeping tools patched |
| Deleting a file that contained a key and moving on | Revoking and rotating the key, because history and forks persist |
Put one person in charge of the approved list of AI coding tools and extensions, and revisit it on a fixed schedule. Run secret scanning on internal repositories and collaboration tools, not only public code. Pair both with a short, recurring refresher for anyone who writes code or builds automations with AI, because the next vulnerability is unlikely to arrive with enough warning to prepare after the fact. Access reviews tie it together, which is why we treat this as part of cleaning up IAM and privileged access rather than a separate project.
Revoke the key first and investigate second. The instinct is to delete the commit or the message and hope nobody saw it, but automated tools watch public repositories continuously, and Wiz's deleted-fork finding shows that removal does not guarantee the secret is gone. Once the key is revoked, issue a replacement through your secrets manager, update the systems that depended on it, and then review the provider's logs for any use of the old key between exposure and revocation.
Write that sequence down before you need it. A one-page runbook that names who can revoke which keys, where the provider logs live, and who must be told turns a stressful incident into a fifteen-minute task. Without it, the person who discovers the leak is often the one least able to fix it, and the key stays live while people look for the right administrator.
When we assess a client's AI coding exposure, we start with inventory: which assistants and extensions are installed, which repositories and automations they touch, and where credentials currently live. Then we move the keys that matter into a managed vault with rotation, scan internal repositories and collaboration tools for what has already leaked, and revoke anything exposed.
From a platform standpoint, the goal is that an AI assistant never holds a long-lived secret it could leak. Combined with an approved-tools list and basic training for the people using these tools, that turns a measurable leak rate into a manageable one. A structured AI readiness assessment is a quick way to see where your team stands today.
The 2x finding is a warning about workflow, not a verdict on AI coding tools. Find out where your keys live, make them short-lived, and give everyone who codes with AI the same few habits before the next leak is yours.
If your team is moving faster with AI than your guardrails are, start with structured training rather than another tool. AI University gives your people role-based AI training with security built into the material, not bolted on afterward.
If you would rather talk through your specific environment first, book a strategy call with Securafy and we will walk your current AI usage, exposure, and the fastest path to safe adoption.