VSCode’s MCP usability fixes show where identity controls still lag

At a glance

What this is: WorkOS describes how VSCode improved MCP usability across installation, API key handling, tool discovery, tool scale, and context management, but the article also shows that those same conveniences expose unresolved identity and governance gaps around delegated access.

Why it matters: IAM and NHI teams need to treat MCP onboarding, secret handling, and tool delegation as governance problems because the easiest developer workflows are now also the easiest paths to uncontrolled access.

Context

Model Context Protocol, or MCP, connects AI clients to tools and data sources. In this article, the governance gap is not the protocol itself but the way installation, credential entry, and tool delegation are becoming routine inside developer workflows without the same controls that govern other non-human access paths.

VSCode's changes make MCP easier to adopt by reducing the number of manual steps needed to install servers, pass API keys, select tools, and manage context. That convenience matters because the more natural the workflow becomes, the more often identity, secret, and authorization decisions move from deliberate administration into ad hoc runtime use.

For IAM and NHI programmes, that shift turns MCP from a developer-experience story into a control-design issue. Once tools can be installed, credentials entered, and context reused with minimal friction, the programme has to know who or what is being trusted, for how long, and under what approval boundary.

Key questions

Q: How should teams govern MCP server installation in developer environments?

A: Treat MCP server installation as a controlled enrollment step, not a convenience action. If the installer can collect API keys, register tools, or establish persistent session authority, then approval, logging, and ownership need to happen at install time. The key control is deciding who can add trusted tools before they become part of daily developer workflow.

Q: Why do MCP workflows increase risk when credentials are entered during setup?

A: Because the credential becomes part of a delegated tool path rather than a one-time login event. If the secret is tied to a client-managed workflow, it can outlive the intent behind the install, spread across environments, or be reused for unrelated sessions. The governance issue is scope, not just storage.

Q: What happens when an MCP client exposes too many tools in one session?

A: The user loses practical visibility into what access is actually active, and least privilege becomes hard to enforce at runtime. A large tool set increases the chance of accidental overreach, confusing prompts, and session drift. Teams need tool scoping and inventory controls or the session boundary becomes the weak point.

Q: How do MCP context features change identity and access governance?

A: Context features turn session memory, summarisation, and reusable modes into part of the trust model. If context can carry decisions, data, or tool selections across tasks, then the organisation must govern what is reused, what is summarised, and what is isolated. Otherwise, the client can blur boundaries that policy assumes are separate.

Technical breakdown

MCP installation changes where trust is established

MCP server installation is no longer just a packaging step. When a client like VSCode hides JSON editing and lets a user install a server through a guided interface, trust is established at onboarding time through registry metadata, authentication prompts, and the client’s own installation flow. That changes the security boundary from manual configuration to delegated setup, where the client decides what the user sees and when credentials are requested. The key risk is that the workflow now feels like app installation rather than privileged access grant, even though it creates live access paths to tools and data.

Practical implication: treat MCP installation as an access control event, not a convenience feature.

API key handling moves secrets out of configuration files

The article’s security improvement is that API keys are entered as structured inputs during installation instead of being pasted into configuration files. That matters because config-file secrets are easy to copy, reuse, leak, and persist beyond their intended scope. In MCP environments, the credential is often the control plane for downstream tool use, so where the secret lives affects whether it can be governed, rotated, or revoked. Moving secrets out of JSON does not eliminate risk, but it does change the attack surface from file sprawl to managed secret entry.

Practical implication: stop allowing manual secret injection into persistent MCP configs.

Tool discovery and sampling expand the runtime trust surface

VSCode’s tool picker, chat modes, and sampling features reduce the need for users to know exact tool invocations or receive full raw outputs. That improves usability, but it also broadens the runtime trust surface because the client is now mediating which tools appear available and how much context flows back into the session. In MCP terms, the security question is not only whether a tool exists, but whether the client can expose, combine, and summarize tools in ways the organisation can still audit. Unlimited tools magnify that issue by making access breadth harder to see.

Practical implication: govern tool exposure and session context as part of the MCP control set.

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.
• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.

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

NHI Mgmt Group analysis

MCP usability is now an identity problem, not just a developer-experience problem: The article shows that installation, secret entry, and tool selection are being normalised into a single client flow. That means governance no longer sits only at provisioning or in a vault, but inside the runtime path where tool trust is granted and exercised. For practitioners, the relevant question is whether the onboarding path itself is now the access decision.

