Банки вже блокують агентів, які входять за обліковими даними, переданими їхніми клієнтами. JPMorgan заявляє, що блокує сервіси зі спільним використанням облікових даних для переказу коштів, паралельно працюючи над тим, як зробити це правильно.
Ми входимо в період розколу. Одні компанії будують для агентів парадний вхід, тоді як інші перекривають їм шляхи проникнення. Walmart щойно анонсував Agent Gateway на базі MCP, починаючи з бета-версії для розробників, а наступного місяця з'являться профілі агентів (Agent Profiles) з лімітами витрат.
Під час звіту Meta про прибутки Цукерберг сказав, що шопінг став найпопулярнішим сценарієм використання Muse із середнім чеком понад 200 доларів. Це безумовно фінансова задача, і вина за її вирішення буде величезною.
Девід Сакс стверджує, що банки мають підтримувати доступ, який клієнти можуть надавати, обмежувати та відкликати. Я погоджуюся з цим вектором. Складніше питання — як саме.
Для вашого банку ваш агент виглядає як гігантська проблема шахрайства та відповідальності.
Передача мого логіна не повідомляє банку, який саме агент його використовує, що я йому доручив і чи відповідає дія моїй інструкції. Клієнт може схвалити доступ, не даючи дозволу на все, що агент може спробувати зробити.
Відчуваю, що час малювати схему.

Є чотири рівні: Вхід, Ідентичність, Інструменти та Намір.
1. Вхід: дайте агенту підтримуваний спосіб потрапити всередину.

Personal Agent Protocol, або PAP (тепер називається Poppy), дає бізнесу можливість опублікувати, як агенти можуть з ним взаємодіяти: де входити, які інтерфейси він пропонує та який доступ надаватиме.
Мій агент знаходить цю інформацію та використовує підтримуваний процес авторизації. Я схвалюю доступ; бізнес вирішує, що саме дозволяти. Цей доступ можна обмежити та відкликати. Bank of America і Wells Fargo є партнерами з розробки, що означає, що вони допомагають формувати протокол, а не обіцяють, що мій агент зможе користуватися їхніми банківськими додатками вже завтра.
Trusted Agent Protocol (TAP) від Visa дозволяє шопінг-агенту представитися за допомогою підписаної інформації: «Я шопінг-агент, затверджений через програму Visa, я роблю покупки для цього клієнта, і ось як він платитиме». Продавець може перевірити цю інформацію, перш ніж дозволити продовжити. Але йому все одно потрібно перевірити, чи схвалив я покупку.
Web Bot Auth дозволяє вебсайту перевірити, хто керує агентом. Недостатньо просто назватися «Muse»; сайт звіряє підпис запиту з опублікованим ключем оператора. TAP використовує цей підхід для шопінг-агентів.
Усі вони доповнюють один одного: «привіт, я бот, я хороший бот, і я хотів би дещо зробити».
2. Ідентичність: надайте докази, яких потребує сервіс.

x401 від Proof дозволяє сервісу запитувати докази щодо особи, яка стоїть за агентом. Банк каже, що йому потрібно, агент пред'являє облікові дані, а банк їх перевіряє. «Мій агент каже, що я Саймон» — це лише заява; підписані облікові дані від довіреного емітента перетворюють її на доказ.
OpenID for Verifiable Presentations (OpenID4VP) — це спосіб, яким гаманець пред'являє ці облікові дані. x401 запитує докази; OpenID4VP допомагає їх доставити.
Стандарти FIDO лежать в основі passkeys. Я розблоковую свій ключ обличчям, відбитком пальця або PIN-кодом пристрою, а мій пристрій надсилає підпис, який сервіс може перевірити. Мої біометричні дані залишаються на пристрої. Це автентифікує мене без передачі пароля агенту, але саме по собі не встановлює мою юридичну особу.
Наявному клієнту банку може бути достатньо лише автентифікації. Новому клієнту або для доступу до обмеженого сервісу може знадобитися ще й верифікована особа чи підтвердження права на доступ.
3. Інструменти: дайте агенту точну операцію.

