AI Coding Agents Leave Credentials Where Repo Scanners Never Look

2026-09-26 Agent & Supply Chain Security by al-ice.ai Editorial

On 25 September 2026, GitGuardian published a per-tool map of a problem most AppSec programs are not instrumented to see: Cursor, Claude Code, and GitHub Copilot scatter credentials across the developer endpoint — config files, logs, shell history, session stores, and temp files that repository, pre-commit, and CI scanners never traverse. The post pairs the inventory with measurements from the company's State of Secrets Sprawl 2026 dataset: 24,008 unique secrets in public MCP-related configuration files, 2,117 of them valid, and a 3.2% secret-leak rate in public Claude Code-assisted commits versus a 1.5% baseline across all public GitHub commits.

The uncomfortable sentence in the analysis is the one about causation. GitGuardian is explicit that the 3.2% figure does not prove the tool causes the leaks. Faster development has not removed the underlying credential failure; it has multiplied the surfaces where a copied token can come to rest. That framing is worth taking seriously, because it reframes the endpoint from a hygiene backlog into the layer where agent-era credential sprawl actually lives.

Where the trail lives, tool by tool

Cursor keeps two MCP configurations: .cursor/mcp.json inside the project, which travels with the repository, and ~/.cursor/mcp.json in the user's home directory, which never enters one. Both accept inline credentials — as environment variables for local servers or request headers for remote ones. Cursor's own docs describe OAuth for remote servers and variable references instead of values, but neither is enforced. So the project file creates the familiar risk (one inline token committed and distributed to every clone), while the user-level file creates the opposite one: credentials and server definitions that sit entirely outside repository controls, invisible to every scanner the security team operates.

Claude Code keeps user state in ~/.claude/ plus a companion ~/.claude.json holding the sign-in session, user-level MCP servers, and per-project trust decisions. The login token is the best-protected item on the machine — OS keychain on macOS, permission-protected file on Linux and Windows — but Anthropic's docs note macOS falls back to that file when the Keychain is unavailable, such as over SSH. And the login token was never the whole inventory: API keys, connection strings, and tool credentials the agent encounters elsewhere on the machine are uncounted. The project-scoped .mcp.json is designed to be checked into version control so teams can share setup; nothing stops a team writing a token inline, at which point the file is pushed and pulled everywhere. The entire state directory relocates with CLAUDE_CONFIG_DIR, so any file-path rule a defender writes is one environment variable away from irrelevance.

GitHub Copilot has the most varied footprint — editor, CLI, OS, and auth method all change it — and GitGuardian's point is that the variation itself is the governance problem: no single file-path rule covers the fleet. Copilot CLI stores its OAuth token in the OS keychain by default, but when no keychain is available GitHub's docs describe a prompt to fall back to a plaintext config file, plus a setting that makes plaintext the default. Around it sit MCP server definitions, session logs, command and session history, a SQLite session store (session-store.db), saved permission decisions, and fallback MCP OAuth material. Like Claude Code, the whole directory relocates with an environment variable (COPILOT_HOME). Across a large fleet, even a minority of machines on plaintext fallbacks or overprivileged MCP configs is a material credential inventory that repository scanning cannot reach.

Why existing controls miss it by design

The analysis is careful to note that nothing here is a control failure in the conventional sense. Repository, pre-commit, and CI scanning cover tracked content, working-tree changes, or pipeline inputs — not unrelated home-directory config, browser stores, shell history, or temp files. IdP, IAM, and PAM govern identities and sessions they issue or observe; a locally copied API key or an unmanaged third-party token falls outside that perimeter. Secrets managers protect credentials stored in and retrieved through the vault; they cannot govern the unmanaged copy after it lands in a log or history file unless some other control discovers it. Each layer works as designed, and the endpoint trail sits in the gap between all of them — a gap that widens every time a developer adds an agent, connects an MCP server, or copies a token to keep local work moving.

The MCP dimension is what makes this an agent-security story rather than a secrets-hygiene rerun. Every new MCP connection can introduce another non-human identity with real organizational access, and the safer patterns — OAuth, environment-variable references, credential stores — are not enforced across unmanaged installations. When credentials go inline, the MCP configuration files of all three tools become plaintext credential stores, and project-scoped ones get shared through version control. The 24,008 public secrets are the visible portion; enterprise endpoints and internal repositories hold the same pattern outside public view. Readers will recognise the shape from the seven coding-agent escapes we covered in July: the sandbox ends where host trust begins, and the credential trail is what host trust leaves behind.

The fix being proposed — and its privacy design

GitGuardian's answer is its Developer Endpoint Protection offering, built from four independently deployable capabilities: a local agent-and-MCP inventory per endpoint, scheduled filesystem scans over configs, dotfiles, logs, caches, shell history, temp dirs, browser storage, and archives, real-time AI hooks (prompt-submission and pre-tool checks that can block secrets in prompts, commands, file reads, and MCP calls; post-tool checks that notify because the tool already ran), and per-machine honeytokens — decoy AWS credentials that grant nothing and alert when used. Two design choices are worth noting regardless of vendor. Detection happens locally, with only a 256-bit Scrypt fingerprint sent through the HasMySecretLeaked protocol plus finding metadata; plaintext secrets and file contents stay on the machine, and validity checks run endpoint-to-provider. And deployment is an MDM-scheduled script rather than a continuously running EDR-style agent. That is a frank acknowledgement of the actual buyer objection: developers will not tolerate a second always-on agent watching their agent.

Treat the vendor's path table as perishable — the post itself warns the documented locations change often and to check the linked vendor pages before encoding any of them in policy. The durable takeaways are structural: inventory the agents and MCP servers on the fleet before writing rules about them, assume a minority of machines are always on the plaintext fallback path, and measure the endpoint layer directly instead of inferring it from repository scan results. April reporting on the same Secrets Sprawl dataset found Claude-assisted commits leaking at roughly double the baseline rate; the September update puts numbers on where the other half of that problem lives. It was never in the repo.

What to do

Inventory agents and MCP servers per endpoint, not per repo. You cannot scope what you cannot enumerate; repository scanning tells you about code, not about the machines that access production.
Ban inline credentials in MCP configs and enforce variable references or OAuth. All three tools support the safer pattern; none enforces it. That gap is policy-shaped, and policy is yours to write.
Assume the plaintext fallback is in use somewhere. Keychain-unavailable paths (SSH sessions, containers, minimal images) silently downgrade token storage on both Claude Code and Copilot CLI. Scan for the fallback files explicitly.
Pin CLAUDE_CONFIG_DIR and COPILOT_HOME in managed environments. A relocatable state directory defeats path-based detection rules; on managed machines those variables should be set by policy, not by developers.
Put MCP configuration changes under change control. A stdio server command spec is code execution with a config file's ergonomics — the same lesson as the OpenClaw authorization batch, applied to the developer's own machine.

Sources: