Sandboxing AI Agents with nono: From Discovery to Production Profiles AI agents that write code, run commands, and interact with your filesystem need guardrails. Without them, a single hallucinated rm -rf or an unintended credential read can cause real damage. nono is a capability-based sandboxing system that uses OS-enforced isolation (Landlock on Linux, Seatbelt on macOS) to make unauthorized operations structurally impossible. This post walks through the three tools that take you from "I have no idea what my agent touches" to "I have a locked-down profile ready for production": nono learn , nono policy , and nono profile . Step 1: Discover What Your Agent Actually Needs Before you can write a sandbox profile, you need to know what filesystem paths and network endpoints your application accesses. Guessing leads to either over-permissive sandboxes (defeating the purpose) or broken applications (missing paths). nono learn solves this by tracing your command and reporting exactly what it touches . Basic Discovery Run your agent under nono learn : shell nono learn -- python my_agent.py On Linux , this uses strace to intercept syscalls. On macOS , it uses fs_usage (which requires sudo ). The output is a categorized summary of every path your application accessed: text ============================================================ nono learn - Discovered Paths ============================================================ READ (5 paths) ---------------------------------------- /home/user/.config/my-agent /home/user/.cache/huggingface /etc/resolv.conf /usr/lib/python3.12 /usr/share/ca-certificates WRITE (1 paths) ---------------------------------------- /tmp/my-agent-workspace READ+WRITE (2 paths) ---------------------------------------- /home/user/.local/share/my-agent /home/user/projects/current 42 paths already covered by system defaults Paths that nono's built-in system groups already cover (like /usr/lib , /etc/ssl ) are filtered out and counted at the bottom, so you see only the application-specific paths you need to add to your profile. Linux Network Discovery On Linux, nono learn also traces network activity, including outbound connections and listening ports. It correlates DNS queries with connections to show you hostnames rather than just IP addresses: text OUTBOUND NETWORK (2 endpoints) ---------------------------------------- api.openai.com (104.18.7.192):443 (12 connections) huggingface.co (18.154.227.89):443 (3 connections) LISTENING PORTS (1 endpoints) ---------------------------------------- 127.0.0.1:8080 (1 connections) Use --no-rdns to skip reverse DNS lookups if they slow things down. Compare Against an Existing Profile If you already have a profile and want to see what's missing, pass --profile : shell nono learn --profile my-agent -- python my_agent.py This shows only the paths not already covered by that profile, making it easy to iteratively tighten permissions. Export as JSON For direct use in profile construction, the --json flag outputs a structured fragment: shell nono learn --json -- python my_agent.py json { "filesystem" : { "allow" : [ "/home/user/.local/share/my-agent" , "/home/user/projects/current" ] , "read" : [ "/home/user/.config/my-agent" , "/home/user/.cache/huggingface" ] , "write" : [ "/tmp/my-agent-workspace" ] } , "network" : { "outbound" : [ { "addr" : "104.18.7.192" , "port" : 443 , "hostname" : "api.openai.com" , "count" : 12 } ] , "listening" : [ ] } } Other Useful Flags Flag Purpose --all Show all accessed paths, including those covered by system defaults --timeout <SECS> Limit trace duration for long-running or interactive programs -v / -vv / -vvv Increasing verbosity levels for debugging Step 2: Understand the Security Policy Before building a profile, it helps to understand what nono protects by default. The nono policy command lets you inspect the built-in security groups and profiles . List All Policy Groups shell nono policy groups This lists every security group available, each one a named collection of allow/deny rules. Groups fall into several categories: Deny groups block access to sensitive locations: deny_credentials -- blocks ~/.ssh , ~/.aws , ~/.gnupg , ~/.kube , ~/.docker , and other credential stores deny_keychains_macos / deny_keychains_linux -- blocks system keychains and password managers deny_browser_data_macos / deny_browser_data_linux -- blocks browser cookies and session data deny_macos_private -- blocks Messages, Mail, and other private macOS data deny_shell_history -- blocks .bash_history , .zsh_history , etc. deny_shell_configs -- blocks .zshrc , .bashrc , and similar files that may embed secrets System groups provide read or write access to OS paths: system_read_macos / system_read_linux -- standard system binaries, libraries, and config system_write_macos / system_write_linux -- temporary directories and device nodes Runtime groups provide access for specific language toolchains: node_runtime -- ~/.nvm , ~/.fnm , ~/.npm , and related paths p...