Los agentes toman cada vez más acciones en nombre de sus usuarios finales, ya sea seleccionando herramientas, navegando por la web y llamando a servidores MCP de forma autónoma para lograr un objetivo. Cuando se pagan las herramientas, los puntos finales de MCP o los recursos web a los que accede un agente, el agente se queda atascado sin la capacidad de realizar transacciones. Los pagos de Amazon Bedrock AgentCore, anunciados en una vista previa en asociación con Coinbase y Stripe (Privy), brindan a los agentes la posibilidad de acceder a recursos pagos en nombre del usuario final para completar la tarea.
Poner dinero real detrás de un sistema autónomo plantea una nueva serie de riesgos. Provienen de agentes que actúan de forma autónoma durante largas sesiones, un modelo no determinista y una superficie de exposición más amplia entre el código del agente y los fondos del usuario final. En esta publicación, analizamos esos riesgos y las barreras que los pagos de AgentCore combinan para abordar cada uno de ellos.
Los pagos AgentCore están disponibles en versión preliminar en EE. UU. Este (Norte de Virginia), EE. UU. Oeste (Oregón), Europa (Frankfurt) y Asia Pacífico (Sídney). Las funciones y API pueden cambiar antes de la disponibilidad general.
A lo largo de esta publicación, utilizamos estos términos:
Usuario final: el ser humano cuyo dinero se gasta y en cuyo nombre realiza la transacción el agente. Desarrollador: el cliente de AWS que integra capacidades de pago en sus agentes de IA. Proveedor de billetera: Coinbase Developer Platform (CDP) o Stripe Privy. Cartera integrada: una cartera con custodia propia, alojada por el proveedor de la cartera, que pertenece al usuario final. Sesión de pago: un contexto de pago con alcance para la interacción de un solo agente, con un presupuesto y un tiempo de vida (TTL) configurables. Credenciales de desarrollador: claves de API, secretos y claves de autorización emitidas por el proveedor de billetera al desarrollador, utilizadas por los pagos de AgentCore para llamar a las API del proveedor de billetera.
En esta publicación, abordamos varios riesgos clave que surgen al diseñar un sistema de pago agente y cómo abordarlos con las capacidades de los pagos AgentCore.
El desafío: riesgos de seguridad en los pagos agentes
Varios riesgos clave determinan cómo debe diseñarse la capacidad de pagos para los agentes.
Gasto desbocado
Los agentes son autónomos y de larga duración. Toman decisiones en nombre de sus usuarios finales, a menudo muchas decisiones por sesión, y siguen funcionando sin ningún ser humano detrás del teclado. Sin barreras de seguridad explícitas, un agente mal informado o comprometido puede incurrir en un gasto desbocado.
Los modelos de lenguaje grande (LLM) tampoco son deterministas, por lo que no se puede garantizar que un modelo no malinterprete una respuesta como autorización para gastar o repita un pago debido a un reintento inesperado. Los límites de gasto deben definirse y aplicarse fuera del modelo, en la capa de infraestructura.
Falta de consentimiento y delegación del usuario final
El agente ahora puede realizar pagos de forma autónoma, pero el usuario final debe conservar el control final. El usuario final decide cuándo delegar la autoridad de gasto, cuándo recargar la billetera y cuándo retirar fondos. El agente debe operar con un permiso explícito y de alcance, no con una concesión general, y el usuario final puede revocar ese permiso cuando así lo desee.
Compromiso de claves de desarrollador y tokens de billetera
Un agente que realiza transacciones en nombre de un usuario final tiene dos tipos de material confidencial. Las primeras son las credenciales de desarrollador que los pagos de AgentCore utilizan para llamar a las API del proveedor de billetera (claves de API, secretos y claves de autorización). El segundo son las claves de billetera integradas del usuario final (que el proveedor de la billetera mantiene bajo su propia custodia). Ambos deben permanecer fuera del código de agente. Si esas credenciales se almacenan en línea en el código del agente o en variables de entorno, un agente comprometido las revela. El agente no debe manejar estas credenciales directamente y las credenciales que el sistema emite para pagos individuales deben ser de corta duración y estar vinculadas a una sesión específica.
Exposición del instrumento de pago del usuario final
El número de tarjeta del usuario final, el valor de verificación de la tarjeta (CVV) y otros detalles de pago personales nunca deben entrar en el contexto del agente. Un agente que tiene visibilidad de una tarjeta de crédito tiene una superficie de exposición mucho mayor que uno que no la tiene, y el alcance de los estándares de la Industria de Tarjetas de Pago (PCI) crece en consecuencia. La visión del agente debería detenerse en “un permiso para gastar desde una billetera propiedad del usuario” y no ir más allá.
Falta de auditabilidad
Cuando algo sale mal, como un cargo inesperado, un pago denegado o un equipo de seguridad o finanzas preguntando qué sucedió, debe haber un registro completo y confiable de lo que hizo el agente, en nombre de quién, contra qué límites y para qué comerciante. Ese registro debe producirse automáticamente. No basta con confiar en el código del agente para registrar sus propias acciones.
Uso de los servicios y controles de AgentCore para abordar estos riesgos
Los pagos de AgentCore se integran con el resto de Amazon Bedrock AgentCore para abordar estos desafíos.
La siguiente figura resume las barreras que los pagos de AgentCore imponen en cada transacción.
Figura 1: Barandillas integradas protegen todos los pagos de los agentes. Cada uno se aplica en la capa de infraestructura, fuera del código del agente.
Límites de pago y política de acceso a herramientas
Cada transacción se ejecuta dentro de una sesión de pago, un contexto de pago con alcance para la interacción de un único agente. Una sesión de pago tiene dos límites configurables: un monto máximo de gasto en una moneda específica y un tiempo de vencimiento. Antes de firmar un pago, los pagos de AgentCore verifican la solicitud con el presupuesto de la sesión. Los pagos de AgentCore rechazan solicitudes que llevarían la sesión más allá de su límite. Si la firma falla después de que el servicio ya se haya deducido del presupuesto, se revierte la deducción, por lo que una transacción fallida no consume presupuesto.
La verificación es determinista y se ejecuta en la capa de infraestructura. La inyección inmediata no puede levantar la tapa porque la tapa se aplica fuera del modelo. El desarrollador configura los límites que coinciden con la carga de trabajo y los pagos de AgentCore los aplican en cada llamada. Recomendamos comenzar con un presupuesto menor y aumentarlo a medida que el agente demuestre su valía en producción.
Para la autorización a nivel de herramienta, recomendamos exponer los puntos finales pagos a través de Amazon Bedrock AgentCore Gateway. Cada llamada a través de AgentCore Gateway es interceptada por Policy en AgentCore, un motor basado en Cedar que evalúa la solicitud, incluida la identidad del agente, el nombre de la herramienta y los parámetros, y decide si la permite. Los dos controles cubren decisiones diferentes. La política decide quién puede llamar a qué herramienta paga y con qué parámetros. Los pagos de AgentCore deciden cuánto puede gastar esa llamada y por cuánto tiempo. Juntos, brindan a los desarrolladores palancas ortogonales para el acceso a las herramientas y el monto del gasto.
Para obtener un tutorial sobre cómo crear una sesión de pago con configuración de presupuesto y TTL, consulte Creación de una sesión de pago en la guía para desarrolladores de Amazon Bedrock AgentCore. Para ver ejemplos de políticas de Cedar que limitan el acceso a las herramientas por función de agente y grupo de usuarios, consulte Política en AgentCore en la guía para desarrolladores.
Control de usuarios, financiación y delegación
El usuario final deposita fondos en la billetera primero y luego otorga explícitamente al agente permiso para gastar, en ese orden. La financiación es una acción fuera de banda. El usuario final lo completa dentro del portal del proveedor de la billetera (Coinbase WalletHub o la interfaz Stripe Privy), en un flujo en el que el agente no tiene API ni visibilidad. Incluso después de que los fondos hayan llegado, el agente no tiene permiso para realizar transacciones hasta que el usuario final delega explícitamente esa autoridad a través de la primitiva de permiso del proveedor de la billetera: Coinbase Spend Permissions o Privy Delegated Actions. Financiar la billetera y autorizar al agente son dos decisiones separadas, tomadas por el usuario final, dentro del portal del proveedor de la billetera.
Las billeteras en sí pertenecen al usuario final, ya sea una billetera integrada Coinbase Developer Platform (CDP) o una billetera integrada Stripe Privy. El usuario final tiene las llaves. AWS no lo hace y el desarrollador tampoco. El usuario final puede revocar la delegación a su discreción. Y como la billetera es suya, pueden retirar fondos a una dirección que controlen cuando lo deseen.
AgentCore Identity and Secrets Manager para almacenamiento de credenciales
AgentCore Identity maneja la seguridad en cuatro capas. Analizamos cada uno de ellos en las siguientes secciones.
1. Autenticación entrante con IAM o SigV4
Para el acceso entrante a los pagos de AgentCore, los desarrolladores configuran AWS Identity and Access Management (IAM) o SigV4. El patrón IAM de cuatro funciones que se incluye con el servicio separa el plano de control (las API que administran y configuran los pagos de AgentCore) del plano de datos (las API que ejecutan transacciones).
En el plano de control, ControlPlaneRole administra el servicio y ManagementRole configura los administradores de pagos y las sesiones. ManagementRole incluye un Deny explícito en ProcessPayment, por lo que las credenciales que utiliza un desarrollador para configurar pagos no pueden ejecutar transacciones.
En el plano de datos, ProcessPaymentRole ejecuta pagos y el propio servicio asume ResourceRetrievalRole para recuperar el estado de la sesión y las credenciales en tiempo de ejecución. Ninguna función por sí sola puede al mismo tiempo recaudar un presupuesto y gastar en su contra.
2. Credenciales de desarrollador para llamar a proveedores de billeteras
Cuando los pagos de AgentCore llaman a Coinbase Developer Platform o Stripe Privy en nombre de un usuario final, lo hacen con credenciales de desarrollador, como las claves API de Coinbase Developer Platform, las credenciales de la aplicación Stripe Privy y la clave de autorización de Privy. AgentCore Identity los almacena en su bóveda de tokens, cifrados en reposo y en tránsito con AWS Key Management Service (AWS KMS). La bóveda se integra de forma nativa con AWS Secrets Manager, por lo que los desarrolladores pueden administrar la rotación y la política de acceso a través de herramientas que su equipo de seguridad ya utiliza. El código del agente no maneja estas credenciales de desarrollador directamente.
3. Direcciones de billetera de usuario final guardadas en el proveedor de billetera
Aparte de las credenciales de desarrollador en la sección anterior, cada usuario final tiene una billetera integrada (una billetera Coinbase Developer Platform o una billetera Stripe Privy) con su propia dirección de billetera con autocustodia. Esa dirección de billetera y las claves que la controlan permanecen con el usuario final y el proveedor de la billetera, y ni AWS ni el desarrollador las conservan. Los pagos de AgentCore hacen referencia a la billetera por identificador, no por clave.
4. Tokens justo a tiempo para cada pago
Cuando los pagos de AgentCore necesitan ejecutar un pago, solicita a Identity un token de alcance a través de la API GetResourcePaymentToken. El token se emite en tiempo de ejecución, se vincula a la sesión de pago y se utiliza únicamente para esa operación. No existen canales de pago abiertos y duraderos. El tiempo de ejecución niega más transacciones después de que se agota el TTL o el presupuesto de la sesión, y el token utilizado para llamar a un proveedor de billetera solo existe mientras la operación lo necesita.
La recarga fuera de banda mantiene al agente alejado de datos confidenciales
Cuando el usuario final ingresa fondos en su billetera, ingresa su tarjeta de crédito, tarjeta de débito o datos bancarios dentro de la vía de acceso alojada del proveedor de la billetera, ya sea Coinbase WalletHub o la interfaz Stripe Privy. Estas superficies son operadas y tienen alcance PCI por parte del proveedor de la billetera. El agente no tiene API ni acceso a la UI. Los números de tarjeta, las fechas de vencimiento, los CVV o los detalles de la Cámara de Compensación Automatizada (ACH) no afectan el código del agente, el contexto del aviso del agente ni los servicios de AWS que opera el desarrollador.
Ese aislamiento es importante porque limita el radio de la explosión. Un agente que se ve comprometido mediante una inyección rápida, una respuesta de herramienta envenenada o un mal comportamiento del modelo no puede extraer un número de tarjeta de un sistema al que, en primer lugar, no tiene acceso. La carga de PCI recae en el proveedor de la billetera. Lo único con lo que opera el agente es un permiso revocable y con alcance para gastar moneda estable o fiat desde la billetera integrada del usuario final, e incluso ese permiso está limitado por los límites de sesión de la sección anterior.
Desde una perspectiva de cumplimiento, este diseño permite a los desarrolladores enviar flujos de pago agentes sin llevar sus propios sistemas al alcance de PCI. La superficie del agente y el alcance de cumplimiento del desarrollador son deliberadamente pequeños. AWS en sí no está en el flujo de fondos, ya que el dinero se mueve entre la billetera integrada del usuario final y el comerciante a través de la infraestructura del proveedor de la billetera.
Información integral con AgentCore Observability
Los pagos de AgentCore se integran con AgentCore Observability para brindar a los desarrolladores visibilidad del ciclo de vida de los pagos. El servicio emite automáticamente registros vendidos a su grupo de registros de Amazon CloudWatch y intervalos vendidos a AWS X-Ray para cada llamada a la API del plano de datos.
Cada invocación de ProcessPayment, ya sea que tenga éxito, alcance un límite de presupuesto o falle en la capa de billetera, se registra con suficiente detalle para diagnosticar el problema sin reproducirlo. Los desarrolladores pueden monitorear las tasas de éxito de las transacciones, rastrear los patrones de gasto entre los agentes y detectar errores a medida que ocurren.
Los seguimientos de pagos utilizan la misma infraestructura de observabilidad en la que los desarrolladores ya confían para el comportamiento de los agentes. La actividad de pago aparece junto con invocaciones de herramientas, llamadas de modelos y pasos de orquestación en una única línea de tiempo. Los equipos de operaciones pueden configurar alarmas de CloudWatch sobre las tasas de error o gastar velocidad para detectar anomalías de manera temprana.
AgentCore Observability incluye paneles prediseñados que muestran el estado de las transacciones de un extremo a otro entre agentes, sesiones y períodos de tiempo. Debido a que la telemetría de pago también fluye hacia CloudWatch y X-Ray, los desarrolladores pueden crear la suya propia. Un único panel de CloudWatch puede mostrar el gasto total por agente, las tasas de rechazo por motivo (presupuesto agotado, política denegada, credencial vencida) y percentiles de latencia de pago. Esto brinda a los equipos de finanzas, seguridad y cumplimiento la auditabilidad que necesitan sin crear una infraestructura de informes personalizada.
Conclusión
Con pagos AgentCore:
El agente no tiene acceso a los fondos ni a los instrumentos de pago del usuario final. IAM y SigV4 aplican la autorización en cada llamada entrante, mientras que el patrón de cuatro roles separa el plano de control (configuración de pagos) del plano de datos (ejecución de pagos) de modo que ningún rol pueda al mismo tiempo generar un presupuesto y gastar en él. Los límites de gasto por sesión y los TTL se aplican en la capa de infraestructura (de manera determinista, fuera del código del agente), por lo que la inyección rápida no puede eliminarlos. El usuario final conserva la custodia de su billetera integrada, delega el gasto según sus propios términos y puede revocar o retirar dinero en cualquier momento. Las credenciales de billetera residen en una bóveda de tokens cifrada con AWS KMS y llegan al agente solo como tokens de corta duración, con alcance de sesión, emitidos justo a tiempo. AgentCore Observability puede emitir automáticamente cada transacción a Amazon CloudWatch y AWS X-Ray, brindando a los equipos de seguridad y finanzas un seguimiento de auditoría completo. El dinero se mueve entre la billetera integrada del usuario final y el comerciante a través de la infraestructura del proveedor de la billetera, no de AWS.
Con estas barreras implementadas, los pagos agentes se convierten en una capacidad administrada que está limitada, auditable y lista para producción.
Para obtener más información, visite la página del producto Amazon Bedrock AgentCore y lea el anuncio de lanzamiento. Para obtener una inmersión técnica profunda en los patrones de comercio de agentes, consulte Análisis técnico profundo: Pagos AgentCore e innovación en el comercio de agentes.
Sobre los autores
Josué Smith
Joshua es arquitecto senior de soluciones en AWS y trabaja con clientes de FinTech. Le apasiona resolver desafíos de sistemas distribuidos de alta escala y ayudar a los clientes a crear soluciones seguras, confiables, rentables y basadas en inteligencia artificial, incluido el comercio agente. Tiene experiencia en seguridad e ingeniería de sistemas en nuevas empresas, grandes empresas y agencias federales.
Guy Bachar
Guy es arquitecto senior de soluciones en AWS y se asocia con empresas de servicios financieros para diseñar soluciones en la nube seguras y escalables. Se especializa en innovación impulsada por IA, transformación de la experiencia del cliente y arquitectura de identidad y seguridad para implementaciones a escala empresarial.