MCP Server: Connect Krova to AI Coding Tools
Learn MCP server security risks, sandbox isolation best practices, and how to safely integrate AI agents with tools and infrastructure.
DM
An MCP server sits between your AI agent and the tools it needs, databases, file systems, cloud APIs, shell commands. Get it wrong, and a compromised or misbehaving agent reaches everything. Get it right, and you have powerful automation with real isolation. The Model Context Protocol ecosystem has grown to 150 million downloads, but 2026 revealed that the protocol's architecture carries systemic security flaws affecting over 200,000 vulnerable instances across the supply chain.
TL;DR:
- An MCP server is a thin bridge that translates AI agent requests into tool calls, database queries, Cube creation, file operations.
- The protocol itself has no native defenses against command injection, tool poisoning, or unauthenticated access; remediation falls on implementers.
- Sandboxing untrusted agent code requires VM-grade isolation (not just containers); ephemeral microVMs with per-Cube kernel separation are the production standard.
- Krova's server lets Claude and Cursor manage Cubes in natural language; each agent runs in its own isolated microVM.
What Is an MCP Server
An MCP server is a lightweight process that speaks the Model Context Protocol, a standard interface between large language models and external tools. Instead of an AI agent calling APIs directly, it calls the server, which translates those calls into concrete actions: list database records, create cloud resources, run shell commands, or fetch files.
Think of it as a typed bridge. Your agent asks the server "create a 2-vCPU Ubuntu server in us-west" and it translates that into an API call to your infrastructure provider and returns the result. The protocol standardizes how agents discover and call tools, so Claude, Cursor, and any MCP-aware client can use the same server without custom integration.
MCP is maintained by Anthropic and published as an open specification. Since launch, adoption has accelerated, major IDEs (Cursor, VS Code with Copilot), AI platforms (Harvey AI, Agentverse), and infrastructure tools now ship integrations. The speed of adoption created a security problem: the protocol was released with a flexible, underspecified design that prioritized implementation freedom over security guardrails.
MCP Server Security Risks in 2026
The threat landscape shifted sharply in April 2026. Security researchers at OX Security disclosed a systemic remote code execution vulnerability embedded in Anthropic's official MCP SDK, not a bug in any single application, but a deliberate architectural choice replicated across every language binding (Python, TypeScript, Java, Rust).
The core issue: the STDIO transport executes operating system commands without sanitization or validation. Any process command passed to the interface runs on the host machine, regardless of whether a valid server was initialized. This design choice propagated into at least seven confirmed critical CVEs affecting MCP Inspector, LiteLLM, Cursor IDE, LibreChat, Windsurf, and other platforms.
Beyond command injection, the protocol specification provides no native defenses against tool poisoning, rug pull attacks, or cross-server tool shadowing. These attack classes are now documented in real-world incidents. Authorization is optional and explicitly marked that way in the spec; as of July 2025, internet scans identified at least 1,862 publicly exposed servers running without authentication.
The National Security Agency's Cybersecurity Information directorate noted that MCP's rapid proliferation has outpaced its security model. The protocol reverses a familiar pattern: instead of clients requesting data from servers, it often expects servers to execute actions for connected clients. This inversion creates attack paths that traditional API security frameworks were not built to address.
The vulnerability is not a patch away. Anthropic has confirmed the behavior is intentional and declined to modify the protocol architecture. Remediation responsibility falls entirely on individual developers and operators. You cannot assume any server is secure by default; you must evaluate threat models per deployment and implement isolation controls yourself.
How MCP Servers Connect to AI Coding Tools
Clients like Claude Desktop, Cursor, VS Code Copilot, or custom agents discover servers through configuration files. For Cursor, this is .cursor/mcp.json. For Claude Desktop, it's claude_desktop_config.json. The config specifies the command to launch the server and environment variables it needs to authenticate.
The standard pattern is straightforward: client launches server process, server connects to backend (API, database, CLI), server returns tool definitions to client, client passes those tools to the LLM, LLM calls tool, server translates call into action.
For Krova Cloud infrastructure, the MCP server exposes 19 tools across Cubes, domains, snapshots, TCP mappings, and pricing. Ask Claude "spin up a 2-vCPU Ubuntu Cube in us" and the server translates that into a Krova Cloud API call. The agent can also list running Cubes, power them off, create snapshots, or manage DNS, anything your Krova account has permission to do.
The setup is direct. Install @krovacloud/mcp from npm, set KROVA_API_KEY and KROVA_SPACE_ID as environment variables, add the server config to your MCP client, and restart. The client launches the server on startup; tools appear in your MCP client's tool menu. Your API key is scoped to a single space and never leaves your machine. The server runs locally and talks directly to the Krova Cloud API.
Sandboxing Untrusted Code with MCP
Not all servers need sandboxing. Servers that proxy APIs, retrieve data, or expose SaaS actions typically don't, they're thin wrappers with no code execution risk. But servers that execute model-generated code, run shells, manipulate files dynamically, or process untrusted workloads absolutely do. Without isolation, a compromised agent reaches your host, other workloads, and user data.
The production approach is to spin up a disposable microVM per agent, give it full root, let it do its job, then tear it down. MicroVMs offer hardware-level separation with startup times close to containers, seconds instead of minutes. Firecracker technology (the same substrate AWS Lambda and Fargate use) delivers this speed without sacrificing isolation.
Each Cube on Krova Cloud has its own Linux kernel in a per-Cube jailer sandbox, never a shared kernel. One Cube's bug or compromise cannot reach another's filesystem, processes, or network. Because each runs a full VM with hardware isolation, an agent's code execution is confined: it can write to its own disk, access its own network, read its own environment, nothing more.
The typical flow: snapshot a clean base image (Node.js, Python, whatever your agents need), then hand a copy of that snapshot to each new agent at boot. The agent installs packages, runs commands, modifies files, all inside its isolated Cube. When done, the Cube is powered off and compute charges stop immediately. No subscription overhead, no fixed monthly cost for idle infrastructure sitting around.
This pattern scales. Spin up ten parallel agents for a batch job and tear them down when done. Per-minute billing means the cost is trivial, a 2-vCPU Cube costs $0.0073 per minute running 24/7, but most agents run for minutes to hours, then shut down.
MCP Server Best Practices for Production
Assume no server is secure by default. The architecture does not provide security guarantees. Your job is to implement them.
Start with authentication and authorization. The MCP spec defines an optional OAuth 2.1 framework; if you're exposing a server to the network, enable it. Never assume a client is authorized just because it can connect. Validate credentials, scope permissions to the minimum needed, and deny everything by default.
Use environment variables for secrets. Your API key should never be hardcoded or committed to version control. Set it as an environment variable that the MCP client passes at launch. Rotate any key you believe has been exposed.
Mount only what the task needs. If you're running AI agents in isolated environments, do not hand the sandbox your entire repository or every secret. Mount the specific project directory the agent needs to access, and keep provider API keys in a control plane so they never travel to the sandbox. This alone stops a huge class of data-exfiltration and dependency-poisoning risks.
Log every action. Secure LLM code execution is not just about walls, it's about visibility. Tie every request to a named user and record prompts, tool calls, and outcomes centrally. When something goes wrong, the audit trail is there.
Add network controls. Default to no outbound network, then allowlist only the endpoints an agent actually requires. This stops data exfiltration and dependency-poisoning attacks in one shot.
For code execution workloads specifically, use sandboxed execution as a tool layer. Anthropic's Sandboxed Code Execution tool runs Python inside isolated environments through MCP; documented tests show it cuts token usage meaningfully. Prompt caching can reduce input costs by up to 90% on cache hits, so isolation and cost efficiency align.
FAQ
What Was the April 2026 MCP Vulnerability?
OX Security disclosed a systemic remote code execution flaw in Anthropic's official MCP SDK affecting all language bindings. The STDIO transport executes OS commands without sanitization; this design choice was intentional and Anthropic declined to change it, shifting remediation responsibility to individual implementers.
Is Model Context Protocol Safe for Production?
MCP itself is a protocol, not a security product. It provides no native defenses against command injection, tool poisoning, or unauthenticated access. Production safety depends entirely on how you implement it: enable authentication, sandbox untrusted code, log actions, and assume every server needs isolation.
How Do I Run an AI Agent in an Isolated Environment?
Use hardware-level isolation, microVMs with per-VM kernel separation, not shared-kernel containers. Spin up one microVM per agent, give it full root within its boundary, and tear it down when done. Krova Cloud's Cubes follow this pattern: each is a Firecracker microVM with its own kernel, booting in seconds and billed per minute.
Can I Use MCP Servers Without Sandboxing?
Yes, if the server only proxies APIs or retrieves data, no code execution. But servers that execute generated code, run shells, or manipulate files dynamically need VM-grade isolation to prevent a compromised agent from reaching your host or other workloads.
Give your AI coding tools a real microVM
Point your agent at Krova's MCP server and it can spin up a Firecracker microVM to run and test its own code in seconds.




