AI coding assistants are leaking credentials across predictable file paths

At a glance

What this is: This is an analysis of how AI coding assistants store credentials and why plaintext token handling creates broad identity exposure.

Why it matters: It matters because IAM, PAM, and NHI teams must account for AI tools that aggregate secrets, bypass normal control boundaries, and turn local credential leakage into cross-system compromise.

By the numbers:

• Trend Micro found that 48% of 19,402 MCP server implementations recommend plaintext credential storage.
• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes.
• Only 44% of organisations are currently using a dedicated secrets management system.

👉 Read Netwrix's analysis of AI coding assistant secret exposure

Context

AI coding assistants and desktop AI tools need credentials to reach models, repositories, chat services, databases, and MCP-connected systems. The governance problem is that many of those credentials are stored in predictable files, often as plaintext JSON, so a local read primitive can become identity compromise across multiple services.

For IAM and NHI teams, this is not just a secrets hygiene issue. It is a boundary problem: one assistant can aggregate access to several environments, while remote control features and extension ecosystems can turn that aggregated access into lateral movement if storage, sync, and session controls are weak.

Key questions

Q: How should security teams govern AI coding tools that store credentials locally?

A: Treat AI coding tools as part of the secrets estate, not just developer utilities. Classify their credential files, keychain entries, sync settings, and environment-variable fallbacks under the same lifecycle, access review, and offboarding controls used for other non-human identities. The key is to govern where tokens live, how they move, and which services they can reach.

Q: Why do AI assistants create more credential risk than traditional developer tools?

A: They often aggregate access to many external services in one workflow, then persist those credentials in predictable local files or sync them into shared environments. That concentration increases blast radius. A single compromise can expose code repositories, chat, cloud projects, and databases instead of just one application boundary.

Q: What breaks when AI tool credentials are stored as plaintext JSON?

A: Plaintext storage removes the protection that should exist between a local file read and reusable identity. Malware, rogue extensions, WSL mounts, or accidental repo commits can recover tokens without bypassing MFA or password policies. At that point, the secret becomes the account, and the local file becomes the attack path.

Q: Should organisations allow remote control features in AI coding assistants?

A: Only with re-authentication, scoped permissions, and explicit governance around what the live session can do. If a remote link inherits full local privileges, it becomes a bearer token for code execution and file access. That design is too close to privileged access to leave outside PAM-style controls.

Technical breakdown

Plaintext credential storage in AI desktop tools

Many AI coding tools write OAuth tokens, API keys, and service credentials into local config files under the user's home directory. In practice, that means predictable paths such as assistant settings, MCP configuration files, and workspace-scoped JSON become the de facto secret store. When the file is plaintext or weakly protected, any process with read access can extract reusable credentials. The technical issue is not just storage format, but discoverability and portability: once copied, the token often works from another machine or session until revoked or rotated.

Practical implication: inventory AI tool credential locations and treat them as production secrets, not developer convenience files.

MCP token aggregation and shared compromise

Model Context Protocol servers centralise access to external systems by design, which means one configuration file can hold tokens for code hosting, chat, databases, and cloud tools at once. That aggregation is efficient for the user but dangerous for security because compromise of a single file can expose multiple service identities. This is a classic blast-radius problem. The risk increases when tokens are stored inline rather than referenced from secure storage, because the file itself becomes both configuration and credential vault.

Practical implication: separate MCP configuration from secret material and reduce the number of services any one config file can expose.

Remote control and extension paths as identity bypass channels

Several AI tools add remote session control or depend on extension frameworks that run with broad user-level permissions. If a remote session does not require re-authentication, the session URL can function like a bearer credential. In VS Code-style extension ecosystems, sandboxing gaps and shared secret stores mean one malicious extension may read another extension's data or the underlying keychain-backed secret. This is why local encryption alone is not enough when the threat is a live process under the same user context.

Practical implication: require re-authentication for remote control, and do not assume extension-level encryption protects against same-user abuse.

Threat narrative

Attacker objective: The attacker wants to convert one exposed AI credential store into persistent access across multiple developer and enterprise services.

1. entry: An attacker gains read access through malware, a compromised extension, WSL file access, or a repo leak that exposes AI tool credentials in predictable paths.
2. escalation: The attacker uses copied OAuth tokens, API keys, or MCP tokens to authenticate as the victim and inherit access to connected services.
3. impact: The attacker pivots through remote control sessions, local shell commands, or aggregated MCP connections to steal data, modify systems, or extend compromise across repositories, chat, and cloud tooling.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Predictable credential paths have created a new secret sprawl problem inside AI tooling. The issue is not that AI assistants need access, but that too many of them persist that access in files designed for convenience rather than governance. Once credentials sit in predictable JSON paths, the identity model collapses from controlled delegation to easily harvested shared secrets. Practitioners should treat AI desktop storage as part of the secrets estate, not an edge case.

