TL;DR

• The hidden trail: Cursor, Claude Code, and GitHub Copilot store credentials across config files, env variables, logs, shell history, and temp files that repository and CI scanners never inspect.
• The evidence: GitGuardian's State of Secrets Sprawl 2026 found 24,008 unique secrets in public MCP configuration files, 2,117 of them valid, plus a 3.2% leak rate in Claude Code-assisted commits.
• The fix: GitGuardian Developer Endpoint Protection discovers this trail fleet-wide with local agent inventory, machine scanning, AI hooks, and honeytokens, so security teams can remediate before compromise.

How AI coding agents handle credentials

Agentic coding tools can read files, run commands, and call external services. Authentication to model providers, source-control platforms, and connected tools creates several ways for credentials to remain on the endpoint:

1. Stored: API keys and tokens can be placed in agent or MCP configuration. Some tools instead use an OS keychain or OAuth flow.
2. Copied: a credential retrieved from a vault or environment can be written to a local file for debugging or reuse, leaving an unmanaged copy.
3. Recorded: prompts, command output, debug logs, and session history can capture a credential when redaction is absent or incomplete.

Some of these files can be committed accidentally but many never enter a repository at all.

On one well-managed workstation, these artifacts may look like isolated hygiene issues but in a large organization with decentralized tooling, contractors, multiple business units, and inconsistent endpoint policy, the same pattern multiplies across the fleet. Security may know which repositories it scans while still lacking an inventory of the agents, MCP servers, and standing credentials on the machines that access them.

Here's what the trail looks like, tool by tool.

Cursor

Cursor keeps two MCP configurations: one inside the project, which travels with the repository, and one in the user's home directory, which never enters a repository. Both accept inline credentials, as environment variables for local servers or as request headers for remote ones. Cursor's MCP docs also describe OAuth for remote servers and variable references in place of values, but neither is enforced.

The project file sits inside the repository, so one inline token can be committed and distributed to every developer who clones it. The user-level file creates the opposite problem: credentials and server definitions can remain entirely outside repository controls. In a large fleet, different teams can connect Cursor to different internal systems with different tokens, scopes, and storage practices. Without endpoint inventory, security has no reliable way to see that population or determine which machines hold access to sensitive services.

Claude Code

Claude Code keeps user state in a home directory plus a companion JSON file that holds the sign-in session, user-level MCP servers, and per-project trust decisions. The login token is the best-protected item on the machine: it lives in the OS keychain on macOS and in a permission-protected file on Linux and Windows. Anthropic's docs add that macOS falls back to that file when the Keychain is unavailable, such as in an SSH session. Protecting the primary login token does not inventory the API keys, connection strings, and tool credentials the agent can encounter elsewhere on the machine.

Claude Code's project-scoped MCP file is designed to be checked into version control so a team can share its setup. The tool supports environment-variable references and keychain storage for OAuth tokens, but nothing prevents a team from writing a token inline. When that happens we know the story, the file is pushed and pulled everywhere, copying the token into repository history and onto every machine that receives the configuration.

GitHub Copilot

Copilot's endpoint footprint varies across the editor, CLI, operating system, and authentication method. That variation is itself a governance problem: a security team cannot apply one file-path rule and assume the fleet is covered. Copilot CLI and Claude Code both let a developer relocate their entire state directory with an environment variable.

Copilot CLI stores its OAuth token in the operating system's keychain by default. When no keychain is available, GitHub's docs describe a prompt to store it in a plaintext config file instead, and a setting that makes that the default.

The primary token is only part of the trail. The same directory holds MCP server definitions, session logs, command and session history, a SQLite session store, saved permission decisions, and fallback storage for MCP OAuth material when no keychain is available (directory reference). Across a large fleet, even a minority of machines using plaintext fallbacks, environment tokens, or overprivileged MCP configurations creates a material credential inventory that repository scanning cannot reach.

Where each tool keeps its state

Paths as documented by each vendor in September 2026. They change often, so check the linked page before writing a policy rule on one of them.

