Amazon Web Services a présenté une méthode permettant aux entreprises de rattacher chaque action d’un agent IA à un véritable employé. Grâce aux connexions Okta, un bot professionnel ne peut utiliser que les outils approuvés par cette personne, un appel à la fois.
Points clés
AWS a montré comment Okta Cross App Access peut associer les droits d’un agent IA à un utilisateur identifié plutôt qu’à un compte de service aux privilèges étendus
Bedrock AgentCore Gateway utilise l’autorisation Okta avant que l’agent puisse accéder à un outil protégé
Les politiques Cedar vérifient chaque appel d’outil, et AgentCore Observability en consigne la trace
Un guide complémentaire étend la configuration à plusieurs agents, à une passerelle centrale et à des agents exécutés sur Amazon EKS
AWS a d’abord expliqué la configuration d’un agent unique, puis l’a étendue à plusieurs agents, à une passerelle centrale et à des mécanismes d’observabilité.
L’identité des agents IA sort du mode démo
Dans la version de base, un agent agit au nom d’un utilisateur identifié. Okta Cross App Access accorde une autorisation, puis Amazon Bedrock AgentCore Identity l’utilise avant que l’agent accède à un outil en aval.
La version plus complète ajoute une passerelle centrale, un deuxième agent sur Amazon EKS et une vérification des politiques à chaque appel d’outil. Selon Amazon, ce modèle offre aux entreprises un point d’accès unique pour gérer l’identité des agents IA, au lieu de comptes de service distincts dispersés dans différentes applications.
C’est important, car les agents IA évoluent : ils passent des chatbots aux logiciels capables d’agir. Dès qu’un agent peut ouvrir des tickets, rechercher des fichiers internes ou déclencher des flux de travail, le principal défi n’est plus seulement la qualité du modèle. Il s’agit de déterminer quel agent peut faire quoi, pour quel utilisateur et dans quelles limites.
À lire aussi : OpenAI établit 5 règles pour empêcher les agents IA de sortir du cadre
Là où les autorisations des agents posent d’abord problème
Le risque apparaît lorsque les équipes greffent des agents sur les anciennes autorisations des applications. Un utilisateur peut avoir des droits dans Salesforce ou Workday, mais un agent fonctionnant en arrière-plan utilise souvent une identité de service très étendue, ce qui rend flou le véritable approbateur de l’action.
La conception d’AWS réduit ce risque. Okta accorde une autorisation liée à l’utilisateur, Bedrock AgentCore Gateway la reçoit, Cedar, le langage de politiques d’Amazon, détermine si cet appel précis à un outil est autorisé, et AgentCore Observability consigne la trace de l’événement.
Les équipes de sécurité, les responsables de la conformité et les développeurs des entreprises réglementées disposent ainsi de ce qui leur manquait : des agents capables d’agir, ainsi que la preuve que chaque action s’inscrit dans une chaîne approuvée par un utilisateur.
Pourquoi cette approche est préférable au raccourci du compte de service
Le changement essentiel est que Bedrock AgentCore ne traite pas l’agent comme un script de serveur générique. Il le considère comme un acteur distinct, qui hérite de droits limités de la personne pour laquelle il travaille.
Pour les entreprises qui utilisent déjà Okta, cela évite le raccourci habituel consistant à accorder à un seul compte de service un accès permanent et étendu à de nombreux systèmes. Une telle configuration complique l’identification de la personne qui a donné son accord en cas de problème.
Il faudra voir si AWS intègre ce modèle documenté aux paramètres par défaut de Bedrock AgentCore. Si c’est le cas, l’identité des agents liée aux utilisateurs pourrait passer du statut de recommandation architecturale à celui de contrôle standard en entreprise.
À lire ensuite : l’UE passe les laboratoires d’IA au crible après la fuite d’agents d’OpenAI qui ont piraté une entreprise