На конференции Black Hat 2026 исследователи Авиям Ивги и Хеди Ингбер продемонстрировали структурную уязвимость, пронизывающую три крупнейших стека агентов: AWS Bedrock AgentCore с SDK Strands, Google Agent Development Kit и среду Vercel AI SDK. Они назвали эту уязвимость CoreBreak. AWS выпустила исправление для CVE-2026-18830 (CVSS 8.6), Google — для CVE-2026-18236 (CVSS 9.3, критический уровень), а Vercel исправила CVE-2026-64650 и CVE-2026-64651. Все три производителя встроили механизмы контроля туда, куда агент имел прямой доступ.
Средства защиты, на которые полагается индустрия, полностью сосредоточены вокруг модели: системные промпты, фильтры контента, обучение отказам. Если вы обходите модель, вы обходите их все. CoreBreak продемонстрировала два способа сделать именно это:
- Передать в среду историю сообщений, в которой последнее сообщение уже содержит вызов инструмента, причем инструмент запускается с аргументами, выбранными злоумышленником, в то время как модель и все защитные барьеры вокруг нее даже не активируются.
- Сфальсифицировать событие «одобрения» (approved) в той же истории, в результате чего этап участия человека в контуре (human-in-the-loop) подтверждает действие, которое ни один человек не видел. Сам механизм подтверждения стал вектором атаки.
Экстренные исправления сошлись в одном решении: привязать выполнение инструментов к состоянию, которое злоумышленник не может подделать, и отклонять внешне переданные вызовы и подтверждения инструментов. Это называется принудительным применением политик вне канала (out-of-band policy enforcement, или OBPE), и каждому вендору пришлось в условиях кризиса заново воссоздавать элементы этой защиты, патч за патчем.
Мы создали границу OBPE еще до взлома
Agentic Data Plane от Redpanda уже сегодня обеспечивает защиту OBPE для агентов в продакшене. Каждый вызов инструмента пересекает типизированную границу, которая находится вне зоны рассуждений агента, его промпта и истории сообщений. Именно на этой границе фиксируется идентификация, обеспечивается соблюдение пределов политики владельца данных и разрешаются подтверждения по каналу, который агент не может прочитать или подделать. Каждое подтверждение привязывается к точной сводке запроса, принимающему решение субъекту и версии политики, после чего возобновляется выполнение исключительно неизменяемого задержанного вызова. Сфальсифицированный вызов инструмента в истории сообщений не является авторизацией. Поддельное значение "confirmed: true" не является одобрением. Обход модели не означает обход границы, поскольку границе все равно, запускалась ли модель.
Это не то же самое, что патчи CVE. Исправления от вендоров добавляют проверки происхождения: они проверяют, поступил ли вызов инструмента из шага модели, а остальные отклоняют. Граница не заменяет эту проверку; она лишает смысла саму попытку ее обойти. Поддельный вызов, прошедший проверку происхождения, все равно упирается в лимиты политики владельца данных, поэтому он может сделать не больше, чем легитимный вызов, а не всё, что позволяют полные полномочия роли выполнения. Подтверждения — еще более яркий пример: в этом случае подтверждение OBPE вообще не считывается из предоставленной агентом истории, поэтому трюк со сфальсифицированным подтверждением просто не имеет почвы для подделки.
Архитектура, лежащая в основе этого решения, не была получена путем обратного инжиниринга CVE. В апреле мы опубликовали O'Reilly Radar essay arguing that nobody had built HR for agents. В мае мы зафиксировали официальную архитектуру в материалах семинара SAO на конференции ACM CAIS. Затем наша полная исследовательская работа по OBPE протестировала этот же проектный подход против родственного класса атак: не поддельных вызовов инструментов, а подвергшихся инъекции промптов агентов, которых склонили к утечке защищенных данных и выполнению запрещенных действий.
Мы провели 3621 тестовый запуск на четырех моделях (Claude Sonnet 4.6, Claude Haiku 4.5, GPT-5 и GPT-5 mini), чтобы измерить это напрямую. Агенты, защищенные только правилами в промптах, потерпели неудачу в 57.6% случаев, допустив утечку защищенных данных, раскрыв защищенные значения или выполнив запрещенные операции на бэкенде. Те же агенты за границей OBPE показали сбои лишь в 0.2% случаев.
Мы также протестировали альтернативу внутри канала, при которой специальная модель-рецензент считывает вывод агента и блокирует небезопасные ответы. В случае с Sonnet рецензент все равно ошибался в 58.6% случаев, поскольку он считывает текст после того, как инструменты уже отработали. Он может отклонить ответ. Но он не может «разчитать» запись, которую агент уже поглотил, и не может отменить уже произошедшую запись в систему. Граница не допустила ни одного сбоя в тех же тестах (0.0%), выполнила больший объем работы (66.2% успешных задач против 58.7% у рецензента) и утроила показатель безопасного и полезного завершения (63.0% против 19.7%). Рецензент сделал 930 лишних вызовов модели и показал худшие результаты по обоим показателям. Граница не потратила на это ни одного ресурса.
OBPE не решает все проблемы. Но она закрывает те пробелы в агентском управлении, которые остаются незакрытыми, когда LLM являются частью решения, причем делает это с эффективностью и детерминизмом классического ПО. Защита на уровне модели — это вызов инференса на каждом шаге, поэтому ее стоимость и задержка масштабируются вместе с ее возможностями. Нельзя купить переход от вероятностного к детерминированному поведению. Принятие политик — это типизированная оценка на основе прописанного правила, которая дает тот же ответ за микросекунды без затрат токенов.
{{featured-resource}}
Вердикт: CoreBreak права
Список мер по усилению безопасности, составленный самими исследователями, выглядит как наши проектные цели для OBPE. Они призвали отклонять вызовы инструментов, инициированные вызывающей стороной, выполнять авторизацию во время выполнения, снижать уровень наследуемых полномочий и привязывать каждый вызов инструмента к конкретному событию модели и состоянию авторизации, которые его породили. Это спецификация для обеспечения безопасности вне самого агента. Самая эффективная команда Red Team в отрасли и наша собственная исследовательская группа независимо друг от друга пришли к одному и тому же выводу, что является либо совпадением, либо готовым ответом.
Стоит особо выделить путь кражи учетных данных, который обнародовала CoreBreak: внедренные инструкции заставили инструменты управления браузером и интерпретатора кода считать облачные учетные данные роли выполнения и эксфильтровать их. Никакой движок политик не способен изменить сетевые настройки песочницы, включая нашу. Урок заключается в том, что именно вы изначально доверяете агенту. Типизированный посреднический доступ к инструментам удерживает учетные данные за границей защиты. Универсальная вычислительная среда с доступными в ней облачными учетными данными делает их удаленными на расстояние одного HTTP-запроса от любой внедренной инструкции. Замки работают только на тех дверях, которые ими оснащены. И CoreBreak показала, что значительная часть индустрии выпустила «здания» без дверей.
Следующий вопрос, который стоит задать
Ни одна компания не позволяет сотрудникам одобрять собственные запросы на доступ из документа, который они написали сами. Агенты тоже не должны иметь такой возможности, и CoreBreak доказывает, что это не философская позиция, а инженерное требование. CVE и патчи указывают в том же направлении, что и собственный список мер безопасности исследователей: обеспечение контроля должно находиться на границе, недоступной для агента. Мы опубликовали архитектуру до обнародования уязвимостей, протестировали ее против этого класса атак и используем ее в продакшене уже сегодня.
Если вы внедряете агентов для работы с реальными данными, главный вопрос к любому оцениваемому стеку — управляет ли ваш агент сам собой. CoreBreak — это то, что происходит, когда ответом на этот вопрос является «да».
Чтобы увидеть, как выглядит ответ «нет», ознакомьтесь с нашей полной исследовательской работой или сразу перейдите к практике и посмотрите Redpanda Agentic Data Plane в действии.
.png)
