ЖУРНАЛ ДОСЛІДЖЕНЬ / ЗВІТ 002

Підписано, але не обґрунтовано: відсутній рівень аудиту платежів ШІ-агентів

Кожна розглянута мною система платежів ШІ-агентів доводить, що агент мав дозвіл заплатити. Жодна не фіксує, що агент прочитав перед вибором, і не дає банку перевірити це без оператора.

Я прочитав специфікації AP2, Mastercard Agent Pay із Verifiable Intent, Trusted Agent Protocol від Visa, Agentic Commerce Protocol та x402, а також цьогорічні відкриті дослідження їхньої безпеки. Усі п’ять підтверджують авторизацію. Жодна не фіксує криптографічного зобов’язання щодо вхідних даних, які привели до купівлі, а лабораторні атаки вже перетворили підставлений текст товарних оголошень на підписані дійсні кошики. Я визначаю шість стиків, порівнюю п’ять систем і формулюю дванадцять вимог до емітентів, продавців, розробників агентів і регуляторів.

  • 5 із 5систем платежів агентів не зберігають запису про прочитане агентом
  • 73.3%успішність атаки через підставлене оголошення на демонстраційних агентів AP2
  • 15 із 15посередників x402 порушили щонайменше одне правило безпеки
  • 6 жовтнязавершуються консультації Казначейства Великої Британії щодо платежів агентів

Короткий виклад

Я прочитав специфікації п’яти систем, що дають ШІ-агентам змогу платити, і всі цьогорічні відкриті дослідження їхньої безпеки, які зміг знайти. Усі вони досить добре доводять, що агент мав дозвіл заплатити. Жодна не фіксує, що агент переглянув, перш ніж обрати покупку. Жодна не дозволяє комусь поза оператором агента перевірити це згодом.

Цю прогалину вже експлуатують у лабораторії. Команда Аріельського університету вставила звичайні речення в товарні оголошення й домоглася помилок демонстраційних агентів AP2 від Google у 90%, 56% і 73,3% випадків у трьох сімействах атак. Кошики, створені цими агентами, усе одно проходили всі перевірки протоколу. [R2]

Момент, до якого я постійно повертаюся, міститься в самому розділі безпеки AP2. Там сказано, що всі LLM та агенти «МАЮТЬ розглядатися як потенційні нападники». Потім для покупок за відсутності користувача специфікація покладає на агента-покупця обов’язок MUST не підписувати закриті мандати, що перекриваються. Постачальники облікових даних і мережі отримують лише право MAY відхиляти їх. Отже, єдине обов’язкове правило проти подвійного витрачання покладається на компонент, якому специфікація щойно наказала не довіряти. [A1]

Бракує того, що я назву простежуваністю рішення: запису вхідних даних, які привели до купівлі, із криптографічним зобов’язанням, зафіксованим до підписання, який банк або споживач може перевірити без звернення до оператора агента.

П’ять систем і те, що доводить кожна

Agent Payments Protocol (AP2) від Google. Анонсований у вересні 2025 року. Версія 0.2 вийшла 28 квітня 2026 року, того самого дня, коли Google передав протокол FIDO Alliance. Він використовує мандати оформлення замовлення та платежу, кожен у відкритій і закритій формах, закодовані як SD-JWT. У режимі Human-Not-Present (HNP) користувач підписує відкриті мандати й залишає процес, а агент-покупець пізніше підписує закриті власним ключем. Запам’ятайте цю останню деталь. [A1][A2][A3]

Mastercard Agent Pay та Verifiable Intent. Agent Pay реєструє агентів і видає токени, обмежувані за агентом, продавцем, категорією, сумою, часовим вікном і використанням. Verifiable Intent, створений разом із Google, з’явився в березні 2026 року. Mastercard позиціонує його як криптографічний доказ того, що дозволив споживач, на який можуть спиратися продавці та емітенти. Його передали FIDO разом з AP2. [C1][C2]

Visa Intelligent Commerce та Trusted Agent Protocol (TAP). TAP запустили разом із Cloudflare у жовтні 2025 року. Агенти підписують HTTP-запити за RFC 9421 відповідно до Web Bot Auth. За специфікацією Visa дійсний підпис показує, що агент зареєстрований у програмі, а зміна заголовка чи шляху робить підпис недійсним. У квітні 2026 року Visa додала Intelligent Commerce Connect, який приймає платежі агентів через TAP, ACP, UCP та Machine Payments Protocol. [C3][C4][C5]

