MCP servers in IDEs create new identity and trust risks

At a glance

What this is: This analysis explains why MCP servers embedded in IDEs create new identity and trust risks by extending AI tools into developer workflows, backend systems, and shared contexts.

Why it matters: It matters because identity teams now have to govern how non-human tools authenticate, inherit privilege, and act across development environments, not just how humans use IDE features.

Context

MCP servers are non-human integration points that connect AI assistants and agents to context, tools, and downstream systems inside development environments. In practice, they can persist state, retrieve documents, and trigger actions across IDE workflows, which means the security model shifts from isolated prompting to governed machine-to-machine access.

The governance gap is that many deployments treat these servers as convenience layers instead of identities with scope, trust boundaries, and lifecycle risk. Once an MCP server can read files, reach internal systems, or reuse broad credentials, the question becomes who or what is authorised to act, under which context, and with what review boundary.

That makes this an IAM and NHI problem as much as an application security problem. The article’s risks are strongest where identity propagation, tool permissions, and third-party dependency trust are weak or inconsistent.

Key questions

Q: What breaks when MCP servers use shared credentials in IDE workflows?

A: Shared credentials break user-level accountability and scope control. The server can fetch data or trigger actions that the individual developer was never authorised to perform directly, which turns a convenience layer into an over-privileged access path. Security teams should insist that downstream systems see the real user or an equally constrained delegated identity.

Q: Why do prompt injection attacks become more serious in MCP environments?

A: Prompt injection becomes more serious because the agent can act on manipulated content, not just display it. If the agent can call tools after reading hostile input, the attack can cross from text influence into real system action, including data access, workflow changes, or exfiltration. The risk is action abuse, not output corruption.

Q: How do security teams know if MCP access policies are too coarse?

A: If a single role or policy grants access to broad datasets or multiple tools when the task needs only one resource, the policy is too coarse. The signal is overpermission, not just denied requests. Good MCP governance should show client-specific consent, narrow scopes, and auditable request context.

Q: Should organisations treat MCP servers as part of the identity control plane?

A: Yes. An MCP server that brokers access to secrets, models, or downstream services is effectively making authorisation decisions on behalf of machine workloads. That makes its retrieval policy, identity trust chain, and audit trail part of identity governance. If those controls are weak, the server becomes a privileged access path rather than a neutral integration layer.

Technical breakdown

How MCP servers change the trust model in IDEs

MCP servers sit between the IDE, the AI model, and external systems, so they are not just plugins but context brokers. They can store memory, retrieve state, and expose tools that the model may call during a session. That architecture creates a larger trust surface because the model no longer reasons only over user prompts. It reasons over server-supplied context, tool descriptions, and returned outputs, any of which can shape execution. If those inputs are untrusted, the IDE becomes a place where instructions, data, and permissions converge.

Practical implication: Treat MCP servers as governed integration points with explicit trust boundaries, not as inert add-ons.

Why access control gaps become more dangerous in MCP workflows

The article highlights that many MCP servers lack strong authentication and may not propagate the real user identity to backend systems. That leads to shared credentials, over-broad tokens, or server-side access that exceeds the developer’s actual rights. In identity terms, the server can become a privilege concentrator: one poorly scoped connection can expose code repos, tickets, databases, or internal files. The risk is not only unauthorized access. It is also confused delegation, where the AI path inherits a standing privilege the human user should not have been able to exercise through that tool path.

Practical implication: Enforce per-user identity propagation and scope tool credentials to the smallest backend privilege that the workflow actually needs.

How prompt injection and tool poisoning work through MCP context

Prompt injection in this setting is a form of context poisoning. Malicious text hidden in code comments, documents, or connected systems can influence the model when the MCP server retrieves it as trusted context. Tool poisoning extends the same pattern by hiding harmful directives in tool descriptions or package metadata so the model selects unsafe actions while the user sees a benign integration. Because MCP servers often combine memory, tool routing, and execution, a single poisoned input can steer both reasoning and action. That is why integrity of context is as important as authentication of the endpoint.

