Как разорвать опасную цепочку в агентной системе

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

Критический риск возникает при соединении трёх элементов в одной сессии: приватных данных, недоверенного контента и возможности менять внешний мир. Каждый элемент нужен в работе сам по себе. Данные дают агенту контекст, внешний контент помогает принять решение, а действия автоматизируют рутину. Их сочетание требует явных границ и минимальных привилегий.

Три элемента опасного контура

Приватные данные — это код, секреты, CRM, внутренние документы, переписка, таблицы и доступы к инфраструктуре. Обычно их передают агенту намеренно: чтобы найти причину сбоя, подготовить отчёт или изменить конфигурацию. Проблема появляется с ростом объёма контекста. Оператор уже не видит каждый фрагмент, который оказался в рабочем окне модели.

Недоверенный контент приходит из почты, тикетов, резюме, сайтов поставщиков, загруженных файлов и сообщений пользователей. Он может содержать прямую или скрытую инструкцию для модели. В контексте LLM инструкция и данные представлены текстом, поэтому разметка в промпте снижает риск, но не создаёт жёсткой технической изоляции. Источником проблемы бывает и обычный устаревший документ: его указание способно направить автоматизацию по неверному пути без злого умысла.

Внешнее действие — любое изменение, сохраняющееся за пределами текущего диалога. Сюда входят отправка письма, публикация сообщения, создание pull request, запрос к API, изменение записи в базе, запуск команды на сервере и загрузка файла. Даже исходящий HTTP-запрос способен стать каналом утечки, если в его параметрах оказался приватный контекст.

Когда агент читает чужой текст, видит конфиденциальные данные и обладает широкими правами, инъекция превращается из ошибки интерпретации в инцидент. Важно учитывать, что современные агенты часто действуют через код: комбинация shell-команд, скриптов и API-вызовов позволяет реализовать почти любой сценарий в пределах доступных учётных данных.

Почему фильтры не дают гарантии

Классификаторы промпт-инъекций, правила для опасных слов и инструкции вроде «считай этот блок только данными» остаются полезной гигиеной. Они могут отсечь известные шаблоны и случайные ошибки. Однако такие меры вероятностны: адаптивная атака получает новые попытки, а модель продолжает интерпретировать единый контекст.

Параллель с параметризованным SQL ограничена. В SQL параметры отделены от исполняемого кода структурой запроса и драйвером. Для текстового контекста LLM подобной встроенной границы нет. Поэтому защита должна располагаться вокруг модели: в управлении доступами, разделении процессов и контроле исходящих операций.

Разделяйте задачи по уровню доверия

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

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

Похожая схема применима к DevOps-задачам. Агент, который анализирует issue, логи или сторонний репозиторий, работает в песочнице и готовит план изменения. Второй контур выполняет ограниченный набор проверенных операций: запускает конкретный pipeline, создаёт ветку или открывает запрос на ревью. Доступ к production должен быть отдельным этапом с короткоживущими полномочиями и подтверждением.

Между контурами передавайте решение в узкой структуре вместо свободного текста. Валидированный JSON со схемой action, target, reason и допустимыми значениями существенно сокращает канал, через который может пройти нежелательная инструкция. Схема должна проверяться программно до исполнения.

Сужайте полномочия и исходящие каналы

У агента не должно быть постоянных ключей ко всем подключённым системам. Храните OAuth-токены, API-ключи и сервисные учётные данные в брокере доступа или отдельном слое интеграций. Агент запрашивает действие через профиль разрешений, а этот слой решает, допустим ли вызов.

Профиль полезно описывать конкретно: разрешённый метод, ресурс, список доменов, объём передаваемых данных, частоту запросов и срок жизни полномочия. Вместо права «работать с почтой» агент может получить возможность создать черновик для одного ящика. Вместо сетевого доступа ко всему интернету — запросы к нескольким API через прокси с журналированием.

Исходящий трафик требует отдельного наблюдения. Логи рассуждений модели могут быть неполными и не доказывают фактическое действие. Контроль на прокси, API-шлюзе, почтовом сервисе или уровне egress-сети фиксирует реальный запрос, его адресата, размер и результат. Для чувствительных операций добавляйте лимиты, allowlist и блокировку неожиданных форматов данных.

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

Подтверждения и человеческий контроль

В интерактивных инструментах человек остаётся важной линией защиты. Подтверждение стоит сохранять для необратимых операций: отправки, удаления, платежа, деплоя, изменения прав и публикации. Его полезность быстро снижается, если оператор подтверждает десятки похожих запросов без проверки.

Поэтому запрос на подтверждение должен показывать последствия в понятной форме: адресата, список затрагиваемых ресурсов, команду высокого уровня, объём данных и признак внешней передачи. Проверять длинный shell-скрипт перед каждым запуском трудно; гораздо надёжнее ограничить сценарии, которые вообще разрешено сформировать и исполнить.

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

Минимальный план внедрения

Составьте карту данных, внешнего контента и действий для каждого агентного сценария.
Найдите сессии, где все три категории доступны одновременно, и разделите их на независимые контуры.
Замените постоянные ключи на короткоживущие полномочия с профилями разрешённых API-вызовов.
Передавайте между агентами только данные по фиксированным схемам; валидируйте их до выполнения действия.
Введите allowlist исходящих адресатов, лимиты объёма и аудит на прокси или API-шлюзе.
Оставьте подтверждения для необратимых операций и сделайте их содержательными для оператора.
Проверяйте архитектуру на сценариях с враждебным письмом, документом, issue и веб-страницей.

Безопасность агентных систем начинается с архитектуры окружения. Модель может ошибиться в интерпретации текста, поэтому риск следует локализовать заранее. Чёткие границы между данными, недоверенным вводом и полномочиями позволяют сохранить автоматизацию полезной и ограничить последствия неизбежных ошибок.