Подпис защищает не то, что кажется
AP2 — платёжный протокол, который Google предложил, чтобы LLM-агенты могли расплачиваться за человека: получать задачу, согласовывать условия с продавцом, оформлять заказ и переводить деньги. Каркас доверия здесь держится на двух подписанных документах — Checkout Mandate и Payment Mandate. Они фиксируют условия сделки, и после подписания подменить их незаметно уже не получится.
Загвоздка — в формулировке «после подписания». Подпись гарантирует, что данные не изменились с момента, когда их заверили, и ничего не говорит о том, как они появились. А собираются они из потока взаимодействий: сообщения между агентами по A2A Protocol, вызовы инструментов через Model Context Protocol, ответы внешних сервисов, содержимое страниц и писем. Всё это лежит за пределами криптографической защиты. Если в контекст до авторизации подмешали чужую инструкцию, подпись заверит уже искажённое намерение — и останется при этом абсолютно валидной.
Отсюда и название исследования: угроза живёт не внутри мандата, а «за мандатом».
Что находили раньше и почему v0.2 потребовал нового разбора
Слабые места в AP2 искали и до этого: в версии v0.1 были описаны атаки повторного воспроизведения и инъекции промпта. В v0.2 часть этих проблем закрыли — но вместе с исправлениями приехали новые возможности и новые допущения о развёртывании. Каждая такая новинка — потенциальная поверхность атаки, а старый анализ на новую версию механически не переносится.
Этим и занялась команда — Avital Aviv, Parth A. Gandh, Ron Bitton и Asaf Shabtai. Работа Beyond the Mandate: A Systematic Security Analysis of the Agent Payments Protocol (AP2) выложена в arXiv 24 августа 2026 года под номером 2608.23858, в рубриках cs.CR и cs.AI.
Роли, фазы, архитектуры и границы доверия
Разбор построен не как охота за отдельными багами, а как разметка всей территории. Авторы описывают роли участников, а жизненный цикл транзакции делят на пять последовательных фаз — от постановки задачи до расчётов и возможных споров после них. Параллельно выделяются пять архитектур развёртывания: они отличаются тем, где размещаются агенты, у кого хранятся ключи и как в схему встроены доверенные посредники.
Ключевой шаг — проведение границ доверия. И тут вырисовывается главная асимметрия: сам мандат находится внутри защищённого контура, а весь информационный поток, из которого он выплавляется, — снаружи. Всё, что происходит между этими зонами, и составляет основной сюжет работы.
MAESTRO: акторы, поверхности, цели
Формальную часть построили на MAESTRO — методологии моделирования угроз для мультиагентных сред. С её помощью описаны четыре актора угроз, одиннадцать поверхностей атаки, восемнадцать возможностей противника и шесть целей, к которым атакующий стремится.
Такая декомпозиция нужна не ради красивых цифр. Она показывает, что противник не один: это не только внешний злоумышленник, но и скомпрометированный инструмент, недобросовестный продавец, подставной сервис. И мотивы у них разные — от прямого вывода денег до незаметного смещения выбора в нужную сторону.
Каталог из 48 угроз
На выходе получился каталог из 48 угроз, сгруппированных в пять семейств атак. Оценивали их с помощью AIVSS — системы оценки уязвимостей, адаптированной под специфику ИИ. Восемь угроз как минимум в одной архитектуре дотягивают до полосы High.
Показательно уже само это «как минимум в одной». Уровень риска зависит не только от кода, но и от схемы развёртывания: то, что смертельно для одного варианта интеграции, в другом может оказаться почти безобидным — и наоборот. Единого ответа на вопрос, насколько безопасен AP2, не существует.
Восемь High-risk: стенд и демонстрации
Публичного развёртывания протокола на момент работы не было, поэтому авторы собрали тестовый стенд своими руками — и покрыли в нём все пять архитектур. На нём же построили пять демонстраций proof-of-concept: каждая закрывает свою группу угроз, а вместе они охватывают все восемь High-risk сценариев вместе с предлагаемыми мерами защиты.
Это важный аргумент против упрёка «у вас тут только теория». Угрозы не просто перечислены — они воспроизведены.
Сканер, который знает про развёртывание
Отдельный практический результат — сканер, учитывающий особенности развёртывания. Его логика в том, что проверять нужно не протокол вообще, а конкретную конфигурацию. Сканер сопоставляет применимые к данной схеме угрозы с проверками трёх типов: статическими, проверками кросс-ролевой согласованности и состязательными тестами.
Кросс-ролевые проверки здесь особенно уместны. В мультиагентной схеме ошибка часто прячется не внутри отдельного компонента, а на стыке ожиданий: один агент уверен, что нужную проверку уже выполнил другой.
Что из этого следует
Главный вывод звучит жёстче, чем хотелось бы: валидной подписи мандата недостаточно, чтобы утверждать, что транзакция отражает намерение пользователя. Подпись подтверждает целостность, а не осмысленность. Если контекст до авторизации был скомпрометирован, криптография аккуратно заверит чужую волю.
Практические следствия для тех, кто строит агентные платежи:
- Контролируйте входной контекст, а не только итоговую транзакцию. Основная масса рисков лежит до момента подписания.
- Считайте архитектуру частью модели угроз. Одна и та же версия протокола в разных схемах развёртывания даёт разный профиль риска.
- Сужайте полномочия агента. Чем конкретнее мандат, тем меньше ущерб от искажённого намерения.
- Проверяйте стыки ролей. Именно там проверки проваливаются чаще всего.
Коротко
Криптография решает ровно ту задачу, которую перед ней поставили, и ни на йоту больше. AP2 честно защищает транзакцию от подмены после подписания; всё, что происходит раньше, остаётся зоной ответственности разработчика. Исследование с 48 угрозами и восемью High-risk сценариями — не приговор протоколу, а карта местности: она показывает, где заканчивается защита, которую даёт подпись, и начинается работа, которую подпись за вас не сделает.
