MCP servers in IDEs create new identity and trust risks

At a glance

What this is: Backslash Security examines how MCP servers inside IDEs expand developer productivity while creating new security exposures around context poisoning, access control gaps, and malicious tool behavior.

Why it matters: For IAM and NHI practitioners, MCP servers turn software development tooling into a privileged integration layer that must be governed like a live identity surface, not a convenience feature.

👉 Read Backslash Security's analysis of the top MCP risks in IDEs

Context

Model Context Protocol, or MCP, is becoming a new control point in AI-enabled development environments. When an IDE connects to MCP servers for memory, tool use, and workflow state, it creates a persistent trust layer that can outlive a single prompt or session. That matters to NHI governance because the same connectors that help an assistant remember context can also carry credentials, permissions, and hidden instructions across systems.

The governance gap is simple: developers expect tooling, while defenders must account for identity, privilege, and provenance. In that setting, unvetted MCP servers can function like high-trust service accounts with weak oversight. The article’s starting position is now becoming typical, not exceptional, as MCP adoption spreads beyond isolated experimentation.

Key questions

Q: How should security teams govern MCP servers used by AI agents?

A: Treat MCP servers as privileged non-human identities, not as convenience plugins. Assign owners, scope access to specific tools and data sources, require authentication, and log every significant action. If a server can reach repositories, ticketing systems, or internal data, it needs the same review discipline as any other high-trust integration.

Q: Why do MCP servers create new risk for IAM teams?

A: MCP servers can collapse the boundary between human intent and machine execution. If they use shared credentials or broad permissions, the agent may act with more privilege than the user should have, which weakens least privilege, complicates audit trails, and increases blast radius when the server is compromised.

Q: What is the difference between prompt injection and tool poisoning in agentic systems?

A: Prompt injection manipulates the content the model reads, while tool poisoning manipulates the tool itself or its description so the model follows malicious instructions. Both aim to control agent behaviour, but tool poisoning is especially dangerous because the abuse is embedded in a trusted integration path.

Q: Should organisations allow community MCP servers in production development environments?

A: Only with strict vetting, containment, and ongoing monitoring. Community MCP servers should be treated like third-party code with privileged access, which means source review, dependency review, permission scoping, and the ability to revoke access quickly if behaviour changes.

Technical breakdown

How MCP servers reshape trust boundaries in IDEs

MCP servers act as intermediaries between an LLM or agent and external systems such as file stores, issue trackers, and code repositories. They persist context, expose tools, and sometimes retain memory state, which means they sit inside the reasoning path of the AI system rather than outside it. That architecture changes the trust boundary: the agent is no longer making decisions only from user prompts, but from server-provided context and tool output. If the MCP layer is untrusted, compromised, or overly broad, it can steer behavior in subtle ways without obvious signs to the user.

Practical implication: Treat MCP servers as privileged parts of the development trust chain and review them with the same scrutiny as any other identity-bearing integration.

Prompt injection, context poisoning, and tool poisoning

Prompt injection in MCP environments is often a context problem, not just a prompt problem. Malicious instructions can be hidden in documents, comments, tool descriptions, or connected content, then surfaced when the agent retrieves context through MCP. Context poisoning occurs when the agent treats that retrieved material as authoritative. Tool poisoning is a related pattern where a malicious server presents benign-looking tools but embeds instructions that alter model behavior. In both cases, the exploit does not need traditional malware. It only needs the agent to trust content that should have been validated before execution.

Practical implication: Validate retrieved context and tool metadata before execution, especially where MCP output can trigger writes, exfiltration, or code changes.

Why access control and shared credentials matter for MCP security

The article highlights a common failure mode in early MCP deployments: weak authentication, broad tokens, and missing user identity propagation. If a server connects to backend systems using shared credentials, the agent inherits more privilege than the human operator actually has. That breaks least privilege and makes audit trails less meaningful. In NHI terms, the MCP server becomes an identity broker for machine activity, but without the controls normally expected of identity brokers. The result is a wider blast radius, especially when users click through initial consent prompts or clients reuse grants indefinitely.

Practical implication: Require per-user or per-session authorization, scoping, and auditability before allowing MCP servers to reach sensitive systems.

Threat narrative

Attacker objective: The attacker aims to convert trusted AI development tooling into a durable access path for code theft, credential exposure, or downstream compromise.

1. Entry occurs when an attacker places a malicious or trojanized MCP server in a directory, package registry, or connected workflow used by developers.
2. Escalation follows when the server leverages weak authentication, shared credentials, or inherited IDE permissions to reach repositories, files, or internal services.
3. Impact occurs when the agent executes poisoned instructions, exfiltrates sensitive material, or writes malicious code that becomes a durable supply chain foothold.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• 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 server sprawl is becoming an identity problem before it becomes a code problem. The article describes a rapidly expanding ecosystem of MCP directories, connectors, and IDE integrations, which means the real issue is not adoption speed alone. The issue is that each new server can act like a machine identity with tool access, context access, and sometimes backend credentials. Security teams should frame MCP inventory as NHI inventory, not just developer tooling inventory.

