AI Coding Tools and Secrets Sprawl: Where Keys Now Leak and How to Contain Them

AI coding tools have turned every developer laptop and every repository into a faster, wider channel for leaking machine credentials. Agents read .env files and shell profiles, remember approved commands, write instruction and MCP configuration files, keep transcripts of everything they saw, and commit code at a pace no reviewer matches. Each of those is a new place where an API key, token or connection string can come to rest, and most of them sit outside the scanners and vaults that security teams already run. This guide pulls together what the 2026 research and the incidents on our breach database show: where keys now leak, which cases prove it, and the containment controls that work across tools. It is written for AppSec, platform, identity and endpoint teams, and it links to the deeper NHI Mgmt Group guides for each task rather than repeating them.

Key takeaways

• The leak paths have multiplied, not just the volume. Prompts, agent instruction files, permission memory, MCP configuration, transcripts, extension settings and agent-written commits are all new resting places for secrets, and a Git-only scanner sees few of them.
• The numbers point the same way. GitGuardian research counted 28.65 million new hardcoded secrets in public GitHub commits in 2025, up 34%, with AI service secrets up 81% and 24,008 unique secrets in MCP configuration files.
• An agent inherits whatever the developer's session can reach. Gemini CLI, Amazon Q, Sentry MCP agentjacking and Nx s1ngularity all turned on the same fact: the agent runs with the developer's environment variables, cloud profiles and tokens.
• Containment is mostly identity work. Short-lived, federated and narrowly scoped credentials, kept out of the agent's reach, shrink every one of these leaks; scanning only finds what is already exposed.
• Revocation is the finish line. Deleting a file, a transcript or an exfiltration repository leaves the key valid. Measure until the issuer rejects it.

Why AI coding tools widen secrets sprawl

Secrets sprawl is the spread of credentials outside the systems built to hold them. The Secret Sprawl Measurement Guide covers how to count it. AI coding tools change four things about how it happens.

• Speed: agents and vibe coding tools produce more commits, more configuration and more throwaway projects per developer. Review capacity has not grown at the same rate. GitGuardian research puts 2025 public GitHub commit volume at about 1.94 billion, up 43%.
• Autonomy: an agent decides which files to read and which commands to run. In the PocketOS case the coding agent searched the codebase, found a Railway API token in a file unrelated to its task and used it. A human might never have opened that file.
• Agents reading local files: context gathering pulls .env files, shell output, cloud CLI configuration and error logs into the model's context, and from there into transcripts, traces and provider-side history. GitGuardian research published in July 2026 lists shell history, .env files and dotfiles, cloud credential files, registry tokens and AI agent and MCP caches among the places secrets sit on a developer machine, and says agents may write keys they generate into conversation history or temp files without the developer knowing.
• Generated code and configuration committing literals: an agent asked to connect a database will often write the connection string where it works first. Approved commands, instruction files and MCP configuration are then committed with the project. Radware research found that only about 10% to 16% of the commits that put credentials into agent instruction files carried AI-authorship signatures, so most of those leaks were typed by people into files that exist because of agents.

The identity point underneath all four: every key an agent can see is a non-human identity that the agent can use, copy or leak. GitGuardian research claims agentic credentials account for more than 40% of secrets found on developer endpoints, though the article does not publish its method or sample size. Developer endpoints as NHI stores covers the laptop itself; this guide follows the credentials outward.

What the numbers say

Vendor research is labelled as such: each publisher sells products in this area and methods differ, so compare direction rather than precise rates.

Two cautions. First, scanner coverage is uneven in these new file types: according to the Apiiro findings as reported, Gitleaks flagged 564 and TruffleHog 643 of the 1,122 settings files with secrets, and neither flagged 215. Second, the NHI Mgmt Group report covers the incidents it analysed, not every breach. More figures: AI Agent Security Statistics.

Where secrets now land

Use this table as the scope list for discovery.

Lessons from incidents: the case table

Every case below is a live NHI Mgmt Group breach page that involves an AI coding tool, an IDE extension, an AI agent or the credentials developers feed to them. The type column separates confirmed incidents from research and vulnerability disclosures. Products are named because the incidents are, not as a judgement on any vendor; each lesson is a customer-side control.

For a broader view across every agent incident, see AI agent breaches.

Four patterns across the cases

• Inheritance: in Gemini CLI, Amazon Q MCP, Sentry MCP and Nx s1ngularity the agent, or a process it launched, simply had the developer's environment. Removing standing secrets from it closes all four.
• Configuration as a carrier: instruction files, permission memory, MCP configuration and extension packages carried either the secret or the instruction to steal one.
• Distribution trust: marketplaces and auto-update delivered the payload in five of the cases, and publishing tokens were the identity abused in most of them.
• Reach beats intent: PocketOS and WorkOS had no attacker; the scope of a reachable credential decided the damage.

