Aplicación de límites de gasto a agentes con x402, AP2 y procesos de compra delegados

Objetivo

Estado a 25 de octubre de 2026. Permitir que cada pago se vincule a una autorización del usuario con límites definidos, incluidas las compras sin supervisión y los reintentos. Volver a comprobar el alcance de x402, los esquemas de restricciones de AP2 y la versión fechada de ACP elegida antes de implementar este procedimiento propuesto. Los campos de los protocolos permiten expresar controles; un componente independiente debe encargarse de aplicarlos efectivamente.

Requisitos previos

Utilizar una pasarela de pagos o un componente de firma que aplique la política fuera del modelo, un registro persistente de autorizaciones, interfaces de aprobación autenticadas y acceso a los registros del estado de los pagos. Definir quién se responsabiliza de las transacciones sin resolver. Registrar la revisión del protocolo, la moneda o el activo, la representación del importe, los destinos permitidos y el vencimiento de cada autorización antes de permitir gastos.

Pasos

1. Establecer un tope por transacción. El Mandato de Pago de AP2 define payment.amount_range. La autorización de uso delegada de ACP proporciona max_amount, la moneda y el vencimiento. En x402, comparar los requisitos de pago anunciados con la política local antes de firmar. Aplicar el tope al importe final autorizado, incluidos los cargos que formen parte del total de la compra.

2. Contabilizar el gasto acumulado. payment.budget de AP2, utilizado junto con payment.agent_recurrence, exige que el importe solicitado más los importes de los mandatos cerrados anteriores no supere el máximo; la aprobación añade el importe al total acumulado. Implementar la comprobación y la reserva de forma atómica en un almacenamiento compartido. Como regla contable propuesta, mantener los intentos sin resolver descontados del presupuesto disponible hasta conciliar su resultado. La especificación principal de x402 excluye la gestión del presupuesto del lado del cliente.

3. Restringir los destinos y los instrumentos. AP2 proporciona checkout.allowed_merchants, además de restricciones sobre el beneficiario del pago y el instrumento. ACP vincula su autorización de uso a un comerciante y a una sesión de compra. En x402, mantener una lista externa de permitidos que abarque el origen del recurso, el destinatario del pago, el activo y la red. No considerar el texto descriptivo de un comerciante como una identidad verificada.

4. Vincular la aprobación humana a condiciones concretas. Mostrar al comprador el destino, los artículos, el importe completo, el instrumento de pago y el vencimiento. Para una delegación previa, mostrar en su lugar los límites permitidos. El marco de autorización de AP2 exige evaluar las restricciones y considera que las restricciones desconocidas son fallos. Su respuesta unresolved_constraint puede activar la aprobación directa. Establecer como política local que los cambios fuera del alcance aprobado exijan una nueva aprobación, aunque una credencial de pago siga siendo técnicamente utilizable.

5. Vincular las evidencias sin filtrar credenciales. Registrar las referencias a aprobaciones y mandatos, la decisión de la política, el importe reservado, el identificador de la compra o del recurso, el identificador del pago y el resultado final. Los recibos de Pago de AP2 enlazan con el mandato cerrado e incluyen el estado del pago. Conservar las credenciales firmadas sensibles en un almacén de evidencias de acceso restringido; los registros de auditoría habituales deben contener referencias en lugar de datos de pago reutilizables. Conciliar por separado el pago y la entrega.

6. Probar los casos de rechazo antes de la puesta en marcha. En un entorno ajeno a producción, probar una aprobación vencida, un comerciante no permitido, un cambio de moneda, un importe superior al tope, compras simultáneas y una respuesta interrumpida. Verificar que los intentos rechazados no crean una autorización nueva y que los intentos sin resolver no restablecen de forma inadvertida la capacidad de gasto. Estas son comprobaciones de aceptación propuestas, no resultados de pruebas realizadas.

Resultado esperado

Cada intento permitido tiene una aprobación rastreable, una reserva de presupuesto y, finalmente, un resultado conciliado. Los rechazos de solicitudes siguen siendo explicables sin dar al modelo autoridad para revocar la decisión. Quien revise los registros puede distinguir entre gasto solicitado, autorizado y completado.

Límites y base de verificación

Este procedimiento no se ha probado con proveedores de pagos. Los presupuestos que abarcan varios proveedores necesitan una contabilidad compartida más allá de los objetos individuales de cada protocolo. La tabla de intervalos de importes de AP2 especifica unidades monetarias menores enteras, mientras que uno de los ejemplos utiliza decimales; resolver esa incoherencia mediante el contrato de implementación antes de aceptar importes. Aquí no se presupone ninguna conversión. Los recibos firmados documentan resultados del protocolo; no demuestran la entrega física.