MCP on macOS

Desktop AI tools with real boundaries

Use macOS-native sandboxing to constrain MCP servers on managed machines. Explicit file, process, and network limits — not broad default trust.

Sandbox launch config

json
{
  "mcpServers": {
    "native-container": {
      "command": "/usr/bin/sandbox-exec",
      "args": [
        "-f", "~/.mcp/config/mcp.sb",
        "node", "~/.mcp/server/server.js"
      ]
    }
  }
}
Why it matters

Local agents need boundaries too

Real sandbox, no Docker

macOS-native sandbox-exec constrains file, network, and process access. No container runtime required.

Explicit permissions

Declare exactly which paths and network endpoints the MCP server can reach. Everything else is denied.

Pairs with the control plane

Local tool isolation + cloud-side policy enforcement. Same principle, different boundary.

Architecture

How the sandbox wraps MCP execution

Execution flow

Security posture

Filesystem

Read/write scoped to declared project paths. Everything else is inaccessible.

Network

Outbound connections constrained or fully blocked for tools that should stay local.

Lifecycle

Launch, restart, and logging managed by a supervisor for predictable behavior.

Deny by default

The sandbox profile starts from deny-all and adds explicit grants. Cloud execution needs IAM and VPC controls. Desktop execution needs filesystem and process controls. Same discipline.

scheme
(version 1)
(deny default)
(allow file-read* (subpath "/Users/yourname/projects"))
(allow process-exec (literal "/usr/local/bin/node"))

Same discipline as cloud. Applied locally.

Clear permissions, predictable lifecycle, observable execution — for the AI tools that run on your developers' machines.