AI Security Platform
Discover RYNO
Full Spectrum Visibility
Adaptive Risk Engine
Contextual Intelligence
Dynamic Policy Engine
Why RYNO?
Secure Employees
Secure Applications
Secure Agents
Secure MCP Servers
Core Capabilities
Access
Shadow AI Discovery
AI Threat Protection
Agentic Applications
Agentic Data Loss Prevention
AI Firewall
AI Runtime Security
Open Source
Secure MCP Servers
Solutions
Audits
AI Risk Assessment and Exposure Audits
AI Policy Enforcement
Enable Secure Deployment of AI Agents
Agents
AI Governance and Compliance
Extend Data Governance to AI
Attacks
Defend Against AI-Powered Attacks
Shadow AI Management
Secure the AI Supply Chain
About us
Resources
2026 Predictions
State of AI Security Report
Gen AI Readiness Playbook
GenAI Safe Usage Policy Template
Risk Report
Gen AI Security for Credit Unions
Blog
Newsroom
Book a Demo
AI Security Platform
Discover RYNO
Full Spectrum Visibility
Adaptive Risk Engine
Contextual Intelligence
Dynamic Policy Engine
Why RYNO?
Secure Employees
Secure Applications
Secure Agents
Secure MCP Servers
Core Capabilities
Access
Shadow AI Discovery
AI Threat Protection
Agentic Applications
Agentic Data Loss Prevention
AI Firewall
AI Runtime Security
Open Source
Secure MCP Servers
Solutions
Audits
AI Risk Assessment and Exposure Audits
AI Policy Enforcement
Enable Secure Deployment of AI Agents
Agents
AI Governance and Compliance
Extend Data Governance to AI
Attacks
Defend Against AI-Powered Attacks
Shadow AI Management
Secure the AI Supply Chain
About us
Resources
2026 Predictions
State of AI Security Report
Gen AI Readiness Playbook
GenAI Safe Usage Policy Template
Risk Report
Gen AI Security for Credit Unions
Blog
Newsroom
Book a Demo
AI Security Platform
Discover RYNO
Full Spectrum Visibility
Adaptive Risk Engine
Contextual Intelligence
Dynamic Policy Engine
Why RYNO?
Secure Employees
Secure Applications
Secure Agents
Secure MCP Servers
Core Capabilities
Access
Shadow AI Discovery
AI Threat Protection
Agentic Applications
Agentic Data Loss Prevention
AI Firewall
AI Runtime Security
Open Source
Secure MCP Servers
Solutions
Audits
AI Risk Assessment and Exposure Audits
AI Policy Enforcement
Enable Secure Deployment of AI Agents
Agents
AI Governance and Compliance
Extend Data Governance to AI
Attacks
Defend Against AI-Powered Attacks
Shadow AI Management
Secure the AI Supply Chain
About us
Resources
2026 Predictions
State of AI Security Report
Gen AI Readiness Playbook
GenAI Safe Usage Policy Template
Risk Report
Gen AI Security for Credit Unions
Blog
Newsroom
Book a Demo
The Acuvity AI Security Blog
The Acuvity Blog publishes in-depth research and insights on AI security, including AI governance, runtime security, and AI risk management, offering thoughtful analysis of industry trends and best practices for securing the future of enterprise AI.
July 7, 2025
Cyril Peponnet
Cross-Server Tool Shadowing: Hijacking Calls Between Servers
Research
MCP
July 5, 2025
Cyril Peponnet
Rug Pulls (Silent Redefinition): When Tools Turn Malicious Over Time
Research
MCP
July 1, 2025
Cyril Peponnet
Secrets in the Wind: Environment Variables, URLs, and the Leaky Abstractions
Research
June 30, 2025
Sudeep Padiyar
GenAI Runtime Enforcement with GenAI gateways
Runtime Enforcement
June 26, 2025
Steven Webster
Acuvity Launches RYNO: The Industry’s First Context-Aware Gen AI Security Platform to Protect the AI-Driven Enterprise
News
May 28, 2025
Chris Serafin
Deploy a Simple Chatbot Application Using Secure MCP Servers
MCP
Model Context Protocol
May 27, 2025
Cyril Peponnet
MCP Server: The Dangers of “Plug-and-Play” Code
MCP
Model Context Protocol
May 25, 2025
Satyam Sinha
AI Security Series: What It Really Takes to Secure Gen AI
Acuvity Perspectives
May 24, 2025
Satyam Sinha
AI Security Series 5 – Model Training
Acuvity Perspectives
Pagination
Previous
1
2
3
4
5
6
7
Next
![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-640x478.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.")
