VS Code MCP install dialog flaw exposes agent identity risk

At a glance

What this is: A VS Code MCP install dialog flaw let hidden settings slip past review, creating one-click code execution and session hijacking risk for AI tooling.

Why it matters: IAM teams need to treat AI agents and MCP servers as governed identities because hidden credentials, headers, and environment variables can turn a trusted install flow into an access-control failure.

👉 Read Oasis Security's analysis of the VS Code MCP install dialog flaw

Context

A VS Code MCP install flow is only safe if the user can actually see the settings being granted. In this case, the dialog rendered five fields while persisting five additional hidden values, which broke the review step that was supposed to establish trust before the tool ran. For teams building around MCP, the primary question is not only whether a server is allowed, but whether the install-time disclosure model is complete enough to govern what the tool can do next.

That matters because MCP servers and AI assistants increasingly behave like non-human identities: they hold credentials, reach external services, and act on behalf of a user or team. When the boundary between visible configuration and hidden execution is unreliable, the governance model for NHI, agentic AI, and developer access collapses at the same point. This is an access-control problem first, a code-execution problem second.

Key questions

Q: What breaks when MCP install dialogs hide runtime settings?

A: The approval step breaks because the user is reviewing an incomplete trust boundary. If environment variables, headers, or other execution-affecting values can be hidden, the installation can authorize a different runtime state than the one the user saw. That turns a local setup action into an identity and access control failure.

Q: Why do hidden MCP credentials and headers matter so much?

A: They matter because they can change which identity a tool uses after installation. A hidden Authorization header or startup secret can make an assistant act under the wrong account, exposing data and actions to the attacker-controlled session. In NHI terms, the access grant outlives the review moment.

Q: How should security teams govern AI tools that write into workspace settings?

A: Treat every workspace-held setting that affects authentication, startup behaviour, or remote access as a governed identity artefact. Require inventory, owner assignment, and periodic review for those settings, and remove anything that cannot be displayed and validated before persistence. If the runtime state is hidden, it should not be auto-approved.

Q: When should organisations treat developer AI tooling as an NHI risk?

A: As soon as the tool can store credentials, call external services, or act on a user's behalf without re-authenticating each time. At that point, it is no longer just software configuration. It is part of the non-human identity estate and should be governed with ownership, scoping, and revocation controls.

Technical breakdown

Hidden environment variables in MCP install dialogs

The flaw sat in the preview boundary of the MCP installation flow. VS Code showed a limited set of fields, but the underlying configuration accepted extra values such as environment variables and headers. In practice, that means the user reviewed one configuration object while the runtime received another. If an attacker can smuggle startup arguments or environment-based loaders into that hidden layer, code execution can begin before the tool's own logic starts. The issue is not complexity alone. It is that the security decision was made on incomplete state.

Practical implication: review the full persisted MCP configuration, not just the visible install preview.

Silent session hijacking through hidden HTTP headers

The same pattern also affects network identity. Hidden headers can carry authentication material that changes which account a tool uses when it connects to a remote service. If those headers are not shown before install, the developer may believe they are authorising one service identity while the tool actually authenticates as another. That turns a local setup action into a delegated access problem. The technical weakness is that identity data and configuration data were allowed to diverge between what the user saw and what the runtime executed.

Practical implication: inspect any persisted Authorization header or equivalent trust token before the tool is allowed to run.

Why workspace persistence turns one click into lasting exposure

Workspace-scoped MCP settings persist across reloads and restarts, which makes the attack durable. Once the malicious configuration is written, the payload does not depend on the original click path staying open. The next startup can reapply the same hidden settings and recreate the compromise state. That persistence is what converts a preview weakness into an operational foothold. For security teams, the architectural lesson is simple: if a hidden control value is written into a durable workspace object, it becomes part of the identity surface until it is explicitly removed.

Practical implication: treat workspace-held MCP settings as durable identity artefacts that require review and revocation.

Threat narrative

Attacker objective: The attacker wants persistent control over the developer's machine or AI assistant session, including shell access, access to tool actions, and exposure of data routed through the compromised account.

1. Entry occurs when the victim clicks a crafted install link that looks like a normal MCP server addition inside VS Code.
2. Credential abuse follows when hidden environment variables or headers are written into workspace configuration without appearing in the preview.
3. Impact arrives when the server starts and the attacker-controlled settings trigger code execution or make the AI assistant operate under the wrong account.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Install-time disclosure is the control, and it failed here because the runtime state outgrew the preview state. The dialog was supposed to be the moment when a human validated what an external party was adding to a workspace. Instead, the persisted configuration contained values that never appeared in the review surface, so the approval step was operating on incomplete information. The practitioner conclusion is that install dialogs for MCP and similar AI tooling must be treated as identity control points, not convenience UX.

