AWS Bedrock AgentCore: políticas de seguridad e interceptores Lambda para agentes de IA

El blog de Machine Learning de AWS ha publicado un artículo sobre cómo Amazon Bedrock AgentCore, la plataforma de AWS para desplegar y operar agentes de IA, ayuda a incorporar el control de acceso directamente en la infraestructura de los sistemas autónomos. Como ejemplo, los autores usan un llamado agente lakehouse, un agente de IA que trabaja con datos en un data lakehouse, para mostrar cómo combinar dos mecanismos de protección distintos: Policy para el control de acceso determinista e interceptores Lambda (Lambda interceptors) para la verificación dinámica de solicitudes en tiempo real.

Cómo funcionan los dos niveles de control de acceso

En la terminología del artículo, Policy es un mecanismo determinista basado en reglas estrictas: describe de antemano qué acciones puede realizar el agente sobre determinados recursos y se aplica igual en cada llamada, con independencia del contexto de la solicitud concreta. Es similar a las políticas clásicas de gestión de identidades y accesos (IAM), usadas desde hace tiempo para personas y cuentas de servicio. Los interceptores Lambda funcionan de otro modo: son funciones sin servidor personalizadas basadas en AWS Lambda que se ejecutan justo en el momento de la solicitud y pueden tener en cuenta condiciones imposibles de fijar de antemano en una regla estática, como valores calculados en tiempo real, el estado de sistemas externos o señales sobre el contexto real de una llamada concreta del agente.

¿Por qué combinar control determinista y dinámico?

El ejemplo que analiza el artículo, la restricción geográfica de acceso, muestra con claridad por qué un solo mecanismo no basta. El hecho de que ciertos datos u operaciones estén sujetos a restricciones territoriales puede y debe fijarse con una regla estática de Policy: así se crea una base de protección predecible y reproducible. Pero la ubicación real desde la que llega la solicitud, o la región a la que pertenecen realmente los datos solicitados, es una variable dinámica que puede cambiar de una solicitud a otra y no se puede codificar de forma rígida en un rol o permiso estático.

Para comprobar esa parte variable, el artículo propone un interceptor Lambda que actúa sobre la Policy determinista, no en su lugar, de modo que la decisión final de permitir al agente una operación solo se toma cuando se cumplen ambas condiciones a la vez.

Qué significa para los desarrolladores de agentes en Bedrock

Para los equipos que construyen agentes autónomos sobre Amazon Bedrock AgentCore, combinar estos dos mecanismos abre el camino para operar sistemas en sectores regulados, como finanzas, salud o manejo de datos transfronterizos, donde los requisitos de cumplimiento cambian según la jurisdicción y no los cubre un único conjunto estático de roles. El ejemplo del agente lakehouse plantea un escenario empresarial realista: un agente al que, en general, se permite un amplio acceso a los datos del data lake para tareas analíticas no debe, sin embargo, poder acceder a datos fuera de su zona de responsabilidad geográfica o regulatoria, aunque técnicamente tenga acceso de red a todo el almacén. Este enfoque de control en dos niveles, reglas deterministas más verificación dinámica en el momento de la solicitud, se perfila como una respuesta práctica a un desafío más amplio para todo el sector, a medida que se delegan a los agentes de IA más acciones autónomas con datos corporativos reales, a menudo confidenciales.

También es relevante que ambos mecanismos estén integrados directamente en la plataforma Amazon Bedrock AgentCore y no los implemente desde cero el equipo de desarrollo por encima de ella: Policy y los interceptores Lambda funcionan como primitivas listas para usar que se pueden combinar según el escenario, ya sean restricciones dependientes de la geografía, separación de accesos por departamentos dentro de una empresa o verificación de que una solicitud cumple los requisitos regulatorios de un sector concreto. Este enfoque reduce la probabilidad de que cada equipo reinvente su propio esquema de control de acceso, potencialmente vulnerable, para sus agentes, y acerca la gestión de permisos de los agentes de IA a la madurez habitual de los servicios cloud tradicionales de AWS.

También es significativo que el artículo analice precisamente un agente lakehouse, es decir, un sistema que trabaja con los datos analíticos de la empresa y no con procesos de servicio secundarios. La elección de este ejemplo subraya que el control de acceso en AWS Bedrock AgentCore no es una cuestión abstracta, sino que está ligado a una clase real de tareas en las que el agente necesita de verdad un acceso amplio pero estrictamente acotado a grandes volúmenes de información corporativa, y donde un error en la configuración de permisos puede afectar a los datos de muchos departamentos y jurisdicciones a la vez.