Как ИИ-агент вырезал 60% кода Kata Containers ради безопасности

Автор блога srcreigh.ca описал эксперимент: за один день он с помощью ИИ-агента Astra удалил около 60% кода проекта Kata Containers, сохранив при этом полную поддержку запуска x86_64-нагрузок Kubernetes в виртуальной машине Firecracker. Цель — максимально сократить поверхность атаки в коде агента и рантайма и сделать оставшееся легче поддающимся аудиту. Сам текст поста написан вручную, но все изменения в репозитории вносились через Codex CLI.

После правок в форке осталось 13,5 тыс. строк кода хостового рантайма и 8,1 тыс. — агента. Это не чистое удаление: попутно пришлось исправлять проблемы, всплывавшие по мере вырезания кода. Работоспособность проверялась на домашнем кластере, где автор гоняет несколько недоверенных нагрузок в Firecracker через Kata.

Зачем это нужно

Автор напоминает, что виртуальные машины в общем случае не являются надёжной границей безопасности: он ссылается на опубликованные 26 августа 2026 года эксперименты Артёма Динабурга, в которых модель GPT-5.6 Cyber трижды сумела выбраться из qemu на хост с Debian. Firecracker считается одной из немногих действительно защищённых Linux-ВМ, но было бы ошибкой полагать, что любая нагрузка внутри неё автоматически так же безопасна.

Любой инструмент, запускающий поды Kubernetes в Firecracker, вынужден открывать новые каналы связи с гостевой системой — например, чтобы копировать файлы в работающий под. В Kata за это отвечает агент внутри ВМ, принимающий RPC от хоста. А значит, гость получает возможность отправлять хосту в том числе некорректные ответы, чего у «голого» Firecracker не было. Проектов с явной целью дать минимальную поверхность атаки для связки Kubernetes и Firecracker, по словам автора, пока нет.

Как проходила чистка

Сначала Astra в режимах Med/High удаляла код, ненужный для конкретных нагрузок автора: поддержку альтернативных ВМ, весь легаси-рантайм на Go, загрузку модулей ядра агентом. Часть удалённого позже пришлось вернуть — например, поддержку volumeDevices для монтирования блочных устройств хоста.

Попытка натравить агента на фаззинг поведения рантайма по некорректным данным гостя упёрлась в защитные ограничения модели, и от неё отказались. Вместо этого Astra составляла инвентаризацию кода, который парсит данные от агента, и вычищала лишнее. Так обнаружились случаи, когда данные из RPC сохранялись, но не использовались, а также места, где некорректный агент мог уронить рантайм в панику. На финальном проходе режим Ultra почти час построчно проверял код и, среди прочего, нашёл дедлок при инициализации сети.

Автор честно предупреждает: он не специалист по безопасности, код не проходил аудита, инструкций по установке нет, в продакшене решение не проверялось. Оригинальный проект Kata активно развивается, и часть изменений он надеется когда-нибудь предложить в апстрим.

Источник: Lobsters