Las empresas están implementando agentes de IA para automatizar flujos de trabajo utilizando bases de datos y repositorios internos. Sin embargo, existe un riesgo crítico: la mayoría de estos agentes no saben quién realiza la consulta, lo que permitiría que un agente manipulado entregue datos confidenciales a usuarios no autorizados. Para mitigar esto, AWS ha demostrado cómo evitar que un agente de IA secuestrado acceda a información que el usuario final no tiene permitido leer.

Las empresas están compitiendo por implementar agentes de IA que extraigan información de bases de datos, repositorios de documentos, plataformas SaaS y bases de conocimientos internas para automatizar los flujos de trabajo.

Pero bajo esa comodidad acecha un riesgo silencioso: la mayoría de los agentes no tienen una conciencia integrada de quién está haciendo realmente la pregunta, lo que significa que un agente comprometido o manipulado podría entregar datos que el usuario solicitante nunca estuvo autorizado a ver.

AWS ha publicado ahora una arquitectura detallada utilizando Amazon Bedrock AgentCore que cierra esta brecha al trasladar la autorización fuera del código del agente y llevarla directamente a la infraestructura.

AWS muestra cómo evitar el acceso a los datos de los agentes de IA

La solución tradicional para este riesgo ha sido otorgar al agente credenciales amplias y confiar en la propia lógica del agente para filtrar los resultados, a menudo mediante condiciones de consulta simples. La guía de AWS identifica esto como una debilidad estructural.

Si un atacante manipula el agente mediante la inyección de prompts o explota un error en ese código de filtrado, todo el conjunto de datos subyacente del agente queda expuesto. Evaluar un software de seguridad de IA robusto se está volviendo necesario a medida que las empresas adoptan agentes autónomos.

La respuesta propuesta por AWS, alineada con la mejor práctica AGENTSEC03 en el AWS Well-Architected Agentic AI Lens, trata al agente puramente como un orquestador que coordina las llamadas a herramientas y el razonamiento, mientras que las decisiones de acceso reales son ejecutadas por los servicios con los que el agente se comunica.

La demostración se centra en una aplicación de chat de CRM compartida por empleados de Ventas y Finanzas, donde cada uno necesita acceso aislado a los registros de clientes en Amazon DynamoDB, documentos etiquetados por departamento en Amazon Bedrock Knowledge Bases respaldados por Amazon S3, y datos de CRM externos en Salesforce.

Cuando un usuario inicia sesión a través de un grupo de usuarios de Amazon Cognito, un activador Lambda de generación de pre-token inyecta una reclamación de departamento y metadatos de etiqueta de sesión de AWS directamente en el JSON Web Token antes de que llegue a la aplicación.

Amazon Bedrock AgentCore Runtime valida este token al recibirlo y rechaza cualquier solicitud cuya reclamación de departamento no coincida con un valor permitido, bloqueando las llamadas no autorizadas antes de que el código del agente se ejecute. A partir de ahí, AWS demuestra tres patrones distintos para propagar esa identidad verificada hacia abajo.

Para DynamoDB, el agente intercambia el token de ID firmado del usuario por credenciales temporales con alcance de usuario a través de AssumeRoleWithWebIdentity, permitiendo que AWS Identity and Access Management evalúe una condición de LeadingKeys vinculada a la etiqueta de departamento del usuario, de modo que las consultas entre departamentos sean rechazadas a nivel de política en lugar de filtrarse a posteriori.

Adoptar estas restricciones de identidad se alinea directamente con los principios básicos para asegurar las API de la nube en entornos multi-inquilino.

Para Bedrock Knowledge Bases, los documentos se etiquetan con metadatos de departamento durante la ingesta, y el agente añade un filtro de metadatos coincidente a cada llamada de recuperación; este es un control de la capa de aplicación ya que la API de recuperación aún no expone los filtros como condiciones de IAM.

Para Salesforce, AgentCore Identity realiza un intercambio de tokens "en nombre de" bajo el RFC 8693, sustituyendo la identidad autenticada del usuario por un token reconocido por Salesforce sin que ninguna credencial toque jamás al agente, permitiendo que las propias reglas de uso compartido de Salesforce gobiernen lo que se devuelve.

Como se detalla en la guía de arquitectura compartida por el Blog de Seguridad de AWS, aplicar la autorización en la capa de infraestructura garantiza que los límites de los datos permanezcan intactos independientemente de la manipulación a nivel de agente.

Objetivo Downstream	Mecanismo de Autorización	Método de Ejecución
Amazon DynamoDB	Intercambio de Token AssumeRoleWithWebIdentity	Condición IAM LeadingKeys vinculada a la etiqueta de sesión del departamento
Bedrock Knowledge Bases	Etiquetado de metadatos en el momento de la ingesta	Filtro de capa de aplicación añadido a las consultas de la API /retrieve
Salesforce CRM	Intercambio de tokens "on-behalf-of" RFC 8693	Reglas nativas de uso compartido de Salesforce y políticas de rol de usuario

La importancia práctica es que incluso un agente totalmente comprometido, uno manipulado a través de la inyección de prompts o un fallo de codificación, no puede llegar más allá de lo que el usuario autenticado tiene derecho a ver, porque el rol de ejecución del agente no posee permisos directos sobre el almacén de datos por sí mismo.

En su lugar, cada solicitud lleva credenciales vinculadas al usuario, derivadas criptográficamente y de corta duración, que expiran rápidamente y no pueden ser reutilizadas ni falsificadas. Realizar regularmente pruebas de seguridad de API ayuda a verificar que los intercambios de tokens downstream sigan siendo resistentes contra los intentos de escalada de privilegios.

AWS plantea esto como un patrón generalizable: el alcance por departamento en el ejemplo se puede aplicar con la misma facilidad a roles, unidades de negocio, regiones o controles de acceso basados en proyectos en otros entornos.

A medida que las organizaciones expanden la IA agentica hacia sistemas sensibles que manejan datos financieros, sanitarios o de clientes, este cambio hacia una autorización impuesta por la infraestructura, en lugar de confiar en que un agente impulsado por un LLM se autoregule, representa un paso de endurecimiento significativo contra la creciente clase de ataques de inyección de prompts y secuestro de agentes que los investigadores de seguridad han señalado como una preocupación principal para 2026.

Fuentes:
https://cybersecuritynews.com/aws-ai-agent-data-access/