sandboxed-api

Sandboxed API takes a C or C++ library you do not fully trust, an image parser, a font renderer, a decompressor, and puts it in its own locked-down process so a memory bug in that library cannot reach the rest of your program. Google built it on top of Sandbox2 and uses it internally. The working motto is sandbox once, use anywhere: you write the policy for a library a single time and every project that needs that library reuses it. Apache 2.0.

Getting there is real engineering. Builds run under Bazel or CMake, it is Linux-only, and each sandboxed library gets a tightly scoped security policy plus generated RPC stubs for calls that now cross a process boundary. That boundary is also a performance and data-marshalling cost you have to design around. This is infrastructure work measured in days, not an afternoon.

Free, entirely, with no commercial edition. The teams that should care are the ones shipping C or C++ that touches untrusted input: file format parsers, media pipelines, anything processing user uploads. Everyone else does not need this. For sandboxing whole workloads rather than a single library, gVisor or Firecracker are the different tool.

The catch is that it only helps if you were already going to do this work. Sandboxing changes your calling convention, and a team that will not maintain a per-library policy will end up with a sandbox that is permissive enough to be theater.