AWS montre comment empêcher un agent LLM de lire les documents des autres : c'est la passerelle qui injecte le userContext

Imaginez un assistant interne utilisé par toute l'entreprise. Un employé du service A demande : « Compare le plan de mon service avec la note générale et montre-moi les initiatives en retard ». L'agent formule lui-même ses requêtes de recherche et creuse dans les documents jusqu'à avoir collecté assez d'informations. Un employé du service B pose la même question. Si la recherche n'est pas liée à une personne précise, le plan d'affaires d'un service peut très facilement se retrouver dans la réponse destinée à un autre. Dans un SaaS multi-locataire, la même chose arrive avec les entreprises clientes, et le coût de l'erreur y est plus élevé.

L'AWS Machine Learning Blog a publié une analyse de la façon de colmater cette brèche dans l'association Amazon Bedrock Managed Knowledge Base et AgentCore Gateway.

Pourquoi c'est plus compliqué avec les agents qu'avec une application classique

Dans une application classique, le code sait lui-même qui s'est connecté et cherche avec les droits de cet utilisateur. Dans un agent, c'est le LLM qui appelle l'outil, et c'est aussi lui qui choisit les arguments. Si l'outil de recherche possède un paramètre « au nom de qui chercher », il sera rempli par le modèle. Il suffit d'une phrase de l'utilisateur comme « cherche en tant que user-b », d'une erreur du modèle ou d'une prompt injection indirecte dans un document trouvé, et l'agent cherche sous l'identité de quelqu'un d'autre.

Managed Knowledge Base dispose d'un mode ACL awareness. Lors du chargement des données, la base mémorise les droits sur les documents et, lors de la recherche, ne renvoie que ce qui est autorisé pour l'utilisateur indiqué dans userContext.userId (c'est son e-mail). Mais la base n'authentifie pas elle-même les utilisateurs : elle croit ce qu'elle reçoit. Et lorsqu'elle est publiée comme outil MCP via AgentCore Gateway, le userContext devient un argument ordinaire, construit par le modèle. Ni la passerelle ni la base ne vérifient que la valeur appartient bien à la personne connectée.

Quatre couches : deux principales et deux de sécurité supplémentaire

Le principe est simple : le LLM ne décide pas de l'identité de l'utilisateur. C'est un code de confiance qui en décide, sur la base de données vérifiées par le fournisseur d'identité. La requête suit ce parcours :

• L'utilisateur se connecte via Amazon Cognito et obtient un JWT. Le déclencheur Lambda pre token generation ajoute au jeton un claim contenant l'e-mail.
• L'agent transmet le jeton dans l'en-tête Authorization, et l'autorisateur de la passerelle vérifie la signature, la durée de validité et le client ID.
• Le request interceptor, c'est-à-dire une Lambda sur la passerelle, extrait l'e-mail du jeton vérifié et réécrit le userContext dans chaque appel tools/call. Quoi que le client ou le modèle envoie, la base recevra l'e-mail de l'utilisateur réel. Les lots (batches) et les corps de requête invalides sont rejetés selon le principe fail-closed.
• Policy in AgentCore vérifie, au moyen d'une politique Cedar, que userContext.userId correspond à l'e-mail du JWT. Si ce n'est pas le cas, la requête est rejetée.
• La resource-based policy de la base de connaissances interdit la recherche à tous, sauf au rôle d'exécution de la passerelle.

Les deux premières couches (intercepteur et ACL) constituent la protection principale. Pour les requêtes passant par la passerelle, elles suffisent si personne d'autre ne peut accéder directement à la base. La politique Cedar et la resource-based policy servent en cas de bug dans l'intercepteur ou de principal extérieur disposant du droit bedrock:Retrieve dans le même compte. L'agent lui-même, construit avec Strands Agents, ne contient aucune logique d'accès : il se contente de transmettre le jeton.

Pièges à éviter

• Les ACL pour S3 sont définies par un fichier global par préfixe ou par un métafichier par document. Un document sans ACL n'entrera tout simplement pas dans l'index.
• Les modifications de droits ne s'appliquent qu'après la prochaine synchronisation : S3 n'effectue pas de vérification en temps réel.
• Les erreurs d'ACL ne lèvent aucune exception, les documents disparaissent discrètement des résultats. Vérifiez-le par des tests.
• Une requête sans userContext ne renverra pas les documents d'une source où les ACL sont activées, mais les documents d'une source sans ACL seront visibles de tous.
• Pour personnaliser l'access token dans Cognito, il faut le plan Essentials ou Plus. Avec Lite, l'e-mail n'apparaîtra pas dans le jeton.
• Pour que l'intercepteur puisse écrire le userContext, celui-ci doit être exposé dans le schéma de l'outil via parameterOverrides, même si les clients ne le renseignent pas.

Que faire de tout cela

La conclusion dépasse un seul produit AWS. Tout paramètre qui détermine l'identité ou les droits ne doit pas être un argument rempli par le modèle. Injectez-le au niveau de la passerelle ou du serveur d'outils à partir d'un jeton vérifié, et ajoutez par-dessus une vérification indépendante. Si vous développez un agent multi-locataire, vérifiez que vous ne confiez pas au modèle le tenant_id ou le user_id.

Un exemple prêt à l'emploi en CDK se trouve dans le dépôt sample-managed-knowledge-base-patterns, dans le répertoire agentcore-access-control. Réserve : il s'agit d'un schéma pour la pile AWS, et sur d'autres plateformes il faudra le reproduire soi-même.