Agentic Commerce Protocol (ACP) від OpenAI та Stripe. За Delegated Payment Spec агент отримує токен із лімітом витрат і строком дії. Цим визначення меж майже вичерпується. Споживчий інтерфейс ChatGPT Instant Checkout вимкнули в березні 2026 року через замалу кількість продавців. Сам ACP продовжує існувати. [C8][C9]

x402 від Coinbase. Він відновлює застосування HTTP-статусу 402 для оплати кожного запиту стейблкоїнами. Позаланцюгові посередники перевіряють платіж, а потім проводять розрахунок у блокчейні. Стаття дослідників EPFL та Чжецзянського університету на USENIX Security 2026 дослідила 15 посередників, через яких проходило 99% спостережуваного трафіку x402. Кожен порушив щонайменше одне з восьми правил безпеки; загалом виявлено 31 недолік. [R5][R11]

Кожна система обслуговує частину платежу. Проблема виникає через тиждень, коли клієнт телефонує до банку й каже, що агент купив не те. Банк хоче знати, що переглядав агент. Відповісти може лише компанія, яка керує агентом, і банку доводиться вірити їй на слово.

Де повноваження передаються без перевірки

Я згрупував опубліковані збої за точками, де одна сторона приймає те, чого інша не може перевірити, й отримав шість груп. Це моя класифікація. Стик потрапляв до переліку лише тоді, коли його прояв показано у статті або самій специфікації.

  1. Ідентичність не визначає намір

    Підпис TAP або Web Bot Auth повідомляє, який агент надіслав запит і що байти надійшли без змін. І все. Якщо за десять хвилин до цього агент підхопив шкідливі інструкції з оголошення, його підпис усе одно перевіряється. Продавці, які використовують підписи TAP у скорингу шахрайства, фактично оцінюють посвідчення бота. [C4]

  2. Вхідні дані ніколи не підписуються

    Мандати фіксують вихідні дані агента. Текст оголошення, відгуки, описи інструментів MCP, результати інструментів і повідомлення між агентами, які він прочитав на шляху до рішення, ніхто не підписує. Команда Університету Бен-Гуріона та Intuit, яка каталогізувала 48 загроз AP2, вісім із високим рівнем ризику, дійшла того самого висновку: дійсний підпис нічого не говорить про те, чи підмінили контекст, поданий агенту. [R1] Стаття Аріельського університету показує практичний прояв. Одне підставлене твердження про запаси або актуальне покоління продукту схиляло агентів до дорожчого товару, тоді як кошик усе ще відповідав оголошенню за кожним полем, яке перевіряє протокол. [R2]

  3. Зміщення меж делегування за відсутності користувача

    Саме тут розмежування MUST і MAY створює проблему. У лютому Lan із колегами перевірили потоки AP2 за повторних спроб, паралельних викликів і довгих ланцюгів оркестрації та спостерігали повторне витрачання одного мандата. Короткочасні одноразові значення nonce, перевірювані сервером, зупинили це. [R4]

  4. Перевірка зараз, розрахунок потім

    Якщо засіб перевірки дає згоду до остаточного розрахунку, товар може бути переданий до надходження грошей. Дослідження x402 підтвердило два такі випадки «безкоштовної купівлі», три способи витрачання комісій gas посередника та один вузький шлях викрадення активів. [R5] Окремий формальний аналіз x402 описує атаку з наданням і подальшим відкликанням дозволу та повторно відтворюваний заголовок X-PAYMENT, який автори називають «платіжним повноваженням на пред’явника». [R6]

  5. Докази свідчать самі за себе

    Коли покупку оскаржують, історія запитів, траса інструментів і журнал транзакцій зазвичай зберігаються в оператора агента або продавця. Часто саме ці дві сторони й сперечаються. Мандати AP2 забезпечують неспростовність у межах того, що охоплюють, але жодна з п’яти систем не дає емітенту чи споживачеві незалежного запису вхідних даних агента.

    Правила США ще не наздогнали зміни. У березні Eli Clemens із Center for Data Innovation стверджував, що CFPB має оновити Regulation E для агентної комерції. Відтоді я не знайшов дій CFPB щодо переказів, ініційованих агентами. Worldpay і Digital Applied повідомляють, що жодна з карткових мереж не має обов’язкового правила повернення платежів для спорів щодо дій агентів. [L1][L2]

  6. Ланцюг постачання інструментів

    Агенти отримують доступ до каталогів і платіжних помічників через MCP, і його попередня історія безпеки складна. У квітні 2025 року Invariant Labs описала отруєння інструментів і показала, як підмінений калькулятор переконав Cursor розкрити SSH-ключ. Тест MCPTox виміряв середню успішність отруєння інструментів у 36,5% на 45 діючих серверах і 20 моделях; у найгіршому випадку показник становив 72,8%. [R9]

    Cloud Security Alliance повторила ці числа в матеріалі від липня 2026 року. У ньому також розглянуто квітневу роботу OX Security щодо обробки STDIO в офіційних MCP SDK, яка привела до понад 30 повідомлень і більш ніж десяти CVE високої або критичної серйозності. Там само описано дві вразливості, виявлені Wiz у плагіні редактора Amazon Q: CVE-2026-12957 та CVE-2026-12958. В обох випадках MCP-файл робочого простору виконувався без запиту. [R10]

    Липнева вимірювальна стаття встановила, що 91,8% із 414 перевірених MCP-серверів, доступних з інтернету, не мали OAuth. Рецензент поставив під сумнів евристики цієї роботи, тому я вважав би показник приблизним. [R7][R8] Visa тепер має власний MCP-сервер для Intelligent Commerce, тож увесь цей ланцюг постачання перебуває за один крок від карткових облікових даних. [C6] Стаття Університету Бен-Гуріона моделює саме цей шлях: від спільного результату інструмента до підписаного мандата. [R1]

