Когда API начинает выставлять счёт
AI-агент, который умеет обращаться к платным API, выглядит как следующий шаг автоматизации. Он может самостоятельно купить вычислительный ресурс, получить данные из закрытого датасета или оплатить доступ к инструменту другого сервиса. Но такая автономность меняет привычную модель риска.
Обычно компания опасается, что злоумышленник украдёт API-ключ и получит доступ к сервису. В платёжном сценарии проблема может быть тоньше: агент сам подписывает криптографическую транзакцию, а внешний сервер сообщает, сколько нужно заплатить. Если приложение без проверки принимает эти условия, сервер фактически получает влияние на финансовое решение.
Именно это показал разбор протокола x402 и его SDK. Протокол использует стандартный HTTP-ответ 402 Payment Required: сервер сообщает, что ресурс платный, клиент подписывает платёж и повторяет запрос с подтверждением. Механика рассчитана в том числе на программных клиентов и AI-агентов, которым не нужно каждый раз ждать ручного подтверждения.
Что обнаружили в x402
Исследовательская компания V12 сообщила о 25 уязвимостях в протоколе и SDK. Три из них были признаны критическими по характеру возможных последствий.
1. Агент мог потратить весь доступный баланс
В старых версиях автоматический клиент не имел обязательного ограничения суммы платежа. Если приложение не задавало собственную политику, оно могло принять платёжные условия, присланные API, и подписать транзакцию на всю доступную сумму поддерживаемого токена.
Практический сценарий прост: агент обращается к внешнему сервису, получает запрос на оплату, а вместо небольшой комиссии видит требование перевести весь баланс кошелька. Вредоносный или неправильно настроенный API при этом не обязан взламывать кошелёк — достаточно сформировать подходящий платёжный запрос.
2. Проверка платежа могла не означать перевод денег
В сценарии с Solana фасилитатор — сервис, который проверяет и отправляет транзакцию, — разбирал платёжную инструкцию, но не проверял её фактический тип. Инструкция ApproveChecked, разрешающая будущие траты, могла быть принята за TransferChecked, которая непосредственно переводит токены.
Это создавало риск ложного подтверждения: сервис мог считать платёж состоявшимся, хотя деньги фактически не были переведены. Для бизнеса последствия очевидны — поставщик открывает доступ к ресурсу, не получив оплату.
3. Подпись могла относиться к другому домену
Ещё одна проблема касалась авторизации. Агент мог подписать сообщение для входа, предназначенное не для того домена, с которым он должен был взаимодействовать. В результате платёжный клиент превращался не только в финансовый инструмент, но и в потенциальный механизм захвата пользовательской сессии.
Это важное напоминание: подпись — не доказательство безопасности сама по себе. Нужно проверять, что именно подписывается, кто указан получателем и к какому домену относится запрос.
Исправление SDK — только первый слой защиты
Разработчики получили информацию об уязвимостях в августе 2026 года. По данным исследователей, три критические проблемы исправили к 20 августа, а публичный разбор появился 22 октября. Исправления вышли для TypeScript, Python и Go.
В обновлённых версиях появились ограничения по умолчанию: отдельный платёж ограничивается суммой в один доллар, а разрешёнными считаются только распознаваемые долларовые стейблкоины, включая USDC. Также добавлены механизмы контроля суммы и список допустимых активов.
Но обновление пакета не решает задачу полностью. Во-первых, компания может использовать устаревшую версию в одной из языковых экосистем. Во-вторых, стандартный лимит SDK не учитывает бизнес-контекст: для одного запроса доллар слишком много, для другого — слишком мало. В-третьих, даже безопасный платёжный модуль не знает, какие адреса, сети и сервисы разрешены именно вашей компании.
Какая политика нужна агенту с кошельком
Лимит на операцию и на период
Минимальная настройка — ограничить не только один платёж, но и общие расходы за час, день или другой расчётный период. Агент, которому разрешено совершать тысячу мелких операций, тоже может создать значительный счёт.
Например, агенту для тестовой среды можно разрешить не более 50 долларов в день и не более 2 долларов на один вызов. Для производственного сценария лимит должен зависеть от конкретной задачи, а превышение — переводить запрос на ручное подтверждение.
Списки разрешений
Недостаточно разрешить «оплату в стейблкоинах». Лучше заранее определить:
- допустимые токены и сети;
- адреса получателей;
- конкретные домены и URI;
- список API, которым разрешено выставлять счета.
Любое изменение этих параметров должно быть отдельным событием, а не следствием ответа внешнего сервера.
Проверка домена перед авторизацией
Перед подписью агент должен сверять домен, назначение сообщения, идентификатор запроса и адрес получателя. Если сервис просит подписать данные для другого домена, операция должна завершаться ошибкой, а не передаваться на усмотрение модели.
Раздельные кошельки и участие человека
Для экспериментов нужен отдельный кошелёк с ограниченным балансом. Производственные средства нельзя смешивать с тестовыми ключами и агентскими прототипами.
Крупные, редкие или нетипичные платежи должны требовать подтверждения человека. Это не отменяет автоматизацию: большую часть мелких операций агент может проводить сам, а исключения передавать оператору с понятным объяснением — кому, сколько и за что отправляются деньги.
Уязвимость — не доказательство атаки
Публичные материалы описывают исследовательские сценарии и исправленные дефекты. Данных о том, что эти уязвимости использовались злоумышленниками в реальных сетях, нет. Поэтому корректно говорить о потенциальной возможности потери средств или ложного подтверждения платежа, а не о подтверждённой краже.
Главный урок x402 шире конкретного протокола. AI-агент с кошельком — это не просто цифровой сотрудник, которому добавили ещё один инструмент. Это программный субъект с правом принимать финансовые решения. Если компания не определила границы этого права, их может определить внешний API — вместе с суммой списания, активом и адресом получателя.
