Защита агентных приложений по OWASP Agentic Top 10 и модели Trifecta

Все мы знаем, что агентные системы давно не просто “чат-боты 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, и как быстро команда умеет откатываться к безопасному профилю.

Источники

• OWASP Top 10 for Agentic Applications for 2026

• OWASP Agentic AI – Threats and Mitigations

• OWASP Securing Agentic Applications Guide 1.0

• OWASP AI Exchange (AI security overview, lethal trifecta)

• Simon Willison — The lethal trifecta for AI agents

• EchoLeak paper (arXiv)

• CaMeL paper (arXiv)

• Design Patterns for Securing LLM Agents against Prompt Injections (arXiv)

• Tenable — “The Trifecta” (Gemini vulnerabilities)

• OWASP Top 10 for Agentic Applications for 2026 (разбор)