AWS anuncia tres funciones de gobernanza para Bedrock AgentCore: políticas temporales basadas en Dogwood (un lenguaje de policy open source para agentes IA), rate limiting en el gateway y visibilidad a través de CloudWatch.

Las políticas temporales son reglas con estado: evalúan la autorización de un agente según su historial de sesión, no solo la acción individual. Puedes forzar el orden de un workflow (primero recuperas datos, luego escribes), bloquear la fabricación de datos, establecer un límite a la exposición financiera y exigir aprobación humana para acciones de alto valor.

El rate limiting protege los destinos: defines límites de solicitudes, tokens y conexiones por usuario y por destino, con reglas basadas en identidad IAM o claims JWT. Si un agente entra en un bucle y comienza a llamar un modelo o herramienta sin parar, el gateway lo bloquea antes de que agote el presupuesto.

La visibilidad llega a través de CloudWatch: métricas sobre qué hace el agente, cuánto gasta, dónde se rompe.

Por qué te importa. Si estás llevando agentes a producción, el modelo ya sabe hacer la tarea. Lo que falta es evitar que haga lo incorrecto en el momento equivocado, y saber cuánto te cuesta antes de que lo descubras. Como contábamos ayer sobre el GA de AgentCore, el centro de gravedad se desplaza del chat al runtime. Estas tres funcionalidades son la gobernanza que hace ese runtime usable fuera de la demo.

El patrón es el mismo que Cloudflare describió hace tres días con su modelo zero-trust para agentes: credenciales temporales, gateway comportamental, límite de gasto. AWS cierra el mismo círculo en su stack.

En detalle

Lo que había antes.

Hasta ayer, controlar un agente en Bedrock significaba evaluar cada acción individual. Podías permitir o negar una llamada a una herramienta, pero no podías decir: «este agente puede llamar a la herramienta de escritura solo después de llamar a la de lectura». La autorización no tenía estado. El agente podía hacer los pasos en el orden incorrecto, repetir la misma acción infinitamente, acumular costo sin que ningún control lo detuviera a nivel de sesión.

Qué cambia con las políticas temporales.

Dogwood es un lenguaje de policy open source, creado para agentes IA. Las políticas temporales escritas en Dogwood mantienen un seguimiento del estado de la sesión: cada vez que el agente quiere hacer algo, la policy examina qué ha hecho hasta ahora y decide si la acción es permitida.

Los casos de uso declarados por AWS son cuatro:

• Secuenciación de workflows: el agente debe completar el paso A antes de poder ejecutar el paso B. Una regla determinística, no una sugerencia en el prompt.
• Prevención de fabricación: bloquea al agente si intenta producir datos sin haberlos recuperado antes de una fuente verificada.
• Límite financiero: establece un límite de gasto por sesión. Cuando el agente lo alcanza, no puede realizar más llamadas pagadas.
• Aprobación humana: para acciones de alto valor (una transferencia bancaria, una modificación en la base de datos de producción, el envío de un correo a una lista), la policy detiene al agente y espera la aprobación de una persona.

Qué cambia con el rate limiting.

El gateway de AgentCore está entre el agente y los modelos o herramientas que llama. Con el rate limiting, configuras límites por usuario y por destino: número máximo de solicitudes, tokens consumidos, conexiones simultáneas. Los límites están anclados a la identidad (IAM o claims JWT), así que puedes dar tarifas diferentes a usuarios o roles distintos.

El caso real: un agente tiene un bug, entra en un bucle y llama el mismo endpoint cien veces por segundo. Sin rate limiting, el downstream colapsa y la factura sube. Con rate limiting, el gateway limita las llamadas y el agente se detiene.

Qué cambia con CloudWatch.

Las métricas sobre comportamiento, costo y errores de los agentes llegan a CloudWatch. Para quien ya usa AWS, nada nuevo que aprender: las alarmas y dashboards que ya usas para el resto de la infraestructura cubren también los agentes.

Limitaciones de lo que se sabe ahora.

Los tres posts del blog de AWS son anuncios de producto con ejemplos de configuración, pero sin números sobre latencia u overhead de las políticas temporales. Dogwood es open source, pero es nuevo: el ecosistema de quiénes lo usan y lo prueban fuera de las demos aún está en formación. El rate limiting y las métricas CloudWatch son características estándar de gateway, así que la duda menor está ahí. La pregunta real es cuánta fricción añaden las políticas temporales en la ruta crítica del agente: cada acción pasa por un control con estado, y en volúmenes altos esto importa. AWS no publica benchmarks. Para quien evalúa, lo honesto es probarlo en tu propia carga antes de confiar en los tiempos.