Aller au contenu principal
SécuritéAWS ML Blog · 2 min de lecture

Sécuriser les agents IA avec des politiques temporelles dans Amazon Bedrock AgentCore

Source originale ↗·

Amazon vient d'annoncer les « temporal policies » (politiques temporelles) au sein d'Amazon Bedrock AgentCore, une nouvelle couche de contrôle d'accès destinée à sécuriser les agents IA au niveau d'AgentCore Gateway. Contrairement aux contrôles classiques, qui évaluent chaque appel d'outil de façon isolée et déterministe, ces politiques analysent la trajectoire complète d'une session, c'est-à-dire l'historique ordonné des actions déjà exécutées par l'agent, avant d'autoriser ou non une nouvelle requête. Elles s'exécutent au niveau de la passerelle, en dehors du code de l'agent lui-même, ce qui les rend impossibles à contourner, quels que soient les prompts utilisés ou les bugs présents dans le code de l'agent. Amazon cite plusieurs cas d'usage concrets : imposer l'ordre d'exécution des outils pour respecter une procédure standard, exiger qu'un argument transmis à un outil corresponde exactement à la sortie d'un appel précédent, plafonner l'exposition financière cumulée sur une session, ou encore bloquer toute action sensible tant qu'une validation humaine explicite n'a pas été enregistrée dans la trajectoire.

Ce dispositif répond à un problème spécifique aux agents IA : contrairement aux applications traditionnelles, un agent décide en temps réel quels outils appeler, avec quels paramètres et dans quel ordre, ce qui rend les erreurs beaucoup plus difficiles à anticiper. Amazon illustre le risque avec plusieurs scénarios où les contrôles classiques échouent : un agent qui invente un numéro de compte différent de celui retourné par un outil de recherche client et l'utilise pour virer des fonds vers le mauvais destinataire, un agent livré à lui-même qui enchaîne des dizaines de transactions en boucle sans jamais vérifier que le seuil de risque global a été dépassé, ou encore un agent qui approuve puis rejette la même demande d'assurance en quelques secondes. Pris individuellement, chacun de ces appels passerait sans problème un contrôle statique classique ; seule une lecture de l'ensemble de la séquence permet de détecter l'anomalie.

Cette annonce s'inscrit dans un mouvement plus large de sécurisation de l'infrastructure agentique chez les grands fournisseurs cloud, à mesure que les entreprises déploient des agents autonomes sur des tâches sensibles, notamment dans la finance et l'assurance. AgentCore disposait déjà d'un système de politiques statiques déterminant qui peut appeler quel outil et sous quelles conditions, mais Amazon reconnaît que cela reste insuffisant face à des agents capables d'halluciner des données ou de s'enchaîner en boucle. Les temporal policies visent aussi à durcir automatiquement les permissions lorsqu'un agent opère sans supervision humaine directe, une approche qui pourrait devenir un standard à mesure que les régulateurs et les entreprises exigent davantage de garanties sur la fiabilité des systèmes agentiques déployés en production.

Impact France/UE

Les entreprises europeennes utilisant Amazon Bedrock AgentCore pourraient beneficier de ces controles renforces pour leurs agents IA, sans impact reglementaire direct sur la France ou l'UE.

Dans nos dossiers

Cet article vous a été utile ?

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

Amazon Bedrock AgentCore Identity permet de sécuriser des agents IA sur Amazon ECS
1AWS ML Blog 

Amazon Bedrock AgentCore Identity permet de sécuriser des agents IA sur Amazon ECS

