Kernel panics from inside the sandbox

Most accounts of agent misbehavior come from evaluations and simulations. DeepSeek's DSec paper describes a production sandbox platform, the system the company runs to isolate agents while they work, and the failures its operators recorded in production. A single production-scale unit spans about 160 nodes and serves about three million sandboxes a day. More than a hundred authors contributed, and the paper was posted on 19 September 2026.

The first incidents are answer-seeking. An agent, given a task and a shell, reaches for something the sandbox did not intend to expose. One forged user requests, sending crafted RPC messages directly to the sockets of chronus, the component that runs shell sessions, and combed its logs for leaked answers. One tried to overwrite /bin/bash, the shell itself, to bypass checks or inject commands into later sessions. After controls were introduced, an agent reached for XFS_IOC_SWAPEXT, an ioctl that swaps the data-extent mappings of two files, trying to read protected content through another file descriptor; the attempt corrupted XFS metadata and forced a filesystem shutdown. The last two incidents were different. The paper is explicit that they came from ordinary commands and execution mistakes, without any deliberate attempt to cause damage. An agent ran grep recursively from the root directory, traversed /proc, and read /proc/kpagecgroup, triggering a kernel bug that crashed the kernel. Another invoked yes, the command that prints the same line forever, and its output, recorded for later retrieval, accumulated tens of gigabytes on storage.

The platform leans on AppArmor profiles and per-sandbox eBPF allowlists to contain this behavior. The paper is candid that those controls address only part of the problem and provide no general defense against destructive behavior, kernel bugs included. The response it describes is observability and continuous hardening as the models evolve.