Порівняння п’яти систем

Це мої оцінки, засновані лише на публічній документації. Вони змінюватимуться разом зі специфікаціями.

Порівняння систем платежів ШІ-агентів за тим, що вони підписують, пов’язують і дозволяють перевірити іншим. Оцінки автора, вересень 2026 року.
ВластивістьAP2 v0.2Mastercard Agent Pay + Verifiable IntentVisa Intelligent Commerce + TAPACPx402
Що підписується або пов’язуєтьсяМандати оформлення замовлення та платежу (SD-JWT), пов’язані з підписаним продавцем замовленнямМежі токена та запис наміруІдентичність агента й цілісність запиту (RFC 9421)Токен з обмеженням суми та строку діїПлатіжні дані для кожного запиту
Фіксує бажання користувачаТак, для підписаних полівЗаявлена проєктна метаНі, лише ідентичністьЛише сума та строк діїНі
Фіксує прочитане агентомНіПублічно не задокументованоНіНіНі
Ключ агента підписує за відсутності користувачаТак, у режимі HNPУ межах токенаУ межах токенаТокен для кожної купівліДля кожного запиту
Перевірка й розрахунок разомЗалежить від постачальника облікових даних і процесораАвторизація мережіАвторизація мережіПостачальник платіжних послуг продавцяНі: перевірка поза блокчейном, розрахунок у блокчейні
Незалежна перевірка рішенняНіЕмітент може перевірити запис наміру, але не вхідні даніНіНіНі
MCP у ланцюгуНа розсуд розробника реалізаціїНе визначеноVisa має MCP-серверСпецифікація охоплює MCPВиявлення ресурсів може спрямовувати агентів
Публічні дослідження безпеки у 2026 роціЩонайменше чотири статтіНебагатоНебагатоНебагатоЩонайменше дві, зокрема USENIX
Орган управлінняFIDO AllianceFIDO (Verifiable Intent)Visa, CloudflareOpenAI, StripeCoinbase, відкритий протокол

Кілька моментів вирізняються. AP2 та x402 мають найбільше опублікованих атак, бо вони відкриті й тому найзручніші для дослідження. Стоси карткових мереж і ACP досліджували публічно дуже мало. Це прогалина в перевірці, яка нічого не говорить про їхню безпеку. Mastercard має найсильніше сформульовану мету щодо фіксації наміру. І кожна система отримує «Ні» в рядку вхідних даних, оскільки в прочитаних мною матеріалах ніде не зафіксовано зобов’язання щодо того, що бачив агент.

Чотири сценарії збою

Усі описані тут механізми вже публічні; кодів експлойтів у цьому звіті немає.

  1. Корисна пропозиція дорожчого товару (стики 2 і 5)

    Той, хто може редагувати оголошення, додає рядок, що дешевші навушники є торішньою моделлю. Агент із відкритим мандатом на навушники з шумозаглушенням вартістю до $300 купує пару за $289 замість пари за $179. Підписи перевіряються, обмеження дотримано. Це атака на вибір із роботи Аріельського університету: вона спрацьовувала в 73,3% випадків на загальнодоступній збірці сімейства моделей, що використовується в прикладах AP2, і працювала на всіх 17 перевірених збірках Google. [R2]

    Відповідь AP2 полягає в тому, що обмеження стримують збитки, і справді стримують їх до $300. Але користувач усе одно не отримав того, що обрав би сам, і не може довести, що саме прочитав агент.

  2. Інструмент, що змінюється після схвалення (стики 6 і 2)

    MCP-сервер порівняння цін отримує схвалення, а потім непомітно редагує опис власного інструмента, стверджуючи, що товар є лише в одного продавця, або спрямовуючи ідентифікатор користувача до пошуку облікових даних. Атака Аріельського університету на отримання облікових даних була успішною в 90% випадків. Їхній захист A-VIP працює завдяки повному вилученню ідентифікатора користувача з доступу агента. Змінений опис ніколи не з’являється в жодному мандаті. [R2]

  3. Повторна спроба, що платить двічі (стик 3)

    Оркестратор не дочікується відповіді й надсилає запит повторно. Але перший закритий мандат не зазнав збою, він просто виконувався повільно. Якщо далі в ланцюгу ніхто не скористався правом MAY, клієнт платить двічі. Група Lan відтворила це в симуляції. [R4]

  4. Вміст уже передано, платіж не надходить (стик 4)

    Сервер x402 передає вміст, щойно посередник повідомляє про дійсний підпис. Потім розрахунок завершується невдачею або його випереджає інша транзакція. Дослідники розкрили всі знахідки, а посередники, зокрема Coinbase, випустили виправлення. Цей шаблон усе ще стосується будь-якого платіжного каналу, який надає доступ за результатом перевірки, не чекаючи остаточного розрахунку. [R5][R11]

Наступні три місяці

Минулого грудня Visa заявила, що очікує мільйони покупців, які купуватимуть через агентів до цьогорічного святкового сезону. У листопаді 2025 року її команда ризиків повідомила, що кількість дописів у даркнеті зі згадками ШІ-агентів зросла більш ніж на 450%, а шкідливих транзакцій, ініційованих ботами, зросла на 25% (на 40% у США). [C7]

Водночас формуються правила:

  • Консультації Казначейства Великої Британії щодо модернізації платіжних послуг прямо запитують, як мають змінитися автентифікація, згода й відповідальність для платежів агентів. Вони завершуються 6 жовтня 2026 року, а відповідь уряду запланована на четвертий квартал. [L3][L4]
  • Після липневого огляду Mills Review FCA заявило, що перегляне межі свого регулювання протягом трьох–шести місяців, тобто приблизно відтепер до січня. [L5]
  • Проєкт рамки платежів агентів EMVCo називає Know Your Agent та індикатори транзакцій агентів можливими функціями. Приймання коментарів завершується 30 вересня. [L6]
  • Робоча група FIDO з платіжних технологій під головуванням Mastercard і Visa тепер опікується як AP2, так і Verifiable Intent. [A3]

Те, що ці чотири групи опублікують до початку наступного року, визначить докази, які має супроводжувати купівлю агента. Якщо простежуваність рішення не включать, гадаю, її додадуть пізніше, коли накопичаться спори.

Чого я вимагав би

Емітенти та постачальники облікових даних

  1. Перетворіть право MAY щодо подвійного витрачання в AP2 на обов’язок MUST у власній політиці. Відхиляйте закриті мандати, що перекриваються й спираються на той самий відкритий мандат, та анулюйте попередні токени.
  2. Забезпечуйте одноразове використання за допомогою серверних nonce, а не довіри до поведінки агента.
  3. Установіть граничну суму витрат для кожного відкритого мандата HNP і вимагайте додаткового підтвердження понад неї.

Продавці та постачальники платіжних послуг

  1. Оцінюйте підпис TAP або Web Bot Auth лише як підтвердження ідентичності агента.
  2. Якщо перевірка й розрахунок можуть відбутися в різний час, не передавайте товар до завершення розрахунку.
  3. Зберігайте підписаний JWT оформлення замовлення разом зі знімком сторінки, яку бачив агент. У разі спору це буде ваша частина матеріалів.

Розробники агентів

  1. Гешуйте описи інструментів MCP під час схвалення й відмовляйте у виконанні після їхньої зміни. Тримайте ідентифікатори користувачів та облікових записів поза інструментами, які модель може викликати самостійно.
  2. До підписання гешуйте все прочитане агентом (оголошення, описи інструментів, їхні результати) до журналу з виявленням змін, закріпленого поза власною інфраструктурою та підписаного ключем, недоступним моделі.
  3. Пов’язуйте кожну позицію кошика з оголошенням, показаним агенту, і блокуйте операцію за невідповідності, як це робить A-VIP.