Amazon a lancé AgentCore Identity, un service intégré à Amazon Bedrock, conçu pour sécuriser l'accès des agents d'intelligence artificielle aux services externes. Disponible en tant que service autonome, il s'intègre aux principales plateformes de calcul d'AWS, Amazon ECS, Amazon EKS, AWS Lambda, ainsi qu'aux environnements on-premises. La solution s'appuie sur deux protocoles standards : OAuth 2.0 (RFC 6749) pour l'autorisation des actions, et OpenID Connect (OIDC) pour l'authentification des utilisateurs. Le flux retenu est l'Authorization Code Grant, dit « 3-legged OAuth » : l'utilisateur s'authentifie auprès d'un fournisseur d'identité comme Microsoft Entra ID, donne son consentement explicite, et l'application échange un code d'autorisation contre un jeton d'accès à portée limitée. Ce jeton est ensuite conservé dans le coffre-fort de tokens d'AgentCore Identity, lié à l'identité précise de l'utilisateur, créant ainsi une chaîne d'audit traçable de l'authentification jusqu'à l'action de l'agent. Ce mécanisme répond à un problème concret et croissant en production : comment empêcher un agent IA d'agir au-delà de ce que l'utilisateur a expressément autorisé. AgentCore Identity introduit un « session binding » applicatif qui protège contre les attaques CSRF et les attaques par substitution de navigateur, deux vecteurs courants dans les flux OAuth mal implémentés. Chaque token est scopé à une session utilisateur individuelle, suivant le principe du moindre privilège : l'agent ne peut accéder qu'aux ressources pour lesquelles le consentement a été donné. La séparation des responsabilités entre le workload agent et le service de session binding permet en outre de réduire la surface d'attaque et de centraliser la gestion du cycle de vie des tokens, sans que l'application principale n'ait à gérer ce risque directement. La mise en production de cette architecture illustre une tendance de fond dans l'industrie cloud : les agents IA autonomes ne peuvent plus fonctionner sur la base de credentials statiques ou de permissions trop larges. AWS propose ici une implémentation de référence déployée sur Amazon ECS derrière un Application Load Balancer, avec chiffrement HTTPS via AWS Certificate Manager et routage DNS via Amazon Route 53. Le code source complet est disponible sur GitHub. Pour les équipes qui construisent des agents agissant pour le compte d'utilisateurs réels, assistants, automatisations, workflows délégués, cette approche standardisée autour d'OIDC et OAuth 2.0 constitue désormais une baseline de sécurité incontournable, d'autant qu'elle s'appuie sur des fournisseurs d'identité existants plutôt que de réinventer une gestion des identités propriétaire.

UELes équipes européennes déployant des agents IA sur AWS disposent d'une baseline de sécurité standardisée qui facilite la conformité RGPD grâce au consentement explicite, à la traçabilité des accès et au principe du moindre privilège.

SécuritéOutil
1 source
Sécuriser les agents IA avec des intercepteurs Policy et Lambda dans la passerelle Amazon Bedrock AgentCore
2AWS ML Blog 

Sécuriser les agents IA avec des intercepteurs Policy et Lambda dans la passerelle Amazon Bedrock AgentCore

Amazon a enrichi son service Bedrock AgentCore Gateway de deux mécanismes de sécurité complémentaires destinés à contrôler le comportement des agents IA en entreprise. Le premier, appelé Policy, permet de définir des règles d'accès aux outils à l'aide de Cedar, un langage déclaratif d'Amazon qui évalue chaque requête selon un principal, une action et une ressource, puis délivre une décision déterministe d'autorisation ou de refus, automatiquement journalisée. Le second mécanisme, les intercepteurs Lambda, permet d'exécuter du code personnalisé avant ou après chaque appel d'outil, pour effectuer de la validation dynamique, de l'enrichissement de payload, des échanges de tokens ou du filtrage de réponses. Pour illustrer ces capacités, Amazon présente un agent de données baptisé "lakehouse data agent", conçu pour une compagnie d'assurance fictive. Cet agent permet à trois types d'utilisateurs, titulaires de contrats, experts en sinistres et administrateurs, d'interroger des données de réclamations stockées dans Amazon S3 Tables au format Apache Iceberg, via Amazon Athena et AWS Lake Formation. L'interface Streamlit authentifie les utilisateurs via Amazon Cognito et transmet des JWT à l'agent, qui expose cinq outils MCP distincts. Les métadonnées de rôles, les mappings IAM par tenant et la géographie des utilisateurs sont stockés dans Amazon DynamoDB. Ces nouvelles fonctionnalités répondent à un problème de gouvernance concret que rencontrent les grandes organisations déployant des agents IA à l'échelle. Contrairement aux applications traditionnelles qui exécutent une logique fixe, les agents pilotés par un LLM décident au moment de l'exécution quels outils invoquer, avec quels arguments et dans quel ordre. Il devient donc impossible d'auditer le graphe d'appels à l'avance. Sur des plateformes unifiées comptant des centaines d'agents et des milliers d'outils MCP répartis entre différentes équipes et unités métier, ce manque de contrôle crée un risque réel. La combinaison Cedar pour l'autorisation déterministe et Lambda pour la validation contextuelle dynamique, notamment basée sur la géographie de l'utilisateur, offre une architecture de sécurité en couches adaptée à cette réalité. Ce développement s'inscrit dans un mouvement plus large d'industrialisation de l'IA agentique au sein des entreprises, où les questions de sécurité et de conformité deviennent aussi critiques que la performance des modèles eux-mêmes. Le Model Context Protocol, promu initialement par Anthropic, s'impose progressivement comme standard d'interopérabilité entre agents et outils, et AWS prend position en intégrant nativement la gouvernance des outils MCP dans Bedrock. Lake Formation assure par ailleurs une sécurité au niveau des lignes et des colonnes directement à l'exécution des requêtes, garantissant que même un agent mal configuré ne puisse pas exfiltrer de données hors de son périmètre autorisé. La prochaine étape probable pour Amazon sera d'étendre ces mécanismes à des scénarios multi-agents, où la chaîne de confiance entre agents orchestrateurs et agents subalternes soulève des défis de sécurité encore plus complexes.

