The Model Context Protocol (MCP) is rapidly becoming a common standard for connecting AI agents to enterprise data and tools. It replaces ad-hoc, per-tool integrations with a shared interface that lets agents call external servers, retrieve context, and execute actions. But every MCP server an agent talks to is a new trust boundary. Recent security incidents — including a malicious npm package that impersonated a legitimate email service and disclosed vulnerabilities in official MCP SDKs — show what happens when teams treat MCP servers as plug-and-play.
MCP security means treating each server as untrusted by default, vetting its source, scoping tool access, isolating execution, logging actions, and governing the deployment with explicit policy. If your team is navigating the broader journey from pilot to production covered in agentic AI in production, MCP security is the layer that determines whether your agent can safely touch enterprise data once it gets there.
Key Takeaways
- MCP turns every external server into a new trust boundary. Default-open MCP integrations can expose enterprise data beyond the agent’s intended scope.
- Top 2026 risks include tool poisoning, prompt injection through MCP server responses, rug-pull and supply-chain attacks, overly broad tool scopes, and OAuth or token validation failures.
- MCP security best practices cover server vetting and version pinning, least-privilege tool scopes, execution sandboxing, comprehensive audit logging, and human-in-the-loop approval for sensitive actions.
- Enterprise governance closes the gap: written policy, data classification, and controls that can support alignment with ISO/IEC 27001:2022 and SOC 2 — but do not by themselves establish compliance.
- Authenticated remote MCP servers are often easier to govern when combined with network segmentation, scoped authorization, egress control, and centralized logging. Remote is not automatically safer; it is safer only when those controls are in place.
What Is the Model Context Protocol (MCP)?
The Model Context Protocol is an open protocol that standardizes how LLM applications connect to external data sources and tools. According to the official Model Context Protocol specification, MCP defines three roles: hosts (applications that manage agents), clients (entities inside the host that connect to servers), and servers (programs that expose tools, resources, and prompts). MCP is an open protocol originally introduced by Anthropic, as described in Anthropic’s introduction of the Model Context Protocol. It is not owned exclusively by any single vendor.
Why teams are moving beyond ad-hoc tool integrations
Before MCP, connecting an agent to a database, CRM, or file store meant writing a custom integration per tool. MCP replaces that with a shared protocol where any MCP-compatible client can call any server. The benefits — faster integration, reusable servers, model portability — are real, but the same ease expands the attack surface. When a developer can install an MCP server in seconds, the question shifts from “can we build this?” to “should we trust this server with our data?”
What MCP Does—and Does Not—Secure by Default
MCP standardizes communication between clients and servers. It does not secure the full integration. The following remain the responsibility of the host and client: server trust, authorization, consent, output validation, and execution controls (sandboxing, rate limiting, isolation). The specification notes that tool descriptions and annotations should be considered untrusted unless they come from a trusted server. MCP gives you a standard way to connect — not a guarantee that what you connect to is safe.
Why MCP Security Matters Now
An MCP server often holds credentials for a database, file system, email provider, or business API. If the server is compromised, over-permissioned, or malicious, the data leak surface expands to everything those credentials can reach.
| Dimension | Ad-hoc integration | MCP-based integration |
|---|---|---|
| Trust boundary | One custom integration per tool | One standard boundary per server, reused across agents |
| Permission scope | Defined per integration, often reviewed | Often inherited from server defaults, easily over-scoped |
| Auditability | Custom logging per integration | Standardized calls, but logging still must be configured |
| Supply chain risk | Limited to chosen dependencies | Any installable server becomes a potential dependency |
MCP makes it trivially easy to add new servers, and each one extends the boundary. Many pilots run local servers with default settings — no authentication, no audit log, no scoped credentials — which is fine for a demo but not when the agent touches real customer data.
Documented MCP Security Incidents, Vulnerabilities, and Attack Patterns
Not every MCP security concern is the same. Some are confirmed real-world incidents. Others are disclosed vulnerabilities patched before known exploitation. Still others are research demonstrations. This section separates the three.
Confirmed incident: malicious postmark-mcp npm package
In September 2025, a malicious third-party npm package called postmark-mcp impersonated Postmark, an email delivery service. This was not an official Postmark package — Postmark had not published its official MCP server on npm before this incident. According to Postmark’s official security notice, the package built trust over 15 versions, then added a backdoor in version 1.0.16 that secretly BCC’d outbound emails to an external server. Koi Security’s analysis of the malicious package reported approximately 1,500 weekly downloads; the hidden BCC destination attributed to Koi Security was an address at the giftshop.club domain.
This was a real-world malicious package and software supply-chain incident, not a breach of Postmark’s official platform. Postmark’s legitimate API and services were not compromised and remained unaffected. The incident demonstrates supply-chain risk, excessive-permission risk, server-vetting failure, and version-change risk. The pattern is rug-pull-like; “rug pull” is used here as a description of the pattern, not as Postmark’s own classification.
Disclosed vulnerabilities: CVE-2025-66414 and CVE-2025-66416
Two disclosed vulnerabilities in the official MCP SDKs highlight implementation-level risks. These are disclosed implementation vulnerabilities, not confirmed real-world breaches, with no public evidence of in-the-wild exploitation.
CVE-2025-66414 — TypeScript SDK. Prior to 1.24.0, the MCP TypeScript SDK did not enable DNS rebinding protection by default for HTTP-based servers. When a server ran on localhost without authentication using StreamableHTTPServerTransport or SSEServerTransport, and enableDnsRebindingProtection was not enabled, a malicious website could bypass same-origin policy and invoke exposed tools or resources. Does not affect stdio transport. Fixed in 1.24.0. See the GitHub advisory for CVE-2025-66414 and the NVD record for CVE-2025-66414.
CVE-2025-66416 — Python SDK. Prior to 1.23.0, the MCP Python SDK (mcp on PyPI) did not enable DNS rebinding protection by default for HTTP-based servers. When a server ran on localhost without authentication using FastMCP with streamable HTTP or SSE, and TransportSecuritySettings was not configured, a malicious website could bypass same-origin policy and invoke exposed tools or resources. Does not affect stdio transport. Fixed in 1.23.0. See the GitHub advisory for CVE-2025-66416 and the NVD record for CVE-2025-66416.
Both advisories note that running HTTP-based MCP servers locally without authentication is not recommended. The affected configurations are specific: stdio transport and authenticated servers were not affected.
Research demonstrations and theoretical attack patterns
Security researchers have demonstrated attack patterns that illustrate how MCP can be abused. These are proofs of concept, not confirmed real-world incidents. Documented MCP attack patterns show that malicious instructions can be embedded in tool descriptions visible to the model but not obvious to the user, causing the agent to take actions the user never approved. They also show how an initially benign server could later introduce indirect prompt injection through returned data, manipulating an agent’s behavior without directly exploiting the model.
Top MCP Security Risks in 2026
Tool poisoning and malicious MCP servers
Tool poisoning happens when a server embeds malicious instructions in tool descriptions or metadata that the model reads but the user does not see. The agent may follow those instructions and take actions outside the user’s intent. The postmark-mcp incident is a confirmed case of a malicious server impersonating a legitimate project.
Prompt injection through MCP server responses
An MCP server returns data — file contents, database rows, API responses. If that data contains instructions, the agent may treat them as commands. Because the agent trusts the server as a data source, returned content becomes an injection surface unless the host validates and isolates it. For a deeper treatment, see LLM security for agentic AI.
Rug-pull and third-party supply-chain risks
A rug-pull occurs when a server that was initially safe changes behavior after an update. Supply-chain risk extends to dependencies, transitive packages, and unmaintained servers. Agents call tools automatically and frequently, so the blast radius of a compromised server is larger than a typical library dependency.
Overly broad tool scopes and credential exposure
Servers are often granted broader permissions than they need. When credentials pass through a compromised or over-permissioned server, exposure extends to everything those credentials can reach. Least privilege is the control that limits damage when a server goes wrong.
OAuth, token validation, and authorization failures
MCP authorization for HTTP-based remote servers follows OAuth 2.1 conventions, as described in the MCP authorization guidance. Authorization protects sensitive resources and operations exposed by MCP servers. OAuth is not an automatic security guarantee: implementations must validate token audience, issuer, expiration, and scopes; tokens should be short-lived and securely stored; production flows should use HTTPS; credentials, authorization headers, tokens, and authorization codes must not be written to logs; and catch-all scopes should be avoided in favor of least-privilege scopes per tool. MCP does not securely implement OAuth on behalf of developers. For broader guidance on token passthrough, confused-deputy risks, SSRF, and scope minimization, see the MCP security best practices.
MCP Security Best Practices
Vet and pin every MCP server
Treat any MCP server as untrusted software: confirm the publisher is official, review requested permissions, read the source or a trusted audit, pin to a specific version, and prefer servers from organizations you trust. The postmark-mcp incident is the cautionary example.
Enforce least privilege on tool scopes
Grant each server the minimum access required. Separate read and write scopes. Use scoped credentials instead of shared admin tokens. If a server is compromised, damage is limited to the narrow scope it was granted.
Sandbox and isolate MCP server execution
Run MCP servers in isolated environments — containers, VMs, or separate network segments — not directly on the host. Do not share filesystems or credentials between servers. Sandboxing reduces blast radius from “the server can reach everything” to “the server can only reach what it was explicitly allowed to reach.”
Audit logging and agent observability
Log authenticated identities, granted scopes, tool calls, sanitized inputs and outputs, policy decisions, approval events, errors, and final action outcomes. Credentials, tokens, and sensitive personal data must not appear in logs. The log is what lets a team reconstruct events, prove compliance, and detect anomalies before they become incidents.
Human-in-the-loop for sensitive actions
Require human approval for actions with real-world impact: writing to production databases, sending external email, calling paid APIs, modifying customer records. Thresholds should be based on data classification — public data may need no approval, while confidential and restricted data requires explicit sign-off.
AI Agent Enterprise Governance Framework
Policy, ownership, and approval workflows
Governance starts with written policy: who can approve a new MCP server, what review is required, who owns each agent deployment. Without explicit ownership, developers install servers ad-hoc and security teams discover them only after an incident. A simple workflow — propose, review, approve, deploy — stops most supply-chain risks before production.
Data classification and residency controls
Classify data as public, internal, confidential, or restricted, and decide which classes an agent and its servers may touch. Enforce residency controls where required: data subject to EU or US regulations should not flow through servers outside the appropriate region.
Aligning MCP usage with ISO/IEC 27001:2022 and SOC 2
MCP security controls can support alignment with ISO/IEC 27001:2022 and SOC 2, but implementing these controls alone does not establish compliance. Server vetting maps to supplier risk management; least privilege maps to access control; audit logging maps to monitoring; human-in-the-loop maps to change management. Full compliance requires the broader management system, risk assessment, internal audit, and external certification.
Secure AI Integration Architecture Patterns
Local vs remote MCP servers
Local servers run on the same host — simple for development, but they share filesystem and network, increasing blast radius. Remote servers run separately, can be authenticated, and are easier to audit. Remote is not automatically safer: an unauthenticated remote server on the open internet is worse than a properly configured local server. Authenticated remote servers are often easier to govern when combined with network segmentation, scoped authorization, egress control, and centralized logging.
OAuth and authenticated MCP connections
MCP authorization for HTTP-based remote servers follows OAuth 2.1 conventions. Use scoped, short-lived, rotated tokens stored securely. Validate token audience, issuer, expiration, and scopes on every request. Do not write credentials, authorization headers, tokens, or authorization codes to logs. Avoid catch-all scopes; grant least-privilege scopes per tool. Production flows should use HTTPS. MCP does not securely implement OAuth for you — see the MCP authorization guidance and the MCP security best practices for protocol-level requirements and broader guidance on token passthrough, confused-deputy risks, and scope minimization.
Network segmentation and egress controls
Place MCP servers in private subnets with controlled egress. Restrict outbound traffic to an allowlist of IP addresses and domains. This limits exfiltration paths if a server is compromised — the same principle HDWEBSOFT uses for outbound email through a NAT Gateway with IP allowlisting. For broader context on secure AI integration, see our AI development services and cybersecurity services.
A Security-First MCP Deployment Workflow
A defensible MCP deployment follows a repeatable workflow: audit the server (confirm source, review permissions, read code), scope permissions (least privilege per tool, scoped credentials), isolate execution (container or separate network segment), observe behavior (log identities, scopes, tool calls, sanitized I/O, policy decisions, approvals, errors, outcomes), and apply human oversight (approval for sensitive actions based on data classification).
HDWEBSOFT applies this workflow in client engagements involving AI agents and enterprise data. As an ISO 9001 and ISO/IEC 27001 certified software development partner, HDWEBSOFT treats security as a release gate, not a final checklist. The goal is not to slow teams down; it is to make sure that when an agent reaches production, the MCP layer is not the thing that breaks.
Conclusion
MCP is the right direction for connecting AI agents to enterprise data. A shared protocol is better than a tangle of custom integrations. But MCP security is not automatic. Every server is a trust boundary, every tool scope is a potential blast radius, and every update is a chance for behavior to change. The teams that ship safely vet servers, enforce least privilege, isolate execution, log what matters, and keep humans in the loop.
If your team is connecting AI agents to enterprise data through MCP, the highest-value next step is an independent review before production. Request an AI Security & Architecture Audit to identify gaps in server vetting, tool scopes, authorization, logging, and governance — and get a concrete remediation plan before an incident forces one.
FAQ
What is MCP security?
MCP security is the practice of protecting AI agents that connect to external data and tools through the Model Context Protocol. It covers server vetting, least-privilege tool scopes, execution isolation, audit logging, human-in-the-loop controls, and enterprise governance of MCP-based integrations.
What are the most common MCP server security risks?
The most common MCP security risks include tool poisoning from malicious servers, prompt injection delivered through MCP server responses, rug-pull and third-party supply-chain attacks, overly broad tool scopes and credential exposure, and OAuth or token validation failures in authenticated deployments.
How do I secure an MCP server in production?
Secure an MCP server in production by vetting and pinning every server, enforcing least-privilege tool scopes, sandboxing server execution, logging authenticated identities and tool calls, applying human-in-the-loop approval for sensitive actions, and aligning the deployment with enterprise governance and compliance controls.
Is the Model Context Protocol safe for enterprise AI agents?
MCP is safe for enterprise AI agents when teams treat every MCP server as a new trust boundary and apply explicit security controls. MCP standardizes communication between clients and servers, but server trust, authorization, output validation, and execution controls remain the responsibility of the host and client.
How does MCP security support ISO/IEC 27001:2022 or SOC 2 compliance?
MCP security controls can support alignment with ISO/IEC 27001:2022 and SOC 2 by mapping server vetting, least-privilege access, audit logging, and supplier risk management to existing control categories. Implementing these controls alone does not establish compliance; organizations must also complete the broader management system and audit requirements.
When should we run an AI Security & Architecture Audit?
Run an AI Security & Architecture Audit before promoting an AI agent to production, after a security incident or near-miss, when connecting agents to new sensitive data sources, and whenever a new MCP server is introduced into a production workflow.
