Почему сохранённые учётные данные — неправильный примитив
Карта на файле — это предъявительский инструмент. Тот, у кого есть номер, может тратить по нему, многократно, пока эмитент или продавец не решит иначе. Никакой системный промпт, никакая инструкция на уровне инструмента и никакое количество рассуждений по цепочке мыслей не меняют это свойство. Агент, которому передали сохранённую карту, не имеет бюджета; он имеет возможность. Различие важно, потому что возможности не ограничены намерением. Они ограничены криптографией, точками применения политик и готовностью эмитента отклонить платёж.
Как только агент владеет многоразовыми учётными данными, отзыв становится единственным оставшимся контролем. Отзыв груб. Он не может отличить законную повторную попытку от дублирующего списания, санкционированного продавца от подменённого или одну крупную покупку от двадцати мелких. Он также медленный относительно выполнения агентом. Цикл отзыва, измеряемый минутами, не управляет циклом, который выдаёт вызовы за миллисекунды.
Ограниченные токены на траты с единой целью
Альтернатива — выпустить учётные данные, которые сами являются политикой. Ограниченный токен на траты — это подписанный артефакт с небольшим, явным набором утверждений:
{
"issuer": "studio-payments",
"subject": "agent-run-8f3a",
"task_id": "replenish-inventory-2026-04-11",
"merchant_category": "office_supplies",
"merchant_id": "supplier-4421",
"amount_ceiling_minor": 25000,
"currency": "EUR",
"not_before": "2026-04-11T09:00:00Z",
"not_after": "2026-04-11T09:15:00Z",
"max_uses": 1,
"nonce": "b7c1...",
"signature": "..."
}
Три свойства выполняют работу. Во-первых, токен привязан к конкретному идентификатору задачи, поэтому авторизующая траектория восстановима: трата отображается обратно на запуск, который её запросил, а не просто на учётную запись пользователя. Во-вторых, токен одноразовый или короткоживущий, поэтому утёкший артефакт имеет ограниченную ценность. Украденный номер карты — это обязательство, пока эмитент не примет меры; украденный одноразовый токен с пятнадцатиминутным окном и привязкой к продавцу — мёртвая строка к тому времени, как злоумышленник его перенаправит. В-третьих, потолок выражен в минорных единицах и применяется на рельсе, а не агентом. Агент не может поднять свой лимит, потому что лимит — это подписанное утверждение, а не переменная в промпте.
Компромисс реален: выпуск токена добавляет круговой обмен и зависимость от подписи до того, как может произойти любая покупка. Для низкостоимостных, высокочастотных вызовов эти накладные расходы нетривиальны, и они вынуждают службу выпуска быть настолько же доступной, как сам агент. Дизайн, который выпускает на каждый вызов, будет медленнее, чем тот, который выпускает на сессию; дизайн, который выпускает на сессию, возвращает повторное использование. Честный ответ — выпускать на задачу с коротким окном и низким потолком и принять, что задача, требующая многих покупок, нуждается во многих токенах.
Авторизация и расчёты
Решение тратить и механизм оплаты разделимы и должны быть разделены. Решение принадлежит политике: движок правил, который оценивает контекст задачи, продавца, сумму и историю против бюджета и выдаёт подписанную авторизацию или отказ. Механизм принадлежит рельсу: карточная сеть, перевод со счёта на счёт или слой расчётов в стейблкоинах. Разделение этих частей означает, что политику можно проверять, версионировать и тестировать, не касаясь рельса, а рельс можно заменить, не переписывая политику.
Расчётные рельсы, поддерживающие программные микроплатежи, лучше подходят для машинно-машинных покупок, чем потребительские карточные потоки. Потребительские карточные потоки оптимизированы для разрешения споров и прав на возвратный платёж, которые ценны для людей и дороги для вызова на каждый вызов. Рельс, который рассчитывает детерминированно, с окончательностью, измеряемой секундами, и комиссиями, которые не доминируют над малыми суммами, лучше подходит для агента, покупающего один вызов API или небольшое приращение данных. Там, где используется карта, токен должен быть выпущенной сетью одноразовой виртуальной картой, а не сохранённым основным номером, чтобы потолок и привязка к продавцу применялись эмитентом.
Сверка должна быть автоматической. Человеческий обзор не масштабируется до покупок на каждый вызов, а очередь ожидающих списаний сводит на нет цель делегирования. Каждый токен должен нести идентификатор задачи и nonce, а запись расчёта рельса должна сопоставляться с записью авторизации по этим полям. Несоответствия — списание без соответствующей авторизации, авторизация без списания, списание вне окна — должны вызывать исключение, а не тикет.
Режимы отказа, против которых нужно проектировать
Разделённые покупки. Агент, который находит потолок, при разрешении разделит покупку на несколько списаний, каждое из которых остаётся под ним. Защита — кумулятивный бюджет на задачу, а не только потолок на списание: служба авторизации отслеживает общую трату против идентификатора задачи и отказывает в токене, который превысил бы намерение. Потолок на списание сам по себе — это предложение.
Подмена продавца. Токен, авторизованный для поставщика A, не должен рассчитываться у поставщика B. Привяжите токен к идентификатору продавца, а не только к категории, и проверяйте при расчёте. Блокировки категорий слабее блокировок продавцов и должны рассматриваться ка
Циклы повторных попыток. Потерянный ответ неотличим от неудачного запроса, если операция не идемпотентна. Дайте каждому токену nonce и требуйте от рельса отклонять второе расчётное списание с тем же nonce. Тогда повторная попытка агента возвращает исходный результат, а не списывает дважды. Это та же дисциплина, что и ключи идемпотентности в платёжных API, применённая к делегированным тратам.
Что это меняет
Ограниченные учётные данные на траты перемещают точку контроля с отзыва на выпуск. Вопрос перестаёт быть «как нам остановить агента» и становится «что именно мы авторизовали, для какой задачи, у какого продавца, до какого времени». Это вопрос, на который может ответить аудит. Сохранённая карта не может.
FAQ
В: Ограниченный токен — это просто виртуальная карта? О: Его можно реализовать как таковую, но важное свойство — подписанный набор утверждений — идентификатор задачи, привязка к продавцу, потолок, срок действия, nonce — а не формат карты.
В: Что мешает агенту запросить новый токен, когда он достигает потолка? О: Служба авторизации, а не агент. Кумулятивный бюджет на задачу и на продавца применяется при выпуске, поэтому повторные запросы против той же задачи отклоняются.
В: Как это взаимодействует с расчётами в стейблкоинах? О: Токен — это полномочие; перевод стейблкоина — это рельс. Утверждения токена проверяются до подписания перевода, а ссылка перевода несёт nonce для сверки.
В: Какова основная стоимость? О: Задержка выпуска и служба выпуска, которая должна быть настолько же доступной, как агент. Выпуск на задачу с короткими окнами — обычный компромисс; выпуск на сессию возвращает повторное использование.