Amla Sandbox

Checked: 2026-07-14

Summary

Amla Sandbox is a Python library that runs agent-generated JavaScript and a small bash-like command set inside WebAssembly. The agent receives only the host tools and permissions the developer explicitly grants.

It is best understood as a locked workshop inside an application, not a disposable Linux computer like Clawk.

Problem it solves

• Unsafe generated code: Agent-written code should not inherit the host process’s files, shell, network, or credentials.
• Overpowered tools: A tool can be narrowed by allowed method, argument rules, and number of calls.
• Agent loops: Code can inspect and transform data locally, then request approved host actions without a new model call for every small step.

How it works

• Embedded runtime: Python loads a bundled Rust WebAssembly module through Wasmtime.
• Languages: QuickJS provides JavaScript ES2020. A shell facade provides selected utilities such as cat, grep, jq, sort, head, tail, and wc.
• Virtual files: Code sees an in-memory file system rather than the host file system.
• Host tools: The application registers functions. A sandboxed call is checked, then routed to the trusted Python handler.
• Limits: The API supports call budgets, argument constraints, maximum execution steps, and tool-result size controls.

The “shell” is not the host shell. It is a small command interpreter inside the WebAssembly runtime.

Security boundary

• No ambient authority: Sandboxed code has no direct host file, process, shell, network, or secret access.
• Memory isolation: WebAssembly linear memory is bounds-checked and separate from the Python host address space.
• Capability checks: Every registered tool call is validated before its host handler runs.
• Small syscall surface: WASI, the WebAssembly system interface, exposes a limited host boundary.
• Trusted gateway: Host tool handlers remain trusted. A broad or buggy handler can still leak data or perform harmful actions.
• Not a full containment VM: This protects the embedded workload. It does not isolate an arbitrary native binary, package installer, or coding-agent command-line program.

The HN launch text made stronger claims about Wasmtime being formally verified for memory safety. Treat that as a project claim, not independent proof of the complete Amla system.

Platforms and agents

• Host: Python 3.11 or newer with cryptography and wasmtime.
• Distribution: Python package containing the prebuilt WebAssembly runtime; no Docker daemon or separate service is required.
• Agent frameworks: Examples cover LangGraph, CodeAct, Anthropic/OpenAI tool ingestion, multi-agent use, audit logging, and rate limits.
• Workloads: JavaScript reasoning, text/data processing, virtual-file tasks, and calls to approved application tools.
• Not supported directly: Full Linux coding agents, native build tools, arbitrary subprocesses, or software that expects a normal operating system.

Setup

1. Install: pip install amla-sandbox.
2. Create a sandbox: Construct the Python sandbox and add initial virtual files if needed.
3. Register tools: Provide host handlers and narrow capabilities.
4. Run code: Execute generated JavaScript or the limited shell syntax and handle approved tool calls.

There is also an amla-precompile command for preparing the runtime.

Network and credentials

• Direct network: None from sandboxed code.
• Approved network: A developer can expose a narrow HTTP, database, or service tool through a host handler.
• Credentials: Secrets can stay in the trusted host handler; sandboxed code receives only the handler’s result.
• Leak risk: Tool output can still reveal secrets, and an overly broad tool can become a confused deputy—an authorized helper tricked into doing the wrong action.
• Control: Parameter rules and maximum call counts reduce misuse but do not replace careful tool design.

Strengths

• Small deployment: One Python dependency path rather than a container or virtual-machine service.
• Default denial: Code receives no host access unless the application grants it.
• Fine-grained tools: Permissions can restrict arguments and call counts, not only tool names.
• Portable design: The same embedded runtime can run wherever its Python and Wasmtime dependencies work.
• Agent-friendly: JavaScript, virtual files, tool calls, introspection, and asynchronous handlers fit CodeAct-style agent loops.
• Release safeguards: The release flow verifies the WebAssembly artifact’s SHA-256 digest and GitHub build-provenance attestation, and publishes to PyPI with short-lived OIDC identity instead of a stored token.

Limits

• Limited compatibility: It cannot run a normal coding-agent executable or arbitrary Linux command.
• Custom integration: Developers must define safe host tools and connect them to their agent framework.
• Runtime scope: JavaScript ES2020 and the shell facade are smaller than a full language and operating-system environment.
• Gateway risk: Security depends heavily on the permissions and behavior of registered host handlers.
• Young project: The package labels itself Alpha and has a short public history.
• Split source: The Python package is a release mirror; development occurs in an Amla Labs monorepo, while the Rust runtime has a separate public release repository.
• Mixed licensing: The Python package states MIT. The bundled Rust WebAssembly runtime is offered under AGPL-3.0-or-later or BUSL-1.1, so commercial users should review the terms.

Activity and maturity

As of 2026-07-14:

• Latest release: v0.2.8, published 2026-05-15.
• Repository: Created 2026-01-29; 342 stars and 13 forks when checked.
• Code activity: The public Python mirror and Rust core were last pushed on 2026-05-15.
• Status: The package classifier says Alpha.
• Interpretation: Promising and actively noticed, but too new and lightly proven to assume production maturity without a security review and workload-specific tests.

Best fit

• Good fit: A Python application wants agents to calculate, transform data, work with temporary files, and call a small set of business tools.
• Good fit: The team wants capabilities expressed in application code and does not want to operate containers or virtual machines.
• Poor fit: The agent must clone repositories, install native packages, compile software, use browsers, or run existing command-line coding agents unchanged.

Comparison with Clawk

Area	Amla Sandbox	Clawk
Boundary	Embedded WebAssembly runtime	Full Linux virtual machine
Agent access	JavaScript, limited shell facade, registered tools	Normal Linux tools and coding-agent programs
Network	None unless a host tool provides it	Controlled network access for the VM
Credentials	Kept behind host tool handlers	Brokered or injected for tools inside the VM
Setup weight	Python package	VM image and virtual-machine runtime
Compatibility	Narrow	Broad
Best use	App-embedded agent code and business tools	Untrusted full coding-agent sessions

Practical choice: Pick Amla when a narrow tool belt is enough. Pick Clawk when the agent needs an entire workshop.

Hacker News context

• Original Amla launch: HN item 46824877 was titled “Show HN: Amla Sandbox – WASM bash shell sandbox for AI agents.” The post described generated-code safety, a bash-like shell, developer-provided constrained tools, and installation without Docker, subprocesses, or SaaS.
• Security discussion: Comment 46825026 quoted Amla’s capability model, WebAssembly/WASI boundary, Wasmtime memory isolation, and validation of every tool call.
• Clawk thread: In HN item 48892859, comment 48893850 linked that Amla security comment in a large list of related sandboxing projects and technologies. The reference was indirect rather than a detailed comparison.

Direct sources

• Amla Sandbox repository
• Amla Sandbox v0.2.8
• Amla Sandbox Rust core
• Amla launch on Hacker News
• Amla security-model comment
• Clawk discussion
• Clawk thread reference to Amla

Unknowns

• Security audit: No independent audit was found in the checked public material.
• Production use: No named large production deployments were verified.
• Platform matrix: The package says it works anywhere supported dependencies run, but a tested operating-system and CPU matrix was not found.
• Long-term licensing: The Rust runtime’s dual-license path and Business Source License conversion terms need legal review for each intended use.
• Roadmap: The development monorepo is not the release mirror, so public activity may not show the full current roadmap.

Sources

• • imported AI research note for Amla Sandbox.