Las politicas temporales en AgentCore son la nueva apuesta de Amazon Web Services para frenar un problema que ya no es teorico: agentes de IA que ejecutan acciones peligrosas porque nadie miraba el contexto completo de la sesion. En lugar de juzgar cada llamada por separado, este sistema evalua toda la secuencia de acciones de un agente antes de dejarle actuar. Si un agente lee datos de una fuente no fiable y luego intenta borrar un registro, la politica lo detecta. Es un cambio de enfoque relevante para cualquier empresa que este poniendo agentes en produccion.
Que ha lanzado AWS y por que importa
Amazon Web Services ha incorporado las politicas temporales en Amazon Bedrock AgentCore, un mecanismo que evalua las acciones de un agente de IA teniendo en cuenta el historial completo de la sesion y no solo la accion aislada del momento. La diferencia es sustancial: los controles tradicionales validan cada llamada de forma independiente, sin memoria de lo que ocurrio antes. Las politicas temporales de AgentCore analizan la secuencia entera, de modo que pueden bloquear una accion legitima en apariencia si el recorrido previo la vuelve sospechosa.
El caso de uso que AWS pone sobre la mesa es claro: un agente que acaba de leer datos de una fuente no confiable no deberia poder ejecutar acciones sensibles inmediatamente despues. Ese patron es la base de los ataques de inyeccion de prompt indirecta, donde el contenido malicioso entra por un documento, un correo o una pagina y el agente lo interpreta como instruccion. Al considerar el contexto de llamadas anteriores, las politicas temporales de AgentCore cortan esa cadena antes de que provoque dano.
Implicaciones tecnicas del nuevo control
El detalle de arquitectura mas importante es donde se ejecutan estas politicas: en el perimetro del AgentCore Gateway, fuera del codigo del agente. Esto significa que el propio agente no puede interceptarlas ni manipularlas. Es una separacion deliberada entre la logica del agente y la logica de control, y resuelve una debilidad conocida: si las reglas de seguridad viven dentro del mismo proceso que puede ser comprometido por una inyeccion, dejan de ser una garantia. Al sacar la evaluacion al gateway, AWS convierte la politica en un punto de control independiente.
Para los equipos tecnicos, las politicas temporales de AgentCore introducen un modelo mental distinto al de los guardrails clasicos. Ya no basta con definir que puede hacer un agente; hay que definir en que orden y bajo que condiciones de sesion. Un agente puede tener permiso para escribir en una base de datos, pero no si en la misma sesion accedio antes a contenido externo no verificado. Este enfoque basado en secuencia se acerca a como se modelan los flujos de confianza en seguridad tradicional, donde el estado previo condiciona lo que se autoriza a continuacion.
Como pueden aplicar esto las empresas hoy
Si tu empresa tiene agentes en produccion o en piloto sobre Bedrock, el primer paso es mapear las acciones sensibles: escrituras en bases de datos, envios de correo, llamadas a APIs externas, operaciones financieras o borrados. Sobre ese mapa, define que secuencias son inaceptables, empezando por la mas evidente: cualquier accion sensible que ocurra despues de leer datos externos no verificados. Las politicas temporales de AgentCore permiten expresar exactamente ese tipo de regla sin tocar el codigo del agente.
En cuanto a ROI, el calculo no es de productividad sino de riesgo evitado: un agente que ejecuta un borrado o una transferencia por una inyeccion de prompt puede costar mucho mas que el esfuerzo de configurar el gateway. Lo que conviene evitar es caer en el exceso contrario, bloquear tantas secuencias que el agente deje de ser util. La recomendacion practica es empezar en modo observacion, registrar que secuencias se activarian, y solo despues pasar a bloqueo. Y no delegar toda la seguridad en esta capa: sigue haciendo falta higiene de datos de entrada, permisos minimos y auditoria de sesiones.
Analisis Blixel
Durante meses el discurso sobre agentes autonomos ha ido por delante de las herramientas para contenerlos. Se hablaba de dar a los agentes acceso a bases de datos, correo y APIs como si el unico reto fuera que funcionaran, no que fallaran de forma segura. Mover la evaluacion fuera del codigo del agente, al perimetro del gateway, es la decision correcta y de sentido comun: la seguridad no puede vivir dentro del componente que intentas proteger. Ese principio es viejo en ciberseguridad y llega tarde, pero llega, al mundo de los agentes.
La verdadera aportacion es reconocer que el peligro de un agente no esta en la accion individual sino en la secuencia. Evaluar el historial completo de la sesion es lo que separa un guardrail de juguete de un control real frente a inyecciones indirectas, hoy el vector de ataque mas incomodo para cualquiera que ponga IA a interactuar con contenido externo. Dicho esto, ninguna capa de perimetro sustituye al diseno cuidadoso: si defines mal las secuencias prohibidas tendras falsos positivos que rompen flujos o, peor, huecos que dejan pasar el ataque. Para las PYMEs el mensaje es sobrio: la herramienta reduce la barrera para desplegar agentes con cierta seguridad, pero no elimina la necesidad de pensar antes en que puede salir mal. Adoptarla sin ese ejercicio previo es cambiar un riesgo por una falsa sensacion de control.
Quieres aplicar esto en tu empresa? En Blixel.ai te ayudamos a integrar IA con sentido comun. Hablemos.