Все мы знаем, что агентные системы давно не просто "чат-боты 2.0". Это уже полноценные приложения, которые:

  • планируют

  • выполняют сложные цепочки действий

  • вызывают инструменты (API/FS/shell/browser)

  • хранят и используют память (RAG/long-term)

  • общаются с другими агентами

  • Но делают все эти действия со скрытыми "побочными эффектами"

Поэтому безопасность здесь - это, в первую очередь про управление доверенными границами и контроль последствий, а не "поймать злой промпт очередным фильтром". Ключевая мысль простая - в агентных системах инциденты редко возникают из-за одной "критической уязвимости". Чаще это цепочка из нескольких поспешных решений:

  • Немного лишних прав

  • Немного избыточной автономии

  • Немного доверия к внешнему контенту

А в сумме мы получаем аварийный сценарий работы системы. Эта статья не про "серебряную пулю", это практическая карта, помогающая определить где чаще всего появляется риск, какие контрмеры реально работают в проде и где именно эти контрмеры обычно обходят. В этом материале я буду опираться на свежий OWASP Top 10 for Agentic Applications 2026 года и привязывать подход к защите к модели Lethal Trifecta (private data + untrusted content + external communication). Давайте начинать!

Trifecta как быстрый тест "катастрофичности"

Lethal Trifecta - это не очередной непонятный термин, а полезная проверка конфигурации вашей системы:

  • Private data: у агента есть доступ к приватным данным (почта, документы, тикеты, БД, секреты, внутренние API)

  • Untrusted content: агент потребляет недоверенный контент (веб, письма, вложения, внешние документы, выводы инструментов, сообщения других агентов)

  • External communication: есть канал наружу (HTTP-запросы, email, комментарии в публичных репозиториях, ссылки, DNS-резолв и т.п.)

Если все три ножки присутствуют одновременно, то непрямая prompt injection практически неизбежно превращается в утечку чувствительных данных. Надёжные стратегии всегда сводятся к "сломать хотя бы одну ножку" или поставить жёсткий контроль последствий, поэтому иногда очень полезно прогонять Trifecta как короткий архитектурный тест на каждом ревью вашей будущей системы и проверять, что агент читает, чему он верит и что он может сделать вовне. Если хотя бы на один из пунктов ответ "почти без ограничений", это повод не спорить про качество промпта, а пересматривать архитектуру доступа и каналов выполнения.

Так как же "сломать ножку"?

Private data

  • Что делать: минимизировать доступ и выдавать его JIT

  • Компромисс: агент выполняет меньше задач "автоматом"

  • Практика: short-lived токены, per-task scope, data minimization, раздельные зоны данных

External communication

  • Что делать: максимально жёсткий egress-контроль

  • Компромисс: меньше гибкости и "магии" в сценариях

  • Практика: allowlist доменов, запрет произвольных URL, HITL для публикаций/писем/PR, DLP на выходе

Untrusted content

  • Что делать: изолировать и санитизировать входы

  • Компромисс: выше latency и сложнее UX

  • Практика: маркировать источники, отделять data от control, запрещать трактовку контента как инструкции без policy gate

Persistent memory (усилитель Trifecta)

  • Как снижать риск: строгая модель доверия к памяти

  • Компромисс: тяжелее персонализация и "долгая" память

  • Практика: TTL/expiry, trust scoring, per-tenant namespaces, rollback, запрет auto-ingest outputs

Где именно ломается безопасность в агенте

OWASP Agentic Top 10 удобно читать как карту мест, где данные становятся инструкциями, а инструкция становится действием:

  • входы: пользователь, RAG, веб, почта, документы

  • планирование: как агент выбирает цели, подцели и инструменты

  • инструменты: что реально умеют и какие побочные эффекты имеют

  • память: что сохраняется, чему доверяем и как переиспользуем

  • межагентное взаимодействие: как формируется доверие между агентами

  • человек: как устроены approvals и как эксплуатируется "automation bias"

