Agent Security

Безопасность агента — это защита активного исполнителя, а не пассивного чат-бота. Как только LLM получает «руки» (инструменты: API, БД, исполнение кода, отправка писем), каждый инструмент становится новой поверхностью атаки и новым способом потерять данные или деньги. Prompt injection — риск №1 в OWASP LLM Top-10 два издания подряд (2024, 2025). Это хаб-заметка по теме.

Суть

Пассивный риск (модель просто генерирует текст) превращается в активный (модель совершает действия). Чат-бот мог в худшем случае «сказать лишнее»; агент с инструментами может выполнить вредную команду: прочитать .env, отправить данные на внешний адрес, списать деньги. Поэтому безопасность агента — это не «фильтр на ответ», а сквозная дисциплина на всех слоях: вход → действие → выход.

Зачем это нужно

  • Бизнес уходит от «личного агента в песочнице» к командным/клиентским сценариям, где нужны строгие меры (изоляция хост-машины, контроль прав).
  • Появились бенчмарки агентной безопасности (например, AgentDojo — измеряет, как часто агента можно принудить к вредному действию).
  • Без security-контура внедрение разворачивается: по прогнозу Gartner, 40% предприятий к 2027 году понизят статус или выведут автономных агентов из-за production-инцидентов (см. Agent Governance).

Как работает (карта темы)

Модель угроз (threat model) — систематизация поверхностей атаки и того, что именно нарушается:

Тип атаки Что нарушается Корневая причина
Jailbreak Attacks Контентная политика провайдера Alignment обходится через перефрейминг
Prompt Injection Намерение приложения (principal intent) Модель не отличает данные от команд
Tool Hijacking Права и действия агента (Excessive Agency) Слишком много прав у инструментов
Data Exfiltration Конфиденциальность данных Нет фильтра на выходе / DLP
RAG Poisoning Целостность базы знаний Недоверенный контент влияет на flow

Слои защиты (от дешёвых к серьёзным):

  • Гигиена ур. 0 — spotlighting, делимитеры, prompt sandwiching (см. Guardrails).
  • Многослойные Guardrails — Input / Action / Output / Format.
  • Детекция инъекций — Injection Detection (ML-классификаторы, бинарный сигнал).
  • Архитектурное разделение — Dual LLM CaMeL.
  • Изоляция исполнения — Agent Sandboxing (Firecracker microVM).
  • Защита данных — DLP for LLM + PII Anonymization.
  • Управление парком агентов — Agent Governance.

Два вопроса, которые задают первыми

Как собрать red-team набор. Методика в четыре шага разобрана в Guardrails: таксономия рисков именно вашего продукта → на каждую вредную категорию парный безобидный запрос (без него не измеряется полезность, см. Over Refusal) → обфускации: транслит, кодировки, ролевые и многоходовые атаки → найденные обходы уходят в регрессионный набор перед каждым релизом. Инструменты авто-редтиминга: HiveTraceRed (поддерживает русский), garak, PyRIT, llamator.

Где граница «достаточной» защиты. Она задаётся не толщиной защиты, а уровнем автономии: контроли должны быть пропорциональны тому, что агент может сделать без человека (Agent Governance). Практический ориентир для уровней 2-3 — необратимые действия закрыты человеком или детерминированным гейтом (Deterministic Veto), права выданы на задачу с TTL, а не в режиме god-mode, и есть kill switch, срабатывающий без деплоя. Всё это проверяется тем же регрессионным набором: защита считается достаточной, когда набор проходит, а не когда список мер выглядит длинным.

Базовый постулат: LLM == Untrusted Node

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

Из постулата следуют четыре независимых эшелона, и ни один не является достаточным сам по себе: каскад входных фильтров (Guardrails), деидентификация персональных данных до отправки в модель (DLP for LLM), инверсия доступа к секретам (JIT Secret Inversion), аппаратная изоляция сред исполнения кода (Agent Sandboxing).

