Обеспечение соблюдения лимитов расходов агента в x402, AP2 и делегированном оформлении заказов

Цель

Сведения актуальны на 25 октября 2026 года. Обеспечить связь каждого платежа с разрешением пользователя, имеющим чёткие границы, в том числе для покупок без участия пользователя и повторных попыток. Перед реализацией этой предлагаемой процедуры заново проверьте область действия x402, схемы ограничений AP2 и выбранную редакцию ACP. Поля протоколов позволяют задавать меры контроля; применять их на деле должен независимый компонент.

Предварительные условия

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

Шаги

1. Установите лимит на одну транзакцию. Payment Mandate в AP2 определяет payment.amount_range. Делегированное разрешение ACP задаёт max_amount, валюту и срок действия. Для x402 перед подписанием сравнивайте объявленные платёжные требования с локальной политикой. Применяйте лимит к окончательной разрешаемой сумме, включая сборы, входящие в итоговую стоимость заказа.

2. Учитывайте накопленные расходы. В AP2 поле payment.budget вместе с payment.agent_recurrence требует, чтобы запрашиваемая сумма в совокупности с суммами предыдущих закрытых мандатов не превышала максимум; при одобрении сумма добавляется к накопленному итогу. Выполняйте проверку и резервирование атомарно в общем хранилище. Предлагаемое правило учёта: вычитайте суммы попыток с невыясненным результатом из доступного бюджета, пока их исход не будет установлен при сверке. Основная спецификация x402 исключает управление бюджетом на стороне клиента из своей области действия.

3. Ограничьте получателей и платёжные инструменты. AP2 предоставляет checkout.allowed_merchants, а также ограничения на получателя платежа и платёжный инструмент. ACP привязывает разрешение к продавцу и сессии оформления заказа. Для x402 ведите внешний список разрешённых источников ресурсов, получателей платежей, активов и сетей. Не считайте текстовое описание продавца подтверждением его личности.

4. Свяжите одобрение человека с конкретными условиями. Покажите покупателю получателя, товары, полную сумму, платёжный инструмент и срок действия. При предварительном делегировании вместо этого покажите допустимые пределы. Система авторизации AP2 требует проверки ограничений и считает неизвестные ограничения основанием для отказа. Ответ unresolved_constraint может инициировать непосредственное одобрение. Установите локальное правило: изменения, выходящие за одобренные рамки, требуют повторного одобрения, даже если платёжные реквизиты технически ещё пригодны к использованию.

5. Связывайте подтверждения, не раскрывая платёжные реквизиты. Записывайте ссылки на одобрения и мандаты, решение по политике, зарезервированную сумму, идентификатор сессии оформления заказа или ресурса, идентификатор платежа и окончательный результат. Payment Receipts в AP2 ссылаются на закрытый мандат и содержат статус платежа. Храните конфиденциальные подписанные удостоверения в хранилище подтверждений с ограниченным доступом; обычные журналы аудита должны содержать ссылки, а не данные, позволяющие повторно провести платёж. Отдельно сверяйте результаты платежа и доставки.

6. Отработайте отказы до запуска. В непроизводственной среде проверьте одобрение с истёкшим сроком, запрещённого продавца, изменённую валюту, сумму выше лимита, одновременные покупки и прерывание получения ответа. Убедитесь, что отклонённые попытки не создают новых разрешений, а попытки с невыясненным результатом не восстанавливают незаметно доступный бюджет. Это предлагаемые приёмочные проверки, а не заявленные результаты тестирования.

Ожидаемый результат

У каждой разрешённой попытки есть прослеживаемое одобрение, резерв бюджета и окончательный результат, установленный при сверке. Причины отклонения запросов остаются понятными, при этом модель не получает права отменять решение. Проверяющий может различить запрошенные, разрешённые и завершённые расходы.

Ограничения и основание проверки

Эта процедура не проверялась на платёжных провайдерах. Для общего бюджета по нескольким провайдерам нужен совместный учёт, выходящий за рамки отдельных объектов протокола. В таблице диапазона сумм AP2 указаны целые числа в минимальных денежных единицах, тогда как один из примеров использует десятичные дроби; прежде чем принимать суммы, устраните это противоречие в контракте реализации. Здесь не предполагается никакого преобразования. Подписанные квитанции фиксируют результаты протокольных операций, но не доказывают физическую доставку.