I spent the last few months reading ten systems papers that, taken together, map the entire design space for serverless sandboxing. This post is not a paper-by-paper summary. It is an attempt to identify the fault lines -- the tensions, convergence points, and trade-offs that define where the field is heading. I am writing this as someone actively building a serverless sandbox (Shimmy), so the lens is practical: what would you actually build today?
Update 2026-03-09: sandbox_exec has since evolved into Sandlock — a modular, full-stack sandbox with strict mode, language-level sandboxes (Python/JS), a source scanner, and LD_PRELOAD hooks. See Sandlock v1.4: From Single File to Full-Stack Sandbox and the GitHub repo.
The previous two posts covered the threat model and the seccomp sandbox. This one is about going further: a WebAssembly execution environment where the security properties come from the compilation target, not from OS-level filters.
Today my MSc project officially kicked off. The premise sounds simple: run student code safely inside AWS Lambda. The constraints make it interesting.
Lambda Feedback is a platform where students submit code and get it evaluated in real time. The backend uses serverless functions — AWS Lambda spins up a container, runs the code, returns the result.