Context poisoning is the most underappreciated control failure in MCP-driven workflows. When model input is assembled from documents, tool descriptions, and connected systems, attackers do not need to break encryption or defeat perimeter controls. They only need to influence what the agent treats as trusted context. That makes content validation, provenance checks, and tool-output handling central to NHI governance rather than optional hardening.

Ephemeral trust is not the same as low trust. MCP integrations often feel temporary because they are added to a session or a project, but temporary access can still be highly privileged. The governance mistake is assuming that short-lived access is inherently safe. In practice, short-lived machine access can be more dangerous if it is broad, poorly scoped, and hard to audit. Practitioners should treat ephemeral access as a control design problem, not a comfort signal.

Tool poisoning shows why AI agent security cannot rely on user prompts alone. If the server itself can shape the agent’s actions through descriptions, outputs, or hidden directives, then the control plane has shifted upward into the tool layer. That changes how we think about appsec, IAM, and PAM for agentic systems. The practitioner conclusion is straightforward: if a tool can act, it must also be governed.

The market is converging on MCP security as a control category, not a feature set. The more MCP spreads into development workflows, the more organizations will need discovery, approval, scoping, monitoring, and revocation controls that resemble NHI governance. This is where agentic AI security starts to overlap with classic identity governance. Teams should expect procurement and architecture reviews to ask where MCP identity is managed and who owns its privileges.

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.
• 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader view of agent governance patterns, see AI Agents: The New Attack Surface report for current control gaps and behaviour drift.

What this signals

Ephemeral credential trust debt: short-lived access to MCP tools is not automatically safer if the permissions are broad, opaque, or shared across users. As AI agents take on more of the execution burden in development environments, practitioners need to assume that any tool with context access can become a control plane for machine action. The governance response is to tie MCP access to explicit ownership, scoping, and revocation workflows, not to rely on session duration as a proxy for safety.

The broader signal is that agentic AI governance is moving into the same operational territory as identity governance and PAM. That means controls such as approval, logging, and review must be designed around machine actors, not merely extended from human user models. For teams following external guidance, the OWASP Agentic AI Top 10 and NIST Cybersecurity Framework 2.0 both map cleanly to this problem space.

As MCP adoption spreads, security teams should expect a rise in review questions about provenance, allowlisting, and connector lifecycle management. The practical implication is simple: if an AI tool can influence code, infrastructure, or credentials, it needs a documented trust model and a revocation path. Without that, MCP becomes another shadow AI pathway into the enterprise.

For practitioners

• Inventory every MCP server and connector Create a register of every MCP server used in IDEs, including source, owner, permissions, backend systems, and whether it is official, vetted, or community-built. Unknown or duplicated servers should be treated as unmanaged NHI assets.
• Require scoped authentication and user identity propagation Block any MCP deployment that relies on shared credentials or broad tokens. Enforce per-user scoping, short-lived access, and auditable identity propagation into downstream systems.
• Review tool descriptions and retrieved context before execution Treat tool metadata, prompts, and connected documents as untrusted until validated. Apply allowlisting, content sanitisation, and execution gating for any action that can read, write, or trigger downstream workflows.
• Isolate unvetted MCP packages and community connectors Run experimental or community MCP tooling in restricted environments with limited filesystem, network, and repository access. The goal is to contain supply chain exposure before broader rollout.

Key takeaways

• MCP servers inside IDEs are creating a new identity and trust layer that security teams cannot treat as ordinary developer tooling.
• Weak authentication, shared credentials, and context poisoning are the core failure patterns, and they map directly to NHI governance gaps.
• Organizations should inventory, scope, monitor, and revoke MCP access the same way they would any other high-trust non-human identity.

Key terms

• MCP Server: An MCP server is a context and tool layer that lets an AI model or agent interact with external systems in a structured way. In practice, it can store memory, expose actions, and pass data between the assistant and connected applications, which makes it a high-value governance point.
• Context Poisoning: Context poisoning happens when malicious or misleading information is inserted into the material an AI agent trusts, such as documents, comments, or retrieved content. The agent then uses that poisoned context to make unsafe decisions, expose data, or take actions the user did not intend.
• Tool Poisoning: Tool poisoning is the abuse of a trusted tool interface so that an AI agent follows hidden or deceptive instructions embedded in the tool itself. The risk is especially serious when the tool can write files, query systems, or trigger downstream actions with elevated permissions.
• Ephemeral Access: Ephemeral access is permission granted for a short period or a specific task instead of being left in place permanently. It reduces standing privilege, but it still needs scoping, auditability, and revocation because short-lived access can be highly privileged if misconfigured.

Deepen your knowledge

MCP server governance and AI agent trust boundaries are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for developer tooling that now acts like a machine identity layer, it is worth exploring.

This post draws on content published by Backslash Security: Top 10 Risks of Using MCP Servers in IDEs. Read the original.