Amazon Bedrock AgentCore ajoute Policy pour contrôler l'accès des agents d'IA

Amazon a décrit un nouveau mécanisme distinct, Policy, dans Bedrock AgentCore pour protéger les agents d'IA. Son rôle est de vérifier l'accès aux outils et aux données non pas selon le « bon sens » du modèle, mais selon des règles strictes, appliquées indépendamment de son raisonnement, qui sortent la sécurité des prompts pour la placer dans une couche d'infrastructure gérable.

Une couche de règles distincte

L'idée clé est que Policy dans AgentCore crée une couche de contrôle déterministe. Même si l'agent estime que, pour répondre, il doit ouvrir un service interne, télécharger un fichier ou appeler un outil avec des privilèges élevés, la décision finale ne lui appartient pas. La requête passe par un système de règles distinct, et lui seul détermine si l'action est autorisée ou non.

Cette approche réduit le risque que le modèle interprète mal les instructions, comprenne trop largement la tâche de l'utilisateur ou tente d'atteindre des données qu'il n'est pas censé voir.

AWS décrit aussi une façon plus pratique de configurer ces restrictions. Les règles métier peuvent d'abord être formulées en langage naturel, puis traduites en politiques Cedar, un langage conçu pour décrire précisément des autorisations. À la place d'un prompt vague du type « ne montre pas les documents des autres », on obtient une vérification formelle : qui, dans quelles conditions et avec quels droits peut réellement ouvrir tel outil ou tel jeu de données via l'agent. Pour les usages en entreprise, c'est plus important qu'une couche d'instructions de plus dans le prompt lui-même.

C'est particulièrement crucial pour les agents dans les scénarios longs, en plusieurs étapes. Un modèle peut bien démarrer une tâche, puis, en cours de chaîne, juger qu'il lui faut un outil supplémentaire ou un accès plus large. Sans politique externe, ces extensions ne sont souvent contrôlées que par le prompt. Policy dans AgentCore propose un schéma plus strict : chaque nouvelle étape est de nouveau confrontée aux règles, même si l'agent est persuadé d'agir dans l'intérêt de l'utilisateur.

Vérification au niveau de la passerelle

En pratique, Policy s'applique via AgentCore Gateway. Cette passerelle intercepte à l'exécution chaque requête de l'agent vers un outil et la vérifie avant que l'action ne soit réalisée. Autrement dit, il ne s'agit pas d'une configuration ponctuelle en début de session, mais d'un contrôle en runtime : un agent peut solliciter des dizaines de fois des API, des bases de données, des espaces de stockage de fichiers et des services internes, et chacune de ces étapes est évaluée au regard de la politique. La protection colle ainsi davantage au comportement réel de l'agent qu'à ses intentions initiales.

• Qui a exactement initié la requête : un utilisateur précis, un rôle ou un groupe
• Quel outil l'agent appelle et quelle action il veut exécuter
• Si l'utilisateur a le droit de voir ces données ou de lancer ce workflow
• S'il faut interdire, autoriser ou restreindre l'accès selon le contexte

L'accent est mis sur l'accès identity-aware. L'agent ne reçoit pas une autorisation abstraite de « travailler avec le CRM » ou de « lire des documents », mais des droits liés à l'identité et aux habilitations de l'utilisateur au nom duquel il agit. Si un employé n'a accès qu'à une partie des fiches clients, l'agent doit voir la même limite. Si un manager a accès à un ensemble d'outils et un analyste à un autre, cela doit aussi être respecté automatiquement.

Cette approche est particulièrement utile lorsqu'un même agent sert différents employés avec des niveaux d'accès différents. Au final, Bedrock AgentCore propose non seulement des guardrails pour les réponses, mais un modèle plus strict de gestion des actions.

Ce que cela signifie

Amazon s'oriente vers des agents d'IA plus matures pour les entreprises, où comptent non seulement une interface intelligente, mais aussi une exécution prévisible des règles. Si cette approche s'impose, les entreprises pourront connecter des agents à leurs systèmes internes sans compter en permanence sur la rigueur du modèle. Le contrôle d'accès deviendra une couche externe et vérifiable, ce qui facilitera la confiance accordée aux agents pour des tâches réelles, de la recherche de données au lancement d'outils au nom d'un employé.