InfrastructureActu
1 source
Contrôlez la navigation de vos agents IA avec les politiques Chrome Enterprise sur Amazon Bedrock AgentCore
3AWS ML Blog 

Contrôlez la navigation de vos agents IA avec les politiques Chrome Enterprise sur Amazon Bedrock AgentCore

Amazon a annoncé le support des politiques d'entreprise Chrome et des certificats CA racine personnalisés dans Amazon Bedrock AgentCore Browser. Cette mise à jour permet aux organisations de configurer plus de 450 paramètres de navigateur via des fichiers JSON conformes au standard Chrome Enterprise, stockés dans Amazon S3 et appliqués à chaque session d'agent. Concrètement, les équipes peuvent désormais définir des listes blanches et noires d'URL, bloquer les téléchargements de fichiers, désactiver le gestionnaire de mots de passe ou contrôler le remplissage automatique de formulaires, le tout appliqué au niveau du navigateur, indépendamment de la logique ou des instructions de l'agent. Le support des certificats CA racine, stockés dans AWS Secrets Manager, permet en outre aux agents de se connecter aux services internes qui utilisent une autorité de certification privée, résolvant ainsi les erreurs de validation HTTPS qui bloquaient jusqu'ici l'accès aux infrastructures d'entreprise. L'enjeu est significatif pour les organisations qui déploient des agents IA autonomes sur le web. Un agent sans restriction de navigation peut accéder à des domaines non autorisés, stocker des identifiants dans le navigateur, télécharger des fichiers hors des flux de travail approuvés, voire exfiltrer des données sensibles. Le nouveau système introduit une séparation claire des responsabilités : les équipes de sécurité configurent les politiques au niveau du navigateur via l'API de plan de contrôle, tandis que les développeurs se concentrent sur la logique métier de l'agent, sans avoir à intégrer des décisions de conformité dans le code applicatif. Les politiques dites "managed", stockées côté service et non surchargeables, s'appliquent à toutes les sessions créées à partir d'un navigateur donné, alors que les politiques "recommended", définies au démarrage de session, jouent le rôle de préférences utilisateur et sont écrasées en cas de conflit. Cette évolution s'inscrit dans une tendance plus large : les agents IA accèdent de plus en plus à des interfaces web réelles pour exécuter des tâches, de la saisie de données à la recherche documentaire en passant par la gestion de portails métier. Cette capacité, aussi puissante soit-elle, ouvre des vecteurs d'attaque inédits, manipulation via des pages web malveillantes (prompt injection), exfiltration involontaire, navigation hors périmètre. En s'appuyant sur l'écosystème Chrome Enterprise, déjà utilisé par des millions d'entreprises pour gérer les navigateurs humains, Amazon évite de réinventer une couche de politique maison et offre aux DSI un cadre familier. L'intégration native avec S3 et Secrets Manager renforce l'alignement avec les architectures AWS existantes, ce qui devrait faciliter l'adoption dans les environnements régulés, finance, santé, administration, où le contrôle granulaire de l'accès aux données est non négociable.

