Monitoring and incident response for a fleet of agents

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

Особенно важны «границы доверия» из прошлых уроков: логируйте, когда в контекст попал недоверенный контент, и что агент сделал после этого. Именно на стыке «прочитал внешние данные → совершил чувствительное действие» живёт большинство атак; без трассировки этот переход невидим. Записывайте также срабатывания approval gate, отказы инструментов и попытки выйти за egress-allowlist.

При этом сами логи — чувствительный актив: в них попадают промпты, данные пользователей, возможно секреты. Их нужно защищать, редактировать секреты и хранить с контролем доступа, иначе система наблюдаемости сама станет мишенью. Практический ориентир — иметь по каждому инциденту достаточно данных, чтобы восстановить полную траекторию: что агент увидел, что решил, что сделал и куда это ушло. Без такой трассировки incident response вырождается в догадки.

Над логами строится обнаружение — сочетание детерминированных guardrails и поведенческой аналитики. Guardrails работают в реальном времени как фильтры на входе и выходе: классификаторы, ловящие попытки инъекции; проверка вывода на утечку секретов и PII; блокировка запрещённых в сценарии инструментов; контроль, что исходящий адрес в allowlist. Ключевой принцип — guardrail должен исполняться детерминированным кодом вне модели, чтобы его нельзя было «уговорить» той же инъекцией.

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

Важно калибровать чувствительность. Слишком шумные алерты ведут к усталости и игнорированию (как и слишком частые approval gate), слишком редкие — пропускают атаку. Практика — многоуровневые реакции: подозрительное логировать и метить, опасное блокировать сразу, критическое эскалировать человеку. И помните: обнаружение — это второй эшелон после архитектурной защиты (least privilege, разрыв триады), а не замена ей; оно ловит то, что просочилось сквозь первый.

Когда обнаружение сработало, нужен заранее написанный план реагирования — импровизировать во время инцидента поздно. Первый этап — сдерживание (containment): быстро остановить ущерб. Для агентов это значит иметь kill-switch (мгновенно приостановить агента или весь класс агентов) и возможность оперативно отозвать токены и права, которыми агент действовал. Здесь окупаются короткоживущие узкие токены из урока 4: отзыв точечный и быстрый, радиус поражения ограничен.

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

Ключевой этап, который часто пропускают, — post-incident: разбор без поиска виноватых, превращение инцидента в новый adversarial-тест (урок 6), чтобы эта дыра больше не вернулась, и обновление детекторов и guardrails. Инцидент — дорогой, но ценный источник новых правил. Agentic-специфика в том, что действия происходят быстро и автономно, поэтому сдерживание должно быть в значительной мере автоматическим: пороги, при которых система сама притормаживает агента и зовёт человека, а не ждёт, пока кто-то заметит.

Чтобы всё это не осталось набором разрозненных приёмов, полезно свести защиту к признанной таксономии. OWASP Top 10 для приложений LLM (редакция 2025) даёт общий язык и чек-лист рисков: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM03 Supply Chain, LLM04 Data and Model Poisoning, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM07 System Prompt Leakage, LLM08 Vector and Embedding Weaknesses, LLM09 Misinformation, LLM10 Unbounded Consumption.

Весь курс ложится на эту карту. Уроки 1–2 — это LLM01; смертельная триада и эксфильтрация — LLM02 и LLM07; sandboxing, least privilege и скоуп токенов — ответ на LLM06 и частично LLM05; MCP и цепочка поставок — LLM03 и LLM04; red-teaming проверяет покрытие по всем пунктам; мониторинг и лимиты закрывают LLM10 (например, защита от неконтролируемого расхода ресурсов и денежных лимитов). Такой маппинг помогает увидеть пробелы: пройдитесь по десяти пунктам и спросите, какая конкретная мера у вас закрывает каждый.

Зрелость measured не отсутствием инцидентов, а наличием видимости, плана и обратной связи. Правильная финальная установка курса: агент проектируется как система, которая переживает компрометацию модели — с ограниченными правами, разорванной триадой, наблюдаемостью, обнаружением и отрепетированным реагированием. Безопасность здесь не разовый чек-лист, а непрерывный цикл: моделируем угрозы, снижаем риск архитектурой, проверяем red-teaming, наблюдаем в проде, учимся на инцидентах — и снова по кругу.