MCP servers: when configuration becomes a credential store

Model Context Protocol servers let agents reach systems such as source control, cloud providers, databases, SaaS applications, and internal services. Each new connection can introduce another non-human identity and another credential with real organizational access. MCP supports OAuth, environment-variable references, credential stores, and runtime helpers, but those safer patterns are not automatically enforced across unmanaged installations.

When credentials are written inline, the MCP configuration files of all three tools become plaintext credential stores. Project-scoped files may also be shared through version control. GitGuardian's State of Secrets Sprawl 2026 analysis found 24,008 unique secrets in public MCP-related configuration files, including 2,117 valid credentials. Public repositories expose the visible portion but enterprise endpoints and internal repositories can hold the same pattern outside public view.

Why this trail grows faster than your hygiene

• Shadow AI scales faster than policy. Individual teams can add agents and MCP servers in minutes, while security reviews, procurement, MDM policy, and identity governance move on a different timescale. Fleet inventory can be outdated before it is complete.
• The surface compounds across the fleet. Each integration can introduce another identity, credential, configuration path, permission decision, or history store. Multiplied by thousands of developers, small local exceptions become governance issues fast.
• AI-assisted workflows show a higher observed leak rate. GitGuardian's State of Secrets Sprawl 2026 analysis found a 3.2% secret-leak rate in public commits assisted by Claude Code versus a 1.5% baseline across all public GitHub commits. For sure, the measurement does not assign causation to the tool alone, but it shows that faster development has not removed the underlying credential failure problem.

What your existing controls miss here

Existing controls can work exactly as designed and still leave this layer uncovered:

• Repository, pre-commit, and CI secret scanning cover tracked content, working-tree changes, or pipeline inputs according to their configuration. They do not traverse unrelated home-directory config, browser stores, shell history, or temporary files.
• IdP, IAM, and PAM govern identities and sessions they issue or observe. Locally copied API keys and unmanaged third-party tokens fall outside that perimeter.
• Secrets managers protect credentials stored in and retrieved through the vault. They cannot govern an unmanaged copy after it has been written to a log, history file, or temporary file unless another control discovers it.

In a large enterprise, that unmeasured gap grows every time a developer adds an agent, connects a new MCP server, or copies a token to make local work move faster. The missing control is a fleet-wide credential discovery on the device.

How GitGuardian Developer Endpoint Protection closes the gap

Developer Endpoint Protection turns this invisible endpoint problem into a fleet-level security program, with four independently deployed capabilities:

• Local agent and MCP inventory: visibility into which supported AI agents and MCP servers run on each endpoint, plus the data and tools they can access and how they are used.
• Machine scan: scheduled filesystem scans covering config files, dotfiles, logs, IDE and agent caches, shell history, temporary directories, browser storage, archives, and other supported formats. Findings are scored by severity and access scope.
• AI hooks: real-time scanning through supported AI coding-tool hooks. Prompt submission and pre-tool checks can block secrets in prompts, commands, file reads, and MCP calls. Post-tool checks notify the developer because the tool has already run.
• Honeytoken protection: a decoy AWS credential planted on each protected machine. It grants no access, and any attempt to use it raises an alert tied to that endpoint.

Three design choices matter for how it fits your environment.

• Privacy: detection happens locally. GitGuardian receives a 256-bit Scrypt fingerprint through the HasMySecretLeaked protocol, finding metadata such as file path and timestamp, and machine and user inventory metadata. GitGuardian does not receive the plaintext secret or source-file contents. Optional validity checks send the credential directly from the endpoint to its provider, not through GitGuardian.
• Deployment: the recommended approach is an MDM-scheduled script, not a continuously running EDR-style agent; launchd, systemd, and configuration-management deployments are also documented.
• Fit: it complements repository and CI scanning, vaults, IdP, PAM, EDR, and DLP rather than replacing them. After a compromise, teams can rank findings by severity and privilege, create incidents, and follow the remediation workflow to revoke or relocate credentials and redact supported local occurrences.