An experienced security researcher has published a detailed case study asking whether access-control mechanisms inside Linux sandboxes used by AI agents actually deliver the expected restrictions. The work focuses on scenarios where an agent runs inside an isolated environment—built on container runtimes or virtual machines—yet individual tools launched by the agent must operate with narrower rights than the full session.
The author explains that simply instructing an LLM “do not modify files” does not reduce process privileges. Instead, a trusted wrapper must apply concrete Linux controls such as Landlock, classic BPF socket filters, or CGROUP_DEVICE programs before handing control to the tool. Because these controls may behave differently under gVisor’s Sentry kernel, each mechanism must be validated from inside the sandbox with the exact privileges the wrapper will possess.
Experiments were performed on Ubuntu 22.04 (Linux 6.8.0-138-generic) and two gVisor releases using both the runsc do command and full OCI bundles. With elevated capabilities, Landlock ABI version queries returned ENOSYS in both gVisor releases, while the host kernel reported ABI 4. Kernel selftests confirmed the absence of Landlock handlers. When a CGROUP_DEVICE program was loaded and attached to a cgroup v2 hierarchy, gVisor accepted the operations and reported the program as attached, yet /dev/null and /dev/zero remained accessible—contrary to the host, where EPERM was correctly returned.
A classic BPF filter attached via setsockopt(SO_ATTACH_FILTER) also succeeded without privileges. On the host the filter dropped UDP datagrams as intended; under gVisor the same packets continued to arrive. The discrepancy persisted across network modes (--network=none and --network=host) and user IDs.
The researcher concludes that three distinct failure modes must be distinguished: absence of the mechanism, insufficient privileges to configure it, and successful configuration that nevertheless produces no effect. A practical acceptance procedure is proposed: verify that the target action succeeds without the policy, confirm the policy is accepted, then confirm the action is blocked afterward. The same sequence must be executed with the exact rights the AI tool will receive, and the entire test repeated after any change to kernel, runtime, image, or mount configuration.
If a mandatory restriction cannot be shown to work, the tool must not be launched. The article provides the full test harness and instructions in a public repository so practitioners can reproduce the checks for their own AI-agent sandboxes.
