There is a version of secret-scanning that most security teams are quietly comfortable with. You wire a scanner into your repos, you add one to your CI pipeline, you catch the occasional AWS key someone pasted into a config, and you move on. That coverage felt complete for years because, for years, credentials mostly lived in two places: source code and pipeline configuration.
That assumption no longer holds. In September 2026, GitGuardian published research showing that AI coding agents — Cursor, Claude Code, GitHub Copilot — scatter AWS tokens, API keys, and other credentials across places your scanners were never pointed at. Config files you never audit. Environment variables the agent sets on its own. Logs. Shell history. Temp files that outlive the session that created them.
None of this is malicious. The agents are doing exactly what they were built to do. But the net effect is a new identity attack surface sitting on every developer laptop running an agent, and most of it is invisible to the tooling you already trust. Let’s walk through what the research actually found, why your current scanners miss it, and what you can do about it without slowing your developers down.
AI Coding Agents Are the New Credential Attack Surface
Start with a simple shift in where credentials live. A traditional developer workflow keeps secrets reasonably contained. You might have a .env file, maybe something in ~/.aws/credentials, and your discipline (plus a pre-commit hook) keeps those out of the repo. The surface area is small and well understood.
An AI coding agent changes the shape of that surface entirely. The agent is a long-running process on the machine that reads files, runs commands, sets environment variables, writes logs, and persists state between sessions. To be useful, it needs to understand your environment, and to act, it needs credentials. The moment you hand an agent the ability to deploy a change, query a database, or fix an IAM policy, you have introduced a non-human identity that holds keys and leaves traces of them in ways a human developer never would.
The important mental model: the agent is not just writing code, it is operating your environment. That makes every place the agent touches a candidate location for a leaked credential. And agents touch a lot of places.
What the Research Found: Where Credentials Actually End Up
The core contribution of the GitGuardian work is mapping where credentials land once agents are in the loop. Content was rephrased for compliance with licensing restrictions, but the pattern is consistent across the tools they examined.
Config files you don’t audit
Agents read and write configuration aggressively. They drop settings into project-local config, user-level dotfiles, and tool-specific directories. Credentials get cached in agent config so the tool does not have to re-authenticate every session. These are not the .env files your pre-commit hook watches — they are agent-specific paths that were never on anyone’s scanning list.
Environment variables set by the agent
To run a command or a build, an agent frequently exports credentials into the environment first. That is convenient and completely standard. It also means a live, usable credential is sitting in the process environment, and anything that dumps the environment — a crash handler, a diagnostic script, a verbose log — captures it.
Logs
This is one of the quieter findings and one of the most dangerous. Agents log what they do, and what they do includes running commands with credentials in them. A command line that embeds a token, a debug trace that echoes a request header, an error message that includes the full request — all of it can land in a log file in plaintext. Logs are rarely treated as sensitive, they get copied around, attached to bug reports, and shipped to centralized logging without a second thought.
Shell history
When an agent runs commands through a shell, those commands can be written to shell history. A token passed as a command-line argument becomes a permanent, plaintext entry in ~/.zsh_history or ~/.bash_history. Shell history is almost never scanned, almost never rotated, and often synced across machines through dotfile repos — which can quietly carry a live key back into a Git repository after all.
Temp files
Agents stage work in temporary files, and those files do not always get cleaned up. A temp file holding a credential can sit on disk long after the task that created it finished, invisible to everyone, waiting for a backup, a sync, or an attacker who already has a foothold on the machine.
The through-line is that credentials are no longer concentrated in one or two well-known files. They are smeared across the filesystem, the process environment, and the shell — exactly the places your scanning strategy assumes are empty.
Why Traditional Scanners Miss This Entirely
If this feels like it should have been caught already, you are not wrong to ask. The reason it slips through is structural, not a matter of effort.
Repository scanners look at what is committed to Git. That is their whole job, and they do it well. But a credential in ~/.zsh_history, in an agent’s cache directory, or in a temp file under /tmp was never committed to anything. It lives on a laptop, outside the repository boundary entirely. The scanner has nothing to scan because the secret never entered the repo.
CI/CD scanners have the same blind spot from a different angle. They inspect the build environment and the pipeline — the code and config that flow through CI. They do not reach back onto a developer’s workstation to inspect that machine’s shell history, its agent logs, or its environment variables. The leak happens on the endpoint, and CI never sees the endpoint.
So you end up with a coverage gap that looks like full coverage. Your dashboards are green. Your repo scans are clean. Your pipeline is enforcing policy. And meanwhile, live AWS tokens are sitting in plaintext in half a dozen locations on every machine running an agent, none of which any of your scanners are designed to look at. The tooling is not broken. It is just pointed at the wrong surface, because the surface moved.
The Real Risk: What Happens When These Credentials Leak
It is worth being precise about why this matters, because “credentials in logs” can sound abstract until you trace the consequence.
The first problem is blast radius. The credentials agents hold are usually scoped to a developer’s full access, not to the narrow task at hand. An agent given long-lived AWS keys to fix one S3 bucket policy is holding keys that can touch everything those keys allow. When one of those keys leaks from a log or a temp file, the attacker inherits the full scope, not the small task.
The second problem is persistence. These are typically long-lived credentials. A key written to shell history in March is still a valid key in September. There is no natural expiry, so the window of exposure is open-ended. Every stale credential sitting in a log is a standing invitation that does not close on its own.
The third problem is invisibility and attribution. Because the leak happens off-repo and off-pipeline, you may have no signal that it occurred. And when a leaked agent credential is used, the activity is attributed to the developer’s identity. Untangling the human’s legitimate actions from the agent’s from an attacker’s — after the fact, with muddy logs — is exactly the kind of forensics nobody wants to do during an incident.
Put those together and the risk is clear: a broad-scope, long-lived, hard-to-attribute credential leaking into locations nobody is watching. That is close to a worst case for identity security, and agent adoption is multiplying the number of machines where it can happen.
What Security Teams Should Do Right Now
You do not need to ban agents to get ahead of this. The productivity gains are real and your developers are not giving them up. The goal is to shrink the surface and shorten the exposure window. Here is a practical sequence.
Expand where you scan
Point secret scanning at the places credentials actually land now, not just the repo. That means local scanning that covers agent config directories, shell history files, and common temp locations on developer machines. Treat the endpoint as in-scope. If a scanner only reads your Git history, you have mapped a small part of the territory.
Treat logs as sensitive by default
Assume agent logs and command output can contain credentials, because they do. Redact tokens at the logging layer, restrict who can read raw logs, and set aggressive retention limits. A log that is deleted after a short window cannot leak a key six months later.
Audit what credentials your agents actually hold
Inventory every long-lived key sitting in a developer environment for agent use. For each one, ask whether it needs to be standing at all. Most do not. This audit alone usually surfaces more broad-scope keys than teams expect.
Stop passing secrets as command-line arguments
Command-line arguments are the fastest path into shell history and logs. Prefer short-lived environment injection or a credential broker over anything that puts a token on a command line.
Shorten credential lifetime wherever you can
The single highest-leverage change is reducing how long any credential is valid. A key that expires in minutes is nearly worthless to an attacker who finds it in a stale log, because by the time they do, it no longer works. This is the principle behind just-in-time access, and it is where the structural fix lives. We have written more on the broader identity angle across the Cloudanix blog if you want the surrounding context.
How JIT for AI Agents Changes the Equation
Every mitigation above helps, but notice that most of them are about cleaning up after a credential that should not have existed in that form in the first place. You scan for leaked keys, you redact logs that captured keys, you audit standing keys. The deeper fix is to make sure there is no long-lived, broadly-scoped key for the agent to leak at all.
That is the core idea behind just-in-time access for AI coding agents. Instead of handing an agent a standing credential that sits in .envrc, in shell history, and in a config cache, you flip the model: the agent requests access at the moment it needs it, gets a tightly scoped credential for a short window, and that credential expires on its own.
Here is how Cloudanix Coding Agent JIT implements it in practice. The agent — whether it is Claude Code, Cursor, or Kiro — calls an MCP broker when it needs to act on cloud resources. The broker mints a short-lived, scoped credential, typically valid for around 15 minutes, and the role detaches automatically when the window closes. There are no standing keys to steal. Nothing lands in .envrc. Nothing gets written to shell history as a permanent entry, because there is no long-lived token to write. And because sensitive grants can route through a human-in-the-loop approval step in Slack, a person stays in control of what the agent is allowed to reach.
Walk that back through the risks from earlier. Blast radius shrinks because the credential is scoped to the task, not the developer’s full access. Persistence disappears because the credential auto-revokes in minutes — a token leaked into a log is dead long before anyone finds it. Attribution improves because each access is brokered, scoped, and tied to a specific request rather than a shared standing key. The leak surface does not just get smaller; for the standing-credential case, it largely stops existing.
This is the same pattern Cloudanix applies across the rest of its access model, so it fits an existing strategy rather than bolting on a one-off. If your teams need human access to infrastructure, Cloud JIT applies the same short-lived, scoped, approval-gated approach to cloud consoles and roles. For data access, Database JIT does it for database credentials. And all of it reports into the broader CNAPP+ platform, so agent access, human access, posture, and identity live in one correlated view instead of scattered across disconnected tools.
Looking Ahead: Building an AI-Agent Credential Strategy
The GitGuardian research is best read not as a scare story but as an early map of a surface that is only going to grow. Agent adoption is accelerating, agents are being granted more capability, and every new agent on a new machine is another instance of the same exposure. A strategy built around “scan the repo and hope” will fall further behind as that happens.
A durable strategy treats AI coding agents as first-class non-human identities and plans accordingly. That means knowing which agents run in your environment and what they can reach. It means defaulting to short-lived, scoped credentials for anything an agent does against real infrastructure, so there is nothing standing to leak. It means extending your detection beyond the repo to the endpoints where agents actually operate — the configs, the logs, the shell history, the temp files. And it means keeping a human in the loop for the access that genuinely warrants one, without turning every routine action into a ticket.
Do that, and the picture inverts. The agent stops being a scattering of long-lived keys across a filesystem you cannot fully see, and becomes an identity that asks for exactly what it needs, exactly when it needs it, and gives it back automatically. The leak surface the research describes mostly evaporates, not because you scanned harder, but because the thing worth stealing stopped sitting around.
Get Started
If your developers are already running Cursor, Claude Code, or Kiro against real cloud resources, the standing-credential problem is already on your machines, whether or not it has shown up in a scan yet. The fastest way to close it is to stop issuing long-lived keys to agents in the first place. See how JIT access for AI coding agents works, or go straight to the Coding Agent JIT product page to see the MCP-brokered, auto-revoking model in action. No standing keys, no secrets in shell history, and a human in the loop where it counts.
