Diseña límites de gasto para agentes que el modelo no puede esquivar

Cuando un agente solicita comprar una API de pago, el presupuesto debe verificarse antes de que se firme la transacción. Los agentes construidos sobre Amazon Bedrock pueden localizar por sí mismos APIs de pago, servidores MCP y contenido web, y pagar esos servicios en USDC. AWS anunció que AgentCore Payments alcanzó disponibilidad general el 18 de agosto. El problema de diseño es dónde reside el límite cuando el modelo se pasa de la raya.

Los pagos de agentes son una responsabilidad del producto. Un agente que puede comprar datos, llamar a una API de pago o reservar un servicio es tan fiable como su control de gasto. Una frase en el prompt es una barrera débil: el modelo puede ser persuadido, distraído o simplemente equivocado. Los usuarios no son ingenieros de seguridad, y no deberían tener que auditar cada transacción para mantener el producto seguro.

El prompt es una política, no una bóveda

Los prompts de sistema son útiles para definir intención, tono y límites de la tarea. No son fiables para acciones financieras irreversibles. Un prompt puede ser largo, y la línea de presupuesto puede olvidarse. Se puede pedir a un modelo que se mantenga dentro de un presupuesto, pero la solicitud puede quedar enterrada bajo una conversación larga o una petición posterior del usuario. El modo de fallo suele ser un error plausible: el agente cree que la llamada adicional es necesaria, o el usuario pide una excepción, y el modelo accede. Los usuarios no van a leer el prompt.

La objeción más fuerte es que los límites matan la autonomía

Los equipos de producto suelen temer que los límites estrictos hagan que los agentes parezcan torpes. Un usuario solicita una tarea de investigación y el agente necesita comprar varias entradas pequeñas. Un límite demasiado bajo hace que la tarea falle. Un límite demasiado alto expone el producto. Un límite es una decisión de producto: legible, acotada y recuperable.

Un presupuesto acotado es más seguro que un permiso permanente que sobrevive al final de la tarea. La idea de caducidad importa porque las tareas de los agentes pueden desviarse. AgentCore Payments verifica las solicitudes de pago contra el presupuesto de la sesión y rechaza las solicitudes que superan el presupuesto antes de firmar, usando una verificación determinista a nivel de infraestructura. El modelo puede proponer un pago, pero la infraestructura decide si la propuesta está permitida.

El rediseño es una regla de ubicación

Para cada acción de alto riesgo de un agente, define el límite, el propietario y el punto de aplicación; coloca los límites irreversibles en la capa de pago, sesión o infraestructura, no en el prompt de sistema. Una verificación determinista es más fácil de explicar que la promesa de un modelo.

• Límite: las sesiones de pago de AgentCore Payments incluyen un importe máximo de gasto en una moneda elegida y un tiempo de caducidad. Muéstralo antes de que el agente actúe.
• Propietario: el usuario final o una política de producto, con una vía clara para elevar o revocar el límite.
• Punto de aplicación: la capa de pago, la cartera o el control de infraestructura que verifica la solicitud antes de firmar.

Los usuarios finales pueden financiar la cartera de un agente con tarjetas de crédito o la stablecoin USDC y deben delegar la autoridad de gasto en el agente. Esa delegación es el evento de confianza. El producto debe hacerlo visible: qué puede comprar el agente, cuánto puede gastar y cuánto dura la autoridad. Un límite visible es una función de confianza. Una cartera por sí sola no crea permiso. Una sesión delegada, con límite y con caducidad, sí.

Más rutas de pago requieren más límites

AgentCore Payments se conecta a las carteras de Coinbase y Stripe Privy para que los desarrolladores puedan configurar las capacidades de pago de los agentes. AgentCore Payments añadió soporte para el Machine Payment Protocol en su disponibilidad general, un estándar de pago entre máquinas coautorizado por Stripe y Tempo. Cada nueva ruta añade un punto donde un límite puede pasarse por alto.

Antes del lanzamiento, pregúntate qué pasa cuando el modelo solicita más de lo que el usuario pretendía. Si la respuesta es que el modelo se dará cuenta, el producto no está listo. Si la sesión lo rechaza y el usuario ve por qué, el producto tiene un control que puede mostrarse a los usuarios.