Why AI Coding Assistants Leak Secrets More Than Twice as Often

"AI coding assistants leak secrets" is usually shorthand for three separate mechanisms that get lumped together and therefore mitigated inconsistently.

The first is context-window exposure. Every time a developer has a file open, pastes a stack trace, or asks a chat-based assistant to debug a failing integration, whatever is in that context, including any live API key, database connection string, or session token sitting in a nearby line, gets sent to the model provider's inference endpoint. For cloud-hosted assistants that is a third-party service outside your network boundary, and depending on the vendor's data retention and telemetry settings, that context can be logged, cached, or in some documented cases used for further model training. This is a fundamentally different exposure surface than a git commit: there is no diff to review, no CI gate to catch it, and often no local log a security team can audit after the fact.

The second is suggestion-level regeneration. Public research from Hong Kong University demonstrated that GitHub Copilot could be prompted to regenerate real, previously-seen hardcoded credentials it had encountered during training, producing valid secrets it had memorized from public repositories rather than secrets it invented. The researchers' own audit found that roughly 6.4% of nearly 20,000 Copilot-enabled repositories they examined had leaked at least one secret, a incidence rate meaningfully higher than what shows up in repositories without AI code suggestion enabled. The assistant is not intentionally exfiltrating anything, it is doing exactly what it was trained to do: complete a pattern. If the training data contains a plausible-looking API key in a similar code shape, a plausible-looking key is what comes back, and developers under deadline pressure accept AI-suggested boilerplate, including credential-shaped placeholders, without scrutinizing it the way they would a colleague's pull request.

The third, and the one growing fastest, is configuration-file exposure. MCP servers, the connectors that let assistants like Claude Code, Cursor, and Copilot reach external tools and data sources, are configured through local files (commonly mcp.json, .cursor/mcp.json, or similar) that routinely contain API keys and tokens in plaintext so the assistant can authenticate to the connected service. These files are easy to commit by accident, are rarely covered by the same review process as application code, and according to GitGuardian's 2026 report already account for 24,008 unique exposed secrets on public GitHub, with 2,117 of those still valid when discovered. CSA Labs' research on the AI coding assistant attack surface documented related exfiltration techniques building on this same weak point, including malicious environment-variable manipulation and hidden MCP server definitions used to harvest credentials from AI tool workflows. This is a related but distinct problem from the tool-description manipulation covered in our piece on MCP tool poisoning; here the risk is the credential sitting in the config file itself, not the tool's declared behavior.

The procedure below assumes a few things are already true. If they are not, do those first, since the controls in the next section only work on top of a working baseline.

This is a numbered sequence. Steps 1 through 3 close the config-file and context-window exposure paths specifically; steps 4 through 7 extend your existing secrets-scanning posture to cover AI-generated code before it lands.

Do not take a config change at face value. Validate each control with a deliberate, harmless test before trusting it in production.

For the MCP config audit, re-run your secrets scanner against the full git history of your MCP and assistant config paths specifically, not just HEAD, and confirm the finding count matches what you expect after remediation, zero, ideally. For the CI gate, commit a deliberately non-functional placeholder credential (a clearly fake string matching your scanner's detection pattern, never a real key) on a throwaway branch and confirm the pipeline blocks the merge. For telemetry and retention settings, check the admin console's audit log after the change, most enterprise tiers of Copilot, Cursor, and Claude Code log configuration changes with a timestamp and actor, and confirm the setting reads as applied org-wide rather than per-user. For the pre-commit hook, have a developer attempt a commit containing a test secret from a machine that has not yet pulled the latest hook configuration, to confirm the CI backstop catches what the missing local hook would have missed.

Even a fully implemented version of the procedure above has real gaps, and security teams should know them going in rather than discovering them during an incident.

A few problems come up consistently when teams roll this out, and they are worth anticipating rather than discovering mid-rollout.

If your scanner is not flagging MCP config files despite being added to the include list, check whether the scanner's default file-type detection is skipping .json files in dotfile directories (a common default behavior), and confirm you explicitly listed the path rather than relying on extension-based auto-detection. If developers report the pre-commit hook is slow enough that they are routinely bypassing it, that is a signal to scope the hook to changed files only rather than a full repository scan, since a slow hook gets disabled in practice regardless of policy. If an enterprise admin console setting for telemetry or training-data opt-out appears greyed out or unavailable, confirm you are on a tier that actually includes that control, some of these settings are gated to specific enterprise or business tiers and are not present at all on individual or free-tier accounts. If CI is blocking legitimate test fixtures that intentionally contain fake-looking credentials for unit tests, add an explicit allowlist entry for that specific file and pattern rather than lowering the scanner's overall sensitivity, which reopens the gap you just closed.

None of this is free. Requiring explicit review on every AI suggestion touching a config-adjacent file slows down exactly the workflow developers adopted AI assistants to speed up, and teams that set the friction too high will see developers route around it, through personal accounts, unmanaged browser-based chat interfaces, or simply disabling the review prompt if the tooling allows it locally. Conversely, teams that only implement the CI-level backstop and skip the pre-commit and IDE-level controls will catch leaked secrets later, after they have already left the context window and potentially been logged by a third-party vendor, which is too late for the context-window exposure path specifically.

The realistic position is to accept that this is a defense-in-depth problem with no single control that closes every path. Config-file hardening and CI enforcement are non-negotiable and low-friction once automated. Vendor-level telemetry and retention settings are policy-dependent and worth applying but not independently verifiable. IDE-level suggestion review is the highest-friction control and should be scoped narrowly, to credential-adjacent files only, rather than applied universally, or adoption will erode. Teams evaluating whether a given assistant's default posture is acceptable for their risk tolerance, rather than just how to configure the one they already picked, should read this alongside our broader piece on governing AI coding assistants and our analysis of AI-generated code risk more generally, since the secrets-leakage mechanism covered here is one piece of a larger AI-assisted development risk surface.