Теперь пройдемся кратко по всем ASI из OWASP Top 10 и определим что находится в зоне риска, как это обычно происходит и какой минимальный набор защит имеет смысл внедрять в первую очередь.

ASI01 Agent Goal Hijack

  • Что ломают: цели и приоритеты агента

  • Как атакуют: indirect prompt injection через веб, документы, письма и tool output, которые агент ошибочно трактует как инструкции или приоритетные задачи

  • Минимум защиты: независимый policy/intent gate, явный approval для high-impact действий, логирование goal-drift, маркировка источников контента

ASI02 Tool Misuse & Exploitation

  • Что ломают: инструменты и их цепочки

  • Как атакуют: "легальный" вызов tool с вредным intent или параметрами, каскады из нескольких tools, компрометация внешних инструментов в цепочке поставки

  • Минимум защиты: allowlist инструментов, ограничение blast radius на каждый tool (права/rate/egress), корреляция опасных цепочек, запрет произвольного внешнего egress

ASI03 Identity & Privilege Abuse

  • Что ломают: токены, делегирование, сессионные контексты

  • Как атакуют: reuse токенов, confused deputy, транзитивное разрастание прав через memory/plans/межагентные сообщения, наследование прав от пользователя или другого агента

  • Минимум защиты: JIT и short-lived токены, task-scoped permissions, ревалидация прав на чувствительных шагах, контроль наследования полномочий

ASI04 Agentic Supply Chain Vulnerabilities

  • Что ломают: зависимости, tool metadata, агентные карточки, registry

  • Как атакуют: подмена дескрипторов, компрометация пакетов, typosquatting, атаки на цепочки поставки внешних инструментов и интеграций

  • Минимум защиты: pin версий/хэшей, provenance и подпись артефактов, allowlist источников, kill switch для быстрого отключения интеграций

ASI05 Unexpected Code Execution (RCE)

  • Что ломают: контуры генерации и исполнения кода/команд

  • Как атакуют: инъекция приводит к unsafe execution (eval, auto-run, небезопасная десериализация), цепочки из нескольких уязвимостей, обходы фильтров через нестандартные форматы и кодировки

  • Минимум защиты: строгая изоляция исполнения, запрет сети по умолчанию, разделение "сгенерировать" и "исполнить", отдельный approval на elevated runs, мониторинг и алерты на подозрительные шаблоны исполнения

ASI06 Memory & Context Poisoning

  • Что ломают: RAG и long-term memory

  • Как атакуют: "отравляют" память и retrieval, создают долговременные ложные паттерны, которые потом влияют на планирование и действия, постепенно расширяя "зону доверия" к вредоносному контенту

  • Минимум защиты: сегментация по tenant, trust scoring, TTL/expiry, карантин и rollback для сомнительных записей, запрет auto-ingest outputs в память без проверки

ASI07 Insecure Inter-Agent Communication

  • Что ломают: протоколы и доверие между агентами

  • Как атакуют: spoofing, replay, downgrade, подмена descriptorов и сообщений

  • Минимум защиты: mTLS/PKI, подпись сообщений, anti-replay (nonce/timestamp), закрытый registry и строгие схемы валидации для межагентных сообщений, мониторинг аномалий в коммуникациях

ASI08 Cascading Failures

  • Что ломают: устойчивость всей системы через цепочки зависимостей

  • Как атакуют: одна ошибка или инъекция размножается через память, планы и межагентные сообщения, вызывая лавину проблем и масштабируя последствия от одной уязвимости до всей системы

  • Минимум защиты: разделение planner/executor, circuit breakers, лимиты blast radius, checkpoints и неизменяемый lineage-лог

ASI09 Human-Agent Trust Exploitation

  • Что ломают: процесс подтверждений человеком

  • Как атакуют: "убедительные" объяснения и consent laundering в интерфейсе, социальная инженерия

  • Минимум защиты: approvals с показом diff/плана, многошаговые подтверждения для high-impact, обучение операторов и быстрый lockdown-режим

