
Amazon Web Services está añadiendo políticas temporales a Amazon Bedrock AgentCore, dando a los desarrolladores una forma de autorizar la acción actual de un agente de IA basándose en lo que hizo antes en la misma sesión. El control está diseñado para flujos de trabajo en los que una llamada individual a una herramienta puede parecer segura, pero se vuelve arriesgada por la secuencia que la precedió.
El cambio aborda una laguna en el control de acceso convencional. Los permisos tradicionales de las aplicaciones suelen evaluar las solicitudes de forma independiente, mientras que los agentes de IA eligen herramientas, argumentos y orden de ejecución en tiempo de ejecución. AWS afirma que su nuevo enfoque puede aplicar pasos obligatorios del flujo de trabajo, preservar la integridad de los datos entre llamadas a herramientas, limitar la exposición financiera acumulada y exigir aprobación humana antes de acciones sensibles.
AWS describe las políticas temporales como una extensión con estado de los controles de políticas existentes en Bedrock AgentCore. En lugar de preguntar solo si un principal puede llamar a una herramienta concreta, el motor de políticas puede inspeccionar la trayectoria reciente del agente y decidir si la solicitud actual está autorizada en ese contexto.
Por ejemplo, un agente podría usar una herramienta de consulta de clientes, recibir un número de cuenta y luego pasar un número diferente a una herramienta de transferencia de fondos. Ambas llamadas podrían satisfacer permisos sin estado. Una política temporal podría exigir que el argumento de la transferencia coincida con la salida anterior de la herramienta, bloqueando la solicitud si el agente alteró o inventó el valor.
Otros ejemplos del AWS Machine Learning Blog incluyen exigir una consulta de cartera antes de una operación, asegurar que una consulta de datos ocurrió lo suficientemente recientemente como para respaldar una decisión y detener una sesión cuando la exposición acumulada de negociación alcanza un límite definido. AWS también describe controles para impedir acciones contradictorias, como que un agente apruebe y deniegue la misma reclamación de seguro en rápida sucesión.
La función forma parte de Amazon Bedrock AgentCore, el conjunto de servicios de AWS para crear y operar agentes de IA. Su punto de aplicación es AgentCore Gateway, que enruta el tráfico compatible entre modelo, herramienta y agente-a-agente a través de un punto de acceso central.
Una solicitud evaluada por una política temporal lleva el encabezado x-amzn-bedrock-agentcore-policy-session-id. Ese identificador conecta la solicitud con una trayectoria que contiene acciones, entradas y salidas previas relevantes. Los equipos de aplicación deciden si una sesión representa una conversación, una tarea de varios pasos o un flujo de trabajo de más larga duración.
AWS recomienda mantener las sesiones relativamente acotadas porque solo puede haber una solicitud de autorización activa por sesión a la vez. El servicio combina el identificador de sesión con la identidad del usuario final, de modo que dos usuarios que presenten el mismo identificador siguen siendo evaluados frente a trayectorias separadas. AWS indica que la ventana de retrospectiva está limitada a 24 horas, tras las cuales los eventos más antiguos se eliminan automáticamente.
Las políticas temporales se ejecutan en el gateway y no dentro del propio código del agente. Esa arquitectura es importante: un agente no puede reescribir la lógica de la política ni manipular directamente el estado usado para la autorización. AWS afirma que el motor devuelve un resultado determinista de permitir o denegar, registra el contexto de la decisión, deniega por defecto y da prioridad a las prohibiciones cuando entran en conflicto reglas de permiso y prohibición.
Los controles no son una capa de orquestación. No transforman solicitudes, no analizan datos ni deciden qué herramienta debe invocar un agente. Su papel es más estrecho: determinar si una solicitud enrutada por el gateway está permitida dadas la historia observada.
La principal evidencia del cambio es la propia publicación técnica de AWS, que ofrece la descripción de la función y un ejemplo desarrollado con un agente de banca privada. En ese escenario, el agente recupera información del cliente, carga posiciones de cartera, obtiene precios de mercado, realiza análisis y ejecuta operaciones en nombre de asesores financieros.
AWS afirma que el ejemplo usa Amazon Cognito para la identidad, JSON Web Tokens para la autenticación de entrada y herramientas MCP expuestas a través de AgentCore Gateway. El lenguaje de políticas usado en el ejemplo es Dogwood, que AWS describe como un lenguaje de gobernanza de código abierto para agentes y sus herramientas. Según AWS, Dogwood puede evaluar políticas Cedar existentes y, al mismo tiempo, añadir soporte para condiciones temporales, permitiendo a los clientes conservar sus reglas Cedar actuales en lugar de migrarlas.
La fuente no ofrece resultados de pruebas independientes, cifras de adopción de clientes ni evidencia de que los controles eviten todas las clases de fallo de los agentes. Las afirmaciones sobre resistencia a la evasión y comportamiento operativo son declaraciones de producto y arquitectura de AWS. El elemento de medios disponible repite el título del anuncio, pero no añade detalles informados de forma independiente.
También existen limitaciones operativas para los equipos que evalúan la función. La ausencia de un encabezado de sesión puede hacer que AgentCore genere una nueva sesión, lo que significa que el motor de políticas ve una trayectoria vacía en lugar del historial previsto. AWS dice que los cambios de política invalidan las sesiones existentes para que las decisiones posteriores usen el conjunto de políticas actual y el esquema de eventos esperado. Estos comportamientos hacen que la gestión de sesiones y el despliegue de políticas formen parte del diseño de seguridad, no solo de los detalles de configuración.
Para los creadores de IA, las políticas temporales ofrecen un punto de control para un problema que es difícil resolver de forma fiable con prompts o verificaciones en la propia aplicación: mantener invariantes a lo largo de una secuencia de acciones seleccionadas por el modelo. Una política puede exigir que una llamada a una herramienta use una salida verificada anteriormente, que una acción de alto impacto siga un procedimiento definido o que un evento de aprobación humana preceda a la ejecución.
Para las empresas, el valor principal es la coherencia en el límite donde el tráfico de los agentes alcanza herramientas y modelos. Un gateway compartido puede aplicar reglas a las llamadas MCP, las llamadas de inferencia de modelos y las interacciones agente-a-agente cuando esas solicitudes pasan por AgentCore Gateway. Eso podría reducir la necesidad de que cada implementación individual de agente replique los controles del flujo de trabajo, aunque los equipos siguen necesitando diseñar las políticas, el modelo de identidad, los límites de sesión y el proceso de aprobación.
El enfoque también puede ayudar con el riesgo financiero u operativo acotado. Una regla sin estado puede limitar el tamaño de una operación, por ejemplo, pero no puede por sí sola determinar cuánta exposición se ha acumulado a lo largo de una sesión. El estado temporal hace expresable ese tipo de restricción acumulativa. La contrapartida es una dependencia adicional de una captura precisa de eventos y de trayectorias cuidadosamente acotadas. Una nueva sesión también puede eliminar el historial que una política esperaba inspeccionar.
Esto sitúa a AgentCore de forma más directa frente a plataformas de agentes que ponen el acento en la gobernanza en tiempo de ejecución, los permisos de herramientas y los controles con intervención humana. La evidencia disponible no es suficiente para comparar la implementación de AWS con productos competidores en latencia, expresividad de políticas o coste de despliegue.
Las próximas señales serán prácticas más que promocionales. Los desarrolladores deberían buscar documentación más amplia sobre Dogwood y su semántica temporal, ejemplos más allá del flujo bancario y detalles sobre la latencia de evaluación de políticas y el registro a escala de producción.
Los compradores empresariales también deberían examinar cómo pueden los equipos probar reglas dependientes de la trayectoria, recuperarse de sesiones fallidas o abandonadas y gestionar cambios de políticas sin interrumpir flujos de trabajo legítimos. Los informes independientes de clientes ayudarían a establecer si la aplicación a nivel de gateway reduce incidentes o esfuerzo de implementación frente a controles integrados en el código del agente.
El alcance del tráfico admitido también importará. AWS dice que las políticas temporales pueden gobernar llamadas de modelo, de herramienta MCP y de agente-a-agente enrutadas a través del gateway; la adopción dependerá de cuánto de la arquitectura de agentes de una organización pueda usar esa ruta sin crear un cuello de botella.
AWS está respondiendo a una debilidad real en la seguridad de los agentes: las decisiones de autorización a menudo necesitan memoria. El riesgo más consecuente no siempre es una llamada a una herramienta prohibida, sino una llamada permitida después de una consulta no confiable, una recuperación de datos obsoleta, una aprobación ausente o una actividad previa excesiva.
Las políticas temporales no hacen que los agentes sean fiables por sí mismas. Crean un límite de aplicación más sólido alrededor del comportamiento del agente, siempre que los desarrolladores definan identidades de sesión confiables, capturen los eventos correctos y prueben las políticas frente a secuencias de fallo. Para los equipos que trasladan agentes a finanzas, atención al cliente u otros flujos de trabajo de alto impacto, esa distinción —aplicación de políticas en lugar de cumplimiento del modelo— podría ser el avance más significativo.
AWS añade políticas temporales con conocimiento de trayectoria a Bedrock AgentCore, ofreciendo a los creadores controles a nivel de gateway para la secuenciación, las aprobaciones, la frescura y la exposición.