Containment controls

Order matters. Controls that shrink what an agent can reach come first, because scanning only finds what has already leaked. The target architecture for agent credentials is covered in the Credential Vaulting for AI Agents Guide and Runtime Secrets Injection for AI Agents Without Prompt Exposure; this section is the cross-tool summary.

1. Keep secrets out of agent reach

• Deny reads of secret files: configure each tool to refuse .env, credential and key files (see the settings table below), and remember that tool-level ignore rules are not a sandbox. Cursor's own documentation says the terminal and MCP tools used by Agent cannot block access to files governed by .cursorignore.
• Strip the inherited environment: start agents and MCP servers with a minimal environment, not the developer's full shell. Move tokens out of shell profile exports.
• Run untrusted work in a sandbox: new repositories, pull requests from outsiders and tasks that read external data (tickets, error events, web pages) belong in a container or cloud sandbox with no developer credentials mounted. See the AI Agent Sandboxing and Code Execution Guide.
• Clean the workspace: any token in the working tree is one the agent may use, so scan it, not only commits.

2. Short-lived and federated credentials

• Cloud access: replace static keys in ~/.aws/credentials and similar files with SSO-issued session credentials that expire in hours.
• CI and publishing: use OIDC workload identity federation and trusted publishing so no long-lived publishing token lives on a laptop or in a repository secret. See How to set up workload identity federation for GitHub Actions to AWS.
• Per-tool AI keys: give each assistant, plugin and MCP server its own provider key with a spend cap, so one leak is one rotation. See How to set spend limits on LLM API keys.
• Agent identities: where an agent acts in production or CI, give it its own scoped identity rather than a developer's token. NHI Mgmt Group's breach report puts "remove standing production write access from coding and other AI agents" in its first 30 days.

3. Push protection and pre-commit checks

• Repository push protection: on GitHub, repository-level push protection is off by default and needs GitHub Secret Protection; user push protection is on by default but covers public repositories only and does not raise bypass alerts on its own. Turn on the repository level, restrict bypass with delegated bypass, and alert on "I'll fix it later" bypasses. Step by step: How to enable GitHub secret scanning push protection.
• Agent commits: confirm that whatever route an agent uses to commit (local Git, the API, an MCP server, a cloud agent) passes the same checks. GitHub documents push protection coverage per surface, including REST API requests and the GitHub MCP server for public repositories.
• Agent-specific files: add custom patterns or path rules for .claude/, .cursor/, .mcp.json, instruction files and inline secrets after keys such as PGPASSWORD=, since the Apiiro findings show general scanners missed a share of these.

4. Scan the new stores, not just Git

• Endpoints: scan approved paths on developer machines for secrets in dotfiles, agent folders, MCP configuration and shell history, with privacy and HR agreement first.
• Transcripts and traces: decode JSON before scanning, scan in place, and redact output. The method is in How to Find Secrets in AI Agent Transcripts and Traces.

5. MCP token hygiene

• No literal tokens in shared MCP files: reference environment variables or the client's secret storage, and keep project MCP files free of values. The MCP Static Token Audit covers discovery.
• Audience-bound tokens: the MCP security best practices state that MCP servers "MUST NOT accept any tokens that were not explicitly issued for the MCP server", which rules out passing a developer's upstream token straight through.
• Consent and least scope: the same document requires clients offering one-click local server setup to show the exact command before running it, and recommends sandboxed launch and minimal scopes. Inspect the command behind any MCP consent prompt before approving it.
• Governance: keep an allow list of MCP servers and owners. See the Local MCP Server Security Guide.

6. Managed settings and extension control

• Enforce centrally: deploy deny rules, sandbox modes and transcript retention through each tool's managed or organisation settings, so a developer's local file cannot loosen them.
• Extensions: allow-list publishers and extensions, delay auto-updates for new versions where the tooling allows, and monitor for plaintext HTTP from IDE processes, a signal named in the JetBrains plugin case.
• Instruction files: require code-owner review for AGENTS.md, CLAUDE.md, .cursor/rules and similar files, and block hidden Unicode in them.

Tool settings that keep secrets out of agent reach

Tools are listed alphabetically; order is not a ranking. Each row gives the vendor's own documented setting as of November 2026, and these change often, so confirm against current documentation before scripting them. Credential storage locations for each tool are in How to audit AI coding assistant tokens and config files.

Implementation: a phased rollout

