The industry keeps framing leaked credentials in the age of AI as a coding-agent behavior problem: the agent was careless, so tighten the agent. That framing is comfortable and wrong. The real issue is that autonomous systems are non-human identities with real access, and almost nobody governs them like it. AI coding agents did not create secrets sprawl. They took a slow, survivable problem and compressed it to machine speed.
We break agents and the identity plumbing around them for a living, so we want to be precise about what actually changed and where the exposure really sits. The numbers are blunt. Per GitGuardian’s 2026 State of Secrets Sprawl report, AI-assisted commits leak secrets at roughly twice the rate of human-written code. Per Keeper Security’s RSAC 2026 survey, 46% of respondents said AI-powered tools have access to critical systems and sensitive data, and 76% said those identities lack consistent governance under privileged access policies. Read those two together: most organizations have handed autonomous systems real access, and most of that access is ungoverned.
Why the agent is the accelerant, not the cause
A coding agent can read an entire project, modify files, generate configuration, and talk to external services in the time a developer spends reviewing a single pull request. That speed is the whole shift. A credential that a human might have fumbled once a month, an agent fumbles across a hundred files in an afternoon. But the leak was always possible. The agent just industrializes it.
From an offensive standpoint, the exposure vectors are exactly the ones we walk through on an assessment, and none of them are new. What is new is the volume:
- Developer environment access. The agent reads the
.envfiles and local configs a developer left behind, and those secrets ride along into wherever the agent operates next. - Configuration files with hardcoded credentials. Setup files for agents and MCP servers routinely carry plaintext keys, and those files rarely get the scrutiny application code does.
- Credential duplication. The same secret lives in the repo, in CI/CD, in a Jira ticket, in a workstation config. Scanning the repository alone misses most of the copies.
- Over-permissioning. The agent gets broad access during prototyping to make things work, and that access silently persists into production.
Every one of those is a credential-exposure path we test for directly. The MCP-server config leaking a plaintext key, the over-scoped token that survives from prototype to prod, the secret duplicated into a ticketing system: these are findings, and finding them before an attacker does is exactly what an AI agent penetration test and a secure code review are for. The MCP tool-chain specifically is its own attack surface, which is why we test it as one under MCP server and tool-chain security testing.
The reframe that actually helps: govern the identity, not the behavior
Here is the sentence worth pinning up: you cannot reliably predict every action an autonomous system will take, but you can control what the identity behind that system is allowed to access. That is the whole game. Trying to constrain agent behavior is a losing race against a non-deterministic system. Constraining what its identity can reach is a solved discipline, you just have to apply it to machine identities the way you already do to humans.
Concretely, that means:
- Centralized secrets management. Agents retrieve secrets from a platform at runtime instead of reading them from
.envfiles or configs. The secret never sits at rest in a place the agent can leak. - Short-lived, auto-rotating credentials. Replace static keys valid for months with credentials that expire in minutes. A leaked secret that is already dead is not an incident.
- Scoped agent identities. Each agent gets its own identity with its own narrow permissions, treated like a contractor with a defined access window, not a shared god-key.
- Human approval loops on credential access, production deploys, and privilege changes.
- An agent inventory: which agents run in your environment, who owns them, what identity each carries, and what it is authorized to touch.
- Comprehensive logging of every agent action against its machine identity, because after an incident the audit trail is all you have.
This is identity engineering, and it is where the abstract advice becomes a concrete testable posture. Whether your agents authenticate through OAuth, OIDC, or SAML, the token issuance, scoping, and validation are exactly the surfaces we probe in OAuth, OIDC and SAML SSO security testing. The over-permissioned machine identity that reaches production is a cloud-IAM finding, which is what a cloud configuration review surfaces. And whether your standing privileges and secret duplication actually hold up under an attacker who has one leaked key is the question a red team operation answers.
Where our own tooling sits on this
Two of the vectors above map directly onto products we built out of this exact problem. The secret that leaks and then gets used is a two-stage event, and each stage has a control.
On the outbound side, an agent with real credentials and network access can exfiltrate or misuse a secret on its own, without any attacker involved. Our firewall airlock_ai sits on that egress path and stops your own agent from leaking or acting on a credential it should never have touched. On the inbound side, when an attacker (human or their own agent) already holds a leaked key and comes to use it, BastionAgent turns that moment into a trap: it seeds dead, watermarked credentials exactly where an agent expects to find them, so the leaked-secret playbook walks into a cage of fabricated data and the use of the credential becomes the detection. Note the synergy with the advice above: short-lived and watermarked secrets are the same instinct, make a leaked credential either already dead or actively self-incriminating.
The takeaway
Secrets sprawl in the AI era is not the story of a careless agent. It is the story of non-human identities with standing access that nobody scoped, inventoried, or rotated, moving at a speed that turns a latent problem into an active one. You will not fix it by trying to make agents behave. You fix it by governing what their identities can reach, and by testing that governance the way an attacker would. Inventory the machine identities, scope them down, make the secrets short-lived, and then have someone prove the boundaries hold before someone else proves they do not.