The recommendation rests on three things public evidence establishes and one it does not. Established: the technical work is real and unusually well-executed; the threat model is stated more honestly than most funded security companies state theirs; and the construction pattern looks like durable systems engineering rather than a demo. Not established: whether anyone has ever tried to break it, and whether anyone pays. Both unknowns are conversation-resolvable — which is exactly what makes this a founder conversation rather than a pass or a watch.

Distribution is unusually complete for a project this young: a CLI, an OCI runtime shim for containerd / CRI-O / Kubernetes, a C ABI, and Python and Go SDKs [S2]. The codebase is 3.3 MB of Rust [S15], and the integration-test files are comparable in size to the modules they test [S2] — an unusual and good sign in a security project.

The organising idea

“Static, input-independent policy is compiled into kernel-enforced rules, while a narrow supervisor handles runtime-dependent decisions and virtualized effects.”

That sentence is the whole architecture, and it is the right frame for evaluating it. Anything expressible as a static rule goes to the kernel, where it is fast and TOCTOU-immune. Anything requiring a runtime decision goes to a userspace supervisor, which is slower and more trusted. The design question is where that line sits — and the hard engineering lives on the supervisor side: cow/seccomp.rs alone is 319 KB, the largest file in the repository [S2].

Beyond a conventional sandbox

Filesystem and syscall confinement is table stakes. The differentiated surface [S3] [S4]: an HTTP-level ACL on method + host + path via a transparent proxy; destination-IP and CIDR allowlists with no DNS; credential injection where the secret stays in the supervisor and is attached after the ACL check; a copy-on-write working directory with transactional commit/abort; deterministic execution (frozen time, seeded randomness); and a handler API on any syscall where a custom handler “can extend confinement but never relax it” [S6].

The diagram is a summary; the dimension-by-dimension table below carries the same comparison in full, and the project’s own comparison page [S7] was one of its sources. There is deliberately no “security score” anywhere on this page — the architectures fail differently, and a single number would erase exactly the information that matters.

What a hostile workload actually does

This is why the interesting layer of Sandlock is not the sandbox. It is the semantic execution policy: an HTTP ACL on method/host/path, a credential the child process can use but never read, and transactional writes that make a failed run leave no trace. The syscall confinement underneath is competent; the policy layer is the part a competitor would have to decide to build, not just port.

The last row is the sharpest challenge — “isn’t this just the kernel’s feature?” Landlock is a public kernel feature. What sits on top: the seccomp user-notification policy engine (the 319 KB CoW path), the HTTP ACL and credential injection, transactional filesystem semantics, the resolved per-protection posture model, and the distribution. Identical ceiling; almost none of the product.

The founder is described on the company site as a Linux kernel developer with 16+ years’ experience, maintainer of the networking traffic-control subsystem since 2017 [S14]. Kernel-subsystem-maintainer expertise applied to a userspace product is rare, verifiable from the public kernel record, and not hireable on a normal timeline. The test files being comparable in size to the modules they test [S2] is what a durable system looks like from outside.

The 5 ms startup figure and the Redis-throughput result were not reproduced here: the pre-registered reproduction budget went to the Headroom experiment, and Sandlock’s default posture needs Linux 6.12 while the test machine is macOS. They are carried as project claims, not as verified numbers — and nothing on this page treats them as verified.

The biggest gap in the record: No evidence of any adversarial contact: no audit, no bounty, no published escape attempt. For a security product, survived adversarial contact is the evidence that matters most, and it is absent from public sources. Absence of an audit is not evidence of weakness — it is absence of evidence, in the category where evidence matters most.

Source: org repository listing [S13]

The AgentSight relationship — stated precisely

Why this matters to the sourcing system itself: Phase 2 counted Multikernel and AgentSight as two independent leads. They share an author, so they are one intellectual cluster as evidence. v2 must not double-count them.

Could a strong security team reproduce it? The architecture, yes — in six to twelve months with two or three engineers who genuinely understand seccomp notification. What stays hard: the CoW correctness surface, the TOCTOU discipline, and the kernel-maintainer judgement about which primitives will exist in two years. That is a real head start and a thin moat, and both statements are true at once.

1. 01

   Your security page says a kernel LPE in a permitted syscall defeats the sandbox. Which customers have accepted that trade, which have refused it — and what did the ones who refused choose instead?

2. 02

   cow/seccomp.rs is your largest file. What is the hardest correctness problem in the copy-on-write path, and what have you got wrong there before?

3. 03

   Has anyone outside the team attempted an escape? Audit, bug bounty, red team, a customer's security review — what happened, and what did it change?

4. 04

   Landlock ABI v6 means kernel 6.12. What fraction of inbound interest dies on that requirement, and what does allow_degraded actually get used for in the field?

5. 05

   Multikernel sells three products. If you had to kill two, which survive — and is Sandlock a wedge into the cloud-OS business, or the business itself?

6. 06

   branchfs and branching both stopped in Q2 2026 as sandlock accelerated. What did you learn that made you consolidate?

7. 07

   Sandlock is Apache-2.0 and your site says “what is open, what is licensed.” Where is that line, and what stops a cloud provider from running the open core as a service?

Pre-registered evaluation: a specific, unflattering war story about a CoW correctness bug strengthens; “nobody has tried to break it yet” weakens — and those bars were written down before any answer could exist.

Related on this site: how the same system pressure-tests a quantitative claim when reproduction is feasible, and what happens when its own rules fail.

One defect found on the way: the project site’s own navigation links to /security-model/ and /comparison/, which 404 — the real paths are security.html and comparison.html. Noted because a careful reader reports that rather than silently working around it.