# 🗝️ Unique? Powerful? What Pipe Actually Does Differently

> Source: <https://pipe-lang.com/blog/sandbox-unique.html>
> Published: 2026-08-14 00:00:00+00:00

[← All posts← Alle Beiträge](../blog.html)

# Unique? Powerful? What Pipe Actually Does Differently

**A sandbox that lives in the language, an MCP protocol that is a first-class sandbox citizen, and an honest look at where it ends.**

When people ask whether Pipe's sandbox + MCP combo is "unique and powerful," the honest answer is: the *isolation* isn't unique — but *where the control lives* is. Here's the landscape, then the difference.

## The Landscape: Isolation Has a Maturity Ladder 🪜

| Layer | Example | Boundary |
|---|---|---|
| MicroVM | Firecracker, E2B, AWS Lambda | own kernel, hardware-enforced |
| User-space kernel | gVisor, Modal | syscalls reimplemented, host kernel never sees them directly |
| Container | Docker | shared kernel — explicitly not a security boundary |
| Permission system | Claude Code | tool-level allow/ask/deny, OS sandbox only for Bash |

OWASP's Top 10 for Agentic Applications (ASI05) is blunt: *software-only sandboxing is insufficient; LLM-generated code must run isolated*. Fair — for untrusted code, put a microVM under Pipe. But the question "where is the control" isn't answered by any of these layers.

## Where Pipe Differs: Control Lives in the Language 🗝️

Pipe's sandbox is a **declarative language construct**, not an external layer. You write the agent *and* the profile in one program:

```
sandbox_profile "cell" {fs: "temp-only", network: true, network_whitelist: ["api.deepseek.com"], exec: false, ai: true, budget: 0.5, max_tool_calls: 25, audit_log: true}
set_sandbox "cell"
```

Three properties matter:

**Ratchet semantics**— once a restricted profile is active, a script may only switch to profiles granting *same or fewer* rights (`IsSubsetOf`

). Even the agent can't free itself.**Structural gates**— a central egress gate and a central network helper check every network-capable builtin, so a future builtin can't silently bypass`--sandbox`

. Bug classes become impossible, not just rarer.**Budget + audit log**—`budget`

,`max_tool_calls`

,`timeout`

, and a per-event audit trail are part of the profile, not bolted on.

## The Real Clou: MCP Is a Sandbox Citizen 🔌

Pipe is simultaneously an **MCP server and an MCP client**. Locally registered tools (`ai_tool`

) and remotely discovered tools (bridged with an `mcp0_`

prefix) run under the **same profile**. In Claude Code, by contrast, MCP servers run *unconstrained on the host* — the permission system gates calls, but the server process itself is outside the sandbox.

That single detail is the difference: an external client like Cursor or Claude Desktop connects to a Pipe `serve`

session, gets the same five sandboxed tools, and every `tools/call`

executes under the profile. One sandbox, two entry points, same guarantee.

## The Honest Limits ⚠️

Pipe's sandbox is **software-level, inside the process** — no own kernel, no hardware boundary. It's superb for orchestrating agents quickly and safely without infrastructure; it's not a hardened boundary for adversarial code. No TLS inspection, so domain fronting is theoretically possible. But because the profile is a *script-level* construct, you can always run Pipe itself inside a Docker container or microVM and keep both layers.

## Try It 🚀

The demo shows the whole idea in one file:

```
DEEPSEEK_API_KEY=sk-... pipe examples/mcp_sandbox_agent.pipe agent
```

See the deep dive: ** The MCP Cell** — and the source at

