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
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.
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.
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
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