ShrekOS: граница доверия для агента ниже контейнера

Редакция 3 сентября 2026 г.

Три режима для агента на вашей машине: жёсткая песочница, полный доступ к хосту или прослойка ОС, которая решает, что выдать по запросу. В разборе ShrekOS автор описывает третий путь — не новое ядро и не очередной Docker, а операционную модель, где доверие живёт ниже агента.

Два плохих режима для AI-агента

Полезный агент упирается в бинарный выбор. Среду можно зажать настолько, что обычные задачи становятся неудобными — и вы весь день вручную расширяете разрешения. Или отдать агенту всё больше реальной машины — и один сбой уже бьёт по системе, а не по изолированному процессу.

Автор формулирует это как «restrict until useless, or trust until dangerous». Контейнеры, пространства имён, cgroups, фильтрация исходящего трафика, пакетные менеджеры, принудительный контроль доступа и неизменяемые файловые системы существуют — каждый закрывает свою часть. Но ни один из них сам по себе не дал ему модель, в которой рабочая нагрузка во время работы запрашивает нужные полномочия, а машина решает, выдавать ли их и с какими ограничениями.

Риски, из-за которых «доверять до опасного» пугает, перечислены прямо: галлюцинация модели, отравленная зависимость, внедрение в промпт, обычный баг. Для соло-разработчика с агентом в терминале или IDE это не абстракция — shell-команды сгенерировать легко, полномочия остаются трудной частью.

ShrekOS — композиция механизмов, не ОС с нуля

ShrekOS не заявлен как операционная система, собранная с нуля, и не как новое ядро. Это композиция уже существующих механизмов в согласованную операционную модель: нагрузка решает, какие полномочия нужны прямо сейчас, и запрашивает их у машины.

Контраст с «наивным» хостом нагляден на примере ffmpeg. Агент видит, что инструмента нет, и запускает установку пакета на хосте:

apt install ffmpeg

Проблема не в самом ffmpeg. Постоянная мутация машины — база пакетов, неаудированные зависимости, скрипты установки, символические ссылки, конфиги, root в системных каталогах — это полномочия непредсказуемой программы над реальной системой. Именно эту границу автор хочет перенести из суждения агента в слой ОС.

Агент — клиент, операционная система — арбитр

В модели ShrekOS агент — клиент. Облачная модель, локальная или та, что вы смените через месяц, не меняет модель безопасности: агент может просить, ОС решает, выдавать ли полномочие и под какими ограничениями. Граница — жёсткий лимит, не совет.

Типичные задачи агента по автору: поставить ffmpeg, скомпилировать что-то, «потрогать» проект, запустить инструмент, обратиться к сетевому ресурсу. Сгенерировать правильные shell-команды — лёгкая часть; кто имеет право их выполнить на вашей машине — сложная.

Агенту не обязательно доверять всю машину, чтобы быть полезным на машине. Решение о доверии должно жить ниже агента — в операционной системе, а не в модели и фреймворке.

Для настройки rules и среды выполнения в агентном сценарии это прямой параллель: правила в редакторе или CLI ограничивают намерение, но без слоя ОС остаётся вопрос, что произойдёт, когда агент дойдёт до apt install или сетевого вызова.

Базовый слой: immutable Debian и AppArmor

Техническая база — неизменяемый Linux на Debian: запечатанный образ, атомарные обновления с откатом. Автор сначала смотрел Fedora из‑за запечатанной проверенной загрузки, но отказался в тот же день: база занимает примерно 15% проекта, нужная модель атомарных обновлений образа не привязана к Fedora, а на долгой сборке ему комфортнее в Debian.

AppArmor даёт модель на основе путей: политика лежит в обычных читаемых файлах. Fedora остаётся эталонным образом в VM и «дешёвым обходным путём» через инструменты сборки — не как основа продукта.

Явно названы опоры решения о доверии: неизменяемая база, атомарные обновления с откатом, AppArmor. Заявлена готовность откатить «жёсткую» идею безопасности, если она не несёт нагрузку — привязанность к принципу стабильного аудируемого базового слоя, а не к конкретному дистрибутиву.

Что известно и чего ждать от серии

Материал написан в настоящем времени строительства — релиз и релиз-ноуты не заявлены. Репозиторий, лицензия и статус открытого исходного кода в тексте не фигурируют; утверждать их сейчас нельзя.

Автор обещает продолжение в следующем посте серии — «something much smaller and more concrete»: место, где агент временно получает мощь без власти над машиной. Пост заканчивается вопросом, который задаёт рамку всей линии:

What should an agent be allowed to change?

Для разработчика, который уже гоняет агентов на хосте, это практический чеклист до выхода кода: что вы разрешаете менять сегодня через sudo, docker run и правила в IDE — и где у вас нет слоя, который отвечает «да/нет» вместо модели.

Источники

@the_leon_odor — Why I'm Building ShrekOS When Containers Already Exist (Dev.to, доступ 2026-09-03)