На конференции Black Hat 2026 исследователи Авиям Ивги (Aviyam Ivgi) и Хеди Ингбер (Hedi Ingber) продемонстрировали структурную уязвимость, проходящую красной нитью через три крупнейших стека разработки агентов: 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 продемонстрировала два способа сделать именно это:
- Передать в среду выполнения историю сообщений, где последнее сообщение уже содержит вызов инструмента, при этом инструмент запускается с аргументами, выбранными злоумышленником, а модель и все окружающие ее защитные барьеры даже не срабатывают.
- Подделать событие «одобрения» в той же истории, в результате чего этап участия человека в контуре (human-in-the-loop) подтверждает действие, которое ни один человек не видел. Сам механизм одобрения превратился в вектор атаки.
Все экстренные исправления свелись к одному решению: привязать выполнение инструментов к состоянию, которое злоумышленник не может подделать, и отклонять внешне переданные вызовы инструментов и подтверждения. Это называется внеполосным (out-of-band) контролем политик, или OBPE, и каждому вендору пришлось восстанавливать его по частям в экстренном порядке, патч за патчем.
Мы создали границу OBPE до того, как произошел взлом
Решение Redpanda Agentic Data Plane уже сегодня поставляется с поддержкой OBPE для агентов в продакшене. Каждый вызов инструмента пересекает типизированную границу, которая находится вне зоны рассуждений агента, его промта и истории сообщений. Именно на этой границе привязывается идентичность, обеспечивается соблюдение верхнего предельного уровня политики (policy ceiling) владельца данных и разрешаются запросы на одобрение по каналу, который агент не может прочитать или подделать. Каждое одобрение привязывается к точному дайджесту запроса, принципалу, принявшему решение, и версии политики, возобновляя работу только для неизменяемого удерживаемого вызова. Поддельный вызов инструмента в истории сообщений не является авторизацией. Поддельное подтверждение «confirmed: true» не является одобрением. Пропуск модели не означает пропуск границы, поскольку границе все равно, запускалась ли модель.
Это не то же самое, что патчи для устранения CVE. Исправления от вендоров добавляют проверки происхождения (provenance checks): проверяется, что вызов инструмента был сделан моделью, а остальное отклоняется. Граница не заменяет эту проверку; она лишает смысла саму попытку ее обойти. Поддельный вызов, прошедший проверку происхождения, все равно упрется в предельный уровень политики владельца данных, поэтому он сможет сделать максимум то же самое, что и легитимный вызов, а не всё, что позволили бы полные права роли выполнения. Одобрения — еще более наглядный пример: одобрение на базе OBPE вообще никогда не считывается из истории, предоставленной агентом, поэтому у трюка с поддельным подтверждением просто нет ничего, что можно было бы подделать.
Архитектура, лежащая в основе этого подхода, не была получена путем обратного инжиниринга CVE. В апреле мы опубликовали статью в O'Reilly Radar, в которой утверждали, что никто еще не создал кадровую службу (HR) для агентов. В мае мы официально зафиксировали эту архитектуру в докладе для семинара SAO на конференции ACM CAIS. Затем в нашей полной исследовательской работе по OBPE этот же проектный подход был протестирован на родственном классе атак: не на поддельных вызовах инструментов, а на агентах с инъекциями в промтах, которых принуждали к утечке защищенных данных и совершению запрещенных действий.
Мы провели 3621 тестовый запуск на четырех моделях (Claude Sonnet 4.6, Claude Haiku 4.5, GPT-5 и GPT-5 mini), чтобы измерить этот показатель напрямую. Агенты, защищенные только правилами из промтов, давали сбой в 57.6% случаев, допуская утечку защищенных данных, раскрывая защищенные значения или выполняя запрещенные операции на бэкенде. Те же агенты под защитой границы OBPE давали сбой лишь в 0.2% случаев.
Мы также протестировали внутриполосную (in-band) альтернативу, при которой специализированная модель-рецензент считывает вывод агента и блокирует небезопасные ответы. На модели Sonnet рецензент все равно ошибался в 58.6% случаев, поскольку он читает текст уже после того, как инструменты отработали. Он может отказать в ответе. Но он не может «разочесть» запись, которую агент уже поглотил, и не может отменить уже выполненную запись в БД. Граница показала 0.0% сбоев в тех же тестах, выполнила больший объем работы (66.2% успешных задач против 58.7% у рецензента) и утроила показатель безопасного и полезного завершения (63.0% против 19.7%). Рецензент сделал 930 лишних вызовов модели и показал худшие результаты по обеим метрикам. Граница не потратила на это ни единого вызова.
OBPE не решает все проблемы. Но она закрывает бреши в управлении агентами, которые остаются уязвимыми, когда LLM являются частью решения, причем делает это с эффективностью и детерминизмом классического программного обеспечения. Защитный механизм на базе модели — это инференс-запрос на каждом шаге, поэтому его стоимость и задержка (latency) растут вместе с его возможностями. Нельзя купить переход от вероятностного поведения к детерминированному. Принятие решения по политике — это типизированная оценка на основе прописанного правила, которая дает тот же результат за микросекунды без затрат токенов.
{{featured-resource}}
Вердикт: CoreBreak права
Собственный список мер по повышению безопасности от исследователей читается как наши цели проектирования OBPE. Они призвали отклонять вызовы инструментов, созданные вызывающей стороной, выполнять авторизацию во время выполнения, снижать уровень наследуемых полномочий и привязывать каждый вызов инструмента к точному событию модели и состоянию авторизации, которые его породили. Это спецификация для обеспечения безопасности вне агента. Самая эффективная красная команда (red team) в отрасли и наша собственная исследовательская группа пришли к одинаковым выводам независимо друг от друга — что является либо совпадением, либо готовым ответом.
Стоит особо выделить путь кражи учетных данных, который обнажила уязвимость CoreBreak: внедренные инструкции заставили управляемые инструменты браузера и интерпретатора кода прочитать облачные учетные данные роли выполнения и эксфильтровать их. Ни один движок политик не меняет сетевые настройки песочницы, включая наш. Урок заключается в том, что вы вообще доверяете агенту. Типизированный опосредованный доступ к инструменту удерживает учетные данные за защитной границей. Универсальная вычислительная среда с доступными облачными учетными данными делает их в один HTTP-запрос от любой внедренной инструкции. Замки работают только на тех дверях, которые они установлены. И уязвимость CoreBreak показала, что значительная часть индустрии выпустила «здания» без дверей.
Следующий вопрос, который следует задать
Ни одна компания не позволяет сотрудникам утверждать собственные запросы на доступ из документа, который они написали сами. Агенты тоже не должны иметь такой возможности, и CoreBreak — это аргумент в пользу того, что это не философская позиция, а инженерное требование. Обнаруженные уязвимости CVE и патчи указывают в том же направлении, что и собственный список мер безопасности исследователей: обеспечение контроля должно осуществляться на границе, недоступной для агента. Мы опубликовали архитектуру до раскрытия уязвимостей, протестировали ее на этом классе атак и уже используем ее в продакшене.
Если вы внедряете агентов для работы с реальными данными, вопрос, который следует задать для каждого оцениваемого стека — управляет ли ваш агент сам собой. CoreBreak — это то, что происходит, когда ответом на этот вопрос является «да».
Чтобы увидеть, как выглядит ответ «нет», прочитайте нашу полную исследовательскую работу или ознакомьтесь с тем, как Redpanda Agentic Data Plane работает на практике.