MCP дозволяє банку описати, що може робити агент і як про це просити. «Щоб заблокувати картку, виклич цей інструмент і дай мені ID картки». Агент надсилає ID; банк повертає результат.
WebMCP пропонує структуровані інструменти через браузер, щоб агент міг використати інструмент блокування картки замість того, щоб вгадувати, на яку кнопку натиснути. API забезпечує прямий програмний інтерфейс. MCP може описати операцію, тоді як API виконує роботу під капотом.
Agent2Agent (A2A) дозволяє моєму агенту передати задачу агенту компанії та відстежувати її виконання. Але це не підтверджує, що я авторизував цю задачу.
Браузер — це те, як агенти отримуватимуть доступ до багатьох сервісів у найближчому майбутньому. Вони клікатимуть сторінки, бо іншого варіанту немає, і несподіване спливаюче вікно може зірвати всю справу.
Бізнес усе одно контролює доступ. Те, що агент виявив інструмент «переказати гроші», не дає йому дозволу спустошити мій рахунок.
4. Намір: узгодьте дію з тим, що я схвалив.

Той моторошний момент, коли не можеш знайти телефон, і так неприємний, а повідомляти кожен банк окремо — ще гірше. Я хочу, щоб мій агент заблокував мої картки та сам пристрій. «Заблокуй мою картку» — це не дозвіл переказати мій баланс чи змінити реквізити рахунку.
Покупка додає умови. Якщо я прошу агента забронювати готель, «підходящий» означає наявність вільних ваг понад 25 фунтів, мініхолодильника та безкоштовного скасування, бо плани на подорожі часто змінюються в останню мить. Я можу схвалити конкретний номер, певні дати та 200 доларів за ніч включно зі зборами.
Схвалення — це лише один крок. Потім сервіс має звірити фактичне бронювання з цими умовами. Номер за 190 доларів із додатковими зборами на 60 доларів перевищує мій ліміт. Підписання платежу також не доведе, що в готелі є потрібний мені спортзал.
x401 також може запитувати підписану дію. Я переглядаю умови на своєму пристрої, схвалюю їх, а сервіс перевіряє підписану відповідь перед виконанням. Там, де провайдер це підтримує, це може охоплювати зміни в акаунті та документи, а не лише платежі.
Verifiable Intent від Mastercard дає бізнесу підписаний доказ, що пов'язує мій дозвіл із покупкою агента. Він перевіряє, чи підписи та транзакція відповідають лімітам, замість того, щоб вірити агенту на слово.
AP2 від Google пов'язує дозволи на оформлення замовлення та оплату, які називаються мандатами. Продавець перевіряє, що агент може купити; платіжний провайдер перевіряє, чи може він використати мій платіжний метод для цієї покупки.
Visa Intelligent Commerce забезпечує платіжні інструкції та контроль. Я автентифікую інструкцію; агент запитує платіжні дані, а Visa перевіряє запит і платіж продавця на відповідність цій інструкції. TAP допомагає розпізнати агента; ці механізми контролю керують оплатою.
Європейська Strong Customer Authentication пропонує корисне порівняння з посиленою перевіркою: для відповідних дистанційних платежів схвалення прив'язане до суми та отримувача. Але воно не дає нам універсального дозволу на весь сценарій із загубленим телефоном.
Бізнес усе одно має сказати «так».

Зрештою, споживачі повинні контролювати те, що роблять агенти.
Так, кожен банк усе одно має надати доступ до свого сервісу. Моя інструкція не може давати дозвіл від імені банку. Протоколи для всього цього існують, їх просто потрібно з'єднати між собою, а агент має звітувати про результати, щоб я знав, що захищено, а що ще потребує уваги.
Ваш апетит до ризику може відрізнятися.
Я спокійно дозволю агенту здійснювати покупки на суму до кількох сотень доларів. Але якщо більше — хочу, щоб він уточнював у мене та залишав аудиторський слід про те, що відомий агент зробив певні речі.
Якщо ми матимемо:
- Дозволи споживачів (через наміри)
- Пов'язані з ідентичностями творців агентів та людей.
- Які можуть запитувати дозволи у компаній і банків
- І при цьому буде аудиторський слід для всього процесу
Тоді неавторизованих агентів більше не буде.
Звісно, проблема в тому, що «авторизований» часто означає «платний». Угода про доступ до даних між JPMorgan і Plaid вже включає тарифікацію, і знадобилося майже десятиліття, щоб дійти до фінального варіанту.
Ви думаєте, банки не вимагатимуть більшого від Meta?
Ми роками спрощували клієнтам натискання правильних кнопок. Тепер приходить їхній агент з інструкцією.
Нам потрібно зробити можливим підтвердження його повноважень і виконання роботи.
І це може означати, що банки зароблятимуть на цьому шляху.
Якщо вам сподобалося, я пишу на brainfood.xyz — загляньте :)





