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?)
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!
0 comments
—
Show HN: Nono – Kernel-enforced sandboxing for AI agents · HackerTrans
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!