AWS muestra cómo evitar que un agente LLM lea documentos ajenos: el gateway inyecta userContext

Imagine un asistente interno que usa toda la empresa. Un empleado del departamento A pide: «Compara el plan de mi departamento con el aviso general y muéstrame las iniciativas rezagadas». El agente formula por sí mismo las consultas de búsqueda y rastrea documentos hasta reunir suficiente información. Un empleado del departamento B hace la misma pregunta. Si la búsqueda no está vinculada a una persona concreta, el plan de negocio de un departamento puede acabar fácilmente en la respuesta a otro. En un SaaS multiinquilino ocurre lo mismo con las empresas cliente, y allí el coste de un error es mayor.

El AWS Machine Learning Blog ha publicado un análisis de cómo cerrar esta brecha con la combinación de Amazon Bedrock Managed Knowledge Base y AgentCore Gateway.

Por qué los agentes son más complicados que una aplicación convencional

En una aplicación clásica, el propio código sabe quién ha iniciado sesión y busca con los permisos de ese usuario. En un agente, la herramienta la invoca el LLM, y los argumentos también los elige él. Si la herramienta de búsqueda tiene un parámetro «en nombre de quién buscar», lo rellenará el modelo. Basta con que el usuario diga «busca como user-b», con un error del modelo o con una prompt injection indirecta en un documento encontrado para que el agente busque con una identidad ajena.

Managed Knowledge Base tiene un modo ACL awareness. Al cargar los datos, la base memoriza los permisos de los documentos y, al buscar, devuelve solo lo que está permitido para el usuario indicado en userContext.userId (su email). Pero la base no autentica a los usuarios por sí misma: se fía de lo que recibe. Y cuando se publica como herramienta MCP a través de AgentCore Gateway, userContext pasa a ser un argumento más, construido por el modelo. Ni el gateway ni la base comprueban que el valor pertenezca a la persona que ha iniciado sesión.

Cuatro capas: dos principales y dos de refuerzo

El principio es sencillo: el LLM no decide quién es el usuario. Eso lo decide código de confianza a partir de datos verificados por el proveedor de identidad. La solicitud sigue este recorrido:

• El usuario inicia sesión mediante Amazon Cognito y recibe un JWT. Un trigger Lambda de pre token generation añade al token un claim con el email.
• El agente reenvía el token en la cabecera Authorization, y el autorizador del gateway verifica la firma, la caducidad y el client ID.
• El request interceptor, es decir, una Lambda en el gateway, extrae el email del token verificado y sobrescribe userContext en cada llamada a tools/call. Sea lo que sea que envíen el cliente o el modelo, la base recibirá el email del usuario real. Los lotes y los cuerpos de solicitud no válidos se rechazan según el principio fail-closed.
• Policy in AgentCore comprueba mediante una política Cedar que userContext.userId coincide con el email del JWT. Si no es así, la solicitud se rechaza.
• La resource-based policy de la base de conocimiento prohíbe la búsqueda a todos excepto al rol de ejecución del gateway.

Las dos primeras capas (el interceptor y las ACL) son la protección principal. Para las solicitudes a través del gateway bastan, siempre que nadie más pueda acceder directamente a la base. La política Cedar y la resource-based policy son necesarias por si hay un bug en el interceptor o un principal ajeno con permiso bedrock:Retrieve en la misma cuenta. El propio agente, basado en Strands Agents, no contiene lógica de acceso: simplemente reenvía el token.

Trampas habituales

• Las ACL de S3 se definen mediante un archivo global por prefijo o un metarchivo por documento. Un documento sin ACL simplemente no entrará en el índice.
• Los cambios de permisos solo se aplican tras la siguiente sincronización: S3 no tiene comprobación en tiempo real.
• Los errores en las ACL no provocan excepciones; los documentos desaparecen silenciosamente de los resultados. Compruébelo con pruebas.
• Una solicitud sin userContext no devolverá documentos de una fuente con ACL habilitadas, pero los documentos de una fuente sin ACL los verán todos.
• Para personalizar el access token en Cognito se necesita el plan Essentials o Plus. En Lite el email no aparecerá en el token.
• Para que el interceptor pueda escribir userContext, hay que exponerlo en el esquema de la herramienta mediante parameterOverrides, aunque los clientes no lo establezcan.

Qué hacer con esto

La conclusión va más allá de un único producto de AWS. Cualquier parámetro que determine la identidad o los permisos no debe ser un argumento que rellene el modelo. Inyéctelo a nivel de gateway o de servidor de herramientas a partir de un token verificado y añada encima una comprobación independiente. Si está construyendo un agente multiinquilino, revise si no le está entregando al modelo un tenant_id o un user_id.

Un ejemplo listo en CDK está en el repositorio sample-managed-knowledge-base-patterns, en el directorio agentcore-access-control. Una salvedad: se trata de un esquema para el stack de AWS, y en otras plataformas habrá que reproducirlo por cuenta propia.