MCP Gives Your Coding Agent Root on Your Laptop

Install an MCP server locally and every tool call it executes runs as you — your OS user, your file permissions, your SSH keys sitting in ~/.ssh, your cloud CLI credentials cached in your home directory. That's not a flaw in a specific server. It's what "local MCP server" means by default.

The trust model nobody explicitly agreed to

Add an MCP server to Claude Desktop, Claude Code, Codex, or Cursor and you haven't sandboxed anything — you've handed a local process the same permissions your terminal has. A bash-capable server can run anycommand your user account can. That's correct behavior for a local process. The problem is that "is this server safe?" usually audits the server's code quality, not the blast radius of the permissions it's handed by default.

What actually changes the model, versus what just feels safer

A confirmation prompt before every tool call feels safer and catches obviously-bad single actions, but it doesn't change the boundary — an approved command still runs with your full user permissions. What changes the boundary is moving execution somewhere that never had your machine's permissions to begin with.

boxxkite-mcp is still a local process, speaking MCP over stdio to your editor like any other server. The difference is what it does with a tool call: instead of running exec against your own shell, it makes an HTTP request to a control-plane that runs the command inside a Kubernetes pod with no route to your filesystem, SSH keys, or credentials — self-hosted on your own cluster, or the free hosted beta.

{
  "mcpServers": {
    "boxxkite": {
      "command": "boxxkite-mcp",
      "env": {
        "BOXXKITE_BASE_URL": "https://api.boxxkite.com",
        "BOXXKITE_API_KEY": "bxk_live_..."
      }
    }
  }
}

The honest tradeoff

This isn't free. Every tool call is now a network round-trip instead of a syscall, and the agent loses direct access to files that are genuinely local — including your working directory, unless you sync it in. For an agent whose job is exploring a local checkout, that's a real workflow change, not a pure win. It's worth it specifically when the agent is running code you don't trust yet — generated snippets, freshly installed dependencies, anything from an untrusted source — not for every tool call an agent makes.