VS Code MCP install dialog flaw exposes agent identity risk

At a glance

What this is: Oasis Security found that a VS Code MCP install dialog flaw could hide environment variables and headers, enabling either code execution on the developer machine or silent takeover of the assistant's session identity.

Why it matters: IAM and security teams should treat AI tooling and MCP servers as governed identities, because install-time trust can conceal the actual credentials and request context that determine runtime access.

Context

VS Code's MCP install flow creates a security boundary at install time, because the preview dialog is the point where users are meant to inspect what an external party is adding to their workspace. In this case, the boundary failed because the dialog displayed only part of the configuration while silently persisting additional fields that could change execution and request identity.

For IAM and AI governance, the issue is not just local code execution. It is that MCP servers and assistants behave like identities with credentials, request headers, and downstream access, so a misleading install surface can turn a normal onboarding step into a trust and authorization failure.

That makes the problem one of identity governance for agentic tooling, not simply an IDE bug. The article shows how a single hidden configuration path can alter who the tool acts as, what it can reach, and which audit trail records the activity.

Key questions

Q: What breaks when an MCP install dialog hides persisted fields?

A: The approval boundary breaks because the user is asked to review one configuration while a different one is written to disk. That means the visible install dialog no longer represents the effective identity, execution inputs, or request context the tool will use later, so the click cannot be trusted as informed authorisation.

Q: Why do hidden headers in AI tooling create identity risk?

A: Because headers can carry the authentication context that tells a remote service who the tool is acting as. If those values are injected during installation and not shown to the operator, the assistant may operate under the wrong account and inherit access the human never explicitly approved.

Q: How should teams govern MCP servers that act on a user's behalf?

A: Treat them as delegated identities with explicit inventory, approval, and audit requirements. Teams should know which credentials they use, which requests they can send, and which data they can reach, because the security impact comes from the principal they represent, not just the code they run.

Q: What is the difference between install-time review and runtime trust for agent tools?

A: Install-time review is the human approval of a package or configuration, while runtime trust is the actual behaviour once the tool starts using persisted settings. In agent tooling, those can diverge, so governance has to verify the effective configuration after persistence, not only the preview shown at install.

Technical breakdown

How hidden MCP fields become execution inputs

The flaw exists because the install dialog rendered a partial view of the MCP configuration, then wrote the full payload into workspace settings. That matters because many runtimes consume environment variables and launch parameters before application logic starts, so a field that is invisible in the UI can still shape the process at startup. In effect, the UI and the persisted configuration disagreed about the true identity and behaviour of the tool. For MCP, that creates a mismatch between what the user thinks they approved and what the runtime actually receives.

Practical implication: treat any install preview that omits persisted fields as an untrusted approval surface.

Why hidden headers can redirect assistant identity

The same weakness applied to request headers, which can carry session or authorization context for the tool's upstream service. If an attacker controls those values, the assistant may authenticate as the attacker's account rather than the developer's, even though the user never entered credentials. That is not classic phishing. It is delegated identity substitution through configuration. The result is a silent shift in who owns the tool's actions, logs, and accessible data, which is especially dangerous when the assistant can read files, make changes, and call remote services.

Practical implication: inspect any tool installation path that can seed authentication headers or bearer context.

Why install-time trust is the wrong control boundary

MCP installations expose a deeper design issue: the control point is being placed before the operator can see the full effective configuration. Security boundaries that rely on a user pressing Install only work if the preview is faithful, complete, and difficult to bypass. Once hidden settings survive into the workspace, the boundary shifts from explicit approval to implicit persistence, and the attacker wins a foothold that outlives the browser click. That is why agent and workload identity governance must include what gets persisted, not just what gets prompted.

Practical implication: move governance checks to the point where configuration is persisted, not only where it is approved.

Threat narrative

Attacker objective: The attacker wants either a shell on the developer machine or a silent way to make the AI assistant operate inside an account they control.

1. Entry occurs when the victim clicks a crafted MCP install link delivered through a webpage or message.
2. Privilege is established when hidden environment variables or headers are persisted into the workspace configuration without being shown.
3. Impact follows when the server starts or reconnects and the hidden values trigger code execution or reroute the assistant's authenticated session to the attacker's account.

