Sandboxed API isolates a library rather than a process, and reuses the policy with it

The unit of isolation is a library, not a program

Sandboxed API builds on Google's Sandbox2 and sets out to make sandboxing of C and C++ libraries less burdensome. The distinction that defines the project is stated first in its list of benefits.

Instead of sandboxing entire programs, or changing source code so that part of a program can be sandboxed as with Sandbox2, individual libraries can be sandboxed with SAPI. The consequence is that the main program is isolated from code execution vulnerabilities inside that library. If a parser or an image codec has a memory safety bug, the blast radius is the sandbox rather than the process.

That is a different engineering commitment from sandboxing a whole program. You are choosing to redesign a library's interface so that it can run behind an RPC-like boundary, and that design work is the real cost of the approach.

The project states it was designed, developed and is maintained by members of the Google Sandbox Team, that many internal projects use it to isolate production workloads, and that Sandbox2 is open sourced as part of the same project and can be used independently.

Sandbox once, use anywhere, and why the policy scope is the win

The working motto in the README is "Sandbox once, use anywhere", and the second bullet explains what it means in practice.

Before SAPI, a sandbox available for use at Google required additional implementation work for each new instance of a project, even when the project reused the same software library. Sandbox2 policies and other restrictions applied to the sandboxed process had to be reimplemented each time, and the data exchange mechanisms between trusted and untrusted parts of the code had to be designed from scratch.

The third bullet explains the consequence for security. Each SAPI library uses a tightly defined security policy, in contrast to a typical sandboxed project where the policy has to cover the total syscall and resource footprint of every library in use. A narrow interface means a small policy, and a small policy is a policy you can reason about.

Taken together, the pitch is that the expensive part, the policy and the interface, is paid once per library and then inherited by every program that uses it.

The bindings are generated by a Clang tool, which sets the LLVM requirement

SAPI ships a clang tool header generator built on LLVM Libtooling, in tools/clang_generator. The generator reads the library headers and produces the sandbox interface, which is what removes the hand written binding layer.

That choice sets the toolchain constraint. The documented dependencies for Debian 13, named Trixie, pin a specific clang generation:

sudo apt-get install -qy --no-install-recommends \
      build-essential \
      clang-19 \
      libcap-dev \
      libclang-19-dev \
      libclang-rt-19-dev \
      libncurses-dev \
      libzstd-dev \
      linux-libc-dev \
      llvm-19-dev \
      pkg-config \
      zlib1g-dev

The Clang 19 packages appear three times: the compiler itself, the development headers, and the compiler runtime. llvm-19-dev is what Libtooling comes from. libcap-dev is there because the sandbox needs capabilities, which is consistent with a runtime that creates constrained processes.

The project's stated support target is at least the latest three LLVM releases, tested on Debian stable. That is a moving window rather than a fixed version, so a clang upgrade is a routine maintenance event for adopters rather than an upgrade event.

Support for both build systems is explicit, with separate dependency sets for each: Bazel needs bazel and openjdk-17-jdk-headless, while CMake needs cmake and ninja-build.

Building the generator is not the same as using it

The dependency list is a build-time story. SAPI and Sandbox2 both support Bazel and CMake, which means you can build the tooling itself under either, and the two are not interchangeable for every target.

The repository carries both systems at the top level. There is MODULE.bazel with a matching MODULE.bazel.lock, a .bazelrc, a .bazelignore and .gitmodules, alongside CMakeLists.txt and a cmake/ directory. CI reflects the split too, with separate build status badges for Debian on Bazel and Ubuntu on CMake.

Under sandboxed_api/ sit the SAPI libraries themselves and the docs directory whose images the README uses, and there is also contrib/ for tooling and an oss-internship-2020/ directory preserved from an internship programme.

So the practical expectation is a build of moderate size before you write a single sandbox. That is not a criticism of the project, which is aimed at C and C++ developers who already have a native build, but it is part of the adoption cost and it belongs in the estimate.

Where Sandboxed API is the wrong tool

The first wrong case is a library whose interface does not survive the boundary. SAPI works by narrowing what a library can be asked to do, through an interface defined in terms of serialisable data. A library whose value is in exposing pointers, callbacks into caller memory, or in-process state cannot be wrapped without redesigning it, and the redesign is often larger than the vulnerability you were mitigating.

The second wrong case is a managed language codebase with one native dependency. Isolating a whole program with Sandbox2 is a smaller change than isolating one library, and the same repository ships Sandbox2 for exactly that. Reaching for SAPI when Sandbox2 would do means taking on an interface design project for a marginal gain in isolation.

The third is the toolchain mismatch. The documented dependency set targets a specific clang generation on a specific Debian release, and the generator is LLVM Libtooling, so the tooling tracks LLVM release cycles. If your organisation cannot keep up with a clang version every few months, that is a maintenance cost the project states rather than hides, but it is real.

Licensing is Apache 2.0 with the copyright stated as Google LLC 2019 to 2026, which is the permissive end of Google's open source output and carries no copyleft obligation on adopters.

Maintenance signals and where the documentation lives

The last push was recorded on 2026-10-16, and the latest release was published on 2026-10-15, so the project is actively worked on. The visible release tags are older and differently shaped: v20241008 from 2024-10-08, v20190823 described as Full CMake support from 2019-09-03, and a rolling latest tag that follows the default branch rather than cutting numbered releases.

That tag scheme matters. There is no semver to pin for a C++ project that pulls its dependencies at build time, so tracking main means tracking whatever the tree contains on the day you fetch it. For a security boundary, that is a deliberate trade-off rather than an oversight, and it means you should vendor a known commit rather than tracking a branch.

Documentation is not in the repository. Developer documentation lives at developers.google.com under code-sandboxing, split into separate Sandboxed API and Sandbox2 sections, with getting started guides recommended for each. There is also a general overview page for sandboxing technologies aimed at people who have not yet chosen a mechanism.

Contribution goes through CONTRIBUTING.md, with a mailing list at [email protected] for product updates.

Editorial conclusion

Adopt Sandboxed API if you have a native library whose execution bugs you need contained without isolating the whole program, and you can live with the cost of designing a narrow interface to it. Do not adopt it as a way to sandbox an application, since that is what Sandbox2 does directly and Sandbox2 is open sourced in the same repository and usable on its own. Verify first your toolchain matches, because the documented dependency set is pinned to clang-19 and libclang-19-dev on Debian 13, and confirm the project supports at least the latest three LLVM releases before committing to a clang version.

Frequently asked questions

Official sources

1. google/sandboxed-api on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases