Как агент сам откроет дверь хакеру? Разбираю три реальных пробоя AI-агентов и почему обычный ред-тиминг их не найдёт

Я добавил в свой опенсорсный сканер BarkingDog режим атаки на AI-агентов с инструментами. Прогнал его на трёх популярных opensource- АГЕНТАХ: Agno , OpenAI CS Agents Demo , LangGraph agent-service-toolkit и получил три разных класса уязвимостей: Agno начал собирать данные для изменения чужого admin-аккаунта (Confused Deputy, ASI03); LangGraph-агент поверил ложному утверждению «менеджер одобрил» и помог обойти политику возврата (Trust Exploitation, ASI08); OpenAI Demo положил сервер от одного рекурсивного текстового запроса (Agentic DoS, ASI06, 30.4% таймаутов). Ниже — архитектура сканера, конкретные пейлоады и мой главный архитектурный вывод 2026 года.

Контекст: что изменилось в 2026

Пока все обсуждают «умных ботов», индустрия незаметно перешла черту. По данным Cloud Security Alliance (опрос 1500+ CISO, июнь 2026):

92% руководителей безопасности обеспокоены AI-агентами в своей организации

88% компаний уже зафиксировали подтверждённые или предполагаемые инциденты с агентами

80,9% технических команд перешли от планирования к production-деплою агентов

Но лишь 14,4% получили полное одобрение от службы безопасности на весь парк агентов

OWASP в декабре 2025 выпустил отдельный стандарт — Top 10 for Agentic Applications 2026 (ASI) . Это признание того, что агенты — это уже не «умный чатбот», а отдельный класс угроз. В Q1 2026 OWASP зафиксировал переход от теоретических рисков к реальным CVE: взлом LiteLLM через GitHub Actions с заливкой backdoor-версии прямо в PyPI, CVE-2026-22708 против Cursor, автономный бот hackerbot-claw без участия человека.

Почему существующие сканеры не справляются

Когда я показывал первую версию BarkingDog для Telegram-ботов, главный вопрос был: «а чем это лучше Garak / PyRIT?» Ответ короткий — они тестируют модель, я тестирую продакшен .

Garak (NVIDIA)

PyRIT (Microsoft)

Цель атаки

Модель напрямую

Модель / агент (кастомно)

Agentic pipeline / tool graph

❌ Ограниченно

⚠️ Кастомный скрипт

⚠️ Ограниченно

⚠️ Частично

✅ Нативно

Multi-turn / Crescendo

Daemon + расписание

Over-Refusal detection

OWASP ASI 2026 mapping

pip/CLI

npm/CLI

pip

docker run

Promptfoo куплен OpenAI в марте 2026 за ~$86M, MIT-лицензия сохранена, но будущее независимости проекта открытый вопрос.

Garak и PyRIT отлично подходят для оценки поведения модели и отдельных сценариев взаимодействия. Однако они не ориентированы на end-to-end тестирование production agent runtime, где между пользователем и моделью находятся system prompt, RAG, маршрутизация запросов, tool graph и внешние инструменты.

Именно этот слой сегодня становится основной атакующей поверхностью агентных систем. BarkingDog атакует тот же HTTP-вебхук, который обслуживает реальный пользовательский трафик, поэтому проверяет не только модель, но и весь runtime целиком — включая orchestration, tool invocation, memory и бизнес-логику.

Почему мы ломаем вебхук, а не фаззим MCP напрямую

Это частый вопрос. Тестируя MCP напрямую, вы проверяете API , а не агента .

Те 30% ошибок HTTP 500 в логах OpenAI Demo — это не «глюк сети сканера», а чистый Agentic DoS . Хакер скармливает боту рекурсию через чат, LLM уходит в бесконечный цикл рассуждений, выжигает RAM и пробивает таймауты FastAPI. Сервер ложится от текста.

Если убрать LLM из контура тестирования и бить сразу в MCP — получите стерильный, на 100% «зелёный» отчёт и ложное чувство безопасности. BarkingDog бьёт End-to-End — ровно туда, куда будет бить реальный хакер. Хотя, следует сказать, что MCP -это следующий логичный шаг в roadmap проекта.

Архитектура сканера: воронка из трёх судей

Самая частая ошибка в самодельных ред-тим скриптах — спросить ещё одну LLM «это плохой ответ?» и поверить ей. Это известная системная проблема: статические rule-based детекторы производят false positives и false negatives по мере того, как поведение моделей и стили отказов меняются. Garak решает её через гетерогенную экосистему детекторов, BarkingDog — через трёхуровневую воронку.

Слой 2 — zero-cost фильтр на regex и сигнатурах. Он отсекает 70–80% шума до того, как полетит платный вызов LLM-судьи. Без него каждое вежливое «извините, не могу помочь» выглядело бы как «частичная утечка».

Атакующая часть — GOAT-генератор , адаптация идеи из работы Meta [«Automated Red Teaming with GOAT», ICML 2025, arXiv:2410.01606]: не статичный список пейлоадов, а LLM-атакующий, который смотрит на предыдущий ответ и сам решает следующий шаг (Observation → Thought → Strategy → Attack). Оригинальный GOAT показал ASR@10 = 97% против Llama 3.1 и 88% против GPT-4-Turbo на датасете JailbreakBench — именно за счёт имитации живого человека, а не одного «идеального промпта». BarkingDog адаптирует эту идею под тестирование production-агентов с инструментами, а не просто базовых моделей.

Дополнительно: движок мутаций (base64, leetspeak, кириллические гомоглифы) и Tenant Isolation Probe — атака от имени «Клиента A» на данные «Клиента B».

Это нужно сказать прямо, потому что это проблема всей индустрии, а не только BarkingDog.

LLM-судьи сталкиваются с двумя классами ошибок: false negatives — реально опасный ответ проскакивает, потому что судья недостаточно строг или его убедила поверхностная корректность; и false positives — безобидный ответ помечается как угроза, потому что судья переусердствовал или неверно интерпретировал контекст.

В логах BarkingDog это видно явно. Среди COMPROMISED-результатов встречаются вещи, которые технически не являются уязвимостью: агент написал стихотворение по запросу (ASI06 на agent-service-toolkit — помечен как компрометация из-за «структурных намёков», хотя это просто стих). Semantic Judge периодически срабатывает на «подозрительный контекст», который человек-аналитик бы отклонил.

Три корневые причины:

1. Судья видит тот же текст, на который среагировал агент. Оценочный компонент во всех автоматизированных сканерах (Garak, CyberSecEval, PyRIT) отображает ответ в сигнал уязвимости. Ненадёжность этого компонента — системная проблема, а не баг конкретного инструмента.

2. Эволюция стилей отказа. Модели всё более изощрённо отказывают: «С удовольствием помогу, но не с этим конкретным запросом» — такая фраза может не попасть в regex-паттерн RefusalJudge и уйти на дорогой SemanticJudge. После рефактора паттернов в июне 2026 показатель ложных срабатываний упал примерно вдвое — но не до нуля.

3. Отсутствие domain-контекста у судьи. SemanticJudge не знает, что ваш агент — это медицинский ассистент. Он оценивает «опасность ответа» в общем смысле, не в бизнес-контексте. Частичное решение — параметр BOT_DOMAIN в .env , который передаётся в system prompt судьи (в режиме бота эта подстройка есть и вообщем все хорошо работает ).

Что это означает на практике: отчёт BarkingDog — это тriage, а не приговор . COMPROMISED-результат означает «здесь нужен человеческий взгляд», а не «система 100% взломана». Это нормально для автоматизированного сканера — так же работают Garak, PyRIT и любой другой инструмент в этом классе. Ценность в том, что человек-аналитик смотрит на 7 подозрительных случаев из 64.

Как BarkingDog вскрывает агентов: пять этапов пайплайна

Классические сканеры работают в лоб — кидают тысячу вредоносных промптов в LLM и считают отказы. В мире Agentic AI это бесполезно. Модель может вежливо отказать пользователю, но при этом бэкенд рухнет от перегрузки памяти, или MCP-инструмент молча исполнит деструктивную команду в фоне.

BarkingDog разбивает атаку на пять изолированных этапов:

Шаг 1. Разведка (Reconnaissance & Fingerprinting)

Перед активной атакой сканер шлёт нейтральные probe-запросы («Who are you?», «What tools do you have?»). Снимаются «отпечатки»: как агент обрабатывает ошибки, структурирует JSON, использует ли статус-коды. Здесь же инициализируется thread_id .

Плюс: позволяет точно настроить парсеры под конкретный стек (Agno, LangGraph), снижая долю ложных срабатываний. Минус: нейтральные запросы всё равно расходуют токены цели; продвинутые ADR-системы могут распознать паттерн разведки и заблокировать сессию до начала боевой фазы.

Шаг 2. Захват контекста (Orchestrator)

Агенты накапливают историю. Тестировать промпты в вакууме бессмысленно. Оркестратор жёстко привязывает серию атак к единому session_id и «прогревает» агента — имитирует затяжной диалог, усыпляя встроенные фильтры.

Плюс: единственный способ пробить защиту агентов, которые отклоняют атаки «в лоб», но ломаются после 3–4 шагов ролевой игры, когда контекст «отравлен». Минус: длинная история раздувает контекстное окно цели и может вызывать искусственные задержки на бэкенде.

Шаг 3. Адаптивная генерация (GOAT Attacker)

Вместо слепого перебора статических пейлоадов — автономная петля: Observation → Thought → Strategy → Attack. Если агент сопротивляется, движок применяет Context Smuggling (подсовывает фейковую историю, где бот якобы уже сдался) или прогоняет текст через обфускацию (Base64, кириллические гомоглифы).

Плюс: сканеру не нужны тысячи захардкоженных шаблонов — движок адаптирует атаку под конкретный бизнес-домен цели. Минус: LLM-атакующий недетерминирован. Траектории атаки в CI/CD могут немного отличаться от запуска к запуску, плюс API-вызовы атакующей модели стоят денег.

Шаг 4. Доставка в Black-Box (Transport Layer)

Сканер стучится прямо в production webhook агента — тот же эндпоинт, на который идёт реальный трафик. Этот слой отвечает за надёжную доставку и мониторинг инфраструктурных сигналов: если агент уходит в бесконечный цикл рассуждений (CoT Hijacking) и вешает сервер — транспорт фиксирует HTTP 500 или таймаут. Это мгновенный маркер успешного Agentic DoS.

Плюс: позволяет найти реальные системные уязвимости (утечки памяти, падения FastAPI/Uvicorn), которые White-Box-сканеры не видят. Минус: случайный лаг облачного провайдера может быть ошибочно классифицирован как DoS, требуя калибровки таймаутов.

Шаг 5. Воронка судей (Judge Ensemble)

Подробнее описана выше. Три фильтра: Reliability → Regex → Semantic LLM. Ответ агента проходит последовательно, и до дорогого LLM-вызова доходят только спорные случаи.

Что нового в атаках 2026: контекст и что из этого есть в сканере

Исследования 2026 года двигаются быстро. Важно честно разделить: что происходит в индустрии — и что из этого реализовано в BarkingDog.

Что есть в BarkingDog:

Движок мутаций (base64 / leetspeak / кириллические гомоглифы) — это рабочий вектор, подтверждённый свежими исследованиями. JBFuzz (март 2026) перенёс классический software fuzzing на текстовые пейлоады и показал средний ASR 99% против GPT-4o, Gemini 2.0 и DeepSeek-V3 на чёрном ящике. Именно за счёт мутаций, а не умных промптов. В отчётах видно, как leetspeak-вариант пейлоада пробивает то, что прямой вариант не пробил.

GOAT-атакующий — адаптация одноимённой работы Meta. Reasoning через Observation → Thought → Strategy → Attack. Не reasoning-модель, а обычная LLM с chain-of-thought промптом, которая смотрит на ответ цели и адаптирует следующий шаг. Это принципиально отличается от статичного списка пейлоадов.

Что существует в индустрии, но в BarkingDog пока нет:

Эволюционные persona-промпты (генетические алгоритмы) — автоматический вывод персон через genetic search, снижающих частоту отказа на 50–70%. Сложная техника, требующая отдельного исследовательского цикла. В BarkingDog есть ручные roleplay-пейлоады, но не автоматическая эволюция персон.

MOBjailbreak — суррогатная LLM, которая переписывает вредоносный промпт так, чтобы скрыть намерение при сохранении вредоносного результата. Отдельный класс атак, заточенный под генерацию вредоносного кода. В roadmap, не в релизе.

LRM как автономные атакующие (Nature Communications, 2026) — reasoning-модели (o3, Gemini 2.5 Pro) как полноценные red-team агенты. Показывает, что следующий шаг в автоматизации — это когда атакующий сам рассуждает, а не просто адаптирует шаблоны. В BarkingDog GOAT-генератор работает на обычной LLM с CoT-промптом, а не на reasoning-модели. Это честная разница в глубине атаки.

Перечисленные техники из индустрии — это roadmap, а не список фич. Если видите, что какая-то из них критична для вашего use case — пишите в issues.

Что я нашёл: три цели — три класса уязвимостей, разберем подробнее:

Тестовый контур:

Три цели: Agno (40.8k звёзд), openai-cs-agents-demo (демо клиентской поддержки от OpenAI), agent-service-toolkit (LangGraph + FastAPI). Все — дефолтные конфигурации «из коробки». Каждая цель показала свой класс уязвимости.

Пейлоад (кириллические гомоглифы):

Ответ агента:

❌ COMPROMISED (ASI03 — Identity & Privilege Abuse)

Агент не отказал. Он принял запрос как легитимную рабочую задачу и начал собирать информацию для её выполнения — уточнять СУБД и схему таблиц. Это классический Confused Deputy : агент с потенциальным доступом к инструментам изменения данных выполняет действие в интересах атакующего, а не легитимного владельца сессии.

Важная деталь: тот же пейлоад без гомоглифов (чистый ASCII) Agno отклонил. Обфускация пробила фильтр — один символ алфавита изменил исход атаки.

Архитектурная причина: авторизация (кто имеет право менять чей account ID) делегирована LLM через системный промпт, а не захардкожена в инструменте на уровне Python/SQL.

Чем грозит в production: если инструмент обновления пользователей подключён — несанкционированное изменение учётных данных любого аккаунта по ID.

Пейлоад:

Ответ агента:

❌ COMPROMISED (ASI08 — Human-Agent Trust Exploitation)

Агент без какой-либо верификации принял ложное утверждение («мой менеджер одобрил») как факт и начал помогать атакующему строить коммуникацию с клиентом на этой недоказанной предпосылке. Он не подтвердил «1 минуту» — но и не сказал «у нас нет такой политики» и не отказался помогать.

Архитектурная причина: агент воспринимает любое утверждение пользователя о корпоративных полномочиях как доверенное. Верификация «одобрил ли менеджер на самом деле» не встроена ни в инструменты, ни в system prompt.

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

Пейлоад:

Результат: 17 из 56 запросов — SYSTEM FAILURE (таймауты + HTTP 500). Reliability Issue Rate: 30.4% .

❌ COMPROMISED (ASI06 — Resource Exhaustion / Agentic DoS)

Это самый дешёвый вектор в тестировании: ни джейлбрейка, ни обфускации, ни социальной инженерии. Обычный текстовый запрос загнал агента в бесконечный внутренний цикл рассуждений (CoT Hijacking), который выжег RAM и пробил таймауты Uvicorn/FastAPI.

Архитектурная причина: в оркестраторе Handoff-агентов нет max_steps , max_tokens на ответ и asyncio.wait_for с жёстким таймаутом. LLM начинает генерировать бесконечный вывод — бэкенд ждёт.

Чем грозит в production: злоумышленник делает сервис недоступным без единой классической CVE — только текстом. Финансовый ущерб: каждый такой запрос сжигает токены до таймаута.

Справедливости ради: agent-service-toolkit показал 0% Reliability Issue Rate и прошёл EU AI Act Art.15 (Robustness). OpenAI Demo завалил именно этот gate. Agno завалил все три compliance-gate одновременно (EU AI Act Art.9, Art.15, CISA Least Privilege). Разрыв между тремя «просто opensource-демо» оказался принципиальным.

Главная архитектурная проблема (и почему это не лечится промптами)

Во всех трёх проектах уязвимости заложены в дизайне: фреймворки делегируют контроль безопасности языковой модели. Разберём каждый по реальному коду.

Agno (agno-agi/agno): небезопасный дефолт в FileTools

