Amazon Bedrock AgentCore ajoute Policy pour le contrôle d’accès des agents AI

Amazon Bedrock AgentCore a reçu Policy pour contrôler l'accès des agents IA

Amazon a décrit comment Bedrock AgentCore dispose désormais d'un mécanisme Policy séparé pour protéger les agents IA. Sa tâche est de vérifier l'accès aux outils et aux données non par le « bon sens » du modèle, mais par des règles strictes qui s'exécutent indépendamment de son raisonnement et qui déplacent la sécurité hors des prompts vers une couche d'infrastructure gérée.

Couche séparée de règles

L'idée clé est que Policy dans AgentCore crée une couche de contrôle déterministe. Même si l'agent avait décidé que pour fournir une réponse il devrait ouvrir un service interne, télécharger un fichier ou appeler un outil avec des privilèges élevés, la décision finale n'est pas prise par lui. La demande passe par un système de règles séparé, et seul ce système détermine si l'action est autorisée ou non. Cette approche réduit le risque lorsqu'un modèle interprète mal les instructions, comprend la tâche de l'utilisateur trop largement ou tente d'accéder à des données qu'il ne devrait pas voir.

AWS décrit également un moyen plus pratique de configurer de telles 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 la description précise des permissions. Au lieu d'un prompt vague comme « ne montre pas les documents d'autres personnes », il y a une vérification formelle : à qui, sous quelles conditions et avec quels droits un agent peut réellement ouvrir l'outil ou l'ensemble de données nécessaire. Pour les scénarios d'entreprise, cela est plus important qu'une autre couche d'instructions dans le prompt lui-même.

Pour les agents, c'est particulièrement important dans les scénarios longs à plusieurs étapes. Un modèle peut correctement commencer une tâche, puis au cours de la chaîne décider qu'il a besoin d'un outil supplémentaire ou d'un accès plus large. Sans une politique externe, de telles expansions sont souvent contrôlées uniquement par le prompt. Policy dans AgentCore propose un schéma plus rigide : chaque nouvelle étape est revérifiée par rapport aux règles, même si l'agent lui-même est confiant qu'il agit dans l'intérêt de l'utilisateur.

Vérification à la passerelle

En pratique, Policy est appliquée via AgentCore Gateway. Cette passerelle intercepte chaque demande de l'agent à l'outil lors de l'exécution et la vérifie avant que l'action ne soit exécutée. En d'autres termes, ce n'est pas une configuration ponctuelle au début d'une session, mais un contrôle au moment de l'exécution : un agent peut faire des dizaines de demandes aux API, bases de données, stockages de fichiers et services internes, et chacune de ces étapes fait l'objet d'une évaluation de politique. Cela rend la protection plus proche du comportement réel de l'agent, plutôt que de ses intentions initiales.

• Qui exactement a initié la demande : un utilisateur spécifique, un rôle ou un groupe
• À quel outil l'agent accède-t-il et quelle action souhaite-t-il effectuer
• Si l'utilisateur a le droit de voir ces données ou d'exécuter ce workflow
• Si l'accès doit être refusé, autorisé ou restreint selon le contexte

L'accent principal ici est sur l'accès tenant compte de l'identité. Un agent ne reçoit pas une permission abstraite comme « travailler avec CRM » ou « lire les documents », mais des droits liés à l'identité et l'autorité de l'utilisateur au nom duquel il agit. Si un employé n'a accès qu'à une partie des dossiers clients, l'agent doit voir la même limite. Si un responsable a accès à un ensemble d'outils et un analyste à un autre, cela doit également être appliqué automatiquement. Cette approche est particulièrement utile lorsque le même agent sert différents employés avec différents niveaux d'accès.

En conséquence, Bedrock AgentCore propose non seulement des garde-fous pour les réponses, mais un modèle de gestion des actions plus strict.

Ce que cela signifie

Amazon se tourne vers des agents IA plus matures pour les entreprises, où non seulement une interface intelligente est importante, mais aussi l'exécution prévisible des règles. Si cette approche prend racine, les entreprises pourront connecter des agents aux systèmes internes sans dépendre constamment de la prudence du modèle. Le contrôle d'accès deviendra une couche externe et vérifiable, ce qui signifie que les agents peuvent être confiés à des tâches réelles — de la recherche de données à l'exécution d'outils au nom d'un employé.