[.](https://github.com/MachuraHarry/pipe/blob/master/examples/mcp_sandbox_agent.pipe)

`examples/mcp_sandbox_agent.pipe`

# Einmalig? Mächtig? Was Pipe wirklich anders macht

**Eine Sandbox, die in der Sprache lebt, ein MCP-Protokoll als Bürger erster Klasse der Sandbox — und ein ehrlicher Blick darauf, wo das aufhört.**

Wenn man fragt, ob Pipes Sandbox+MCP-Kombination „einmalig und mächtig" ist, ist die ehrliche Antwort: die *Isolation* ist es nicht — aber *wo die Kontrolle lebt*, sehr wohl. Erst die Landschaft, dann der Unterschied.

## Die Landschaft: Isolation hat eine Reifeskala 🪜

| Ebene | Beispiel | Grenze |
|---|---|---|
| MicroVM | Firecracker, E2B, AWS Lambda | eigener Kernel, hardware-gesichert |
| Userspace-Kernel | gVisor, Modal | Syscalls neuimplementiert, Host-Kernel sieht sie nie direkt |
| Container | Docker | geteilter Kernel — ausdrücklich keine Sicherheitsgrenze |
| Permission-System | Claude Code | Tool-Ebene allow/ask/deny, OS-Sandbox nur für Bash |

Der OWASP-Top-10-Bericht für Agentic Applications (ASI05) ist unmissverständlich: *Software-Sandboxing reicht nicht; LLM-generierter Code muss isoliert laufen*. Berechtigt — für unvertrauten Code legt man eine MicroVM unter Pipe. Aber die Frage „wo lebt die Kontrolle" beantwortet keine dieser Ebenen.

## Wo Pipe sich unterscheidet: Kontrolle lebt in der Sprache 🗝️

Pipes Sandbox ist ein **deklaratives Sprachkonstrukt**, keine äußere Schicht. Du schreibst Agent *und* Profil in einem Programm:

```
sandbox_profile "cell" {fs: "temp-only", network: true, network_whitelist: ["api.deepseek.com"], exec: false, ai: true, budget: 0.5, max_tool_calls: 25, audit_log: true}
set_sandbox "cell"
```

Drei Eigenschaften zählen:

**Ratchet-Semantik**— ist erst ein restriktives Profil aktiv, darf ein Skript nur in Profile wechseln, die *gleich viele oder weniger* Rechte gewähren (`IsSubsetOf`

). Nicht einmal der Agent kann sich selbst befreien.**Strukturelle Gates**— ein zentraler Egress-Gate und ein zentraler Netz-Helper prüfen jedes netzfähige Builtin, damit ein künftiges Builtin`--sandbox`

nicht stillschweigend umgeht. Fehlerklassen werden unmöglich, nicht nur seltener.**Budget + Audit-Log**—`budget`

,`max_tool_calls`

,`timeout`

und ein lückenloser Audit-Trail gehören zum Profil, sind nicht nachträglich aufgesetzt.

## Der eigentliche Clou: MCP ist Sandbox-Bürger 🔌

Pipe ist zugleich **MCP-Server und MCP-Client**. Lokal registrierte Tools (`ai_tool`

) und entfernt entdeckte Tools (gebridged mit `mcp0_`

-Präfix) laufen unter **demselben Profil**. Bei Claude Code laufen MCP-Server dagegen *uneingeschränkt auf dem Host* — das Permission-System sperrt Aufrufe, aber der Serverprozess selbst liegt außerhalb der Sandbox.

Genau dieses Detail ist der Unterschied: Ein externer Client wie Cursor oder Claude Desktop verbindet sich mit einer Pipe-`serve`

-Session, bekommt dieselben fünf sandboxed Tools, und jeder `tools/call`

läuft unter dem Profil. Eine Sandbox, zwei Einstiegspunkte, dieselbe Garantie.

## Die ehrlichen Grenzen ⚠️

Pipes Sandbox ist **auf Software-Ebene, im Prozess** — kein eigener Kernel, keine Hardware-Grenze. Sie ist hervorragend, um Agenten schnell und sicher *ohne* Infrastruktur zu orchestrieren; keine gehärtete Grenze für adversariellen Code. Keine TLS-Inspektion, Domain-Fronting ist theoretisch möglich. Aber weil das Profil ein *Skript-Ebenen*-Konstrukt ist, kannst du Pipe selbst jederzeit in einen Docker-Container oder eine MicroVM legen und beide Ebenen behalten.

## Probier es 🚀

Die Demo zeigt die ganze Idee in einer Datei:

```
DEEPSEEK_API_KEY=sk-... pipe examples/mcp_sandbox_agent.pipe agent
```

Zum Eintauchen: ** Die MCP-Zelle** — und der Quelltext unter

[.](https://github.com/MachuraHarry/pipe/blob/master/examples/mcp_sandbox_agent.pipe)

`examples/mcp_sandbox_agent.pipe`