At a high level, nono works by creating a temporary OS-level sandbox around a process and enforcing allow/deny rules for filesystem, network, and execution. Everything is default-deny, and only what you explicitly allow is permitted.
The important part: the blocking happens below your program, not inside Python or your agent code.
When you run:
nono run --allow-cwd -- python3 my_agent.py
nono launches the command in a restricted environment where: File reads/writes are checked Executables are checked Network access can be checked
If the path isn’t in the allowlist, the OS returns:
Operation not permitted
Your program doesn’t know anything about nono — it just sees the OS refusing the operation.
Under the hood, nono relies on operating system security mechanisms rather than implementing its own file monitoring. Depending on the platform, this usually involves things like:
Uses Apple Sandbox / Seatbelt policies. These policies control: file read file write process execution network connections
Example rule conceptually:
deny file-read*
deny file-write*
allow file-read /Users/gideonaina/dev/nono-hack
allow file-read /Users/gideonaina/.pyenv/versions/3.10.14
When Python tries to open a file:
open("/Users/gideonaina/.ssh/id_rsa")
the kernel checks the sandbox policy and blocks it.
Tools like nono usually rely on combinations of:
| System | Restrictions |
|---|---|
| seccomp | filesystem paths |
| landlock | system calls |
| namespaces | network |
| cgroups | process capabilities |
The flow looks like this:
you run command
│
▼
nono creates sandbox policy
│
▼
nono launches process inside sandbox
│
▼
kernel enforces rules