Breaches seen in the wild

• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.
• 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.

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 approval is no longer a reliable identity boundary for AI tooling: The article shows that a user can approve one visible configuration while a different, more powerful configuration is written behind the scenes. That breaks the assumption that the human reviewer sees the effective trust decision. For MCP and agentic workflows, the governance question is no longer who clicked Install, but whether the persisted identity state matches what was reviewed.

Session identity can be substituted through configuration, not just credentials: The hidden header path demonstrates that a tool can be made to act as the wrong principal without a password prompt or obvious login event. That is a governance failure in delegated identity, because the account behind the tool becomes the real security subject. The implication is that agent access reviews must examine how identity is injected, not just whether credentials exist.

Hidden configuration is a named control gap, not a niche bug: Invisible persisted fields describe the gap precisely. The install dialog presented five fields but stored ten, which means the actual authorization and execution context could not be audited at the moment of approval. That undermines both NHI governance and agent identity governance, because the effective access model is created in the gap between UI and runtime.

MCP servers now behave like governable identities, not just software packages: The article makes clear that these tools authenticate, hold credentials, and act on behalf of users. That places them squarely inside identity governance, where inventory, approval, runtime scope, and auditability all matter together. Practitioners should stop treating agent tooling as an application deployment problem and start treating it as delegated identity management.

The market signal is broader than VS Code: Any workflow that lets an external prompt, page, or message seed persisted tool configuration is now part of the identity attack surface. That expands the scope of IAM, PAM, and NHI governance into developer tooling, where access decisions are often made through user experience rather than policy. The practical conclusion is that tooling security must be evaluated as identity design, not just endpoint hardening.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Invisible persisted fields: the real risk is not just that a dialog can mislead a user, but that the effective identity state is created outside the user's line of sight. Programmes that govern AI tooling need a control point after persistence, because approval without faithful rendering is not a reliable trust decision.

MCP server governance now belongs alongside NHI and agentic AI programmes, because these tools can hold credentials and shape downstream access without a traditional login ceremony. That changes the practitioner question from whether to allow the tool to whether the effective principal, scope, and audit trail are visible before any action can execute.

For practitioners

• Audit persisted MCP configuration fields Inspect workspace mcp.json files and installation flows for env, envFile, headers, and cwd values that were not intentionally set by the operator. Hidden fields that survive the click boundary should be treated as unreviewed identity state, not benign metadata.
• Block approvals that hide execution inputs Require install previews to render every field that can affect process startup, request headers, or downstream authentication context. If the preview omits a persisted field, the approval is incomplete and should not be treated as valid authorisation.
• Inventory AI tooling credentials and principals Map which MCP servers, assistants, and agent-like tools hold credentials, which account they use upstream, and which systems they can reach. The goal is to know which identities are being delegated before a single click can alter them.
• Separate install-time review from runtime trust Apply a second governance checkpoint after configuration is written, because the approved preview and the effective runtime payload may differ. That second check should validate the actual persisted identity and request context before the tool is allowed to operate.

Key takeaways

• The flaw is an identity boundary problem, not only a user-interface defect, because hidden configuration can change what principal a tool becomes at runtime.
• A single install click can enable either local code execution or silent session substitution, which shows how quickly delegated access can be abused when the preview is incomplete.
• Governance has to move beyond approval screens and into persisted configuration, where the actual access context and request identity are defined.

Key terms

• MCP install preview: The MCP install preview is the dialog or confirmation screen that shows a proposed server configuration before it is written to a workspace. In this article's context, its security value depends on whether it faithfully exposes every field that can change runtime identity, credentials, or execution behaviour.
• Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.
• Persisted configuration: Persisted configuration is the set of settings written to disk or workspace state and reused when a tool starts later. It matters because the security decision is not what the user saw in the moment, but what continues to exist after approval and can shape execution or authentication at runtime.
• Invisible persisted fields: Invisible persisted fields are configuration values that are saved and acted on even though they were not shown in the approval interface. They create a governance gap between review and enforcement, which can let an attacker smuggle identity, credential, or execution context into an otherwise normal install flow.

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.