Контейнеры ограничивают радиус поражения, а не поведение
Когда команды впервые помещают агента в песочницу, разговор обычно начинается с технологии изоляции. Микровиртуальные машины Firecracker, gVisor, профили seccomp, лимиты cgroup, корневые файловые системы только для чтения. Всё это реально и полезно, но отвечает на более узкий вопрос, чем большинство предполагает. Они ограничивают, куда может попасть ущерб. Они не ограничивают, что агенту разрешено попытаться сделать.
Песочница, разделяющая сетевой namespace хоста, уже уступила самую интересную часть проблемы. Агент по-прежнему может достичь внутреннего сервиса метаданных, реестра пакетов, провайдера модели, корпоративной вики и любого сервиса, доверяющего IP хоста. Изоляция файловой системы не ограничивает агента, чья реальная поверхность возможностей — это исходящий HTTP плюс набор учётных данных API. Можно смонтировать корневую файловую систему только для чтения и всё равно наблюдать, как агент выкачивает базу данных через разрешённый путь исходящего трафика, потому что возможность, которая имеет значение, никогда не была файловым дескриптором. Это был токен.
Именно поэтому подход «сначала контейнер» обычно порождает песочницы, которые выглядят строгими, а ведут себя разрешительно. Единица анализа выбрана неверно. Полезная единица — это набор возможностей на шаг, и этот набор меняется по мере выполнения.
Бюджет возможностей как примитив проектирования
Примитив проектирования, вокруг которого стоит строить, — это бюджет возможностей, привязанный к каждому шагу выполнения. Шаг — это ограниченная единица работы: один вызов инструмента, один ход модели, одна навигация в браузере, одна команда исполнительного механизма. Каждый шаг объявляет необходимые ему возможности. Среда выполнения предоставляет ровно эти возможности на время шага и не дольше.
Конкретный механизм выглядит так. Оркестратор содержит движок политик и брокер краткосрочных учётных данных. Перед выполнением шага агент отправляет запрос на возможности: структурированный документ, называющий ресурс, операцию и предполагаемую область действия.
{
"step": "fetch_invoice_pdf",
"capabilities": [
{"type": "http", "host": "billing.internal", "methods": ["GET"], "paths": ["/invoices/*/pdf"]},
{"type": "fs", "mount": "/tmp/run-7f3a", "mode": "write"}
],
"ttl_seconds": 30
}
Движок политик оценивает запрос относительно накопленного бюджета выполнения и объявленной области задачи. Если запрос проходит, брокер выпускает учётные данные с областью действия, ограниченной этим хостом, методом и путём, со сроком жизни, измеряемым в секундах. Шаг выполняется. Учётные данные истекают. Следующий шаг начинается с нуля и должен запросить снова.
Эскалация — это интересный случай. Когда шагу нужно что-то за пределами текущего бюджета, он должен подать явный запрос на эскалацию. Этот запрос сам по себе является регистрируемым событием с прикреплённым решением политики: кто или что его одобрил, по какому правилу, с каким сроком действия. Это превращает разрастание привилегий из тихого дрейфа в аудируемую последовательность. Это также делает историю возможностей выполнения первоклассным артефактом, что как раз и нужно, когда что-то идёт не так на сороковом шаге.
Отзыв должен быть возможен в середине выполнения. Это ограничение исключает долгоживущие токены, выпущенные в начале задачи. Если единственные учётные данные, которые есть у агента, — это bearer-токен с областью задачи и часом жизни, то среда выполнения не может отозвать полномочия, когда поведение агента отклоняется, когда предпосылка задачи оказывается ложной или когда человек замечает что-то неладное. Краткосрочные учётные данные с областью шага делают отзыв вопросом непродления. Это гораздо меньшая и более надёжная операция, чем попытка аннулировать токен, который уже находится в полёте через десяток сервисов.
Компромисс реален, и о нём стоит сказать прямо. Учётные данные с областью шага умножают число обменов токенов, добавляют брокера на критический путь и вносят задержки и режимы отказа, которых нет у одного долгоживущего токена. Каждый шаг теперь зависит от доступности брокера и корректности движка политик. Команды, принимающие этот шаблон, платят за него операционной сложностью, и им следует сознательно решить, оправдывает ли профиль риска задачи эту цену. Для агента суммаризации только для чтения по публичным данным часто нет. Для агента с доступом на запись к производственным системам обычно да.
Браузерные и десктопные агенты
Браузерные и десктопные агенты по своей конструкции обладают широкими неявными полномочиями. Драйвер браузера может кликнуть по чему угодно, ввести текст куда угодно и перейти куда угодно, куда позволяют cookie сессии. Десктопный агент часто может больше. Бюджет возможностей не может быть обеспечен контейнером, потому что контейнер размещает полную пользовательскую сессию с полным набором неявных учётных данных. Он должен обеспечиваться на уровне драйвера.
На практике это означает, что драйвер перехватывает навигацию, отправку форм, скачивание файлов, доступ к буферу обмена и любой вызов, пересекающий границу доверия, и проверяет каждый из них на соответствие объявленным возможностям текущего шага. Шаг, объявляющий «прочитать страницу с ценами», не должен иметь возможности отправить форму, даже если DOM её предлагает. Это политика уровня драйвера, и это единственный уровень, где проверка имеет смысл, потому что именно этот уровень фактически выполняет действие.
Физические и робототехнические агенты
Физические агенты добавляют второе измерение бюджета, которого нет у программных песочниц: конверт движения и ограничения по усилию. Набор возможностей роботизированной руки включает не только то, какой API она может вызвать, но и куда она может двигаться, как быстро и с каким усилием. Эти ограничения обеспечиваются контроллером, и они должны быть ограничены по шагу таким же образом. Шаг, объявляющий «взять объект из бункера A», должен нести конверт движения, исключающий бункер B, и потолок усилия, соответствующий классу объекта. Эскалация к более широкому конверту — это регистрируемое решение политики, точно как с сетевыми возможностями.
Причина, по которой это важно, в том, что режимы отказа необратимы. Отозванный HTTP-токен останавливает утечку данных. Отозванный конверт движения останавливает руку на середине траектории, что является другой инженерной задачей, включающей профили замедления и безопасные состояния. Модель возможностей та же; семантика отзыва — нет.
Стенды оценки
Стенды оценки должны применять то же обеспечение возможностей, что и производство, иначе результат теста не является доказательством. Это наиболее часто пропускаемый шаг и тот, который больше всего подрывает ценность оценки. Если стенд предоставляет агенту надмножество производственных возможностей, то измеренная доля успеха агента отражает систему, которой не существует. Если стенд обеспечивает подмножество, агент будет выглядеть проваливающим задачи, которые он прошёл бы в производстве.
Правильный шаблон — запускать стенд против того же движка политик и того же брокера, что использует производство, с теми же объявлениями возможностей, и рассматривать отказы политики как первоклассные результаты оценки, а не как инфраструктурный шум. Агент, завершающий задачу с тремя эскалациями, ведёт себя иначе, чем тот, кто завершает её в пределах бюджета, и стенд должен уметь сказать вам, что именно произошло.
Что это меняет
Вопрос контейнера не исчезает. Технология изоляции по-прежнему определяет, что происходит, когда проверка возможностей не проходит и агент всё равно делает что-то неожиданное. Смысл в эшелонированной защите. Но контейнер — это вторая линия, а не первая. Первая линия — это бюджет возможностей, который объявляется на шаг, предоставляется на время этого шага, эскалируется только через регистрируемые решения политики и может быть отозван, пока выполнение ещё продолжается.
Команды, начинающие с контейнера, обычно приходят к песочнице, которая технически впечатляет и операционно разрешительна, потому что поверхность возможностей никогда не была перечислена. Команды, начинающие с бюджета возможностей, приходят к ясной картине того, что агент может делать в каждый момент, и к контейнеру, размер которого соответствует остаточному риску, а не всей проблеме. Второй порядок требует больше работы на старте и значительно меньше работы во время инцидента.