标签：#sandbox

A year ago, "it's just a ChatGPT wrapper" was a dismissal. You'd hear it about a startup and know what it meant: an LLM API call, a little RAG, file upload, a chat box on top. Thin. Replaceable. Probably dead the next time the base model shipped a feature. I keep coming back to that phrase, because it stopped being true in a way I didn't notice happening. The thing you'd be wrapping is no longer a model with a chat UI. It's a fast, stateful web application with its own agent loop, its own sandbox, its own artifact system. The wrapper didn't get easier to build as the models got better. It got heavier . The simple interface hides the hard part. A ChatGPT-shaped product is not just an API call with a chat box around it; it's the accumulation of many product and infrastructure decisions that make execution feel safe, stateful, and immediate. The model is the part you can buy. The surrounding runtime is the part people had to design. What gets me is the timescale. It's been roughly a year, and the question actually worth arguing about has moved out from under us — from "is this just a wrapper?" to "where does the sandbox even run?" The pace is faster than I can comfortably track. And the part I keep finding fun is that it all bends toward the practical, not away from it: every one of these shifts makes the tools more usable, more real, closer to something you'd actually ship. Surprising and, honestly, a good time to be building. This isn't a "wrappers are over" argument, and it isn't advice. It's me writing down where my thinking has drifted while trying to build these things myself — partly so I can find out where it's wrong. Read it as one person's notes. What "wrapper" used to mean The old shape was honestly small. Roughly: prompt → LLM API → (RAG retrieval) → response + file parsing on the side The whole game was prompt design, a retrieval index, and some glue. You could stand it up in a weekend. The reason "wrapper" was an insult is that the surface area was tiny —

A capability-compiler meets ten deliberately-broken MCP servers. The honest scorecard: it cleanly stops one class, shrinks the blast radius on several, and is useless against another. Knowing which is which is the whole point. Disclosure: I'm the author of capgate , the Apache-2.0 sandbox compiler this post puts to the test. The DVMCP project and the other tools mentioned aren't mine; the manifests and compiled output are reproducible from the repo . The setup Damn Vulnerable MCP (DVMCP) is a teaching project: ten MCP servers, each built to demonstrate one attack — prompt injection, tool poisoning, excessive permission scope, token theft, command injection, and so on. It's the closest thing the ecosystem has to a shared adversarial fixture. capgate is a compile-time tool. You write a manifest declaring what an MCP server is allowed to do — fs:read:/workspace/** , net:connect:api.github.com:443 , nothing else — and it compiles that to a concrete sandbox policy ( docker run flags, bwrap argv, or an egress-proxy config). It does not run anything, watch traffic, or inspect the server's code. It turns a declared capability set into an enforced boundary. So this is a fair, falsifiable test: for each DVMCP challenge, I wrote the honest minimum manifest, compiled it, and asked one question — does the boundary capgate emits actually stop the attack? The answer is not "yes" across the board, and the cases where it's "no" are the interesting ones. The bullseye: Challenge 3 — Excessive Permission Scope The vulnerable tool advertises "read a file from the public directory" and then does this: @mcp.tool () def read_file ( filename : str ) -> str : # VULNERABILITY: doesn't restrict file access to the public directory if os . path . exists ( filename ): # any absolute path works with open ( filename , " r " ) as f : return f . read () The private directory next door holds employee_salaries.txt , acquisition_plans.txt , and system_credentials.txt (a live DB password and cloud API ke

In sandbox runtimes, "isolation" is the core requirement. qwrap (based on bwrap user namespace) and Container (podman/docker) are two mainstream backends. They solve the same problem — running code in a restricted environment — but take completely different paths. This article uses extensive analogies to help you understand the similarities and differences. Building Intuition: Two Ways to "Lock the Door" Imagine you need to confine someone you don't fully trust in a room to do work: qwrap approach : In your existing house, you put up a partition to wall off a corner, leaving only a small window to pass materials through. The walls are still the original walls, the floor is still the original floor, but the person can only see what's inside the partition. Container approach : You build a shipping container with its own independent power, water, and ventilation systems. Put the person inside, close the door. They feel like they're in a complete little house, completely unaware of what's outside. This is the most fundamental difference: qwrap is lightweight view isolation, Container is complete environment encapsulation . What is qwrap (bwrap user namespace) qwrap uses bubblewrap (bwrap) under the hood, a sandboxing tool that leverages Linux user namespaces. How it Works Host filesystem ├── /usr/bin/python3 ← Host's Python ├── /home/user/project/ ← User project └── /tmp/secrets/ ← Sensitive files qwrap sandbox view (what the process sees) ├── /usr/bin/python3 ← bind-mounted in, read-only ├── /workspace/ ← Only the project directory is exposed └── (/tmp/secrets/ doesn't exist) ← Completely invisible Key mechanisms: User Namespace : The process thinks it's root, but actually maps to an unprivileged user on the host Mount Namespace : Only bind-mounts necessary directories in, everything else is invisible No images, no layers, no network namespace (unless explicitly configured) Analogy: VPN Split Tunneling qwrap is like split-tunneling rules on your phone — you're not wrap