MCP token aggregation concentrates blast radius in a way many IAM programmes are not modelling. One MCP config can hold tokens for source code, chat, databases, and deployment tooling, which means a single disclosure can expose several identities at once. That is a governance failure mode, not just a storage defect. Identity blast radius: when one readable file unlocks multiple downstream services, the control question becomes how much access one local credential artefact can fan out into. Practitioners should re-evaluate segmentation assumptions across assistant-linked systems.

Remote control sessions turn local trust into a usable bearer credential. The article shows that once a session is active, the connection itself can become a control plane if re-authentication is missing. That means the security boundary is no longer the device login or the user prompt. It is the live session token and the permissions behind it. Practitioners should treat remote assistant control as privileged access and govern it accordingly.

Same-user process access is the real weak point in extension-based secret handling. Encryption at rest inside application databases helps against offline disk theft, but it does not protect against a malicious extension or another process running as the same user. That is why sandboxing, extension trust, and OS keychain assumptions matter together. Practitioners should not count local encryption as a sufficient control boundary for AI development environments.

Static secret storage is becoming incompatible with the way AI assistants operate. These tools chain credentials, reuse sessions, and connect to more external systems than most traditional developer tools ever did. The result is a governance model that assumes one identity equals one purpose, when the article shows one identity can fan out into many services. Practitioners should redesign policy around connected service scope, not just individual token ownership.

From our research:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to The 2024 State of Secrets Management Survey.
• 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management.
• The Guide to the Secret Sprawl Challenge shows how to structure discovery and containment when secrets proliferate across tools and workflows.

What this signals

Secret sprawl is no longer confined to pipelines and cloud workloads. AI coding assistants extend the same problem into developer desktops, where local files, sync services, and extension ecosystems can all become secret repositories. Teams that already struggle with secrets governance should expect AI tooling to widen the discovery surface before it ever improves productivity.

Identity blast radius now includes the assistant itself. When one tool can reach code, chat, cloud services, and databases, governance has to focus on connected-service scope rather than a single login event. That is a meaningful shift for IAM and PAM teams because it changes what must be reviewed, what must be revoked, and what must be segmented.

For security programmes that already track workload identity and secrets lifecycle, the next control gap is policy enforcement at the assistant boundary. The question is not whether AI tools need credentials, but whether those credentials are allowed to persist, sync, and fan out into other services without strong containment.

For practitioners

• Map every AI tool secret location Identify all credential files, keychain entries, sync paths, and environment-variable fallbacks used by AI coding assistants on Windows, macOS, Linux, and WSL. Include per-user, workspace, and repo-scoped locations so you can classify them under secrets governance and access reviews.
• Move MCP credentials out of inline JSON Replace inline tokens with secure references or runtime retrieval where the tool supports it, and block repository commits of .mcp.json and similar files. Reduce the number of services exposed by any single local configuration artefact.
• Require re-authentication for remote sessions Treat remote control links as privileged access paths and force fresh authentication before accepting instructions, especially where shell execution or file writes are possible. Do not allow a session URL to function as a permanent bearer credential.
• Harden extension and WSL trust boundaries Restrict extension installation, review publisher identity, and assume same-user process access can read application secrets. On WSL systems, validate Windows-mounted paths and permissions because local protection may not survive the mount boundary.

Key takeaways

• AI coding assistants are turning credential storage into an identity governance problem because one local file can now expose several downstream services.
• Plaintext JSON, predictable paths, and weak session controls combine to create a high-blast-radius compromise path for developers and defenders alike.
• The practical response is to move AI tool credentials into governed secrets workflows, tighten remote session access, and treat extension trust as part of identity policy.

Key terms

• MCP token aggregation: MCP token aggregation is the practice of storing credentials for multiple external services inside one Model Context Protocol configuration or adjacent secret file. It increases convenience, but it also concentrates blast radius. If the file is exposed, several downstream identities can be compromised at once, which turns a local leak into multi-system access.
• Remote control session: A remote control session is a live connection that lets a user operate an AI assistant on another device or through a browser interface. In security terms, it can behave like a privileged session token if it inherits the local machine's permissions without fresh re-authentication or scoped approval for each action.
• Same-user process abuse: Same-user process abuse occurs when a malicious process running under the victim's user context can read files, decrypt application secrets, or invoke shared application resources. It is important because local encryption alone often protects only against offline theft, not against a live process with the same permissions.
• Secret sprawl: Secret sprawl is the uncontrolled spread of credentials across files, tools, environments, and sync services. In AI development environments, it often appears when tokens are copied into config files, extension storage, workspace settings, or environment variables without central governance, making discovery and revocation slow.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Netwrix: Your AI coding assistant is leaking secrets. Read the original.