Sandboxing AI Agents at the Kernel Level (www.greptile.com)

Abhinav from Greptile digs into how to safely run LLM-powered agents that can traverse a filesystem, arguing that application-level sanitizers aren’t enough and that the kernel should be the arbiter of what an agent can see. He traces the Linux open syscall to show three distinct kernel-level choke points where file access can be denied: do_open (permission checks, i.e., chmod → -EACCES), link_path_walk (pathname traversal which can be fooled by mounting something over a directory → mount masking / -ENOENT), and path_init (the process’s root, settable via chroot/pivot_root, which determines where path resolution starts). Each failure mode maps to a practical hiding technique: file permissions, mount overlays, and changing the process root. The key implication for the AI/ML community is clear: if you expose an agent to a cloud host, assume the process can exfiltrate anything it can "see" unless the kernel prevents it. Combining mount namespaces (so mounts affect only the agent), controlled mounts or bind mounts, and changing the process root gives you a sandbox that enforces visibility at the kernel level — essentially what containers (Docker/Podman/containerd) already implement via clone namespaces and pivot_root. In short, use kernel-level isolation (containers, mount namespaces, root pivoting) rather than trusting app-layer guards to protect secrets from autonomous agents.