UELes entreprises européennes opérant sur AWS dans des secteurs régulés (finance, santé, administration publique) peuvent désormais imposer des politiques de navigation granulaires à leurs agents IA, facilitant la conformité avec le RGPD et les exigences sectorielles de contrôle des accès aux données.

OutilsOpinion
1 source
5 bonnes pratiques pour sécuriser les systèmes d'IA
4AI News 

5 bonnes pratiques pour sécuriser les systèmes d'IA

Les organisations qui intègrent l'intelligence artificielle dans leurs opérations critiques font face à une surface d'attaque inédite que les cadres de sécurité traditionnels n'ont pas été conçus pour couvrir. Face à cette réalité, cinq pratiques fondamentales se dégagent pour protéger ces systèmes : contrôle d'accès strict, défense contre les menaces propres aux modèles, visibilité unifiée de l'écosystème, surveillance continue et gestion rigoureuse des vulnérabilités. Le contrôle d'accès basé sur les rôles (RBAC) limite l'exposition en n'accordant les permissions qu'aux personnes dont la fonction le justifie. Le chiffrement des modèles et des données d'entraînement, aussi bien au repos qu'en transit, constitue une protection indispensable, notamment lorsque ces données contiennent du code propriétaire ou des informations personnelles. Sur le front des menaces spécifiques aux LLM, l'injection de prompt occupe la première place du classement OWASP Top 10 pour les applications à base de grands modèles de langage : un attaquant insère des instructions malveillantes dans une entrée pour détourner le comportement du modèle. Des pare-feux spécialisés pour l'IA, capables de valider et d'assainir les entrées avant qu'elles n'atteignent le modèle, constituent une première ligne de défense directe. Des exercices de red teaming simulant des scénarios réels, empoisonnement de données, attaques par inversion de modèle, permettent de détecter les failles avant que des acteurs malveillants ne les exploitent. L'enjeu dépasse la simple protection technique : c'est la fiabilité de systèmes désormais embarqués dans des décisions critiques qui est en jeu. Un modèle compromis par injection de prompt peut divulguer des données confidentielles, produire des sorties trompeuses ou servir de point d'entrée latéral vers d'autres systèmes. La fragmentation des outils de sécurité aggrave le problème : lorsque les données de télémétrie réseau, cloud, identité et endpoints restent cloisonnées, les équipes ne peuvent pas corréler une connexion anormale, un mouvement latéral et une tentative d'exfiltration en un tableau de menace cohérent. Le cadre de cybersécurité pour l'IA du NIST est explicite sur ce point : sécuriser ces systèmes implique de couvrir l'ensemble des actifs concernés, pas seulement les plus visibles. La sécurité de l'IA ne peut pas être une configuration ponctuelle, car les modèles évoluent en permanence : mises à jour, nouveaux pipelines de données, changements de comportement des utilisateurs. Les outils de détection basés sur des règles statiques peinent à suivre ce rythme, car ils s'appuient sur des signatures d'attaques connues plutôt que sur une analyse comportementale en temps réel. La surveillance continue permet d'établir une baseline comportementale et de signaler immédiatement les déviations : sorties inattendues d'un modèle, variation soudaine dans les appels API, ou accès inhabituels d'un compte privilégié. Ce contexte s'inscrit dans une prise de conscience plus large de l'industrie : les incidents liés à l'IA, du biais algorithmique aux attaques adversariales sophistiquées, se multiplient à mesure que ces systèmes gagnent en puissance et en déploiement, rendant une stratégie de défense en profondeur non plus optionnelle, mais structurellement nécessaire.

UEL'AI Act européen imposant des exigences de sécurité pour les systèmes à haut risque, ces pratiques sont directement pertinentes pour les organisations européennes en phase de mise en conformité.

SécuritéOpinion
1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour

Gratuit · 1 email le matin, l'essentiel de l'IA · désinscription en un clic