MCP servers, sandboxed — introducing ACT

Alexander Shishenko — Fri, 08 May 2026 17:01:35 +0000

Setting up an MCP server for your AI agent today usually looks like this:

npx -y @some-org/mcp-server # or
uvx some-mcp-server # or the occasional
curl https://example.com/install.sh | bash

The server runs as you. It can read your home directory. It sees your SSH keys, your .env files, your shell history, your browser cookies, your GPG keyring. If the server has a bug — or a malicious dependency sneaks in — the code that reads those files also runs as you. If your kernel or any installed binary has an unpatched local privilege escalation, the agent-invoked tool just inherited that escalation path too.

That isn't a failure mode of any particular MCP server; it's the default deployment model. Ambient-permission native processes, shipped by anyone, invoked on demand by an LLM that's notoriously easy to talk into misusing them."Your agent has your credentials and runs strangers' code on request" is the baseline security posture of every MCP setup built on npx / uvx / curl | bash today. It's a full-blown security nightmare that the industry has collectively decided not to look at.

ACT — Agent Component Tools — is the model that looks at it.

Every ACT tool is a WebAssembly component running inside wasmtime — a full VM with a JIT, linear memory, and no ambient host syscalls. Out of the box the component has zero filesystem access, zero outbound network, and no way to spawn a process. Each capability it does use (wasi:filesystem, wasi:http) is declared in the component manifest at build time and granted by the operator at run time. The host enforces the intersection: a permissive operator can't escalate past the component's stated intent, a lazy component can't silently exceed the operator's grant. You hand a tool from ghcr.io/someone-else/whatever to your agent, and the worst-case blast radius is still bounded by the policy you wrote.

That's the core trade ACT offers. The rest of this post is about why the WebAssembly-component substrate makes it practical.

Distribution, for free

A side benefit of picking WebAssembly: the artifact is a single binary that runs everywhere.

act info ghcr.io/actpkg/random:latest --tools

That command pulls a small component from GitHub's container registry, reads its metadata from a WASM custom section (no instantiation), and prints the tools it exposes. First pull is cached, every subsequent invocation hits the local ~/.cache/act/components. The artifact is signed by GitHub's attestation workflow and comes with an SBOM — all upstream machinery; ACT just uses it.

Same bytes, same SHA256, on Linux x86_64, macOS arm64, Windows, Android (validated), Raspberry Pi, inside a browser tab, inside a serverless runtime. No per-platform wheels, no native shims, no build toolchain required on anyone's machine but yours. And because the artifact is a registry object rather than three separate npm/pip/cargo packages, there's one supply-chain path to audit instead of three.

act accepts components from any of:

local path: ./my-component.wasm
HTTP URL: https://example.com/tool.wasm
OCI ref: ghcr.io/your-org/tool:1.2.3

No "my-tool-npm" and "my-tool-pypi" and "my-tool-cargo". One artifact. One namespace.

How the sandbox actually works

The isolation comes from three stacked layers, and it's worth separating them because "WASI sandbox" isn't quite the right phrase.

wasmtime is the actual isolation. It's a WebAssembly VM: linear-memory bounds enforced, no direct syscalls, no pointer aliasing, no escape outside of explicit host imports. Every ACT target runs the same wasmtime, so the isolation is identical on every OS and CPU.

WASI is the capability-import layer on top. A component asks for wasi:filesystem or wasi:http imports; the host either wires them up, provides a gated proxy, or leaves them unlinked. There's no "deny" at the capability level — a component either has the import or it doesn't.

ACT is the policy layer on top of WASI. Filesystem and outbound network are deny-by-default. The component's manifest declares what it needs ([std.capabilities."wasi:filesystem"], "wasi:http") — this is a ceiling. The operator's runtime flags (--fs-allow /tmp/db.sqlite, --http-allow host=api.example.com) are the grant. The host computes the intersection and refuses to wire up anything outside it.

Deny-CIDR rules sit in front of DNS resolution, so a component that tries to reach 169.254.169.254 (the cloud-metadata service) fails with a DnsError before a socket opens. HTTP redirects are re-checked per-hop, so a 302 to a denied host fails mid-chain instead of quietly succeeding. Details are in the capability-layer deep-dive (next post).

The VM gives us isolation. WASI gives us capability imports. ACT gives us the declaration-plus-ceiling model that makes those capabilities safe to hand to third-party code.

One component, any transport

Because tools are components, not native processes, the host can serve them over whatever wire format the caller wants.

# Claude Desktop / Cursor / Cline → stdio JSON-RPC
act run ghcr.io/actpkg/sqlite:latest --mcp \
  --fs-policy allowlist --fs-allow /tmp/demo.sqlite

# Web backend → REST-ish HTTP with SSE streaming
act run ghcr.io/actpkg/sqlite:latest --http --listen "[::1]:3000"

# Script / CI → one-shot direct call
act call ghcr.io/actpkg/sqlite:latest query \
  --args '{"sql": "SELECT sqlite_version()"}' \
  --metadata '{"database_path":"/tmp/demo.sqlite"}'

# Browser tab → jco transpile, no server at all
jco transpile ghcr.io/actpkg/sqlite:latest -o dist/

Same component, same tool, four deployments. Whatever new transport shows up next, the component doesn't change.

Writing one

Rust, the whole SDK surface for a trivial tool:

use act_sdk::prelude::*;

#[act_component]
mod component {
    use super::*;

    #[act_tool(description = "Reverse a string", read_only)]
    fn reverse(text: String) -> ActResult<String> {
        Ok(text.chars().rev().collect())
    }
}

cargo build --target wasm32-wasip2 --release + act-build pack and you have a .wasm that speaks MCP, HTTP, and the CLI. #[act_tool] derives the JSON Schema from the function signature; #[act_component] emits the WIT export. Python has the same shape with @component / @tool decorators on top of componentize-py.

Where this is

Early, and deliberately narrow.

The core spec lives in actcore/act-spec — a small WIT package for cross-cutting types and an opt-in interface package for tool dispatch, with stateful capabilities (sessions, events, resources) layered on as separate opt-in packages. The host ships as act on npm, cargo, and PyPI. A growing set of components is published on ghcr.io/actpkg — sqlite, http-client, crypto, encoding, filesystem, openwallet, python-eval, js-eval, random, time, plus three bridges (mcp-bridge, openapi-bridge, act-http-bridge). Rust and Python SDKs are live; JavaScript via componentize-js is blocked on upstream async-export support.

DEV Community: Alexander Shishenko

MCP servers, sandboxed — introducing ACT

Distribution, for free

How the sandbox actually works

One component, any transport

Writing one

Where this is