Your AI Agents Are Using Your Credentials

Key findings

It's a secrets problem before it's an identity problem. Many AI agents don't have their own distinct identity, so they operate using API keys, tokens, and other credentials issued to humans or workloads.
Those credentials can sit outside agent-specific identity controls. When no enterprise IdP mediates the exchange, agent activity can create a governance blind spot that standard identity reviews may not expose.
Discovery and attribution come first. Find where agent credentials actually live and identify the human or workload that owns them.
Prevention has to run alongside cleanup. Block new secret exposure while you migrate credentials already in use.
The end state is scoped, short-lived access. Replace standing, reusable credentials with agent-specific or delegated identities backed by scoped, short-lived credentials that limit the value of anything stolen.

Every conversation with security leadership lands on the same question sooner or later: all our developers and citizen developers use AI agents now, so how do we govern what those agents can reach? The instinct is to treat this as an identity problem and reach for the identity stack, because that's where governance lives.

The instinct rests on an assumption worth poking at: that your agents have identities you can govern. Many agents running in enterprises today don't. They borrow existing human or workload identities through credentials no identity system mediates.

The agent identity spectrum has two well-lit ends

Agent identity runs on a spectrum. At one end sits the human-controlled session. An employee drives the agent through single sign-on, watches what it does, and stays accountable for the outcome, the same way they're accountable for anything else done under their login. Your identity provider (IdP) owns this end, and access is issued and revoked where everything else already is.

At the other end sits the system service account: a single-purpose, least-privilege identity that does exactly one job, running in a sandboxed environment with an egress allowlist. The design goal for this end is an environment that holds nothing worth stealing: no static credential on disk, and nothing reusable for a compromised agent to exfiltrate.

Between them can sit secure delegated identity, where both the user and the agent retain distinct, auditable identities and access is granted through scoped, short-lived tokens.

All three models are governable. The emerging playbook says deploy in one of them and stay there. Authentication is the control that defines what an agent can reach, how long it can keep reaching it, and how quickly a team can shut it down when something goes wrong.

How the agent gray zone fills up

Beside those governable models sits the agent that carries a reusable credential issued to a person or workload into systems that person isn't watching. No agent-specific identity is attached. Accountability there is ambiguous, and the standard guidance treats this gray zone as a place to avoid. That works when you're choosing where new, sanctioned agents will live. The problem is that the gray zone isn't populated by deployment decisions alone. It fills up on its own.

That gap widens as agentic tooling moves beyond traditionally trained software teams. Citizen developers can now build workflows, connect applications, and deploy MCP servers without the security background, development practices, or tooling that established software teams are more likely to have in place. A developer may recognize that an API key should not live in a configuration file. A business user wiring up their first Zapier workflow or MCP server may not know what a .env file is, let alone that credential harvesters know to look for one. They are being given the ability to create software and connect sensitive systems before they have been given the practices needed to secure them.

The mechanism is mundane. An agent is only useful with access, and many of the systems it needs, from internal APIs to databases to older SaaS tools, rely on one practical access mechanism: a static credential. So a developer pastes a personal access token into a Model Context Protocol (MCP) server config. An API key lands in a .env file. The agent now authenticates as the credential's owner, in systems no human is watching, with credentials that rarely expire.

The path isn't always a paste. AI coding tools routinely pull credentials from a developer's password manager at runtime and write them into session logs or cache directories, locations no repository scanner will ever see.

The scale is measurable. Gartner predicts that by 2028, an average global Fortune 500 enterprise will have more than 150,000 agents in use, up from fewer than 15 in 2025. Each of those agents needs credentials to reach anything. GitGuardian found 24,008 unique secrets in public MCP config files in 2025. AI-service credential leaks grew 81% year over year, with 1.27 million exposed in 2025. Claude Code co-authored commits leaked secrets at roughly twice the public GitHub baseline in GitGuardian's 2025 dataset. One over-permissioned agent can turn a single credential into reach across an entire environment. These credentials don't age out, either. Of the credentials confirmed valid in 2022, more than 64% were still valid when GitGuardian retested them in January 2026. An agent with the wrong credentials has access to everything those credentials can reach, no attacker required.

Agent identity is a secrets problem before it's an identity problem

The industry is converging on agentic identity as the next frontier of identity and access management. Directionally, that's right. Agents should hold first-class, scoped identities. The old identity model, though, was built for people and standing permissions that changed slowly. Agents provision themselves, act autonomously, and can be gone before an access review runs. That gap is structural, not a configuration problem. An IdP can only govern identities it issues or mediates. When an agent authenticates to your database with an API key it reads from a config file, no enterprise IdP mediates the exchange, and no agent-specific identity is attached to the request. It may never appear in the identity system's access reviews, and the target service generally cannot tell that an agent used it. At the authorization layer, the activity can be indistinguishable from the human or workload whose credential it borrowed.