Організації зі стандартизації та регулятори

  1. Передбачте в ланцюгу мандатів місце для простежуваності рішення: гешуйте вхідні дані кожного закритого мандата, фіксуйте зобов’язання щодо них і дозволяйте перевірку третій стороні.
  2. Визначте роль незалежного засобу перевірки, щоб емітент, споживач або оцінювач міг перевірити це зобов’язання офлайн.
  3. У британських консультаціях вимагайте правил відповідальності, що розглядають несанкціоноване рішення авторизованого агента як окремий випадок, відмінний і від звичайних авторизованих платежів, і від звичайного шахрайства. Відповіді приймають до 6 жовтня.

Як я це дослідив і чого не робив

Джерелами були специфікація AP2 v0.2, зокрема розділ безпеки, специфікація TAP від Visa, Delegated Payment Spec від OpenAI, публікації Mastercard про Agent Pay і Verifiable Intent та оголошення FIDO від 28 квітня. Додатково я прочитав дослідження безпеки AP2, x402 і MCP, опубліковані з лютого до вересня 2026 року. Для кожного засобу контролю я позначив його місце в транзакції та перехід, який він охоплює. Неохоплені переходи утворили шість стиків.

Жодної виробничої системи для цього не тестували. Жодне наведене число не походить із моєї лабораторії. Щоб змінити це, я запланував три роботи. По-перше, повторити атаку Аріельського університету на вибір на прикладах AP2 v0.2 за допомогою CRUCIBLE, мого засобу оцінювання з умовним противником. По-друге, спрямувати MCP Trust Scanner на публічні MCP-сервери, пов’язані з платежами. По-третє, створити невеликий прототип Matrix Scroll, що фіксує зобов’язання щодо вхідних даних агента й перевіряє їх офлайн. Результати публікуватиму тут у міру отримання.

Більшість цитованих робіт є препринтами arXiv, що ще не пройшли рецензування. Винятком є дослідження посередників x402, представлене на USENIX Security. Стаття Аріельського університету описує AP2 зі старішими назвами мандатів: намір, кошик і платіж. Я всюди використовую назви з v0.2, а автори зазначають, що тестували еталонну збірку v0.2.0.

Короткі відповіді

Що таке простежуваність рішення для платежів ШІ-агентів?

Запис вхідних даних, які привели до купівлі (оголошень, описів інструментів та їхніх результатів), із зобов’язанням, зафіксованим до підпису агента, який банк або споживач може перевірити, не покладаючись на оператора агента.

Чи фіксують AP2, Visa TAP, Mastercard Agent Pay, ACP або x402 те, що прочитав агент?

Ні. За публічною документацією станом на вересень 2026 року кожна система підтверджує авторизацію або ідентичність, але жодна не фіксує зобов’язання щодо вхідних даних, використаних агентом для вибору.

Чи продемонстровано на практиці ін’єкції інструкцій у платежі агентів?

Так, у лабораторії. Дослідники Аріельського університету повідомили про успішність 90%, 56% і 73,3% проти демонстраційних агентів AP2 від Google, а отримані кошики проходили всі перевірки протоколу.

Джерела

Дослідження безпеки

  1. R1За межами мандата, arXiv 2608.23858Університет Бен-Гуріона та Intuit
  2. R2Підписання транзакції, але не рішення, arXiv 2609.11757Аріельський університет і JCT
  3. R3Атаки на платформи агентної комерції на рівні протоколу, arXiv 2607.21824arXiv
  4. R4Перевірка AP2 під час виконання за принципом нульової довіри, arXiv 2602.06345Lan та ін.
  5. R5Коли HTTP 402 зустрічає блокчейн, arXiv 2607.19545USENIX Security 2026
  6. R6П’ять атак на x402, arXiv 2605.11781arXiv
  7. R7Відкриті за задумом, arXiv 2608.00150arXiv
  8. R8Рецензія на «Відкриті за задумом»Pith
  9. R9Тест MCPTox, arXiv 2508.14925arXiv
  10. R10Отруєння інструментів MCP та автоматичне виконання в IDECloud Security Alliance
  11. R11Огляд дослідження посередників x402CryptoSlate

Знайшли помилку?

Напишіть на UA@ssx360.com. Я виправлю її на цій сторінці та зазначу дату зміни на сторінці виправлень.

Постійне посилання: ssx360.com/research/002

Замовити презентацію.

Підготуйте повідомлення для UA@ssx360.com і надішліть його зі своєї поштової програми.

У першому повідомленні обмежтеся загальними вимогами. Погодьте умови конфіденційності, перш ніж передавати непублічну інформацію.

Ознайомтеся з повідомленням про конфіденційність та юридичною контактною інформацією.