Не зря я вёл канал про безопасность агентных платежей практически год, ведь недавно вышла отличная статья о безопасности платёжных агентов. Самые критичные риски кроются в протоколах связи между агентом и сервисом.

В чем суть? Успех семантической атаки зависит от того, поддастся ли модель манипуляции. Структурная же атака срабатывает всегда (вероятность успеха - 100%), независимо от того, что под капотом: легкая и дешевая модель или топовая модель. Например, злоумышленник эксплуатирует отсутствие криптографической подписи у транзакции или подменяет скрытые поля в API-запросах.  Модель может быть идеально выравнена и безопасна, но если сам протокол имеет дырки, то агент просто и эффективно переведет деньги не туда.

Немного данных:

1) Найдено 33 структурные уязвимости на трех независимых платформах (CoralOS, Fetch.ai uAgents и Google AP2).
2) Выделено 6 первопричин (от отсутствия проверки целостности реестра до race conditions при проведении платежей).
3) Три из этих уязвимостей легко выстраиваются в полноценную цепочку атаки для перехвата транзакций.
4)Тесты (1440 запусков) показали: популярные модели вроде GPT-4o-mini и Gemini Flash пасуют перед косвенными промпт атаками в описании агента в 99–100% случаев.

Хотя вот на этом моменте можно поставить двойку. Где Opus 4.8, где GPT 5* ?

Отдельного внимания заслуживает сама среда тестирования (AIP-Bench) и её датасет на HuggingFace. Это 16 жестких сценариев с однозначным результатом.
Они разбиты на 6 классов атак: от подмены личности плательщика и утечек секретов до атак на цепочку поставок маркетплейса и уязвимостей типа TOCTOU (Time-of-check to time-of-use). В случае с TOCTOU злоумышленник использует рассинхронизацию системы: он успевает подменить данные (например, адрес кошелька получателя) ровно в ту долю секунды, когда агент уже проверил безопасность операции, но еще не успел нажать кнопку «отправить».

И тут есть уже моменты, на которые нам стоит обратить свой взгляд. Множество бенчмарков, даже тот же AgentDyn, о котором я писал - используют LLM в качестве судьи. Но LLM-судью тоже можно обмануть, да и от галлюцинаций никто не застрахован.

AIP-Bench опирается только на жесткие, детерминированные проверки. HTTP-коды ответов, точные совпадения адресов кошельков, регулярные выражения в логах, подсчет событий. Никакой чёрной магии. Только проверяемые события.

Протоколов взаимодействия ИИ-агентов становится всё больше: экосистема растет, появляются новые стандарты и маркетплейсы. Но часто выходит так что модели уделяется больше внимания, а про остальное просто забывается.

Выходит, так что, если архитектура по умолчанию доверяет непроверенному источнику в реестре, агент выполнит задачу безукоризненно - просто не в вашу пользу. Как-то так.