Два вектора, которые дописывают карту угроз

  • Excessive Agency — избыточные права агента на запись или удаление данных без участия человека. Отличается от остальных пунктов тем, что это не атака, а дефект проектирования: система уязвима даже без злоумышленника, достаточно ошибки модели.
  • Goal Hijacking — подмена цели агента через вредоносные инструкции в стороннем источнике, например во вложении обрабатываемого письма. Родственник непрямой инъекции (Prompt Injection), но целится не в отдельное действие, а в постановку задачи целиком: агент продолжает работать «правильно», просто над чужой целью.

Эксфильтрация через Markdown

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

Защита двухсоставная и обе части обязательны: строгая политика безопасности контента (CSP) на фронтенде плюс фильтрация URL на шлюзе. Фронтенд без шлюза не спасает от других клиентов API, шлюз без фронтенда — от ссылок, собранных из разрешённых доменов.

Модель угроз становится артефактом, когда у каждой строки есть доказательство

Таблица выше отвечает на вопросы «что нарушается» и «почему». Для промышленной системы этого мало: нужна ещё колонка проверяемого следа — какое событие или поле в трассе доказывает, что контроль сработал.

Пример связки для нескольких угроз:

Угроза Где ловить в первую очередь Проверяемый след
Внедрение инструкций Сборка подсказки, поиск, шлюз модели Событие границы подсказки, метки источников, трасса отклонённой инструкции
Отравление памяти Путь записи и извлечения памяти Идентификатор записи памяти, состояние проверки, доказательство отката
Злоупотребление инструментом Шлюз инструментов, путь подтверждения Идентификатор вызова, запись подтверждения, результат проверки аргументов
Избыточная автономность Планировщик, политика действий Событие бюджета шагов, причина остановки, решение об эскалации
Потеря аудиторского следа Рантайм, плоскость телеметрии Идентификатор трассы решения, указатель неизменяемого журнала

Привязка к OWASP: у этих угроз есть общепринятые идентификаторы

Веб-сверка 2026-08-23: перечень угроз, который книга по архитектуре агентов излагает своими словами, совпадает с рецензируемым списком OWASP Top 10 for Agentic Applications 2026 (проект OWASP GenAI Security). У рисков там есть устойчивые идентификаторы ASI01ASI10, и на них удобно ссылаться в модели угроз вместо вольных названий:

Идентификатор Риск Где разобран в базе
ASI01:2026 Agent Goal Hijack — подмена цели агента Выше в этой заметке, Prompt Injection
ASI02:2026 Tool Misuse & Exploitation Tool Hijacking, Tool Gateway
ASI03:2026 Agent Identity & Privilege Abuse Agent Identity
ASI04:2026 Agentic Supply Chain Compromise Ждёт разбора части VIII книги
ASI05:2026 Unexpected Code Execution Agent Sandboxing
Memory Poisoning Memory Poisoning

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

Четыре критерия приёмки, без которых таблица остаётся редакционной заметкой:

  1. У каждой угрозы конкретная граница перехвата, а не фраза «модель должна быть осторожнее».
  2. У каждого контроля есть владелец: слой политик, шлюз инструментов, память, песочница, контур делегирования или телеметрия.
  3. У каждой строки есть проверяемый след — событие, поле или ссылка на доказательство (Agent Audit Log).
  4. После инцидента строку можно связать с оценочным сценарием, правилом раскатки или управленческим действием.

Смысл критериев в том, что они переводят модель угроз из документа, который пишут раз в год, в артефакт, который проверяется вместе с системой (Trust Boundary Agent).

Связано с

  • Continuous Red Teaming — состязательное тестирование прода и интеграция сигналов в контур ИБ
  • Prompt Injection — главный вектор (OWASP №1)
  • Guardrails — основной слой защиты, уже существовавшая заметка, дополнена этой партией
  • Agent Governance — организационный слой: уровни автономии
  • Computer Use — частный случай: угрозы агента, управляющего экраном (Confused Deputy)
  • Agent Evals — no_policy_violation и security-эвалюация