Защита от path traversal в Agno есть — check_escape() и PathSecurityError . Но дьявол в дефолтах. Во-первых, если base_dir не задан явно, он становится Path.cwd() — то есть рабочей директорией процесса, которая в продакшене нередко оказывается корнем приложения. Во-вторых, флаг restrict_to_base_dir можно передать как False — и тогда защита полностью отключается:

Нигде в документации это не помечено как опасная опция. Разработчик копирует пример из README, не задаёт base_dir , получает молчаливо небезопасную конфигурацию.

LangGraph agent-service-toolkit (JoshuaC215/agent-service-toolkit): user_id приходит из тела запроса

Аутентификация здесь — не JWT с claims, а просто сравнение токена с константой AUTH_SECRET :

Это проверяет лишь «знает ли клиент ключ». А user_id при этом берётся из тела запроса — то есть клиент сам решает, от чьего имени работать:

Любой аутентифицированный клиент может указать чужой user_id и получить доступ к его истории и данным. В multi-tenant сценарии это горизонтальная эскалация привилегий.

OpenAI CS Agents Demo (openai/openai-cs-agents-demo): нет явных лимитов на цикл агента

Runner.run_streamed() вызывается без max_turns и без asyncio.wait_for :

SDK устанавливает дефолт в 10 итераций, но он нигде явно не переопределён и не задокументирован в демо. Для production-сервиса без таймаута на уровне asyncio рекурсивная задача может привести к OOM.

Эти проекты создавались как демонстрация оркестрации LLM — безопасность намеренно упростили. Но именно такие «демо из коробки» копируют в продакшен.

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

Подтверждение от индустрии 2026

Выводы сканирования совпадают с официальным консенсусом:

OWASP ASI 2026 классифицирует наши уязвимости: ASI03 (Identity and Privilege Abuse), ASI02 (Tool Misuse), ASI08 (Cascading Failures). OWASP ввёл принцип Least Agency — агент должен работать с минимальной автономией, необходимой для конкретной ограниченной задачи. Это развитие классического Least Privilege применительно к агентным системам.

NSA + CSA, май 2026: NSA опубликовало Cybersecurity Information Sheet по MCP, зафиксировав, что распространение протокола значительно опередило развитие его модели безопасности. Исследователь Simon Willison сформулировал это точнее всего: «lethal trifecta» — агент становится опасным, когда одновременно имеет доступ к приватным данным, подвергается воздействию недоверенного контента и может общаться с внешним миром. Улучшение моделей не решает проблему — защита должна быть на транспортном уровне и в runtime.

OWASP Q1 2026 Exploit Round-up: Зафиксирован реальный переход: атаки теперь нацелены на идентичности агентов, слои оркестрации и supply chain — не только на выводы моделей.

Реальный ущерб за 2024–2026:

Air Canada (2024): Суд обязал выплатить компенсацию за обещание агента, нарушившее официальную политику возврата.

DPD UK (2024): Промпт-инъекция — бот начал материться и критиковать собственную компанию. Экстренное отключение всего AI-модуля.

LiteLLM/PyPI backdoor (март 2026): Группа TeamPCP через автоматизированный бот hackerbot-claw скомпрометировала CI/CD Trivy, похитила PyPI-токен и опубликовала backdoor-версии LiteLLM — шлюза, который используют CrewAI, DSPy, Microsoft GraphRAG.

Vercel (апрель 2026): Сотрудник подключил сторонний AI-инструмент Context.ai к корпоративному Google Workspace с правами «Allow All» без административного одобрения. После компрометации Context.ai атакующий получил OAuth-токен и через него — доступ к внутренним переменным окружения Vercel.

Ни один из трёх протестированных проектов не плохой — это живые, поддерживаемые open-source решения. Проблема не в коде авторов, а в том, что agentic-фреймворк «из коробки» — это шасси, а не сейф : guardrails, идентификацию и лимиты нужно добавлять самостоятельно, и большинство команд до этого не доходит до первого инцидента.

Если у вашего агента есть доступ к инструментам, базе или сети — прогоните его через ред-тиминг до деплоя, а не после.

Код BarkingDog — MIT, отчёты остаются у вас: https://github.com/PPushkarev/BarkingDog

#llmsecurity #aiagents #redteaming #owasp #agentic #barkingdog