In September 2025, researchers confirmed the discovery of a malicious Model Context Protocol (MCP) server embedded in an npm package named postmark-mcp. The package presented itself as a connector for transactional email services but contained a small modification that copied every…
What is Generative AI Security?
Generative AI security is the set of practices and controls that keep large language models (LLMs) and other content-producing AI systems safe from misuse, manipulation, or data exposure. It focuses on protecting the algorithms, training data, and outputs so the technology…
The AI Supply Chain: Lessons from the Drift Incident
The first major AI-adjacent SaaS supply-chain breach has arrived. In August 2025, attackers exploited integrations tied to Salesloft’s Drift app, an AI chatbot and sales automation assistant, to compromise OAuth tokens and pivot into Salesforce and Google Workspace. This was not…
What is Shadow AI?
Shadow AI refers to employees using artificial intelligence tools—often generative AI—without approval or oversight from IT, security, or compliance teams. These unsanctioned tools can expose sensitive data, create compliance gaps, and weaken security controls. Understanding what Shadow AI is, why it spreads, and how to manage it is now a critical priority for CIOs, CISOs, and governance leaders.
AI Misuse in the Wild: Inside Anthropic’s August Threat Report
Anthropic released its August 2025 threat intelligence report, adding to a growing body of evidence that artificial intelligence is now deeply embedded in criminal operations. Security researchers have long anticipated this shift, but the specificity of the examples in this report makes…
Key Takeaways from IBM’s 2025 Cost of a Data Breach Report
For 20 years, IBM’s Cost of a Data Breach Report has been one of the industry’s most trusted sources on the financial and operational impact of security incidents. Each edition provides a rare combination of breadth, spanning hundreds of breaches across industries and geographies,…
![With great power comes great(er) responsibility Since its launch in November 2024, MCP (Model Context Protocol) has been adopted across industries, for high impact use cases it is now the de facto funnel between generative AI models and external data sources, tools, and enterprise systems. We are talking about enterprise tools (Microsoft, Github, Slack, Atlassian) connecting to developer platforms and databases (PostgreSQL,Single Store) and browser automation frameworks (Playwright, Puppeteer) resulting in core business data and work streams being exposed to agentic AI applications. There have been several vulnerabilities listed by security researchers from various security companies including Acuvity ranging from unauthorized access to data leakage to tool poisoning to cross server tool shadowing that can give hackers the keys to the MCP kingdom easily. Securing all aspects of MCP clients and servers becomes paramount to ensure Gen AI teams can adopt the extremely powerful component of the Gen AI developer ecosystem without having to worry about threats in production deployments. Acuvity has taken up the gauntlet to secure the MCP ecosystem with a complete range of tools – secure containers, SBOM validation, miniaturized proxy with authorization and threat prevention controls that are enhanced based on core functionality the MCP server provides and more. Introduction Running MCP (Model Context Protocol) servers using local executables like Node’s npx, Astral’s uvx, or downloaded binaries might be convenient, but it carries serious security risks. When you run an MCP server locally, you grant untrusted code your user’s full permissions. This means the code can: Access any file your user can read or modify Scrape sensitive environment variables Open network connections and more Security researcher Bob Dickinson warned, “the code that is then run on your machine has root access — it can see your entire machine, environment variables, the file system. It can open ports to listen or to exfiltrate data” [1]. Each time you use npx (or uvx), you’re downloading the latest code published by the author without any built-in auditing or sandboxing. This is similar to the notorious “curl | bash” anti-pattern—with no pinning, signing, or checksum verification for code integrity [2]. Supply Chain Risks Because MCP servers are community-contributed, there’s little assurance of safe practices. A malicious actor could: Publish a package that mimics a popular tool’s name (typosquatting) Inject harmful code in a once-trusted project (a “rug pull”) With auto-update defaults, you might pull a compromised version immediately. The risk increases further if the MCP tool is distributed as a compiled binary with no easy way to inspect its behavior [2]. The Safer Path: Docker Container Isolation Using Docker or Podman to containerize MCP servers significantly mitigates these risks. Here’s why: Isolated Execution: Containers confine the tool to a restricted filesystem and process space. The MCP code only accesses files and directories you explicitly allow, keeping your system safe even in the presence of malicious code [1]. Non-Root by Default: Container best practices run processes as non-root users, or if as root, within a namespaced environment. This reduces potential damage from exploits, aligning with Kubernetes’ Pod Security Policies [2]. Immutable Runtime: Docker images offer a fixed filesystem snapshot that doesn’t change at runtime. Unlike npx, which fetches the latest code every time, a container runs a specific tagged or digest image. This ensures that updates occur only when you decide to update and review the changes [3]. Version Pinning & Vulnerability Scanning: You can pin container versions and use security tools to scan images for known vulnerabilities before deployment. Official images on Docker Hub are often digitally signed, adding an extra layer of trust [4]. SBOM and Provenance: Container builds can generate a Software Bill of Materials (SBOM) and cryptographic provenance attestations. This transparency helps verify that the tool hasn’t been tampered with [5]. A Cautionary Example: “Everything Wrong” Local Execution Demo Imagine a not so fictive MCP tool server called mcp-server-everything-wrong. This insecure MCP server: Reads private files Dumps environment secrets Makes unauthorized network requests For example, a debug tool like env_var might be harmless in a secure setting, but in the wrong hands, it could send sensitive API keys or credentials to an attacker. Running this server with npx or as a local binary gives it full control of your user permissions—handing over your secrets without your consent. Server with full user access Server in an isolated container An exploit like this can occur without your knowledge, as the tool may trigger harmful actions automatically as mentioned in these articles [1] [2] [6] [7]. A Better Approach: Containerize and Govern with ARC & MiniBridge Security experts recommend containerizing MCP servers. This is why at Acuvity, we built ARC (Acuvity Runtime Container) to offer a hardened runtime as described in our articles Securing MCP Servers [8] and Securing Anthropic MCP with Acuvity [3]. Isolated Execution: Run securely in isolated containers, preventing lateral movement. Non-root by Default: Minimize risks by enforcing least-privilege. Immutable Runtime: Read-only file system ensures tamper-proof operations. Version Pinning & CVE Scanning: Consistent and secure deployments with proactive vulnerability detection (via Docker Scout). SBOM & Provenance: Traceable builds for complete supply chain transparency. Acuvity also pairs ARC with MiniBridge [9], a specialized opensource lightweight proxy enhancing security and governance. MiniBridge supports policy engines (like Open Policy Agent with Rego policies) to enforce fine-grained runtime security. Together, ARC and MiniBridge form a robust defense that limits damage even if an exploit occurs. Remember, just because a tool is listed in an MCP registry doesn’t mean it’s safe. The safest approach—especially for handling sensitive data—is to self-host MCP tools in containers on trusted infrastructure with strict security policies. Bob Dickinson. “Stop Running Your MCP Tools via npx/uvx Right Now.“ Medium. May 2025. Rami McCarthy. “Research Briefing: MCP Security.“ Wiz Blog. April 17, 2025. Sudeep Padiyar. “Securing Anthropic MCP with Acuvity.“ Acuvity Blog. May 16, 2025. Acuvity. “MCP Security.“ Acuvity (product page), 2025. Docker Docs. “Explore Analysis in Docker Scout.“ Docker Documentation. Repello AI. “MCP Tool Poisoning to RCE.“ Repello Blog, 2025. Repello AI. “MCP Exploit Demo.“ GitHub Repository, 2025. Acuvity. “Securing MCP Servers.“Acuvity (web article), 2025. Minibridge: “Make your MCP servers secure and production ready” GitHub Repository, 2025.](https://acuvity.ai/wp-content/uploads/2025/10/ChatGPT-Image-Oct-3-2025-08_42_12-AM-1340x638.png "With great power comes great(er) responsibility Since its launch in November 2024, MCP (Model Context Protocol) has been adopted across industries, for high impact use cases it is now the de facto funnel between generative AI models and external data sources, tools, and enterprise systems. We are talking about enterprise tools (Microsoft, Github, Slack, Atlassian) connecting to developer platforms and databases (PostgreSQL,Single Store) and browser automation frameworks (Playwright, Puppeteer) resulting in core business data and work streams being exposed to agentic AI applications. There have been several vulnerabilities listed by security researchers from various security companies including Acuvity ranging from unauthorized access to data leakage to tool poisoning to cross server tool shadowing that can give hackers the keys to the MCP kingdom easily. Securing all aspects of MCP clients and servers becomes paramount to ensure Gen AI teams can adopt the extremely powerful component of the Gen AI developer ecosystem without having to worry about threats in production deployments. Acuvity has taken up the gauntlet to secure the MCP ecosystem with a complete range of tools – secure containers, SBOM validation, miniaturized proxy with authorization and threat prevention controls that are enhanced based on core functionality the MCP server provides and more. Introduction Running MCP (Model Context Protocol) servers using local executables like Node’s npx, Astral’s uvx, or downloaded binaries might be convenient, but it carries serious security risks. When you run an MCP server locally, you grant untrusted code your user’s full permissions. This means the code can: Access any file your user can read or modify Scrape sensitive environment variables Open network connections and more Security researcher Bob Dickinson warned, “the code that is then run on your machine has root access — it can see your entire machine, environment variables, the file system. It can open ports to listen or to exfiltrate data” [1]. Each time you use npx (or uvx), you’re downloading the latest code published by the author without any built-in auditing or sandboxing. This is similar to the notorious “curl | bash” anti-pattern—with no pinning, signing, or checksum verification for code integrity [2]. Supply Chain Risks Because MCP servers are community-contributed, there’s little assurance of safe practices. A malicious actor could: Publish a package that mimics a popular tool’s name (typosquatting) Inject harmful code in a once-trusted project (a “rug pull”) With auto-update defaults, you might pull a compromised version immediately. The risk increases further if the MCP tool is distributed as a compiled binary with no easy way to inspect its behavior [2]. The Safer Path: Docker Container Isolation Using Docker or Podman to containerize MCP servers significantly mitigates these risks. Here’s why: Isolated Execution: Containers confine the tool to a restricted filesystem and process space. The MCP code only accesses files and directories you explicitly allow, keeping your system safe even in the presence of malicious code [1]. Non-Root by Default: Container best practices run processes as non-root users, or if as root, within a namespaced environment. This reduces potential damage from exploits, aligning with Kubernetes’ Pod Security Policies [2]. Immutable Runtime: Docker images offer a fixed filesystem snapshot that doesn’t change at runtime. Unlike npx, which fetches the latest code every time, a container runs a specific tagged or digest image. This ensures that updates occur only when you decide to update and review the changes [3]. Version Pinning & Vulnerability Scanning: You can pin container versions and use security tools to scan images for known vulnerabilities before deployment. Official images on Docker Hub are often digitally signed, adding an extra layer of trust [4]. SBOM and Provenance: Container builds can generate a Software Bill of Materials (SBOM) and cryptographic provenance attestations. This transparency helps verify that the tool hasn’t been tampered with [5]. A Cautionary Example: “Everything Wrong” Local Execution Demo Imagine a not so fictive MCP tool server called mcp-server-everything-wrong. This insecure MCP server: Reads private files Dumps environment secrets Makes unauthorized network requests For example, a debug tool like env_var might be harmless in a secure setting, but in the wrong hands, it could send sensitive API keys or credentials to an attacker. Running this server with npx or as a local binary gives it full control of your user permissions—handing over your secrets without your consent. Server with full user access Server in an isolated container An exploit like this can occur without your knowledge, as the tool may trigger harmful actions automatically as mentioned in these articles [1] [2] [6] [7]. A Better Approach: Containerize and Govern with ARC & MiniBridge Security experts recommend containerizing MCP servers. This is why at Acuvity, we built ARC (Acuvity Runtime Container) to offer a hardened runtime as described in our articles Securing MCP Servers [8] and Securing Anthropic MCP with Acuvity [3]. Isolated Execution: Run securely in isolated containers, preventing lateral movement. Non-root by Default: Minimize risks by enforcing least-privilege. Immutable Runtime: Read-only file system ensures tamper-proof operations. Version Pinning & CVE Scanning: Consistent and secure deployments with proactive vulnerability detection (via Docker Scout). SBOM & Provenance: Traceable builds for complete supply chain transparency. Acuvity also pairs ARC with MiniBridge [9], a specialized opensource lightweight proxy enhancing security and governance. MiniBridge supports policy engines (like Open Policy Agent with Rego policies) to enforce fine-grained runtime security. Together, ARC and MiniBridge form a robust defense that limits damage even if an exploit occurs. Remember, just because a tool is listed in an MCP registry doesn’t mean it’s safe. The safest approach—especially for handling sensitive data—is to self-host MCP tools in containers on trusted infrastructure with strict security policies. Bob Dickinson. “Stop Running Your MCP Tools via npx/uvx Right Now.“ Medium. May 2025. Rami McCarthy. “Research Briefing: MCP Security.“ Wiz Blog. April 17, 2025. Sudeep Padiyar. “Securing Anthropic MCP with Acuvity.“ Acuvity Blog. May 16, 2025. Acuvity. “MCP Security.“ Acuvity (product page), 2025. Docker Docs. “Explore Analysis in Docker Scout.“ Docker Documentation. Repello AI. “MCP Tool Poisoning to RCE.“ Repello Blog, 2025. Repello AI. “MCP Exploit Demo.“ GitHub Repository, 2025. Acuvity. “Securing MCP Servers.“Acuvity (web article), 2025. Minibridge: “Make your MCP servers secure and production ready” GitHub Repository, 2025.")
MCP Server: The Dangers of “Plug-and-Play” Code
With great power comes great(er) responsibility Since its launch in November 2024, MCP (Model Context Protocol) has been adopted across industries, for high impact use cases it is now the de facto funnel between generative AI models and external data sources, tools, and enterprise systems….