Hidden configuration fields create an identity blind spot, not just a UI bug. Once env, envFile, and headers can be smuggled into a durable workspace object, the tool inherits a trust grant the user never consciously made. That is a governance failure in the NHI layer because credentials and execution context can be installed together without equivalent scrutiny. The practitioner implication is that any tool that writes hidden identity material into workspace state expands the non-human identity attack surface.

Ephemeral review assumes the subject of review is stable long enough to inspect. That assumption fails when a developer click can install both code and identity material in one step, because the approval target is not a fixed secret or a fixed server identity. It is a composite runtime state that can change underneath the reviewer before execution begins. The implication is that identity governance for developer AI tools must stop relying on the idea that visible intent and actual execution state are the same thing.

Agent identity governance now reaches the editor boundary, not only the backend boundary. MCP servers and assistants can carry credentials, choose services, and act inside a user's workflow, so the control problem starts at install and continues through runtime use. This does not mean every tool is autonomous, but it does mean the governance perimeter must include what the tool is allowed to become after the click. Practitioners should classify these flows as governed NHI with agentic exposure, not as ordinary software configuration.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to Astrix Security research.
• For a broader control lens, see the OWASP NHI Top 10 for agentic tool and identity risk.

What this signals

The practical signal for security teams is that developer tooling is now part of the identity estate, not just the software delivery stack. Hidden runtime state: when install previews can omit the values that actually govern authentication and execution, approval becomes a false control. Teams should align editor, endpoint, and identity owners around the same control boundary before AI assistants become the path of least resistance for credential abuse.

The broader governance implication is that MCP deployments need explicit scoping and review because most environments still do not have it. Only 18% of MCP server deployments implement any form of access scoping for tool permissions, so organisations should expect default trust to fail first at the tool boundary. That makes inventory, ownership, and revocation the immediate programme priorities, not future enhancements.

For practitioners

• Audit persisted MCP configuration, not just install previews Review mcp.json files and any workspace-scoped settings for env, envFile, headers, cwd, and startup-loader values that were not intentionally entered. Focus on hidden identity material that changes runtime trust after installation.
• Block hidden credential injection paths in developer tooling Require install flows to render every persisted setting that can influence execution or authentication, including Authorization headers and environment variables. If the preview cannot represent the full runtime state, do not treat the click as a valid approval boundary.
• Inventory AI tooling as non-human identity surface Map which MCP servers, assistants, and extensions can access credentials, external APIs, or production systems, then assign owners and review cadence for each identity-bearing component. Use the same control ownership model you would apply to service accounts.
• Separate code execution risk from account trust risk Assess local execution exposure and downstream session identity exposure as two different problems. A patch may stop one-click shell access while leaving account hijacking paths in place if headers or tokens can still be hidden in the configuration.

Key takeaways

• The core failure was not just code execution, but a broken trust boundary that let hidden identity material bypass user review.
• The incident shows why MCP servers and AI assistants must be managed as non-human identities with visible scope, ownership, and revocation.
• The control that matters most here is full disclosure of persisted runtime state before installation, because hidden settings can turn a harmless click into durable compromise.

Key terms

• Mcp Install Boundary: The MCP install boundary is the point where a user reviews and accepts a tool's configuration before it is written into a workspace. In security terms, it is supposed to separate visible intent from persisted runtime state. If hidden values can bypass that review, the boundary no longer governs trust.
• Hidden Runtime State: Hidden runtime state is configuration that affects execution or authentication but is not shown to the person approving the action. In developer tooling, that can include environment variables, headers, or startup options. When hidden state persists beyond the click, it becomes part of the identity attack surface.
• Agent Identity Surface: The agent identity surface is the set of credentials, permissions, and trust relationships used by AI tools, assistants, and related non-human identities. It includes what the tool can reach, what account it uses, and how that access is granted or revoked. Governance fails when this surface is invisible to owners.

Deepen your knowledge

AI agent and NHI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to govern developer tooling and workspace-held identities from a similar starting point, it is worth exploring.

This post draws on content published by Oasis Security: Envade: One Click in VS Code, Full Shell for the Attacker. Read the original.