Агентные платежи под управлением человеческих правил

Агентные платежи — это платежи, которые инициирует программа, а не человек на странице оплаты. ИИ-агент владеет учётными данными, сам решает, что нужно совершить покупку, и сам проводит платёж: оплачивает счёт, продлевает подписку, бронирует чартер, и никто не нажимает последнюю кнопку. Главное здесь — инициатор. Если человек нажимает «купить» — это обычный карточный платёж с чат-ботом впереди; агентный платёж — это когда решение, авторизацию и расчёт в момент движения денег берёт на себя программа. Всё сложное в этой категории вытекает из одного свойства: тратит не человек, а значит, нет ни усталости, ни подозрительности, ни тревоги, которые остановили бы человека перед переводом денег незнакомцу.

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

Сценарий сбоя очевиден, и в этом суть

Дайте агенту действующий платёжный токен без лимитов — и вы получите инцидент с мошенническим переводом, который просто ещё не случился. Ничего экзотического в том, как это происходит, нет. Prompt injection на веб-странице велит агенту заплатить злоумышленнику. Кривое описание инструмента направляет законную покупку не тому получателю. Цикл повторных попыток тысячу раз проводит один и тот же платёж, потому что сигнал об успехе так и не вернулся. Для этого не нужен хитрый противник — это обычные баги автономного ПО, только на выходе деньги уходят с вашего счёта.

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

Продукт — это политика, а не промпт

Модель сдерживания — это политика, которую платформа применяет до движения денег, а не после того, как агент уже принял решение. У каждого агента есть лимит на транзакцию и дневной лимит — в нашей демо-политике €150.00 на платёж и €500.00 в день, — а сверх них месячный потолок €6,000.00. Это жёсткие границы, которые проверяет платформа, а не обещания, которые даёт агент. Когда демо-бот для путешествий попытался зафрахтовать чартер за €640.00, платёж был отклонён сразу: превышение лимита, ни цента не списано. Даже агент, безупречно работающий каждый день, не может выйти за рамки месяца.

Бюджет определяет «сколько», белый список — «куда». Агенты платят только тем продавцам, которых вы назвали заранее. Демо-агент Ops Agent знает ровно четырёх, а попытка заплатить €180.00 нелистингованному поставщику была отклонена как not-listed. Вместе они очерчивают рамки: столько денег и только этим получателям. Внутри рамок агент работает на полной скорости и ни о чём не спрашивает; сами рамки — то, чем владеет человек.

Вопрос не в том, будет ли ИИ-агент тратить деньги. А в том, кто написал правила, по которым он тратит, и ответом всегда должен быть человек — заранее и письменно.

Человек над чертой

Некоторые решения слишком крупные, чтобы оставлять их рамкам. Поэтому в политике есть порог: сумма, выше которой платёж проходит только после одобрения человеком. В демо эта черта — €100.00. Когда Ops Agent отметил счёт №088 от Nord Logistics — €120.00, что вполне укладывается в дневной бюджет €500.00, но выше порога одобрения, — он не стал платить. Он приостановился, показал предложение человеку и стал ждать. Ответ в одну строку снял блокировку; платёж прошёл с референсом 9F21-0716 и попал в журнал аудита в 09:41. Ниже черты агент действует сам; выше — сначала отвечает человек.

Одобрение — это не флажок, который исчезает без следа. Фиксируется, кто одобрил, с какого устройства и когда, с приложенной подписью: одобрено в приложении, ключ телефона, 09:41:12. Когда позже спросят, почему платёж состоялся, ответом будет конкретный человек и отметка времени, а не пожатие плечами.

Аварийный выключатель и журнал, который нельзя незаметно править

Даже внутри хороших границ агенты ведут себя неправильно, а политики оказываются ошибочными. С этим справляются два механизма. Первый — аварийный выключатель (kill-switch): одно нажатие приостанавливает агента и мгновенно блокирует все платежи, которые он мог бы инициировать. Ключи остаются действительными, так что ничего другого не ломается: агент просто не может тратить, пока человек его не включит, а отложенные предложения замирают на месте, а не исчезают. В демо-флоте бот для путешествий стоит на паузе с €0.00 потрачено, очередь цела.

Второй — журнал аудита только на добавление (append-only). Каждое решение остаётся в записи: что пыталось сделать агент, какая проверка политики пройдена или провалена, кто что одобрил, вплоть до ротации ключей. Одна запись позволяет восстановить весь платёж: решение DEC-4471 содержит запрос, каждую проверку политики с результатом (белый список — пройдена, лимит — пройдена, порог — эскалация), подпись человека и проведённую сумму с каналом и референсом. В каждой записи есть собственный хеш, хеш предыдущей записи и позиция в цепочке (в демо — №4,471), поэтому правка любого поля ломает все последующие записи. Журнал экспортируется в JSON вместе с хешем: его можно передать аудитору, он принадлежит вам, а не нам.

Расчёты — скучными, новизну — в авторизацию

Есть соблазн сделать агентские платежи новыми целиком: новый рельс, новый инструмент, новый способ передвижения денег. Не поддавайтесь. По-настоящему нова только авторизация: как агент доказывает, что ему разрешено платить, по чьей политике и с каким одобрением. Пройдя этот барьер, платёж должен проводиться по рельсам, которые годами остаются скучными. В демо одобренный платёж на €120.00 превращается в обычный кредитовый перевод SEPA — проводится через SEPA Instant спустя минуты после одобрения — и ниже по цепочке неотличим от платежа, который сделал человек. Банк не знает и не интересуется, что его инициировал агент.

Это разделение намеренное. Скучные рельсы предсказуемы, допускают возврат там, где это позволяет схема, и понятны любой казначейской службе и любому аудитору, с которыми вам придётся иметь дело. Когда новизна заключена в политике, а платёж идёт по отработанному рельсу, рискованная и быстро меняющаяся часть оказывается полностью под вашим контролем, а часть, затрагивающая чужие банки, — той, которую никому не нужно переучивать. Агенты тратят деньги из того же ядра, на котором работает всё остальное семейство платежей (описано на /products/pay), а не из параллельной вселенной, построенной для роботов.

Ландшафт протоколов ещё не устоялся — стройте с расчётом на это

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

На практике это означает небольшую и скучную поверхность интеграции. Агенты подключаются по MCP на mcp.protocore.io/agents; кошелёк может держать любой фреймворк, говорящий на этом протоколе. Интерфейс намеренно узкий — предложить платёж, получить решение, — потому что вся интересная логика живёт на платформе, а не в промпте. Когда отрасль определится, как агентам подтверждать себя перед торговцами, изменится фасад, а стены за ним останутся там же, где были.

Где это находится

Агентские платежи — не ставка на то, что автономное ПО должно тратить без ограничений. Скорее наоборот: ставка на то, что ПО будет тратить, а значит, ограничения должны быть реальными, внешними и понятными. Бюджеты и белые списки очерчивают рамки, порог направляет крупные решения к человеку, аварийный выключатель останавливает всё, а журнал только на добавление позволяет восстановить любой платёж позже. Страница продукта /products/agents проводит через весь цикл на тех же демо-данных: создать агента, задать политику, увидеть, как платёж эскалируется и проводится, а /products/pay — это ядро, на котором эти платежи работают. Автономность настоящая, как и поводок, и держит его человек.