Два места для размещения контроля
В любой агентной системе есть два возможных места для контроля безопасности. Первое — внутри инструкций модели: системный промпт, который говорит «не удаляй производственные данные», описание инструмента, предупреждающее против эксфильтрации секретов, абзац политики, добавленный в контекстное окно. Второе — на пути runtime между агентом и тем, что он пытается сделать: вызов инструмента, запрос на исходящий трафик, использование учётных данных.
Это не эквивалентные варианты, и разница не в степени. Ограничение на уровне промпта — это вход в вероятностную систему. Оно конкурирует за внимание с сообщением пользователя, извлечёнными документами, выводом инструмента, пришедшим три хода назад, и всем, что злоумышленник разместил на веб-странице, которую агент только что загрузил. Оно подвержено всем режимам отказа модели: дрейфу инструкций на длинных контекстах, сикофантии по отношению к уверенному пользователю, восприимчивости к внедрённому тексту и обычной дисперсии сэмплирования. Когда оно работает, оно работает потому, что модель решила подчиниться. Когда оно не работает, ничто в архитектуре этого не замечает.
Контроль на уровне runtime перехватывает в точке, где действие уже конкретно. Модель выдала вызов инструмента с именем и аргументами. Этот вызов — структурированный объект, а не диспозиция. Его можно разобрать, сопоставить с политикой, задержать, переписать или отклонить, прежде чем что-либо достигнет файловой системы, сети или хранилища секретов. Контролю не нужно согласие модели.
Текущая дискуссия вокруг фреймворка безопасности runtime-агентов от Nvidia и более широкого спора о kill-switch — под вендорским языком — это спор о том, какой слой обладает властью. Один лагерь рассматривает модель как поверхность принуждения и пытается сделать инструкции сильнее. Другой рассматривает модель как недоверенный планировщик и помещает власть на путь, который она должна пройти. Второй лагерь прав с точки зрения архитектуры, и движение индустрии в его сторону — правильная ставка.
Kill switch — это симптом
Идея kill switch привлекательна, потому что сводит сложную проблему управления к одной кнопке. Она также предполагает две вещи, которых у парков агентов редко бывает: единый супервизор с властью над всем развёртыванием и надёжный канал от этого супервизора к каждой работающей нагрузке.
Ни то, ни другое не выдерживает контакта с реальной системой. Агенты порождаются оркестраторами, масштабируются по регионам, встраиваются в очереди и cron-задачи и получают учётные данные, которые переживают процесс, их запросивший. Супервизор часто отделён несколькими слоями абстракции от контейнера, который фактически держит открытый сокет. Сигнал, отправленный по этой цепочке, — это запрос, а не гарантия, и запросы теряются из-за упавших сайдкаров, разделённых сетей и нагрузок, находящихся посреди повторной попытки.
Что действительно останавливает агента — это лишение возможности, а не доставка намерения. Конкретно: отозвать токен, который использует агент, чтобы его следующий вызов провалил авторизацию независимо от того, что он думает, что делает. Закрыть путь исходящего трафика на сетевой границе, чтобы запрос, покидающий процесс, никуда не дошёл. Осушить очередь, из которой читает агент, чтобы новая работа не поступала. Ротировать секрет, который он собирался прочитать. Это действия принуждения, потому что они меняют то, что возможно, а не то, что задумано. Процедура остановки, построенная на отзыве возможностей, деградирует плавно: если один отзыв не удался, остальные всё равно срабатывают.
Стоит быть точным в отношении того, чем являются и чем не являются артефакты политики. Когда лаборатория публикует критерии остановки или пункт спецификации модели, описывающий, когда агент должен остановиться, это документ управления. Он формирует поведение, он сигнализирует о намерении, он создаёт подотчётность. Это не механизм принуждения, потому что он живёт на той же стороне границы, что и модель, которую он ограничивает. Чтение таких публикаций как гарантий безопасности путает заявление о ценностях с заявлением о контроле.
Правило проектирования: перехватывай, а не инструктируй
Следующее правило узкое и механическое. Каждый значимый инструмент получает точку принятия решений по политике на пути вызова с режимом запрета по умолчанию. Значимый означает всё, что пишет, удаляет, отправляет, тратит, аутентифицируется или выходит за пределы песочницы. Запрет по умолчанию означает, что инструмент непригоден, пока политика явно не разрешит конкретную форму вызова, а не пригоден, пока кто-то не вспомнит его заблокировать.
Механизм непритязателен. Runtime агента оборачивает каждый инструмент в перехватчик. Перед диспетчеризацией перехватчик собирает запрос на решение: субъект (какой агент, какая задача, какая делегированная идентичность), имя инструмента, дайджест аргументов и контекстные сигналы, такие как классификация данных сессии. Он запрашивает движок политики, получает вердикт «разрешить», «запретить» или «преобразовать» и только затем диспетчеризует, переписывает или отклоняет. Преобразование важно: редактирование поля или сужение пути часто лучше бинарной блокировки.
Каждое решение логируется с субъектом, инструментом, дайджестом аргументов и вердиктом. Дайджест, а не сырые аргументы, делает лог безопасным для хранения, при этом всё ещё позволяя воспроизведение и разбор споров. Этот лог — субстрат для аудита, для разбора инцидентов и для настройки самой политики.
Инструкции при таком дизайне не исчезают. Они остаются правильным инструментом для формирования поведения: тон, стратегия декомпозиции, когда задать уточняющий вопрос, как суммировать. Меняется заявление, которое делается. Ни одно свойство безопасности не должно опираться только на инструкцию, потому что инструкция — это предложение системе, чьё соответствие вероятностно по построению.
Чего стоит принуждение
Перехват на уровне runtime не бесплатен, и притворяться иначе — значит производить плохие архитектуры. Три издержки реальны.
Первая — задержка и новая единая точка отказа. Каждый перехваченный вызов теперь ждёт решения по политике, а путь политики находится на критическом пути продукта. Если он недоступен, правильное поведение по умолчанию — запрет, что означает, что сервис политики нуждается в собственном бюджете доступности как минимум не слабее, чем у инструментов, которые он охраняет. Это инженерное обязательство, а не деталь конфигурации: реплицированные точки принятия решений, локальное кэширование подписанных пакетов политик с коротким сроком действия и документированное поведение для деградированного случая.
Вторая — авторство политик это проблема схемы. Расплывчатая схема порождает один из двух режимов отказа: правила настолько широкие, что штампуют всё подряд, или правила настолько узкие, что блокируют легитимную работу, и команда обходит их. Работа в том, чтобы правильно составить запрос на решение — какие атрибуты доступны во время вызова, какие стабильны, на какие может повлиять злоумышленник. Движок политики, получающий неформализованный контекст, будет принимать уверенные решения о неправильных вещах.
Третья — измерение. Количество правил не является метрикой безопасности; большой набор правил может быть полностью инертным. Результат, который стоит отслеживать, — это отношение перехваченных к разрешённым действиям на значимых инструментах, в разбивке по инструменту и субъекту. Отношение, близкое к нулю на инструменте, который пишет в производство, — сигнал, что политика декоративна. Отношение, резко меняющееся после изменения, — сигнал, достойный расследования. Ни одно из чисел не является гарантией, но оба описывают, действительно ли контроль находится на пути.
Честное резюме: управление на уровне runtime переносит доверие с соответствия модели на инфраструктуру оператора. Это сложнее построить и гораздо легче аудировать. Учитывая, что агентным системам выдаются учётные данные и сетевой доступ, аудит — это та часть, которая имеет значение.