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.","title":null,"type":"comment","url":null}],"created_at":"2026-02-02T00:16:35.000Z","created_at_i":1769991395,"id":46850844,"options":[],"parent_id":46849615,"points":null,"story_id":46849615,"text":"I think with access to bash any AI agent can write a basic python/bash script and run it to evade you sandbox , Right ?","title":null,"type":"comment","url":null},{"author":"veunes","children":[],"created_at":"2026-02-02T09:27:50.000Z","created_at_i":1770024470,"id":46854039,"options":[],"parent_id":46849615,"points":null,"story_id":46849615,"text":"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","title":null,"type":"comment","url":null}],"created_at":"2026-02-01T21:35:04.000Z","created_at_i":1769981704,"id":46849615,"options":[],"parent_id":null,"points":4,"story_id":46849615,"text":"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+)\nmacOS: Seatbelt (sandbox_init)\nAfter sandbox + exec(), there's no syscall to expand permissions. The kernel says no.
What it does:
nono run --read ./src --allow ./output -- cargo build\nnono run --profile claude-code -- claude\nnono run --allow . --net-block -- npm install\nnono run --secrets api_key -- ./my-agent
Filesystem: read/write/allow per directory or file\nNetwork: block entirely (per-host filtering planned)\nSecrets: 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.\nLinux: Landlock doesn't cover everything (no UDP filtering until recent kernels, no syscall filtering - that's seccomp territory)\nNo 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\nDocs: https://docs.nono.dev\nSite: 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!","title":"Show HN: Nono \u2013 Kernel-enforced sandboxing for AI agents","type":"story","url":"https://nono.sh"}