Hey HN
Luke here.
I built nono and got it out quick then I expected, in response to the openclaw carnage, but its use is beyond openclaw.
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.
The solution pitch: 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 --read ./src --allow ./output -- cargo build nono run --profile claude-code -- claude 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?)
Origin:
Built this for OpenClaw (AI agent platform handling Telegram/WhatsApp messages). Needed real isolation, not "please don't read this file" isolation. Generalized it because every agent runner has this problem.
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!
The zeroize after exec feature sounds good, but what is the threat model in an agent context? If the agent can run printenv in the first millisecond and exfiltrate it (if net is allowed), zeroizing won't help
It seems egress filtering (allowlists) is more critical for agents than memory protection. If I allow an agent to run npm install, I'm opening a network Pandora's box, and Landlock (until ABI v4) offers pretty limited control there
[deleted]
This hits the real problem: once agents execute code, “please don’t read ~/.ssh” is not a security control. Kernel-enforced isolation + tight allowlists is. The secrets workflow (keychain/secret service → env → zeroize) is especially practical. Biggest thing I’d want as a user is very explicit docs on the remaining gaps (macOS read-permissive mode, procfs/env/subprocess behavior, and what Landlock can’t cover yet vs seccomp). If that’s clear, this could be a default wrapper for local agent runs.
I think with access to bash any AI agent can write a basic python/bash script and run it to evade you sandbox , Right ?
Good question - and the answer is no, they cannot escape. nono uses Landlock (Linux) and Seatbelt (macOS) - these are kernel-level security mechanisms. When a sandbox is created:
All child processes inherit the restrictions - if the agent spawns Python, Bash, or compiles and runs a binary, that process is equally sandboxed There is no API to remove or expand the sandbox - once restrict_self() (Landlock) or sandbox_init() (Seatbelt) is called, the restrictions are permanent for that process tree.
nice project, it seems the only non-broken websites are Github and nono.sh