ИИ-агент потратил ваши деньги. Кто докажет, что вы это разрешили?

Вы даёте задание ИИ-агенту: «Найди футболку дешевле $30, но не покупай». Агент находит — и оформляет заказ. Вы оспариваете списание. Продавец показывает, что заказ сделан с вашего аккаунта. Разработчик агента — что вы дали инструкцию не покупать. Платёжная система — что платёж прошёл. Каждая запись может быть точной. Но ни одна из них не связывает платёж с заданием, которое вы дали агенту. Обычный чат-бот предлагает футболку и ждёт. Агент же может использовать ваш аккаунт, связываться с другими сервисами и завершать транзакцию. Одно предложение запускает цепочку действий в системах разных компаний. Каждая компания видит только свою часть. Чтобы урегулировать спор, нужен ответ, охватывающий все три системы: совершил ли этот агент, действуя от вашего имени, это действие в рамках вашего задания?

В Сенате США уже увидели проблему. Сенатор Марк Уорнер (демократ, Вирджиния) внёс законопроект AI AGENT Act (S. 5051) 21 июля 2026 года. Он определяет «подотчётного пользовательского агента» как агента, уполномоченного действовать от имени пользователя в прозрачной, документируемой, ограниченной и отзываемой форме. Законопроект требует от таких агентов вести записи о действиях в реальном времени и поручает NIST разработать стандарты для верификации того, что пользователь делегировал полномочия агенту, и для ведения аудируемых записей. Но законопроект не требует создания верифицируемой цепочки доказательств, которая связывает все системы: от инициирования задачи до конечного результата. В случае с футболкой такая цепочка должна была бы связать инструкцию пользователя, действия агента и записи продавца и платёжной системы.

Продавец может опознать поставщика ИИ-агента, но не конкретного агента. Платёжная система может маркировать того же клиента по-другому. Сопоставить пользователя, поставщика и конкретного агента по этим записям — сложно. А даже если сопоставить, нужны доказательства, что пользователь уполномочил агента именно на это действие. В технических системах есть механизмы делегирования полномочий — например, OAuth. Но токен, полученный неделями ранее, всё ещё может давать право на оплату сегодня, даже если текущая инструкция запрещает покупку. Продавец видит действующий токен и проводит транзакцию. Ограничение «не покупать» остаётся внутри системы поставщика агента.

Чтобы такая подотчётность работала, нужно пять элементов: верифицируемая привязка между аккаунтом пользователя, агентом в конкретный момент времени и заданием; ограничения, специфичные для этого задания; верифицируемая связь между транзакциями; проверка перед каждым действием; и записи, изменения в которых можно обнаружить. Платёжные системы уже собирают эти элементы.

Первая запись идентифицирует учётную запись пользователя, утвердившую задание, и агента, получившего полномочия. Поставщик агента привязывает аккаунт, агента и задание в записи об авторизации и цифровой подписью заверяет её. Продавец и платёжная система могут проверить, кто её выпустил и была ли она изменена. Затем поставщик преобразует запрос пользователя в ограничения, которые могут выполнять другие системы: «искать 15 минут, не покупать, не передавать платёжные полномочия другому агенту». Перед началом работы пользователь видит и утверждает эту структурированную версию. Для связи между системами можно использовать уникальный идентификатор задачи, который сопровождает каждый запрос и появляется в записях каждой компании. Похожий механизм уже используется в распределённых системах.

На этапе оплаты продавец проверяет подписанную запись авторизации и сравнивает предлагаемую покупку с разрешёнными действиями. Если покупка запрещена — транзакция блокируется. После решения система продавца записывает агента, идентификатор задачи, проверенное правило, время, решение и результат. Поставщик хранит инструкцию и утверждённое правило. Каждая компания ведёт защищённую от изменений запись. Пользователь получает чёткий отчёт: «Ваш агент нашёл три магазина и попытался оформить заказ. Покупка была заблокирована, так как покупка не была разрешена».

Протокол Google Agent Payments Protocol (AP2) соответствует некоторым из этих требований. Он создаёт записи, которые могут показать утверждённые пользователем ограничения и информацию, представленную каждому участнику. Но AP2 не решает, кто несёт потери, и не определяет, как долго каждая компания должна хранить записи и как их можно получить. NIST в феврале 2026 года опубликовала концептуальный документ об идентичности агентов и разрешениях. Сейчас он рассматривает комментарии. Однако первоначальный подход NIST охватывает агентов, действующих внутри организаций, где возможен больший контроль. Агенты, приходящие извне, исключены из этой инициативы. Случай с потребительскими агентами, пересекающими границы компаний, — это именно тот случай, который NIST отложила. Каждая компания использует свои идентификаторы, свой язык авторизации и правила хранения. Спор может остаться неразрешённым, даже если каждая компания предоставит свои записи точно в том виде, в каком они хранятся.

Спор о футболке за $30 можно уладить легко. Но те же проблемы возникнут, когда агент переведёт $40 000, подаст апелляцию о пособии или запросит повторный рецепт на лекарства от вашего имени. В этих спорах будет легко доказать, что агенту разрешили доступ к сервису. Совсем другое дело — доказать, разрешали ли вы агенту сделать то, что он сделал от вашего имени.

Итог: ИИ-агенты уже могут тратить ваши деньги, а доказать, разрешали вы это или нет, почти невозможно. Законодательство делает первые шаги, но техническая инфраструктура для верификации ещё не готова. Спор из-за футболки за $30 — только начало. Когда агенты начнут переводить крупные суммы, подавать заявления и управлять медицинскими записями, вопрос «кто дал разрешение?» станет критическим. Пока что ответа на него нет.