Practical implication: Review retrieved context and tool metadata as security-sensitive inputs, not just as model prompts.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Microsoft Azure OpenAI abuse by Storm-2139: Storm-2139 used API keys leaked by Microsoft customers to hijack Azure OpenAI, bypass safety guardrails and resell access to generate harmful content.

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

MCP servers create an identity layer inside development tools, not just an integration layer. Once a server can persist context, call tools, and reach backend systems, it is participating in access decisions. That means developers are no longer only consuming software features; they are delegating actions through a machine identity path that needs lifecycle and privilege governance. The practitioner implication is to model MCP as NHI, not as a harmless extension.

Identity propagation is the fault line that determines whether MCP access is bounded or shared. The article’s key risk is that servers may authenticate to downstream systems with broad credentials rather than the individual user’s effective rights. That breaks least privilege in practice because the actor performing the action is not the actor whose rights were intended to govern it. The implication is that access scope must follow the user-task boundary, not the server default.

Context poisoning is a governance problem as much as a security exploit. When retrieved documents, tool descriptions, or embedded rules can alter model behaviour, the trust boundary has moved into content itself. That creates a named concept worth tracking: MCP trust spillover, where context, tools, and permissions bleed into each other and the AI can no longer be governed by a single control plane. Practitioners should treat context provenance as part of identity assurance.

Supply chain risk is amplified because unverified MCP packages run with meaningful reach. The article’s warning about trojanized or dependency-confused servers shows that the package is not merely code, it is an access vehicle. A compromised connector can inherit workspace access, internal network reach, and sensitive file access in one step. The practitioner implication is that package trust and runtime privilege must be reviewed together, not separately.

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

MCP in IDEs shows why development tooling now needs the same governance discipline as other non-human access paths. The control point is no longer only code execution or repository access. It is whether machine-mediated context can be trusted to move from retrieval to action without a clear identity boundary.

MCP trust spillover: when context, tool output, and execution rights collapse into one workflow, security teams lose the ability to separate data provenance from authority. That means access review, tool approval, and connector trust have to be designed together rather than managed as separate controls.

For practitioners

• Map MCP servers as non-human identities Inventory every server, connector, and extension that can act inside IDE workflows, then assign an owner, purpose, and access scope for each one.
• Propagate the human identity into backend calls Avoid shared service credentials where the server acts on behalf of a developer. Use per-user authorization so backend systems can enforce the developer’s real entitlements.
• Restrict tool permissions to task-scoped access Remove broad file, network, and execution rights from MCP servers and allow only the minimal tool set required for the current development task.
• Review retrieved context as untrusted input Inspect prompt sources, document feeds, and tool descriptions for hidden instructions, and block any connector that can import unreviewed content into model context.
• Vet third-party MCP packages before deployment Require source review, provenance checks, and update control for community connectors so a package cannot become an unnoticed access path into the IDE.

Key takeaways

• MCP servers in IDEs widen the attack surface because they can carry context, tool access, and action rights across development workflows.
• The main failure mode is identity confusion, where server-level credentials or untrusted context outrun the developer’s intended permissions.
• Governance should focus on per-user delegation, connector trust, and tight task-scoped access rather than treating MCP as a simple productivity feature.

Key terms

• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• Context Poisoning: Context poisoning is the manipulation of information that an AI agent reads before acting. The malicious content does not need to be code. If it changes the agent’s instructions, tool choices, or assumptions, it can alter behaviour and expand the impact of a compromised delivery path.
• Tool Poisoning: Tool poisoning is an attack in which malicious instructions are hidden inside tool descriptions, examples, or schemas that an AI agent reads when deciding what to do. The danger is not only in the tool's code, but in the metadata that shapes the agent's behaviour and trust decisions.
• Identity propagation: The preservation of origin and acting principal information as a request moves through multiple services. In MCP chains, this is what allows downstream systems to make a trustworthy authorization decision instead of relying on a stripped-down token with no task context.

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.