Почему статическая политика плохо подходит агентам
Статическая политика исходящих вызовов предполагает, что множество назначений известно до запуска агента. Для человеческих рабочих процессов это допущение в основном выполняется: сервисная учётная запись обращается к фиксированному набору хостов, разработчик — к известному реестру пакетов, cron-задача — к одной базе данных. Список конечен, поддаётся проверке и меняется медленно.
Агенты ломают это допущение, потому что вызовы инструментов составляются во время выполнения. Назначение часто выводится, а не объявляется. Шаг retrieval возвращает URL, шаг суммаризации извлекает из этого URL имя хоста, а шаг fetch вызывает его. Ни один инженер не вписал это имя хоста в файл политики, потому что ни один инженер не знал его в момент написания. Вызов легитимен по построению и невидим для предварительно одобренного списка.
Обычная реакция — расширять список, пока он не перестанет блокировать. Это приводит к противоположному сбою: список разрешений, достаточно широкий, чтобы пропустить любое выведенное назначение, по сути является правилом «разрешить всё» с лишними шагами. Политика всё ещё выглядит как контроль, но больше не различает. Между этими двумя режимами сбоя нет статической настройки, которая работала бы, потому что политику просят ответить на вопрос, которого она не видит.
Более глубокая проблема в том, что назначение — неверная единица суждения. Одна и та же конечная точка может быть безобидной или враждебной в зависимости от полезной нагрузки и шага, который её породил. Вызов внутреннего сервиса метаданных — рутина, когда он получает конфигурацию, и серьёзная проблема, когда аргумент — это путь к учётным данным. Запрос к API партнёра нормален, когда тело — это запрос статуса, и ненормален, когда тело содержит конкатенацию всего, что агент прочитал за сессию. Фильтрация только по хосту выбрасывает информацию, которая различает эти случаи.
Что на самом деле проверяет интент во время выполнения
Проверка интента во время выполнения переносит решение с куда идёт вызов на чего вызов пытается достичь. Для этого нужно смотреть не только на назначение.
Аргументы, а не только назначения. Параметры, форма полезной нагрузки и происхождение значений. Происхождение — самая важная часть и та, которой у статических инструментов обычно нет. Если аргумент восходит к сообщению пользователя, это одно значение. Если он восходит к выводу инструмента, прочитавшего недоверенный контент, — другое. Отслеживание этой линии через траекторию позволяет проверке отличить параметр, заданный пользователем, от параметра, заданного внедрённым документом.
Позиция в последовательности. Вызов подозрителен относительно траектории, которая его породила. Чтение хранилища секретов сразу после неудачной попытки аутентификации — это другое событие, чем чтение его первым шагом запуска провижининга. Один и тот же вызов в другой позиции несёт другой смысл. Поэтому проверкам интента нужна недавняя траектория как вход, а не только отдельный вызов инструмента.
Частота и повторение. Один и тот же безобидный вызов сорок раз подряд — это другое событие, чем тот же вызов один раз. Повторение часто и есть сигнал, отличающий перебор от однократного обращения, и его дёшево измерять, потому что счётчик уже существует в слое оркестрации.
Конкретный механизм, связывающий это вместе: поддерживайте граф происхождения на каждый запуск, где каждое значение несёт метку taint, фиксирующую, какие источники в него внесли вклад. Когда вызов инструмента вот-вот сработает, guard собирает вектор признаков из аргументов вызова, меток taint на этих аргументах, позиции вызова в траектории и недавней частоты вызовов к этому назначению. Небольшой классификатор оценивает этот вектор. Политика действует на оценку, а не на имя хоста. Распространение taint — несущая часть; без него классификатор угадывает по поверхностному синтаксису.
Бюджет задержки
Проверки интента находятся между моделью и инструментом, поэтому каждая миллисекунда оплачивается на каждом шаге. Агент, делающий десятки вызовов инструментов на задачу, платит за guard десятки раз, и эта стоимость лежит на критическом пути. Guard, добавляющий заметную задержку на вызов, меняет продукт, а не только posture безопасности.
Практическая структура — многоуровневая. Сначала работают дешёвые эвристики: класс назначения, форма аргументов, наличие метки taint, пороги частоты вызовов. Это табличные поиски и сравнения, и они разрешают подавляющее большинство вызовов без модели в цикле. Дорогая классификация запускается только на неоднозначности, где дешёвый уровень не может решить. Правило эскалации должно быть опубликовано, а не подразумеваться, потому что оно определяет, что система поймает, а что нет. Если правило — «эскалировать, когда любой аргумент несёт недоверенную метку taint и назначение вне внутреннего класса», это утверждение, о котором оператор может рассуждать, а рецензент — оспорить.
Честный компромисс в том, что уровни покупают задержку за счёт покрытия. Вызов, который пропускает дешёвый уровень, никогда не доходит до классификатора, поэтому всё, к чему эвристики слепы, пропускается по замыслу. Ужесточение правила эскалации, чтобы ловить больше, означает чаще платить стоимость классификатора. Нет настройки, которая была бы одновременно максимально быстрой и максимально чувствительной; выбор нужно делать явно и пер
Цена ошибки также асимметрична так, что мышление на основе алертов это скрывает. Измеряйте ложные срабатывания в шагах агента, а не в алертах. Заблокированный шаг может аннулировать весь запуск: агент теряет результат инструмента, траектория сходит с рельсов, и задача либо проваливается, либо завершается с ухудшенным результатом, который пользователь не может отличить от правильного. Guard, срабатывающий слишком часто, не создаёт очередь алертов для разбора; он создаёт тихие сбои, выглядящие как ошибки модели. Поэтому бюджет ложных срабатываний для guard агента жёстче, чем для обычного сетевого контроля, и поэтому решения guard должны быть видны в трассировке запуска.
Эксплуатация модели
Классификатор — не одноразовый артефакт. Версионируйте модель интента вместе с агентом. Изменение политики — это развёртывание: оно поставляется с версией агента, записывается в трассировку запуска и может быть откатано так же. Отношение к политике как к конфигурации, дрейфующей независимо от агента, — это то, как guard'ы начинают применять правила, о написании которых никто не помнит.
Держите теневой режим, который логирует предполагаемые блокировки без применения, и просматривайте дельту еженедельно. Теневой режим — единственный способ узнать частоту ложных срабатываний guard'а до того, как он начнёт стоить запусков. Еженедельный обзор — это место, где настраивается правило эскалации и где дрейф в паттернах использования инструментов агентом проявляется до того, как станет инцидентом.
Подавайте подтверждённые инциденты обратно как размеченные траектории. Обучающий набор классификатора — это журнал инцидентов, а значит, процесс разбора инцидентов и процесс обучения модели — один и тот же процесс. Каждый подтверждённый инцидент становится положительным примером с приложенной траекторией; каждая блокировка в теневом режиме, которую обзор отменяет, становится отрицательным. Это замыкает цикл и поддерживает модель актуальной без отдельного усилия по сбору данных, которое никто не поддерживает.
Компромисс здесь — операционная нагрузка. Guard, который учится на инцидентах, требует своевременного и последовательного разбора инцидентов, а это постоянное обязательство, а не проект. Командам, которые не могут его выдержать, лучше подойдёт более простой, хорошо понятный эвристический уровень, чем классификатор, который тихо устаревает.
Что из этого следует
Статические списки разрешений не ошибочны; они недообучены. Они отвечают на вопрос о назначениях, тогда как риск живёт в аргументах, происхождении и последовательности. Проверка интента во время выполнения отвечает на правильный вопрос, но только если сигнал интента достаточно дёшев для оценки на горячем пути. Разделите проверки на уровни, опубликуйте правило эскалации, измеряйте ложные срабатывания в аннулированных запусках, а не в алертах, и версионируйте модель вместе с агентом. Свойство безопасности не в том, что каждый вызов предварительно одобрен. Оно в том, что каждый вызов судится в контексте, по цене, которую агент может позволить себе платить на каждом шаге.