Show HN: Nono – Kernel-enforced sandboxing for AI agents

The problem: AI agents execute code on your machine. Prompt injections, hallucinations, or compromised tools can read ~/.ssh, exfiltrate credentials, or worse. Application-level sandboxes can be bypassed by the code they're sandboxing.

I have been around security for a long old time now (i started something called sigstore a few years back) and have seen this pattern so many times before.

nono uses OS-level isolation that userspace can't escape:

Linux: Landlock LSM (kernel 5.13+) macOS: Seatbelt (sandbox_init) After sandbox + exec(), there's no syscall to expand permissions. The kernel says no.

What it does:

nono run --profile openclaw -- openclaw gatewa nono run --allow . --net-block -- npm install nono run --secrets api_key -- ./my-agent

Filesystem: read/write/allow per directory or file Network: block entirely (per-host filtering planned) Secrets: loads from macOS Keychain / Linux Secret Service, injects as env vars, zeroizes after exec

Technical details:

Written in Rust. ~2k LOC. Uses the landlock crate on Linux, raw FFI to sandbox_init() on macOS. Secrets via keyring crate. All paths canonicalized at grant time to prevent symlink escapes.

Landlock ABI v4+ gives us TCP port filtering. Older kernels fall back to full network allow/deny. macOS Seatbelt profiles are generated dynamically as Scheme-like DSL strings.

Limitations:

macOS: Currently allows all reads to make executables work. Tightening in next release. Linux: Landlock doesn't cover everything (no UDP filtering until recent kernels, no syscall filtering - that's seccomp territory) No Windows support (yet?)

GitHub: https://github.com/lukehinds/nono Docs: https://docs.nono.dev Site: https://noto.sh

Apache 2.0. Would love feedback on the security model, especially from folks who've worked with Landlock or Seatbelt. Having said that, the code needs a good tidy and I am not exactly proud of it, so go easy on me!