Nono: Kernel-Level Sandboxing for AI Agents That Can’t Be Prompt-Injected Away
Hook
Every application-layer guardrail you’ve put on your AI agent can be disabled with the right prompt. Nono makes sandbox escape structurally impossible by moving enforcement to the kernel.
Context
AI agents are eating the world, but they’re eating it with root access. When you give an LLM the ability to execute code, write files, or call APIs, you’re trusting a stochastic parrot to not accidentally—or through prompt injection—nuke your production database. The standard approach is defensive prompting: ‘You are a helpful assistant who never accesses /etc/passwd.’ This is security theater. Researchers have demonstrated that sufficiently clever prompt injection can bypass virtually any application-layer restriction you can dream up.
The problem compounds when agents need credentials. If your coding agent needs a GitHub token to push code, that token typically lives in environment variables or config files accessible to the agent’s process. A compromised or manipulated agent can exfiltrate those credentials before you even realize what’s happening. Traditional sandboxing approaches—Docker containers, VMs, cloud sandbox services—provide isolation but at the cost of complexity, latency, and often missing agent-specific features like ‘undo everything the agent just did.’ Nono, created by the founder of Sigstore, brings supply-chain security thinking to AI agents: cryptographic audit trails, zero-trust architecture, and kernel-level enforcement that no amount of clever prompting can circumvent.
Technical Insight
Nono’s core innovation is leveraging platform-specific kernel security primitives—macOS Seatbelt and Linux Landlock—to create capability-based sandboxes that are irreversibly applied to a process. Unlike Docker or AppArmor which require configuration files and orchestration layers, nono provides a Rust API (with Python and TypeScript bindings) where you declare capabilities before spawning your agent process. Once applied, the kernel enforces these restrictions; there’s no userspace code the agent can execute to escalate privileges.
Here’s what a basic sandbox configuration looks like in Python:
from nono import Sandbox, Capability
# Define what the agent CAN do, not what it can't
sandbox = Sandbox()
.allow_read("/workspace")
.allow_write("/workspace/output")
.allow_network(["api.github.com:443", "pypi.org:443"])
.allow_exec(["/usr/bin/python3", "/usr/bin/git"])
.enable_rollback() # Atomic filesystem snapshots
# Credentials never enter the sandboxed process memory
sandbox.inject_credential(
name="GITHUB_TOKEN",
proxy_to="api.github.com",
token_from_keychain=True
)
result = sandbox.run(["python3", "agent.py"])
if result.violated_policy:
sandbox.rollback() # Undo all filesystem changesThe inject_credential feature is particularly clever. Instead of passing the GitHub token as an environment variable visible to the agent process, nono sets up a transparent proxy. When the agent makes requests to api.github.com, the proxy intercepts the connection, injects the Authorization header from your system keychain, and forwards the request. The token never exists in the agent’s memory space, so even if the agent is completely compromised, it cannot exfiltrate the credential. This is conceptually similar to how AWS IAM roles work for EC2 instances, but implemented locally with kernel-level network interception.
The rollback mechanism uses filesystem snapshots (APFS snapshots on macOS, Btrfs/ZFS on Linux) to create atomic checkpoints. Before your agent runs, nono snapshots the allowed write directories. If the agent violates a policy, triggers an error, or you simply change your mind, calling rollback() restores the filesystem state in a single atomic operation. This is dramatically faster than container-based approaches where you’d need to destroy and recreate volumes.
Under the hood on Linux, nono uses the Landlock LSM (Linux Security Module) introduced in kernel 5.13. Landlock allows unprivileged processes to create security sandboxes for themselves—critically, once applied, even root can’t remove the restrictions. Here’s a simplified view of how nono applies a Landlock ruleset:
use landlock::*;
let sandbox = Ruleset::new()
.handle_access(AccessFs::ReadFile)?
.handle_access(AccessFs::WriteFile)?
.create()?;
// Allow read access to /workspace
sandbox.add_rule(PathBeneath::new(
PathFd::new("/workspace")?,
AccessFs::ReadFile
))?;
// Allow write only to /workspace/output
sandbox.add_rule(PathBeneath::new(
PathFd::new("/workspace/output")?,
AccessFs::WriteFile
))?;
sandbox.restrict_self()?; // Irreversible kernel enforcement
// Agent code executes here with kernel-enforced restrictions
execute_agent();The restrict_self() call is the point of no return. After this, the kernel will deny any filesystem access not explicitly allowed, and no syscall can undo it. On macOS, nono generates a Seatbelt profile and applies it via sandbox_init(), achieving similar irreversibility.
Nono also maintains a cryptographic audit chain of every action the agent attempts—allowed or denied. This audit log is cryptographically signed using Sigstore’s Rekor transparency log approach, creating an immutable provenance record. If your agent goes rogue and starts scanning for private keys, you’ll have a tamper-proof record of exactly what it tried to access, when, and from which code path. This is invaluable for post-incident forensics and compliance requirements around AI system behavior.
Gotcha
The repository README contains a critical warning in bold: ‘Alpha software. Do not use in production.’ Despite the sophisticated architecture, nono hasn’t undergone the security audits you’d want before trusting it with genuinely sensitive workloads. Landlock itself is relatively young (merged in 2021) and has known edge cases around bind mounts, ptrace, and certain file descriptor passing operations that sophisticated exploits might leverage. The credential injection proxy, while clever, introduces a TOCTOU (time-of-check-time-of-use) window where a sufficiently fast agent might race the proxy setup.
Platform support is limited to macOS and Linux with kernel 5.13+, which excludes Windows entirely and rules out many production Linux environments running LTS kernels from 2020 or earlier. The rollback feature only works with APFS (macOS), Btrfs, or ZFS—if you’re on ext4 (still the most common Linux filesystem), you don’t get atomic rollback. The network allowlist is domain-based, not IP-based, which means a compromised DNS resolver could potentially bypass restrictions. And while nono claims ‘zero-latency overhead,’ Landlock and Seatbelt do add syscall filtering overhead that becomes measurable in tight loops with filesystem-heavy operations.
Verdict
Use if: You’re building AI coding agents, data analysis tools, or automation systems that need filesystem/network access during development or internal deployment. The combination of kernel-level enforcement, credential injection, and atomic rollback makes nono uniquely suited for ‘what if the agent goes wrong’ scenarios where you want defense-in-depth without VM overhead. Particularly valuable if you’re already in the Rust ecosystem or want to prototype agent security policies quickly. Skip if: You’re deploying to production (wait for 1.0 and proper audits), need Windows support, run Linux kernels older than 5.13, or operate in highly regulated environments requiring certified security controls. Also skip if you need multi-tenant isolation (use gVisor/Firecracker) or if your agents require exotic filesystem operations that Landlock’s capability model doesn’t support well. For production AI agent workloads today, cloud sandbox services like E2B or Modal provide better isolation guarantees despite the latency and cost tradeoffs.
