TL;DR: AI desktop assistants and coding tools often store OAuth tokens, API keys, and MCP credentials in plaintext JSON at predictable locations, creating easy theft paths through malware, WSL exposure, extension abuse, and session hijacking, according to Netwrix. The core issue is not just exposure, but trust assumptions that let one readable file or session inherit far more access than governance teams expect.
At a glance
What this is: This analysis shows that AI coding assistants commonly place reusable credentials in predictable local files, sync paths, and extension stores, creating an easy theft surface across desktop and developer environments.
Why it matters: It matters because IAM and NHI teams now have to govern assistant-stored secrets, token reuse, and delegated tool access as part of the same control plane, not as an afterthought.
Context
AI coding assistants need credentials to reach cloud services, but many of them keep those credentials in plaintext JSON files under predictable paths. That turns local storage into an identity control problem, because the file location often matters more than the tool brand.
The article examines 14 popular AI tools across Windows, macOS, and Linux and shows how storage choices differ across platforms, keychains, and extension stores. The governance issue is not limited to one application; it is the pattern of brittle secret handling across the AI assistant stack.
For identity programmes, the core question is whether assistant-held secrets are being treated as governed NHIs with inventory, storage, and offboarding discipline, or as convenience data left to accumulate in user home directories.
Key questions
Q: What breaks when AI coding assistants store secrets in predictable local files?
A: Predictable file paths turn credential storage into a discoverable attack surface. If OAuth tokens, API keys, or MCP secrets live in plaintext JSON, any same-user process, malware, or misconfigured sync feature can read them. The failure is not only exposure, but the loss of a stable trust boundary around assistant-held credentials.
A: Plaintext administrator credentials collapse the boundary between initial access and full environment control. Once an attacker finds credentials in scripts, shared files, or other accessible locations, they can often move into privileged systems, cloud services, and source code repositories. The risk is not the file itself, but the fact that exposed admin secrets can turn a limited foothold into broad operational access.
Q: What are the signs that AI assistant secret storage is misconfigured?
A: Look for inline tokens in JSON, synced extension settings, world-readable files in WSL, and any assistant profile that stores multiple service credentials together. Those patterns show that storage convenience has overridden secret governance. If the same file can authenticate to several systems, the risk is already elevated.
Q: Should organisations treat AI assistant credentials as NHI assets?
A: Yes. Assistant-stored tokens behave like non-human identities because they authenticate to external services, persist across sessions, and often outlive the user action that created them. Governance should cover inventory, scope, storage, rotation, and revocation, because the exposure pattern is identity-driven rather than purely endpoint-driven.
Technical breakdown
Why plaintext JSON becomes an identity control failure
Many AI assistants persist OAuth tokens, API keys, and MCP credentials in JSON because they need unattended access to external services. The security problem is that plaintext local storage makes the credential itself the control point, so file permissions, sync settings, and path predictability decide who can authenticate. Once a token is copied, the service often cannot distinguish the original device from the stolen copy. In identity terms, the secret becomes a portable authenticator rather than a managed trust object.
Practical implication: Treat every assistant credential file as a governed secret store, not a convenience cache.
How credential aggregation expands the blast radius
MCP configurations are especially risky because they concentrate tokens for multiple services in a single file. That creates a one-read compromise pattern: one exposed file can yield GitHub, Slack, database, and cloud access at once. The problem is not only exposure, but aggregation of trust boundaries that were never meant to fail together. This is the same structural weakness seen when multiple dependencies share one credential container: once the file is reachable, lateral movement is immediate.
Practical implication: Separate high-value tokens by service and eliminate shared credential bundles wherever possible.
Why remote control and extension trust assumptions fail
Remote control features and unconfined editor extensions turn local secret exposure into live execution risk. If a session reuses the local assistant context without re-authentication, the session URL can function like a bearer token. Extension secret storage also relies on process-level trust that disappears when any same-user process or malicious extension can read the store or its key material. That means encryption at rest alone is not enough when the runtime boundary is already porous.
Practical implication: Reassess whether your assistant sessions, extensions, and key storage model assume a trusted local process boundary that no longer exists.
Threat narrative
Attacker objective: The attacker wants to convert one local credential exposure into reusable access across the victim's assistant session, connected services, and downstream developer systems.
- Entry occurs when malware, a malicious extension, or a shared file path exposes the assistant's plaintext credential file or synced configuration store.
- Credential access follows when OAuth tokens, API keys, or MCP tokens are copied from predictable locations and become portable to another machine or process.
- Escalation happens when the stolen credentials are used to reopen assistant sessions, invoke connected tools, or access multiple services through one aggregated configuration.
- Impact is broad account and data compromise, with persistence when refresh tokens or remote control sessions remain valid after the initial theft.
Breaches seen in the wild
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
- Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.
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
Predictable secret paths create identity exposure, not just storage exposure. When credentials live in known JSON files, the security boundary shifts from authentication to file discovery. That means local OS permissions and sync behaviour become identity controls, which is a poor fit for secrets that can authenticate to multiple external services. The practitioner conclusion is that file location is part of the trust model.
Credential aggregation is the real blast-radius amplifier. A single MCP config or assistant profile can concentrate access to code repos, chat systems, databases, and cloud services. That collapses what should be separate trust domains into one failure point, which is why isolated service-specific tokens matter more than the assistant brand. Practitioners should treat aggregated assistant configs as high-risk NHI containers.
Portable refresh tokens undermine the assumption that access remains device-bound. Once a refresh token can generate new access tokens from elsewhere, governance no longer tracks a machine, it tracks a reusable identity artefact. That is an NHI pattern, not a desktop hygiene issue, and it demands inventory, revocation, and scoping discipline. The practitioner conclusion is that token portability must be governed like standing privilege.
Trust assumptions built for interactive users do not survive assistant-mediated control. Remote control sessions and same-user extensions often assume that the local runtime is benign. When the local process boundary is weak, those assumptions fail and the assistant becomes a high-trust proxy for anything connected to it. The practitioner conclusion is to reassess where human and machine trust boundaries now overlap.
Identity blast radius is the right named concept for this problem. One readable file can unlock many services because the assistant architecture reuses credentials across tools and sessions. That is a governance failure in how access is packaged, not merely where it is stored. The practitioner conclusion is to reduce blast radius before adding more assistant integrations.
What this signals
Identity blast radius is now a desktop problem. When an assistant stores multiple service tokens in one config file, a single local read can become broad service compromise. That pushes NHI governance into developer workstation policy, not just vault design or cloud access reviews.
The strongest control shift is from protecting the file after storage to eliminating the need for the file in the first place. Runtime credential helpers, keychain-backed storage, and strict session re-authentication reduce the number of places where assistant trust can silently expand.
For practitioners
- Audit assistant credential paths Inventory every AI desktop assistant, coding tool, and CLI that stores tokens in home-directory files, extension stores, or synced config paths. Include Windows, macOS, Linux, and WSL locations because the same product can expose different file modes across platforms.
- Replace plaintext token storage Move OAuth tokens, API keys, and MCP secrets out of plaintext JSON and into OS keychains or runtime credential helpers wherever the tool supports it. Remove inline secrets from shared configs and treat any file with reusable tokens as a managed secret store.
- Reduce MCP credential aggregation Split multi-service MCP configs so one file does not carry GitHub, Slack, database, and cloud credentials together. Where aggregation cannot be avoided, scope each token narrowly and review whether the assistant needs persistent access at all.
- Require re-authentication for remote sessions Treat remote control features as separate access paths that must authenticate independently from the local assistant session. Do not let a session URL inherit full execution authority or skip permission prompts for shell, file, and tool actions.
- Block cloud sync of assistant secrets Disable settings sync for files that contain credentials and verify that editor extensions are not uploading secret-bearing configuration into cloud storage. Sync settings are convenience features, not safe secret distribution channels.
Key takeaways
- AI coding assistants are turning everyday developer workflows into secret distribution channels when tokens live in predictable local files and synced configs.
- The most dangerous pattern is credential aggregation, where one assistant file can unlock multiple services and extend access beyond the original device or session.
- Practitioners should inventory assistant-stored secrets, move reusable tokens out of plaintext storage, and separate remote control from local session trust.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10, OWASP API Security Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Plaintext JSON and synced config files expose assistant secrets directly. |
| NHI-07 — Long-Lived Secrets | Refresh tokens and stored API keys persist far beyond a single session. | |
| NHI-05 — Overprivileged NHI | Aggregated MCP files often bundle far more access than one task requires. | |
| Recommendation — Scan assistant config paths for exposed secrets and remove plaintext credential storage. Replace long-lived assistant credentials with shorter-lived, scoped token patterns. Limit assistant credentials to the narrowest service scope possible. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Remote sessions and extension trust can let stolen identity artefacts drive unauthorized actions. |
| Recommendation — Separate assistant identity from local user authority and re-authenticate privileged sessions. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Portable tokens and remote session reuse weaken authentication boundaries across services. |
| Recommendation — Validate token audience and session binding before allowing assistant-mediated access. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack pattern centers on stealing tokens and reusing them across connected services. |
| Recommendation — Map assistant secret exposure to credential access and hunt for downstream service reuse. | ||
Key terms
- Credential Aggregation: The concentration of multiple tokens, keys, roles, and secrets inside one runtime identity. This raises blast radius because compromise of the agent can expose every system those credentials can reach, making actor-level governance more useful than secret-by-secret review alone.
- Persistent Token: A persistent token is a credential that remains valid across sessions and can continue authorizing access until it is revoked or expires. These tokens are risky in AI and SaaS environments because they often outlive the original workflow and are hard to track consistently.
- 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.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org