Decide what untrusted code is allowed to do — and prove it.

For years, code under your account was code you wrote, installed, and were watching — so letting it inherit your full authority was fine. It isn't any more. A modern $HOME runs npm and pip trees, build plugins, language servers, and AI agents that write and run code on your behalf: pulled in wholesale, mostly unread, executing with access to your keys, your email, your browsing history, and all of your source.

The kernel has been able to contain this for years — SELinux, AppArmor, Landlock — but those are authored by the OS vendor, not by the person running the code, so in practice they get switched off rather than used. And because nothing separates you from a program under your UID, every shortcut you take is inherited by whatever you run next. The boundary that matters moved inside your account; the means to defend it stayed outside, and out of reach.

So you impose it from the outside instead. That is a kennel: a space you set up in advance, where the code runs freely but reaches only what you chose to put in with it.

The longer argument — why the existing mechanisms fail, why self-sandboxing misses the point, and where an organisation's own policy is meant to attach — is laid out in the case for Kennel.

The word Project is deliberate. Confining untrusted code is mostly a thinking problem — deciding what to confine, and being able to show the working — and only then a sandbox. Kennel publishes that reasoning as three deliverables, each derived from the one before, so the controls in the code trace back to named risks and the risks trace back to a stated practice.

The order is the method, not a roadmap. The catalogue names the threats; the design is the reasoning that answers them; the runtime is what you get when you build controls that discharge each one. The traceability — control to threat to principle — is the deliverable. The catalogue and the design don't depend on running our code: cite the catalogue in your own posture, or build a fresh runtime to the design. The Linux runtime is one worked answer, not the only one. Start with the threat catalogue, read the design, or jump to the reference runtime.

When Microsoft shipped MXC in 2026 — "policy-driven, layered isolation and containment" — it confirmed the category is real. Kennel's contribution is the part underneath the tool: the catalogue and the design that say why a given control belongs, written down to be argued with.

Most sandboxes advise; this one enforces. Default-deny throughout — it bounds the files a workload can see, brokers and logs its network, and runs only the binaries you name, on the real kernel and on your actual files. Each capability below traces back to a threat in the catalogue.

The runtime is Linux, composing Landlock, cgroup BPF, seccomp and namespaces. It isn't the portable part — the threat catalogue and the design are, and a different team could build a runtime to them on another substrate entirely. Other backends (macOS Seatbelt, FreeBSD jails, a microVM) are possible future work, not a current claim.

Project Kennel is pre-release: the reference runtime is built and runs the full vertical unprivileged on stock Linux (kernel 6.17, Landlock ABI ≥ 6), but interfaces and guarantees may still change. The install is offline — prebuilt binaries, no toolchain, no network — and adds one setuid-root helper for the three host-global operations a user namespace cannot reach.

3 · run something inside a kennel

A policy is declarative, signed, version-pinned code — not behaviour, but kernel-level constraint. The shipped ai-coding-strict template, in part:

Full instructions, the policy language, and the man pages are in the documentation. Builds are on the releases page; the source is on GitHub.

Kennel doesn't reimplement the kernel or put a runtime in front of it. It composes the enforcement the platform already provides and wires it to one declarative policy. Everything starts from deny: filesystem access is a specific grant rather than your whole home, outbound traffic is brokered and logged, and execution is limited to named binaries. A small privileged helper does the few steps that genuinely need root, so the workload itself never runs with elevated rights.

Because Kennel governs what a workload can reach rather than the host kernel's attack surface, it sits comfortably underneath stronger isolation when a job calls for it. Run a kennel around a gVisor sandbox or a microVM and you add host-kernel-exploit containment without giving up the egress control, the recon-resistance, or the audit trail. Different layers doing different jobs — stacked only when it's worth it.