How an AI Agent Cut 60% of Kata Containers' Code for the Sake of Security

The author of the blog srcreigh.ca described an experiment: in a single day, using the AI agent Astra, he deleted about 60% of the code in the Kata Containers project while retaining full support for running x86_64 Kubernetes workloads in a Firecracker virtual machine. The goal was to shrink the attack surface in the agent and runtime code as much as possible and to make what remained easier to audit. The text of the post itself was written by hand, but all changes to the repository were made through the Codex CLI.

After the edits, the fork was left with 13.5 thousand lines of host runtime code and 8.1 thousand for the agent. This wasn't pure deletion: along the way he had to fix problems that surfaced as the code was cut. Functionality was tested on a home cluster, where the author runs several untrusted workloads in Firecracker via Kata.

Why this is needed

The author reminds us that, in the general case, virtual machines are not a reliable security boundary: he cites experiments published on August 26, 2026 by Artem Dinaburg, in which the GPT-5.6 Cyber model managed three times to break out of qemu onto a Debian host. Firecracker is considered one of the few genuinely hardened Linux VMs, but it would be a mistake to assume that any workload inside it is automatically just as secure.

Any tool that runs Kubernetes pods in Firecracker is forced to open new communication channels with the guest system — for example, to copy files into a running pod. In Kata this is handled by an agent inside the VM that accepts RPC from the host. And that means the guest gains the ability to send the host, among other things, malformed responses, which plain Firecracker did not allow. According to the author, there are as yet no projects with the explicit goal of providing a minimal attack surface for the Kubernetes-and-Firecracker combination.

How the cleanup went

First, in Med/High modes, Astra deleted code unnecessary for the author's specific workloads: support for alternative VMs, the entire legacy Go runtime, kernel module loading by the agent. Some of what was deleted later had to be brought back — for example, volumeDevices support for mounting host block devices.

An attempt to sic the agent on fuzzing the runtime's behavior against malformed guest data ran into the model's safety restrictions, and it was abandoned. Instead, Astra compiled an inventory of the code that parses data from the agent and cleared out the excess. This revealed cases where data from RPC was stored but not used, as well as places where a malformed agent could crash the runtime into a panic. On the final pass, Ultra mode spent nearly an hour checking the code line by line and, among other things, found a deadlock during network initialization.

The author honestly warns: he is not a security specialist, the code has not been audited, there are no installation instructions, and the solution has not been tested in production. The original Kata project is actively developing, and he hopes to someday propose some of the changes upstream.

Source: Lobsters