AI coding assistants are creating a secret exposure problem

At a glance

What this is: This article argues that AI coding assistants are expanding the attack surface inside developer environments by ingesting sensitive files, environment variables, and MCP configurations that can leak secrets.

Why it matters: IAM, PAM, and NHI teams need to treat developer-side AI tools as privileged components because their access patterns can bypass assumptions about file boundaries, secret storage, and human oversight.

Context

AI coding assistants are now part of the developer control plane, not just productivity helpers. They read files, inspect environment variables, and interact with local tooling to build context, which means secret exposure can happen before a human notices the data was in scope.

The governance gap is that many teams still treat the IDE as a human workspace with occasional automation layered on top. Once assistants can recursively scan directories, ingest MCP configuration, and trigger actions through plugins, the relevant question becomes which secrets they can reach and where those secrets can leave the environment.

This is primarily an NHI governance problem because the identity at work is not the developer alone. The assistant inherits or consumes access in a way that looks more like a privileged non-human component than a simple coding aid.

Key questions

Q: What breaks when AI coding assistants work in a poorly structured codebase?

A: The assistant loses context, spreads change across the wrong files, and makes it harder for reviewers to understand impact. Poor structure increases defect rates, hides security-sensitive changes, and raises the chance that a seemingly small task will alter a large amount of code. Clean structure is a control, not just a preference.

Q: Why do AI coding environments create more secret exposure risk than standard developer tools?

A: They can inspect repository context, read dotfiles, and infer where credentials are stored, then act on that information through commands or file changes. That means secrets can be exposed both by reading them and by persisting changes that keep access alive. Teams should assume workstation-local state is part of the secret attack surface.

Q: How do security teams know whether remote admin access is too broad?

A: Look for accounts that can reach servers, stop services, or manage recovery tooling without task-specific approval or expiry. If the same identity can authenticate broadly and make destructive changes, the access model is overextended. Audit RDP entitlements, backup rights, and service-control permissions together, not separately.

Q: How should organisations respond when hidden prompts can steer coding assistants?

A: They should treat repository content as a potential control input, not just code. Hidden instructions can redirect assistants into reading secrets or using tool channels for exfiltration, so detection needs to cover anomalous file access, DNS behaviour, and unsafe tool use inside the IDE workflow.

Technical breakdown

Why AI coding assistants behave like privileged NHI components

Modern assistants operate inside the IDE with broad read access to project trees, configuration files, shell context, and sometimes local services. That makes them closer to privileged non-human identities than to passive autocomplete. They can ingest context recursively, and the more context they consume, the greater the chance they encounter secrets that were never meant to be machine-readable. The risk is structural: the assistant is optimised to collect information, not to distinguish safe from unsafe data boundaries.

Practical implication: Treat AI coding tools as in-scope privileged actors and map the files, variables, and local services they can reach.

How secrets leak through .env files and MCP configurations

The article highlights two common leakage paths. First, .env files remain a frequent source of credentials because they are easy for assistants to read once they are in the working directory. Second, MCP configuration files often contain arguments, paths, and environment variables, which can include tokens or keys in plaintext JSON. If the assistant can read these files, it can expose the secrets; if it can also run them, it can misuse those secrets as part of its toolchain.

Practical implication: Move secrets out of developer-readable configuration and separate assistant context from credential material.

Why prompt injection turns context ingestion into exfiltration

When hidden instructions or malicious repository content influence the assistant, the problem stops being simple disclosure and becomes active exfiltration. The article describes cases where the assistant was induced to read sensitive files and encode them into DNS queries or follow hidden instructions embedded in repository artifacts. This is important because it shows a second stage beyond exposure: the assistant can be steered to transmit secrets through channels that look like normal tool use.

Practical implication: Assume repository content can manipulate assistant behaviour and monitor for tool-driven outbound channels, not just local file reads.

Threat narrative

Attacker objective: The attacker wants to obtain developer secrets and move them out of the workspace through the assistant’s own context and tool access.

1. Entry begins when the assistant is given access to the developer workspace, including project directories, configuration files, and local tools.
2. Credential access occurs when the assistant ingests .env files, MCP configurations, and environment variables that contain secrets or tokens.
3. Escalation follows when hidden instructions or malicious repository content steer the assistant to reuse those secrets or encode them for transmission.
4. Impact is secret exposure or exfiltration from the developer environment without obvious human intent or approval.

Breaches seen in the wild

• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
• postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI coding assistants are now privileged non-human identities, not benign developer aids. They read, interpret, and act inside environments that contain secrets, and that access pattern is materially closer to NHI privilege than to simple autocomplete. Once the tool can inspect directories, environment variables, and local configuration, governance has to move from user experience to entitlement scope. The practitioner conclusion is straightforward: treat assistant access as a governed identity surface.

Secret exposure in the IDE is a governance failure, not a file-format problem. .env files, YAML templates, and MCP configuration files become dangerous because they place credentials inside paths the assistant can legitimately read. That is why this issue sits squarely in OWASP-NHI and NIST CSF access control territory. The implication is that the control boundary must follow the assistant’s real read path, not the developer’s intent.

Prompt injection turns local context into a secret transport channel. The article’s DNS exfiltration example matters because it proves the assistant can be manipulated into using its own tools to move secrets externally. That is a toolchain trust problem, not just a model-safety problem. Practitioners should regard hidden instructions in repositories as a control-plane threat to non-human execution.

AI development tooling now creates identity blast radius inside software delivery. When assistants can ingest secrets, run commands, and interact with MCP servers, a single overbroad workspace can expose more than source code. The security model must therefore cover developer machines, local tool integrations, and the data they can touch, because the blast radius is defined by assistant reach rather than by the human operator alone.

Need-to-know for humans does not automatically become need-to-see for machines. Security programmes built around human roles assume the person can be trusted to ignore sensitive material that appears in context. Assistants do not make that judgment, so the same workspace can be safe for a developer and unsafe for a machine consumer of context. The practitioner takeaway is to govern machine-readable context separately from human access.

From our research library:

• Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
• Read next: AI Coding Agents Security Guide

What this signals

Secret exposure now starts at context ingestion. The important shift is not that AI assistants can sometimes leak data, but that they can reach sensitive material before any human review step occurs. That moves the control question upstream to workspace design, secret placement, and the boundaries assigned to machine-readable context.

Developer AI needs its own governance model. A code assistant that can read configuration, invoke local tools, and consume MCP definitions is operating as a privileged non-human actor. Teams should govern that reach as part of identity and access management, not as a side issue in developer productivity tooling.

Assistant activity belongs in security monitoring. If secret exposure can happen through ordinary file reads, DNS queries, or hidden prompt instructions, then logging and detection need to follow assistant behaviour inside the IDE and adjacent tooling. The programme signal is clear: the attack surface has moved into the developer workflow.

For practitioners

• Treat coding assistants as privileged NHI components Inventory every file, directory, environment variable, and local tool the assistant can access, then classify that reach as an identity boundary rather than a convenience feature.
• Move secrets out of assistant-readable paths Relocate tokens, keys, and credentials from .env files and MCP JSON into secure vaults or OS-level secret managers that are not exposed in working directories.
• Constrain MCP and plugin context Review MCP server definitions, plugin settings, and local tool wrappers for plaintext environment variables, broad arguments, and unnecessary filesystem access.
• Monitor assistant-driven outbound behaviour Watch for file reads, DNS lookups, unusual command execution, and other tool-mediated exfiltration patterns that can originate from hidden prompts or malicious repo content.
• Fold AI workflows into incident response and logging Add assistant activity, context ingestion, and local tool use to logging, detection, and incident response playbooks so secret exposure can be investigated quickly.

Key takeaways

• AI coding assistants can expose secrets because they see more of the developer environment than most teams assume, including files and configuration that often contain credentials.
• The article ties that exposure to real tooling behaviour, not theory, and shows how prompt injection can turn local context into exfiltration.
• The most effective response is to treat assistants as privileged non-human actors and narrow their workspace, secret access, and tool reach.

Key terms

• AI coding assistant: An AI coding assistant is software that helps write, refactor, debug, or navigate code using model-driven suggestions and sometimes command execution. In practice, it can become part of the operational control plane if it has access to files, terminals, and external tools that can change a system.
• MCP Configuration: MCP Configuration is the set of settings that tells an AI agent how to connect to Model Context Protocol tools, data sources, and permissions. It defines endpoints, authentication, allowed actions, and context boundaries. In practice, it governs how an agent discovers and uses external capabilities without exposing unnecessary data or control.
• Context Ingestion: The process by which an IDE, AI assistant, or plugin reads files, environment variables, metadata, or logs to build task context. In security terms, context ingestion is risky when the tool has more visibility than the task requires, because it can collect and retain secrets unintentionally.
• Assistant Exfiltration: Assistant exfiltration is the transfer of sensitive data out of an environment through the actions or outputs of an AI assistant, often after it has read material it should not have handled. This can happen through normal-looking channels such as tool calls, outbound queries, or encoded responses.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.