Концепция, которая продолжает терпеть неудачу
Большинство обсуждений безопасности агентов по-прежнему сосредоточены на промпте. Задаётся вопрос, можно ли уговорить модель сгенерировать вредоносный текст, и в качестве контроля предлагается классификатор или системная инструкция. Эта концепция рушится в тот момент, когда агенту выдаются учётные данные и инструмент. Инъекция промпта, приводящая к вызову инструмента, — это не событие модерации контента. Это удалённое выполнение кода в рамках набора разрешений агента, выполняемое интерпретатором, который оказался языковой моделью.
Различие важно, потому что меры защиты разные. Фильтры промптов работают с входными данными и вероятностны. Границы разрешений работают с возможностями и детерминированы. Команда, которая внедряет только первое, защищает не тот уровень.
Злоумышленники уже совершили этот сдвиг. Отчёты об агентных роях, используемых для кражи карт, описывают инфраструктуру, а не разговор: оркестрированные процессы, которые создают учётные записи, хранят платёжные учётные данные и маршрутизируют ценность через нижестоящие сервисы. Агенты — это рабочая нагрузка. Промпт — лишь интерфейс к ней.
Поставщики решений для идентификации приходят к тому же выводу. Работа над идентичностью агентов — выдача агентам собственных субъектов, ограничение области их токенов, аудит их действий — существует именно потому, что агент с учётными данными — это рабочая нагрузка, которой нужен жизненный цикл идентичности. Это правильная концепция, и именно из неё исходит данное эссе.
Как выглядит боковое перемещение
Боковое перемещение — это набор техник, которые злоумышленник использует после первоначального доступа для достижения систем, на которые у него не было разрешения. Для агентов первоначальный доступ обычно представляет собой успешную инъекцию через контент, который читает агент: извлечённый документ, ответ инструмента, веб-страницу, тело тикета. Оттуда собственные разрешения агента становятся разрешениями злоумышленника.
Рассмотрим агента с доступом на чтение к одному набору данных и доступом на запись к нижестоящему инструменту — системе тикетов, API обмена сообщениями, хостингу кода. Ни одно из разрешений по отдельности не является избыточным. В сочетании они образуют путь эксфильтрации: прочитать набор данных, закодировать результат в поле, которое примет нижестоящий инструмент, и записать его наружу. Каждый отдельный вызов находится в рамках заявленной области. Композиция — нет.
Это агентный эквивалент сервисной учётной записи, которая может читать базу данных и писать на внешний эндпоинт. Ни одна зрелая команда безопасности не приняла бы такое сочетание без контроля исходящего трафика. Развёртывания агентов routinely принимают его, потому что список инструментов выглядит аккуратно в файле конфигурации.
Два множителя усугубляют это.
Во-первых, общие учётные данные инструментов. Когда несколько агентов аутентифицируются в одном инструменте с одним и тем же секретом, радиус поражения одной компрометации — это весь флот. Нет способа отозвать скомпрометированного агента, не отозвав всех, и нет способа атрибутировать вызов конкретному агенту постфактум. Журнал аудита фиксирует сервисную учётную запись, а не субъект.
Во-вторых, долгоживущие токены. Токен со сроком жизни в несколько дней превращает одну успешную инъекцию в постоянную точку опоры. Злоумышленнику не нужно повторно внедряться; он держит учётные данные, которые продолжают работать после того, как разговор, породивший их, закончился. Окна ротации, измеряемые неделями, превращают временный инцидент в постоянное предоставление доступа.
Контроли, которые действительно ограничивают
Контроли, уменьшающие радиус поражения, — те же, что применяются к любой привилегированной рабочей нагрузке, адаптированные к шаблону вызовов агента.
Учётные данные для каждого агента, каждого инструмента, краткосрочные
Каждый агент должен иметь собственную идентичность, и эта идентичность должна быть ограничена конкретными инструментами, которые ему нужны. Учётные данные должны выдаваться в начале задачи и истекать в конце, с явным ограничением аудитории, указывающим инструмент, для которого они действительны. Токен, выпущенный для аналитического эндпоинта только для чтения, должен быть отклонён API обмена сообщениями, даже если он предъявлен правильно.
Это стандартная практика идентичности рабочих нагрузок. Компромисс операционный: краткосрочные учётные данные требуют пути выпуска токенов, доступного агентам, и этот путь становится зависимостью. Если выпуск недоступен, агенты перестают работать. Команды должны решить, предпочтительнее ли деградировавший агент долгоживущим учётным данным, и ответ обычно да — но это нужно проектировать, а не предполагать.
Списки разрешённых исходящих соединений на сетевом уровне
Ограничения на уровне инструментов необходимы и недостаточны. Если среда выполнения агента может открывать произвольные исходящие соединения, скомпрометированный агент может эксфильтровать данные через канал, не регулируемый политикой инструментов. Исходящий трафик должен быть ограничен на сетевом уровне до пунктов назначения, которые агенту законно нужны, с соответствующим ограничением разрешения DNS.
Честный компромисс здесь — трение. Списки разрешений ломаются, когда инструмент добавляет эндпоинт, когда поставщик меняет CDN или когда законный рабочий процесс обращается к новому хосту. Затраты реальны и повторяются. Они всё ещё ниже стоимости неограниченного пути исходящего трафика, но команды должны закладывать бюджет на обслуживание, а не рассматривать список разрешений как одноразовую конфигурацию.
code-on-screen-dark-9fc1eb-81348e.jpg)
Каждый вызов инструмента должен записываться с субъектом, который его авторизовал, использованными учётными данными, переданными параметрами и возвращённым результатом. Журнал должен быть доступен только для добавления и храниться там, куда агент не может писать. Журнал траекторий, который агент может изменять, не является журналом аудита.
Механизм важнее формата. Полезная запись траектории связывает три вещи: идентичность агента, конкретный экземпляр учётных данных и вызов инструмента. Без экземпляра учётных данных вы не можете отличить вызов, сделанный до ротации, от сделанного после. Без идентичности агента вы не можете ограничить инцидент одним агентом, а не общей учётной записью.
Оценка как контроль безопасности
Оценка безопасности агентов должна следовать шаблону, используемому для сервисов: предполагайте, что входные данные враждебны, и измеряйте, чего может достичь противник.
Проводите red-team агента так, как вы бы проводили red-team API. Внедряйтесь через каждый канал, который читает агент — извлечённые документы, выходные данные инструментов, сообщения пользователей, содержимое файлов — и наблюдайте, какие вызовы инструментов возникают. Цель — не найти промпты, генерирующие плохой текст. Цель — найти входные данные, порождающие несанкционированные вызовы.
Оценивайте сдерживание, а не отказ. Показатель отказов говорит, как часто агент отклоняет. Оценка сдерживания говорит, как далеко распространяется успешная инъекция: сколько инструментов она достигает, сколько учётных данных может использовать, как долго сохраняется результирующий доступ. Показатель отказов — метрика качества. Сдерживание — метрика безопасности, и именно она соответствует радиусу поражения.
Практический результат — конверт сдерживания для каждой инъекции: при успешной инъекции в точке X, какие инструменты достижимы, какие учётные данные можно использовать и каков срок жизни результирующего доступа. Этот конверт вы уменьшаете с помощью вышеуказанных контролей, и именно его вы сообщаете заинтересованным сторонам.
Публикуйте поверхность атаки
Развёртывание агента должно поставляться с документом о поверхности атаки вместе с его системным промптом. Документ должен указывать, какие входные данные агент считает недоверенными, какие инструменты он может вызывать, чего может достичь учётные данные каждого инструмента, где разрешён исходящий трафик и как выглядит конверт сдерживания при успешной инъекции.
Это не упражнение по раскрытию. Это артефакт проектирования. Запись достижимого набора инструментов заставляет задать вопрос, необходимо ли каждое ребро, и даёт службе реагирования на инциденты начальную карту. Системный промпт описывает предполагаемое поведение. Документ о поверхности атаки описывает, что система может фактически делать, когда промпт не контролирует ситуацию.
Эти два документа не являются заменами. Промпт — это контракт интерфейса. Поверхность атаки — это контракт безопасности. Агентным системам нужны оба, и второй будет проверен противником, который никогда не читает первый.