GitHub - amlalabs/amla-sandbox amla-sandbox is a secure, lightweight sandbox for running code generated by AI agents. Unlike most agent frameworks that execute LLM-generated code using subprocesses or exec—creating a serious security risk through arbitrary code execution—amla-sandbox uses WebAssembly (WASM) with capability-based security to prevent escapes and enforce strict access controls. Popular frameworks like LangChain, AutoGen, and SWE-Agent rely on unsafe execution methods. For example, LangChain uses exec(command, globals, locals), which has a known vulnerability (CVE-2025-68664), while AutoGen and SWE-Agent use subprocess.run(), leaving systems exposed to prompt injection attacks. Some frameworks offer Docker-based isolation (like OpenHands and AutoGen), but this requires a running Docker daemon and adds complexity in managing containers. amla-sandbox eliminates these risks. It runs in a WASM environment with WASI (WebAssembly System Interface), providing minimal, secure system calls. WASM ensures memory safety by design—linear memory is bounds-checked, and there’s no way to access the host’s address space. The underlying wasmtime runtime is built with defense-in-depth principles and has been formally verified for memory safety. Beyond WASM isolation, amla-sandbox enforces capabilities at runtime. Agents can only call tools you explicitly permit, with constraints you define. For example: ```python from amla_sandbox import Sandbox, MethodCapability, ConstraintSet, Param sandbox = Sandbox( capabilities=[ MethodCapability( method_pattern="stripe/charges/*", constraints=ConstraintSet([ Param("amount") <= 10000, Param("currency").is_in(["USD", "EUR"]), ]), max_calls=100, ), ], tool_handler=my_handler, ) This works sandbox.execute('await stripe.charges.create({amount: 500, currency: "USD"})') This fails — amount exceeds the allowed limit sandbox.execute('await stripe.charges.create({amount: 50000, currency: "USD"})') ``` This model is inspired by capability-based security systems like seL4, where access is granted explicitly, not implicitly. This is critical because prompt injection remains a fundamental and unsolved threat in AI systems. By limiting what agents can do, even if compromised, the damage is contained. The sandbox includes a writable virtual filesystem under /workspace and /tmp, but blocks network access and shell escapes entirely. It requires no Docker, no VM, and runs as a single binary across platforms. Efficiency is another key benefit. Tool-calling in agents is expensive—each call typically requires a round trip to the LLM. Code mode reduces this by batching multiple operations. But without security, running generated code is dangerous. amla-sandbox delivers both efficiency and safety. Quick start is simple. The JavaScript API uses object syntax for tools and supports return or console.log() for output. The virtual filesystem is accessible only within /workspace and /tmp. For integration with LangGraph, the sandbox supports yielding on tool calls. The host executes the tool (after capability checks) and resumes execution. The JavaScript runtime runs inside WASM via QuickJS. Initial setup takes about 300ms to compile the WASM module, but subsequent loads are near-instant (~0.5ms) when cached. The constraint system supports pattern matching on method names and allows flexible validation logic. Tradeoffs exist: amla-sandbox doesn’t provide a full Linux environment, native module support, or GPU access. It also doesn’t protect against infinite loops—code like while(true){} will hang, since the step limit only applies to WASM yields, not JavaScript execution. For full VMs with persistent state and complex dependencies, tools like e2b or Modal are better suited. But for the typical use case—running AI-generated code with controlled tool access—amla-sandbox offers a secure, lightweight, and efficient alternative. The Python code is licensed under MIT. The WASM binary is proprietary: it can be used with the package but cannot be extracted or redistributed independently. Website · Examples · Docs