Обычная языковая модель отвечает текстом. AI-агент получает цель, планирует шаги, вызывает инструменты, использует память и может менять состояние внешних систем. Поэтому ошибка в его контексте способна превратиться в действие.
Разобраться, как устроен такой цикл, можно по записи мастер-класса по сборке AI-агента для пентеста, а затем проверить собственного агента на учебном полигоне Standoff Hackbase.
Защищать нужно не только LLM. Объектом анализа становится вся агентная система: входные данные, инструкции, память, подключённые tools, права, секреты, API и среда выполнения. Полезная модель угроз начинается с простого вопроса: какой путь должен пройти внешний сигнал, чтобы превратиться в значимое действие?
Агент — это цепочка доверия
Минимальную архитектуру агента можно представить как последовательность:
внешний контент → контекст модели → выбор действия → вызов инструмента → изменение во внешней системе.
Каждый переход здесь является доверительной границей. Агент может читать issue, pull request, документацию, письма, страницы, результаты поиска или ответы API. Затем модель интерпретирует полученный текст, планировщик выбирает следующий шаг, инструмент выполняет команду, а корпоративная система принимает её от имени выданной агенту учётной записи.
Для threat modeling стоит выписать шесть элементов:
- какие активы доступны агенту: код, документы, секреты, тикеты, инфраструктура;
- откуда поступают данные и каким источникам нельзя доверять;
- какие инструкции имеют приоритет и где смешиваются команды и данные;
- какие инструменты агент может вызвать и с какими параметрами;
- от чьего имени он действует и какие полномочия получает;
- что попадает в память и журналы и как долго там хранится.
Такая схема помогает увидеть риск ещё до выбора защитного продукта. Если неизвестно, какие данные входят в контекст и какое действие завершает цепочку, невозможно определить ни границы доступа, ни безопасный отказ.
Prompt injection превращает данные в инструкцию
Прямая prompt injection приходит от пользователя. Косвенная скрывается во внешнем контенте, который агент должен обработать: документе, pull request, тикете, странице или ответе подключённого сервиса. Главная проблема в том, что полезные данные и потенциальная инструкция оказываются в одном контексте.
Сам факт влияния на ответ модели ещё не определяет ущерб. Критично то, что агент способен сделать после такого влияния. Если у него есть только чтение публичного файла, последствия ограничены. Если тот же агент может менять репозиторий, создавать задачи, обращаться к внутреннему API или запускать shell-команды, вредоносный текст получает гораздо более короткий путь к инфраструктуре.
Поэтому фильтрации входа недостаточно. Контроль нужен в точке действия: параметры вызова необходимо валидировать, опасные операции — сверять с политикой, а выход за разрешённый сценарий — блокировать независимо от объяснения модели.
Отравленный инструмент меняет смысл действия
Tools и MCP-серверы расширяют возможности агента, но одновременно становятся частью его цепочки поставки. Риск возникает, если команда подключает сторонний сервер без проверки источника, доверяет описанию инструмента, выдаёт интеграции широкие разрешения или не контролирует её обновления и ответы.
В результате агент может получить не тот набор действий, на который рассчитывала команда, передать данные не туда или использовать инструмент в непредусмотренном сценарии. Отдельно стоит учитывать memory poisoning: опасный контекст способен сохраниться и влиять на последующие шаги уже после завершения исходной задачи.
Минимальный процесс подключения tools включает реестр разрешённых MCP-серверов, проверку источника, allowlist доступных действий, ограничения параметров, sandbox execution и журналирование каждого tool call. Новая интеграция должна проходить security review как самостоятельный компонент, а не как безобидное расширение интерфейса модели.
Лишние права превращают ошибку в инцидент
Агенту нужна отдельная machine identity или service account. Если он действует с правами пользователя или общей технической учётной записи, становится трудно понять, кто инициировал операцию, какие разрешения действительно требуются и как быстро отозвать доступ.
Принцип least privilege для агента означает ограничить не только список систем, но и конкретные действия внутри них. Возможность прочитать задачу в Jira не должна автоматически означать право менять её статус. Доступ к GitLab для анализа кода не требует записи в защищённую ветку. Инструмент для просмотра конфигурации не должен уметь применять изменения.
OAuth scopes, RBAC или ABAC задают техническую границу. Approval workflow добавляет человеческое подтверждение там, где цена ошибки высока: изменение кода, доступ к секрету, запуск команды, публикация результата или операция в production.
В записи мастер-класса можно посмотреть путь от настройки агента до безопасной проверки его на задаче, а на полигоне — увидеть, где агенту хватает инструкций, а где нужны ограничения среды.
Базовая матрица угроз
| Поверхность | Что может пойти не так | Базовый контроль |
|---|---|---|
| Внешний контент | Агент принимает недоверенный текст за инструкцию | Разделение данных и команд, маркировка недоверенного контекста, action validation |
| Tools и MCP | Подключённый компонент подменяет ожидаемое поведение или получает лишний доступ | Реестр разрешённых серверов, проверка источника, allowlist, sandbox |
| Identity и permissions | Ошибка или компрометация приводит к действию с широкими правами | Отдельная identity, least privilege, узкие scopes, RBAC или ABAC |
| Память | Вредоносный или ошибочный контекст влияет на будущие задачи | Ограничение записи, срок хранения, очистка и контроль происхождения данных |
| Среда выполнения | Агент запускает опасную команду или выходит за пределы задачи | Изоляция, policy enforcement, подтверждение критических операций |
| Наблюдаемость | Нельзя восстановить, почему и как было выполнено действие | Логи prompt, response и tool calls, трассировка последовательности шагов |
Проверять нужно траекторию, а не только ответ
Обычный функциональный тест отвечает на вопрос, получил ли пользователь нужный результат. Для агента этого мало: одинаковый итог может быть достигнут безопасным путём или через лишний доступ, опасную команду и несанкционированный вызов инструмента.
В негативный набор тестов стоит включить:
- prompt injection во входном запросе;
- вредоносную инструкцию во внешнем документе;
- попытку вызвать запрещённый инструмент;
- запрос секрета или данных за пределами роли;
- обход подтверждения критической операции;
- изменение памяти недоверенным контентом;
- отказ или подмену ответа MCP-инструмента;
- проверку безопасной остановки и rollback.
Логировать следует не только prompt и финальный ответ, но и всю последовательность tool calls: какой контекст видел агент, почему выбрал действие, с какими параметрами вызвал инструмент и что получил в ответ. Именно траектория позволяет расследовать опасное поведение и отличить единичную ошибку от системной слабости.
С чего начать до подключения к production
Сначала нарисуйте архитектуру, активы, потоки данных и trust boundaries. Затем выдайте агенту отдельную identity и минимальные права. Подключайте инструменты по одному, проверяя разрешённые и запрещённые сценарии. Для критических операций добавьте подтверждение, для выполнения — sandbox, для расследования — полную трассировку действий.
После этого проведите негативные тесты и убедитесь, что система умеет безопасно отказать, заблокировать действие и восстановиться. Повторяйте проверку при смене модели, инструмента, политики доступа или поведения системы: код приложения может не измениться, а траектория агента — измениться.
Проверить этот подход на практике можно без доступа к боевой инфраструктуре: получите запись мастер-класса, соберите своего AI-агента и испытайте его на полигоне Standoff Hackbase до 17 сентября. Хорошая модель угроз не запрещает агенту действовать. Она делает его действия ограниченными, наблюдаемыми и обратимыми.