Ephemeral credential trust debt: The convenience of structured API key entry reduces friction, but it also encourages credentials to be issued and used with less deliberation than traditional admin workflows. That creates trust debt when the organisation cannot easily prove which key was entered, for which tool, and under which approval boundary. The implication is that secrets governance has to follow the installation moment, not just the storage location.

MCP tool explosion changes what least privilege means in practice: The article’s support for 171 tools at once illustrates that breadth, not just sensitivity, becomes the governance challenge. Once a client can surface many tools dynamically, the control question shifts from “can this identity authenticate?” to “which tool set was exposed in this session, and why?” Practitioners should treat tool inventory, selection, and session scope as one policy surface.

Context engineering becomes a governance surface when context is reused: Reusable chat modes and sampling make context portable across tasks, which improves efficiency but also blurs task boundaries. That means context is now part of the security model because it can shape what the client reveals, retains, or recycles across requests. For identity programmes, the practical conclusion is that session context needs the same governance mindset as secrets and credentials.

Official protocol adoption will force control standardisation: As the official MCP registry spec matures, the ecosystem will need more consistent expectations for authentication, authorisation, and tool exposure. The article signals that ad hoc handling is already giving way to repeatable client behaviour, and repeatable behaviour is what governance can finally measure. Practitioners should be ready to map MCP onboarding and runtime controls to explicit policy rather than developer preference.

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

Ephemeral credential trust debt: When installation flows hide the mechanics of secret entry, the governance burden shifts from visible configuration to invisible runtime trust. That makes MCP adoption look easy while quietly increasing the number of places where a credential can be introduced, reused, or forgotten.

MCP adoption is likely to move from experimentation to routine use as clients make installation and tool selection feel native to developer workflows. That shift will expose which programmes can already govern delegated tool access and which ones still rely on manual discipline.

Teams should expect MCP controls to converge with broader NHI governance patterns, especially around onboarding, revocation, and session scope. The clients may differ, but the control questions are the same: who granted access, what did it unlock, and how is it withdrawn?

For practitioners

• Treat MCP server installation as a control point Require review of what a server can access before it is installed, not after it is already available in the client. Installation should map to an approval or trust decision, especially when the server can reach sensitive tools or data sources.
• Remove API keys from persistent configuration files Move credential entry into managed prompts or vault-backed flows so secrets are not copied into JSON blobs that persist across environments. The goal is to eliminate static secret handling inside the MCP configuration path.
• Define tool exposure rules for each session Limit which tools can appear in a given workflow and record when the client broadens that set. If a user can load dozens or hundreds of tools, the governance model has to account for session scope and tool inventory, not just authentication.
• Audit context reuse and sampling behavior Review how chat modes, resource links, and sampling change what information is retained or summarised during a session. That review should focus on whether context reuse can expose data across tasks that should remain isolated.
• Align MCP onboarding with NHI policy Map MCP installations, tool grants, and secret inputs to the same lifecycle expectations used for other non-human access paths, including revocation, ownership, and review. The client experience may be simple, but the governance requirement is not.

Key takeaways

• MCP convenience is compressing installation, credentials, and tool choice into a single user flow, which weakens the separation between setup and access governance.
• The main security issue is not one missing feature but the accumulation of trust in client-mediated onboarding, persistent secrets, and broad runtime tool exposure.
• Identity and access teams need to govern MCP with the same lifecycle discipline used for other non-human access paths, including approval, scope control, and revocation.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Mcp Registry: An MCP Registry is a catalog that lists available Model Context Protocol servers, tools, and resources for AI agents to discover and use. It typically stores metadata such as endpoints, capabilities, ownership, and trust information, helping organizations govern which tools agents can access and how those connections are managed.
• Context Engineering: The practice of selecting, curating, and delivering the information an AI system uses at runtime. In agentic environments, context engineering is a security function because the quality, provenance, and trust level of the inputs directly shape the system’s actions and outputs.
• Delegated tool privilege: Delegated tool privilege is the effective authority an AI agent inherits from the systems it can call, even when it is not the owner of those systems. It is the practical blast radius created by connectors, credentials, and runtime permissions. This is often the real control boundary in agentic environments.

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.