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

At a glance

What this is: WorkOS highlights how VSCode reduced the main MCP developer pain points, with the clearest security theme being safer credential handling during server installation.

Why it matters: This matters because IAM teams are now being asked to govern MCP-style access patterns that blur the line between application configuration, secret distribution, and runtime tool authorization.

👉 Read WorkOS's MCP Night 2.0 recap on VSCode's developer experience fixes

Context

Model Context Protocol is turning developer tooling into an identity and access problem as much as a usability problem. Once API keys, tool access, and context-sharing move into the same workflow, traditional assumptions about who approves access and when that access is granted start to fray.

WorkOS’s source article focuses on how VSCode made MCP easier to install, safer to set up, and less noisy to use. The broader governance question is whether organisations can keep treating these flows as developer convenience when they are increasingly acting as credential and authority distribution paths.

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 tool pickers create governance risk even when users stay in control?

A: Tool pickers can turn one-off access into repeatable authority patterns. When users save tool bundles or reusable modes, the client is no longer just helping them choose actions, it is normalising a stable access profile. That matters because repeated authority is easier to misuse, harder to spot, and often broader than the original task.

Q: What breaks when MCP context handling becomes too compressed?

A: Auditability breaks first. Sampling and summary layers can hide the precise sequence of tool use, data access, and prompt coordination that led to a result. If the environment only preserves condensed output, investigators lose the evidence needed to understand whether access was appropriate, excessive, or misused.

Q: What should security teams do when MCP usage starts spreading across many tools and modes?

A: They should define exposure boundaries for the tool classes each environment is allowed to surface, then review those boundaries as usage grows. Once a client can load very large tool sets, the risk is not just clutter. It is uncontrolled authority expansion across tasks, teams, and sessions.

Technical breakdown

MCP server installation and credential capture

MCP server setup can move sensitive access from manual configuration into an install flow that looks benign but still establishes authority. In the article’s example, API keys are no longer pasted into JSON blobs, which reduces obvious exposure, but the real mechanism is that installation becomes the moment when trust is granted. That shifts risk from file handling to onboarding control. The protocol and client experience together determine whether credentials are typed, stored, or brokered. Practical implication: treat MCP installation as a privileged enrollment event, not a simple developer convenience step.

Practical implication: control MCP installation as a privileged enrollment event with explicit approval and audit.

Tool discovery, chat modes, and runtime authority

The article shows a client that can surface many tools, let users pick among them, and store useful combinations as reusable chat modes. That is more than interface design. It is a delegation mechanism that shapes which tools are reachable in a session and how often users reuse the same authority pattern. Even when the user is driving, the toolset being presented can create durable access habits that outlive the original task. Practical implication: govern reusable tool bundles and session templates as authority objects, not just productivity features.

Practical implication: govern reusable tool bundles and session templates as authority objects, not just productivity features.

Context management, sampling, and log visibility

Sampling and resource links are meant to stop context bloat, but they also determine what data is surfaced, summarized, or hidden from the operator. In an identity sense, that matters because the system is shaping the evidence trail around tool use. The same article also notes deeper logs for agent-MCP coordination, which improves diagnosability but also reveals that the useful control point is observability of action, context, and prompt flow together. Practical implication: require traceability across tool invocation, context reduction, and prompt-level coordination before broad MCP rollout.

Practical implication: require traceability across tool invocation, context reduction, and prompt-level coordination before broad MCP rollout.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

MCP usability work is really authority design work. When an MCP client makes installation, credential entry, and tool selection feel effortless, it is also reducing the friction that normally exposes access decisions. That matters because friction is often the last visible sign that a governance boundary exists. The field should stop treating MCP ergonomics as a separate layer from identity control. Practitioners should read easy setup as a signal to harden the enrollment and authorisation path.

Tool picker design creates a hidden governance layer. The ability to choose tools explicitly, save combinations, and reuse them as chat modes means the client is shaping repeated access patterns. That does not make the system autonomous, but it does make tool authority more durable and more reusable than a one-off prompt. The lesson for identity teams is to classify these patterns as governed access constructs, not harmless UX shortcuts. Practitioners should inventory them as part of the access model.