ASI10 Rogue Agents

  • Что ломают: контроль над долгоживущим поведением агента

  • Как атакуют: скрытый дрейф целей, low-and-slow активность, коллюзия между агентами, постепенное расширение прав и доверия

  • Минимум защиты: platform-level kill switch, behavioral baseline и алерты, карантин с аттестацией перед возвратом в продакшн, регулярные ревью целей и планов

Три типовых сценария и где горит сильнее всего

1) Корпоративный агент для почты и документов

Чаще всего здесь проявляются ASI01, ASI02, ASI03 и ASI09. Агент читает входящие письма, вытаскивает контекст из внутренних документов и может отправлять ответы.

Где риск:

  • письмо содержит "инструкцию", которую агент ошибочно трактует как приоритетную задачу

  • агент наследует слишком широкие права пользователя/сервисного аккаунта

  • оператор подтверждает действие "по инерции", не вникая в diff

Что помогает:

  • разделять "чтение контента" и "действие от имени пользователя"

  • делать явный шаг подтверждения для отправки наружу

  • хранить прозрачный trail: какой источник данных повлиял на каждое действие

2) RAG-агент с доступом к внутренней базе знаний

Обычно доминируют ASI06 и ASI08, так как память становится "усилителем" для других уязвимостей. Если агент может сохранять и переиспользовать фрагменты из недоверенных источников, то даже одна инъекция может постепенно отравить всю память и планы.

Где риск:

  • в память попадают непроверенные фрагменты и потом переиспользуются как "доверенные"

  • загрязнение копится постепенно и становится "новой нормой" для retrieval

  • ошибка в одном пайплайне начинает тиражироваться по зависимым сервисам

Что помогает:

  • доверять памяти не "по факту записи", а по уровню доверия источника

  • вводить TTL и процедуры очистки/отката

  • изолировать tenant-контексты и не смешивать рабочие зоны

3) Агент-оркестратор инструментов (CI/CD, тикеты, CRM, облако)

Критичны ASI02, ASI04, ASI05, ASI07 и ASI10.

Где риск:

  • легитимный tool вызывается с вредным intent

  • компрометирован descriptor/интеграция во внешней цепочке поставки

  • мелкие опасные действия складываются в каскад

Что помогает:

  • для каждого инструмента заранее фиксировать допустимые операции

  • пинить версии и проверять provenance интеграций

  • ограничивать "радиус взрыва" лимитами, квотами и policy gate

Компактный roadmap внедрения защиты в агентные системы

Этап 1

  • инвентаризация tools, данных и внешних каналов (Trifecta check)

  • запрет "лишнего" egress и сокращение прав по умолчанию

  • включение подробного аудита действий агента и источников данных

Этап 2

  • внедрение независимого policy/intent gate перед consequential actions

  • JIT-токены и более короткое время жизни доступов

  • обязательные approvals для high-impact действий

Этап 3

  • сегментация памяти, TTL, trust scoring и карантин для сомнительных данных

  • трассировка цепочек действий (lineage) и корреляция событий для раннего обнаружения аномалий

  • регламент аварийного реагирования: kill switch, отзыв токенов, карантин агента

Такой порядок полезен тем, что даёт быстрое снижение риска уже на первом этапе, а не откладывает пользу до "идеальной архитектуры".

Что важно понять про защиту и где она может подводить

  1. Детекторы prompt injection - это слой, а не стена. Реальные кейсы показывают, что обходы классификаторов и санитайзеров неизбежны (пример: EchoLeak как цепочка bypass’ов, включая неожиданные форматы ссылок/выводов)

  2. Самая сильная защита - ограничить последствия. В OWASP-терминах это policy enforcement до исполнения, least privilege, JIT, egress control, sandboxing и kill switch

  3. Агентные системы - распределённые системы. Без неизменяемых логов, корреляций цепочек и "circuit breakers" вы не увидите катастрофу до её наступления

Ещё один практический нюанс - почти все инциденты выглядят "правдоподобно" в моменте. Поэтому важна не только техническая защита, но и операционная дисциплина - кто и как проверяет изменения поведения, кто имеет право на emergency stop, и как быстро команда умеет откатываться к безопасному профилю.

Источники