In early October 2026, GitGuardian published research from its State of Secrets Sprawl work that should make every platform and security team pause: analysts found 24,008 unique secrets hardcoded in public Model Context Protocol (MCP) configuration files, of which 2,117 were valid, live credentials. A separate analysis of coding activity found a measurable leak rate in commits made with AI coding assistants. In parallel, other researchers reported that across tens of thousands of public MCP config files, roughly one in eight credential slots held a hardcoded secret anyone could read.
Primary sources: GitGuardian, TechTarget, and the structural analysis in Ars Technica.
If you are reading this as a CISO, a platform lead, or a security engineer, you already know what a live credential in a public file means. It means anyone on the internet can pick it up and use it, with the exact permissions you granted. What is new is where these credentials are leaking from, and why the usual advice — “store your secrets in a vault” — does not actually close the hole this time.
This post explains what MCP is, why AI coding agents have turned into a credential-leak engine, why vaulting alone does not solve it, and the control model that does. The problem is real, but it is also bounded and fixable. You do not need to ban AI coding tools or panic. You need to change one thing about how agents get access.
First, What Is MCP and Why Should You Care?
MCP, or Model Context Protocol, is the connective tissue that lets an AI coding agent talk to the outside world. When Claude Code, Cursor, Copilot, or Kiro needs to read a database, call a cloud API, hit an internal service, or query a SaaS tool, it does so through an MCP server. The MCP configuration file tells the agent how to connect to each of those systems — including, very often, the credentials to authenticate.
That last part is the problem. MCP config files have quietly become a place where developers paste API keys, database passwords, cloud access keys, and tokens so their agent “just works.” And because these files live in repositories, dotfiles, and example projects, a large number of them have ended up public — on GitHub, in shared templates, in documentation.
So the research findings are not describing an exotic exploit. They are describing a filing cabinet of live keys that got left on the sidewalk. The agents did their job. The humans configuring them did the natural, convenient thing. And convenience, as usual, won over safety until someone counted.
Why AI Coding Agents Made This So Much Worse
Teams have leaked secrets into code for as long as there has been code. So why is this moment different? Three reasons, and they compound.
1. Agents multiply the number of connection points. A traditional application has a handful of integrations, configured once by someone who thought about it. An AI coding agent is encouraged to connect to everything — your database, your cloud, your ticketing system, your observability stack — because that is what makes it useful. Every connection is another credential that has to live somewhere, and the path of least resistance is the config file.
2. The credentials are usually long-lived and broad. When a developer wires up an agent, they tend to give it a durable key with generous permissions, because scoping it tightly is extra work and a too-narrow key means the agent fails mid-task. So the typical agent credential is both powerful and permanent — the worst combination to leave in a file.
3. Agents generate and commit code fast. The whole point of a coding agent is velocity. More commits, more frequently, with less line-by-line human review. GitGuardian’s finding of a leak rate in AI-assisted commits is the direct consequence: when a machine is producing and committing code quickly, a hardcoded secret slips into history more easily and gets noticed later.
Put together: more credentials, each one more valuable, flowing through a faster pipeline with lighter review. That is why a problem that always existed just jumped an order of magnitude.
Why “Just Use a Secrets Vault” Does Not Fully Fix It
Here is the uncomfortable part, and we would rather be straight with you than hand you comforting advice that does not hold.
The standard response to leaked secrets is: “stop hardcoding them, put them in a secrets manager, and reference them at runtime.” That is good hygiene and you should do it. But it does not actually solve the agent problem, for a simple reason:
A vault changes where the credential is stored. It does not change the fact that the credential is long-lived and broadly scoped. The agent still ends up holding a durable, powerful key at runtime — and that key can still be extracted, logged, mishandled, or lifted out of memory.
A vault moves the key from a file into a slightly better drawer. The key still exists, still works forever, and still reaches far more than any single task requires. If an agent is manipulated through prompt injection, or a developer’s machine is compromised, or the credential is simply misused, the vault did not change the outcome — because at the moment of use, the agent was holding the same powerful, persistent key.
This is the core insight, and it is the one the industry is slowly arriving at: the problem is not where the credential is kept. The problem is that a durable credential exists at all.
The Fix: Just-in-Time Access for Agents
Cloudanix approaches this with Just-in-Time (JIT) access extended to AI coding agents and other non-human identities. The model inverts the default:
- The agent holds no standing credential. There is nothing in the config file, nothing in the vault that the agent carries around, nothing to leak.
- When the agent needs to act, it requests access for that specific moment.
- It receives a scoped, short-lived credential — good for the task at hand and nothing more.
- The credential auto-revokes after the task, usually in seconds.
Let us connect that directly to the research.
Coding Agent JIT via MCP: the credential never sits still
Cloudanix provides Coding Agent JIT through an MCP server. Instead of the config file holding a static key, the MCP server mints a scoped credential at request time, hands it to the agent for the task, and destroys it afterward — with a human-in-the-loop approval where you want one.
Now re-read the finding: “24,008 secrets hardcoded in MCP config files.” With Coding Agent JIT, there is no secret to hardcode. The config points the agent at the broker, not at a key. The thing that leaked by the thousands simply is not present. You cannot leak a credential that is minted for ten seconds and destroyed before the next commit.
Agentic JIT: the same model for pipelines and service agents
The same inversion applies to CI/CD pipelines, Lambda functions, service accounts, and autonomous agents through Agentic JIT. Register the identity once; from then on it elevates for the operation it needs via an SDK call and auto-revokes. No permanent pipeline secret, no standing service-account key.
Identity-stamped audit in your own storage
Every grant, approval, and revocation is logged with the real identity behind it, written to your own S3 bucket. When an auditor asks “who accessed this database and when,” or when you investigate an incident, the answer is already recorded. This replaces the uncomfortable truth most teams live with today: nobody can say with precision what their agents’ credentials have actually been used for.
Correlation with posture and entitlements
Because JIT runs on the same platform as Cloudanix CSPM and CIEM, an over-privileged or orphaned machine identity surfaced by posture analysis can feed straight into JIT policy. The system that detects “this agent credential reaches too much” is wired to the system that removes the standing access.
Being Honest About the Boundaries
We want you to deploy this with full understanding, so here is where the line sits.
What JIT genuinely eliminates: the standing credential. No durable key in a config file or a vault means nothing to find, nothing to lift, nothing that outlives its task. The specific thing GitGuardian counted — live secrets sitting in files — goes to zero for agents under JIT, because the model does not produce durable secrets in the first place.
What still needs ordinary hygiene: JIT governs the credentials your agents request through the broker. It does not retroactively clean secrets already committed to your git history, and it does not replace secret scanning on your repositories. You should still scan, still rotate anything already exposed, and still keep a vault for the credentials that genuinely must persist (and some will). JIT shrinks that set dramatically; it does not claim to make it empty.
What JIT does not do: it does not stop an AI agent from being tricked by a malicious prompt. What it does is make the trick far less rewarding — a manipulated agent holding a ten-second, single-task credential cannot pivot into your wider environment the way one holding a permanent admin key can.
We flag these boundaries on purpose. A control is only trustworthy when you know exactly what it covers. This one covers the part of the problem that the headline numbers are actually measuring.
A Rollout You Can Start Without Slowing Anyone Down
-
Scan for what has already leaked. Run secret detection across your repos and MCP configs. Rotate anything live immediately. This is triage, independent of JIT.
-
List your agents’ standing credentials. For every AI coding agent and pipeline, write down the keys it holds and what they reach. This inventory is usually eye-opening.
-
Move the highest-value credentials to JIT first. Database and cloud credentials that reach production are the priority. Replace the static key in the config with a broker reference.
-
Default to friction-free approvals for low-risk work. Auto-approve read-only requests and incident-driven access so developers feel no drag; reserve explicit approval for sensitive operations.
-
Confirm audit lands in your storage. Make sure every grant and revocation is queryable in a bucket you own.
Each step reduces exposure on its own, and none of them requires taking tools away from your engineers. That is the point: the goal is not to make AI coding agents harder to use. It is to make the credentials they use worthless to steal.
The Takeaway
The 24,000-secret finding is not a reason to distrust AI coding agents. It is a reason to distrust durable, broadly-scoped credentials — and to stop handing them to agents in the first place. Vaulting the key is better than hardcoding it, but the real answer is to not have a standing key at all.
When every agent requests access just in time, uses a credential scoped to its task, and gives it back seconds later, the config file has nothing worth stealing, the vault holds far less, and your audit trail finally answers the questions your auditors and your board are asking. You can keep moving fast with AI in your pipeline. You just need the credentials to move at the same speed — appearing when work happens and disappearing when it is done.
Want to see how many standing agent and pipeline credentials exist in your environment right now? Talk to us and we will map them with you, then show you how JIT takes them off the table.
People Also Read
- AI Coding Agents Are Leaking Credentials: What Security Teams Need to Know
- Why AI Coding Agents Become an Identity and Credential Risk
- One Prompt, Every Agent: What the AWS Bedrock AgentCore Flaw Means for Your Cloud
- Governing CI/CD Pipeline Credentials Without Standing Secrets
- What is IAM Just-In-Time (JIT) Access?
- Cloudanix: Coding Agent JIT
- Cloudanix: Agentic JIT