1. Week 1 to 2, inventory: list the AI coding tools, IDE extensions, MCP servers and AI provider keys in use, with an owner for each. Run the token and config audit on a pilot group of developer machines and record findings by store from the "where secrets now land" table.
2. Week 2 to 4, revoke what is live: rotate every valid secret found, starting with cloud, publishing and production credentials. Track until the issuer rejects the old value, not until the file is cleaned.
3. Week 3 to 6, cut reach: roll out deny rules, minimal environments for agents and MCP servers, and sandbox defaults to the pilot ring in audit or ask mode first. Collect which legitimate tasks break, adjust, then enforce through managed settings.
4. Week 4 to 8, replace standing credentials: move developers to SSO-issued cloud sessions, CI to OIDC federation, package publishing to trusted publishing, and AI tools to per-tool capped keys.
5. Week 6 to 10, block at commit and publish: enable repository push protection with delegated bypass, add custom patterns for agent files, and add scanning to extension and package builds.
6. Ongoing, scan the stores and measure: schedule endpoint, transcript and trace scans; report the metrics below monthly.

Testing and rollback: keep every policy change in version control, deploy to a pilot ring before the fleet, and roll back by reverting the managed settings file or policy, not by asking developers to edit local files. Never roll back a credential rotation; issue a new credential instead. The AI coding assistant rollout playbook covers the wider rollout, the AI IDE and Coding Agent Security Guide covers permission and sandbox design, and the AI Coding Agent Incident Playbook and Compromised Developer Workstation Playbook cover response.

Decision guidance

Small organisations: start with per-tool capped keys, user and repository push protection, deny rules for .env files and a monthly endpoint scan of agent folders. Large organisations: add managed settings through MDM, an MCP server allow list, extension allow lists with delayed updates, transcript and trace scanning, and federated credentials everywhere CI and cloud allow it.

Detection and measurement

Watch for AI API key usage from unexpected networks or volumes, new public repositories under developer accounts, new SSH authorised keys or self-hosted runners on developer machines, plaintext HTTP from IDE processes, changed instruction or MCP files in pull requests, and push protection bypasses. Honeytokens placed in .env files and agent folders give a high-signal alert when an agent or malware reads and uses them; see AI Agent Honeytokens and Canaries.

Common failure patterns

• Cleaning the file instead of revoking the key: deleting a settings file, a transcript or an exfiltration repository leaves the secret valid. GitGuardian research found more than 64% of secrets valid in 2022 still valid in January 2026.
• Typing secrets into commands an agent remembers: the Claude Code settings leak research shows inline passwords saved as standing approvals and then pushed.
• Trusting ignore files as a boundary: tool ignore rules help, but terminal and MCP access can still read the file. Pair them with environment hygiene and sandboxes.
• Leaving broad tokens in the workspace: the PocketOS Database Deletion began with an account-scoped token in an unrelated file.
• Letting repository content configure the agent: MCP files and instruction files from a cloned repository ran or steered commands in the Amazon Q MCP Config Vulnerability and the TrapDoor Supply Chain Campaign.
• Scanning only Git: endpoint, transcript, extension and collaboration stores hold a large share of the exposure and are missed by repository-only programmes.

Framework mapping

Practitioner checklist

• Inventory AI coding tools, extensions, MCP servers and AI provider keys, each with an owner.
• Scan agent folders, instruction files, MCP configuration, transcripts and shell history on a pilot group, then the fleet.
• Revoke and rotate every live secret found, and record time to revoke.
• Deploy deny rules for .env and credential files and minimal inherited environments through managed settings.
• Run untrusted repositories and tasks that read external data in a sandbox with no developer credentials.
• Replace static cloud keys and publishing tokens with SSO sessions, OIDC federation and trusted publishing.
• Give each AI tool and MCP server its own capped key; never pass a developer's upstream token through an MCP server.
• Enable repository push protection with delegated bypass and custom patterns for agent files.
• Require code-owner review of instruction and MCP files, and block hidden Unicode in them.
• Allow-list IDE extensions and publishers, and plant honeytokens where agents and malware look.

Standards and references

• Model Context Protocol: Security Best Practices
• GitHub Docs: About push protection
• GitHub Docs: Risks and mitigations for Copilot cloud agent
• GitHub Docs: Content exclusion for GitHub Copilot
• Anthropic: Claude Code settings files and precedence
• Cursor: Ignore files
• OpenAI: Codex configuration reference
• GitGuardian: The State of Secrets Sprawl 2026
• GitGuardian: Every Laptop Is a Credential Store: Where Secrets Hide
• Radware: The New .env: Measuring Credential Leakage in AI Agent Instruction Files

Related NHI Mgmt Group resources: AI agent breaches · Secret Sprawl Measurement Guide · Developer endpoints as NHI stores · AI Coding Agents Security Guide · Secrets Management Guide