🗝️ Unique? Powerful? What Pipe Actually Does Differently

Pipe, a language-embedded agent sandbox, distinguishes itself by placing sandbox control inside the programming language itself, with ratchet semantics that prevent privilege escalation, structural gates that block silent bypasses, and integrated budget and audit logs. Unlike Claude Code, where MCP servers run unconstrained on the host, Pipe acts as both an MCP server and client, ensuring that all tools, whether local or remote, execute under the same sandbox profile. The sandbox is software-level and not a hardened boundary for adversarial code, but it can be nested inside a Docker container or microVM for additional isolation.

← 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