Context compression changes what can be audited. Sampling, resource links, and summarised outputs reduce overload, but they also change the fidelity of the record around what data was accessed and why. This is where MCP starts to overlap with NHI governance concerns: the more the system abstracts the interaction, the more important it becomes to preserve traceability below the presentation layer. Practitioners should assume that weaker context fidelity means weaker forensic confidence.

The named concept here is context-to-authority drift. The article shows how a convenience layer can quietly convert context handling into access handling, especially when the same environment handles secrets, tools, and agent coordination. That drift is the governance problem, not the feature set. Practitioners should map every place where a developer convenience can also widen runtime authority.

MCP adoption will force IAM, platform, and developer tooling teams into the same conversation. The post demonstrates that identity questions now sit inside the developer experience itself, not beside it. Once that is true, any programme that owns secrets, privileged access, or workstation tooling has to decide who governs installation, who approves tool bundles, and who can reconstruct session behaviour. Practitioners should expect governance ownership to cross team boundaries.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a broader agentic lens, OWASP Agentic Applications Top 10 helps teams map how tool use, context, and authority drift intersect.

What this signals

Context-to-authority drift: when developer tooling makes secrets entry, tool discovery, and session reuse feel seamless, the governance model starts to inherit those shortcuts. The practical consequence is that access design becomes embedded in client experience, which is hard to audit unless teams deliberately separate onboarding, authorization, and runtime tracing.

As MCP spreads into everyday development, the main programme risk is not tool count alone but authority sprawl across installation, chat modes, and context reducers. Teams that already struggle with fragmented secret estates should expect the same pattern to appear in developer agents unless they enforce a single control plane for enrollment and auditability.

The security conversation now has to connect workstation tooling, secrets governance, and agentic access patterns. For practitioners, that means aligning developer experience decisions with identity governance controls rather than treating MCP as a purely technical integration layer.

For practitioners

• Treat MCP installation as an enrollment event Require explicit approval, logging, and ownership assignment when an MCP server is installed, especially if the flow captures API keys or other secrets. The installation step should be reviewed like any other privileged access grant, not handled as routine software setup.
• Inventory reusable tool bundles and chat modes Identify any saved tool combinations, preconfigured modes, or shared client profiles that let users reuse access patterns across sessions. Document who can create them, who can edit them, and whether they expand authority beyond the original task.
• Separate secret entry from freeform configuration Move API key handling out of manual JSON editing and into controlled input flows with validation, audit trails, and secrets management integration. The goal is to reduce accidental exposure while preserving traceability.
• Demand traceability below the UI layer Confirm that tool invocation, context reduction, and agent coordination are logged in a way that supports investigation. If the environment only logs user-visible output, it will not be enough to reconstruct how authority was exercised.
• Define governance for tool discovery at scale If a client can surface dozens or hundreds of tools, set policy for which tool classes can be exposed in which environments and how that exposure is reviewed over time. Scale changes access risk even when the interface stays simple.

Key takeaways

• MCP usability improvements reduce friction, but they also move access decisions into developer workflows that need governance.
• The article’s strongest security signal is not tool abundance, but the way secret handling and reusable tool modes can widen authority quietly.
• Practitioners should treat MCP installation, tool bundles, and context compression as control points that need ownership, logging, and review.

Key terms

• Model Context Protocol: A protocol for connecting AI-enabled clients to external tools, services, and data sources in a standard way. In practice, it becomes an identity and access concern because the same flow can establish which tools are reachable, which secrets are supplied, and what context is exposed during a session.
• Tool bundle: A reusable set of tools or capabilities that a client can present together for a task or session. In governance terms, a tool bundle behaves like a reusable access profile, because it shapes what authority is available, how often it is reused, and whether it is reviewed as a control object.
• Context compression: The process of reducing tool output, search results, or coordination data into a smaller form before presenting it to the user or agent. It improves usability, but it also lowers evidence fidelity, which can make later audit, investigation, and accountability harder if the raw trail is not preserved.
• Secret handling flow: The path a credential takes from entry to storage, use, and rotation. For MCP-style environments, the concern is not only where a secret lives, but whether the entry point is controlled, whether the secret is exposed in configuration, and whether its use is visible to governance teams.

Deepen your knowledge

MCP governance, secrets handling, and developer-facing identity controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building policy around tool-enabled developer environments, it is worth exploring.

This post draws on content published by WorkOS: From Pain Points to Solutions, How VSCode Solved MCP's Biggest Developer Challenges. Read the original.