Ask two questions of any agent in your fleet. On whose behalf is it acting, and what actor can you see when it acts? For a service account or secure delegated identity, both have crisp answers. For a reused static credential, the target system can usually identify the credential's principal. It cannot reliably tell whether a human, an AI agent, or malware exercised it.

A misaligned agent behaves like an insider moving at machine speed. Ponemon Institute's 2026 Cost of Insider Risks report puts average containment time for an insider incident at 67 days. That number describes human insiders, not AI agents, but it highlights the visibility problem. Agents execute in seconds, and breakout times; the window from initial access to lateral movement has been measured at under a minute in recent campaigns. You can't start a containment clock on a credential you don't know exists.

Attackers have already operationalized the gap. The Nx s1ngularity payload attempted to use locally installed AI CLIs with unsafe permission settings to identify sensitive files, then collected and exfiltrated credentials from compromised systems. Shai-Hulud spread through npm by harvesting credentials from compromised machines. In the Shai-Hulud 2 wave, GitGuardian found substantial duplication across the harvested data, with each live secret appearing in roughly eight locations on average. These campaigns aren’t creating a new attack. They run the oldest one available: credential theft and reuse, at a scale no human attacker could sustain.

Shining a light on the AI agent gray zone

You won't empty the gray zone with a policy memo, because nobody knows what's in it. The work sequences like this.

Discovery comes first

Fleet-wide scanning of developer machines surfaces the credentials agents actually use: .env files, cloud credential stores like ~/.aws, MCP and agent config files, shell history, and logs. GitGuardian's Developer Endpoint Protection deploys through the mobile device management tooling you already run, on a schedule, with no continuous agent, and inventories the credentials stored across AI-agent and MCP configuration paths on each machine. For organizations already running ggshield in pre-commit hooks or CI, endpoint scanning is a configuration change, not an agent project: the same ggshield binary, extended with a new scan token and deployed via your existing MDM push. That inventory answers a question no single vendor console can, because each vendor console sees only its own tools and identities.

Attribution turns findings into a plan

A credential with a named owner can be governed. An anonymous one is just a liability with no return address. Each finding gets attributed to a human or workload owner and correlated with live incidents, which is what turns a pile of detections into a migration queue.

For observability in the meantime, plant tripwires

Honeytokens, decoy credentials placed in realistic-looking configuration files on endpoints and in repositories, give the gray zone the alarm it lacks. A compromised machine's attacker, or a rogue agent scanning for usable credentials, will test whatever looks real. If anyone attempts to use a honeytoken against a real service, you know in real time, and you know which machine.

Prevention runs in parallel

Agents are still creating new exposures while you clean up the old ones. GitGuardian's AI Hooks register ggshield as a checkpoint inside Claude Code, Cursor, VS Code with GitHub Copilot, and Codex, the four major AI coding environments. Prompts are scanned before they reach the model. File reads, shell commands, and MCP tool calls are scanned before the agent executes them. If a secret appears in a prompt or pre-tool action, the action is blocked, and the agent receives the exact finding so it can self-correct and continue. Tool output is also scanned after execution. Anthropic, Cursor, and GitHub each police their own console. AI Hooks is the layer that covers all of them at once, fleet-wide. And if ggshield can't scan, the tool stays usable and warns that content wasn't checked, fail-open by design, , so a scanning gap never becomes a workflow blocker.

Migration happens in priority order

GitGuardian NHI Governance inventories the credential estate, scores risk, and provides the ownership and exposure context teams need to decide which delegated credentials to replace first with scoped non-human identities (NHIs) or bring under the IdP. The migration itself is your team's work. Knowing where to start shouldn't be.

Not every agent runs on a developer's laptop

Platform agents like Zapier workflows, Make.com automations, and n8n sequences carry credentials from system to system without ever touching a developer machine. GitGuardian NHI Governance extends the same discovery and attribution logic to these identities: each agent's credential, the systems it can reach, and when its access was last reviewed. The mechanism is different, but the governance question is the same: what can an agent reach, and does that still match what you intended?

The future of agent authentication

The work proceeds in two phases.

The nearer-term goal is removing plaintext credentials from the places agents read them, replacing static values in config files and environment variables with references that resolve to nothing an infostealer can harvest.
The further goal is a proxy layer where an agent requests access at runtime and receives a scoped, short-lived credential it never stores, a model where the agent connects to the service without ever holding the secret value.

No long-lived secret on disk for an infostealer to harvest, and nothing reusable if the agent is compromised. That would make the safe end of the spectrum a property of the machine, regardless of which vendor built the agent.

Attackers don't need to break in when they can log in. The governable parts of the spectrum are already well-lit, and platform vendors keep making them brighter. The advantage goes to the teams that can see the gray zone, because that's where many of their agents already are.

See how GitGuardian secures agentic AI