SécuritéAWS ML Blog · 16 juin 2026, 23:46· 2 min de lecture

Amazon Bedrock Guardrails : protégez vos applications IA à base d'agents avec l'API InvokeGuardrailChecks

Amazon Web Services a annoncé une nouvelle interface de programmation pour son service Amazon Bedrock Guardrails : l'API InvokeGuardrailChecks. Disponible dès à présent, elle permet aux développeurs d'appliquer des contrôles de sécurité individuels à n'importe quel point d'une application d'IA agentique, sans avoir à créer et gérer des ressources de guardrail dédiées en amont. Concrètement, l'API fonctionne en mode détection seule et retourne des scores numériques pour chaque vérification effectuée. Les équipes peuvent ensuite définir leurs propres seuils et décider de bloquer, contourner, relancer ou journaliser les résultats selon leurs besoins spécifiques.

Cette annonce répond à un problème concret posé par les agents IA modernes, qui fonctionnent en boucles multi-tours plutôt qu'en simples échanges question-réponse. Une session utilisateur peut enchaîner dix, vingt interactions ou davantage, chacune présentant un profil de risque distinct : injection de prompt à l'entrée, contenu nuisible dans la réponse du modèle, données personnelles exposées dans un message de suivi. Jusqu'ici, sécuriser chaque étape de cette boucle supposait de provisionner des ressources de guardrail séparées pour chaque étape, une complexité opérationnelle qui devient ingérable à mesure qu'une organisation déploie des centaines d'agents. L'API InvokeGuardrailChecks supprime cette friction en offrant un contrôle granulaire, requête par requête, sur les vérifications à activer à chaque tour de boucle, sans identifiant de guardrail à suivre ni version à maintenir.

Amazon Bedrock Guardrails existe depuis que l'entreprise a cherché à doter sa plateforme de services IA managés de mécanismes de filtrage du contenu, pour protéger aussi bien les entrées utilisateurs que les sorties des modèles fondamentaux. L'essor des architectures agentiques, où des modèles comme ceux d'Anthropic, Meta ou Mistral orchestrent des outils et prennent des décisions en autonomie, a rendu les approches de sécurité monolithiques insuffisantes. Le nouveau schéma de messages structuré, qui attribue un rôle explicite (système, utilisateur, assistant) à chaque bloc de contenu, permet aux vérifications de prendre en compte le contexte précis de chaque interaction dans la boucle. La prochaine étape pour AWS sera vraisemblablement d'étendre la liste des vérifications supportées et d'intégrer l'API plus étroitement avec les frameworks d'orchestration d'agents comme LangChain ou Amazon Bedrock Agents, alors que la sécurité des systèmes autonomes s'impose comme l'un des défis centraux de l'industrie pour 2026.

Impact France/UE

Les développeurs européens utilisant Amazon Bedrock peuvent intégrer dès maintenant ces contrôles de sécurité granulaires dans leurs agents IA, ce qui facilite la conformité aux exigences de supervision humaine et de gestion des risques imposées par l'AI Act.

Dans nos dossiers

AWS Agents IA Anthropic Mistral AI

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

1AWS ML Blog

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

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.

UELes 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.

SécuritéActu

1 source

2AWS 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

3Amazon Science

Amazon utilise des agents IA pour la détection de vulnérabilités à grande échelle

En 2025, la base de données nationale des vulnérabilités américaine (NVD) a enregistré plus de 48 000 nouvelles failles de sécurité référencées (CVE), un volume rendu possible en grande partie par la prolifération des outils automatisés de détection. Face à cette explosion, Amazon Web Services a développé RuleForge, un système d'intelligence artificielle agentique conçu pour générer automatiquement des règles de détection à partir d'exemples de code d'exploitation de vulnérabilités. Déployé en production chez AWS, RuleForge affiche une productivité supérieure de 336 % à la création manuelle, tout en conservant le niveau de précision exigé pour des systèmes de sécurité industriels. Les règles produites sont au format JSON et alimentent directement MadPot, le système mondial de "honeypot" d'Amazon qui capture le comportement des attaquants, ainsi que Sonaris, le moteur interne de détection d'exploits suspects. Avant RuleForge, transformer une CVE en règle de détection opérationnelle était un processus entièrement manuel : un analyste téléchargeait le code de preuve de concept, étudiait le mécanisme d'attaque, rédigeait la logique de détection, la validait par itérations successives contre les journaux de trafic, puis soumettait le tout à une revue par un second ingénieur avant déploiement. Ce cycle, rigoureux mais lent, obligeait les équipes à prioriser strictement les vulnérabilités traitées, laissant potentiellement des failles critiques sans couverture. RuleForge comprime ce délai de façon drastique : le système ingère automatiquement le code d'exploitation public, attribue un score de priorité via une analyse de contenu croisée avec des sources de threat intelligence, puis génère en parallèle plusieurs règles candidates via un agent tournant sur AWS Fargate avec Amazon Bedrock. Chaque candidate est évaluée non pas par le modèle qui l'a produite, mais par un agent "juge" distinct, évitant ainsi l'auto-validation biaisée. Les humains restent dans la boucle pour l'approbation finale avant mise en production. Cette architecture reflète une tendance profonde dans la sécurité offensive et défensive : l'automatisation par IA ne remplace pas les experts, elle leur permet de travailler à une échelle autrement inaccessible. AWS anticipe une croissance continue du nombre de CVE à haute sévérité publiées, portée par les mêmes outils d'IA qui accélèrent la découverte de failles côté attaquants. RuleForge représente la réponse symétrique côté défense, en industrialisant la réactivité. L'approche modulaire, avec des agents spécialisés pour la génération, l'évaluation et le raffinement, plutôt qu'un seul modèle monolithique, s'inscrit dans la lignée des architectures multi-agents qui émergent comme standard pour les tâches complexes nécessitant fiabilité et auditabilité. D'autres grands acteurs du cloud font face aux mêmes défis, et la publication par Amazon des détails de RuleForge suggère une volonté de positionner cette approche comme référence sectorielle.

SécuritéActu

1 source

4AWS ML Blog

Se retirer d'une action unique : nouvelles fonctionnalités de contrôle des agents et des coûts dans Amazon Bedrock AgentCore

Amazon a annoncé de nouvelles fonctionnalités pour Bedrock AgentCore, sa plateforme dédiée à la construction et au déploiement d'agents IA en entreprise. La mise à jour introduit les politiques temporelles, propulsées par Dogwood, un nouveau langage de politique open source conçu spécifiquement pour les agents IA, ainsi qu'une limitation de débit au niveau de la passerelle (gateway) d'AgentCore. Cette passerelle sert de point d'entrée managé et serverless pour tout le trafic IA, orientant les requêtes vers les serveurs MCP (Model Context Protocol), les modèles de langage, les agents et les bases de connaissances. Jusqu'ici, les politiques de sécurité d'AgentCore évaluaient chaque action de façon isolée et sans état, vérifiant à chaque appel qui pouvait utiliser quel outil et sous quelles conditions. Les politiques temporelles changent cette logique en examinant l'historique complet des actions menées par un agent au cours d'une session avant d'autoriser ou de refuser un nouvel appel. Amazon s'appuie sur des chiffres de McKinsey, tirés de ses études State of AI Trust in 2026 et Trust in the age of AI agents 2026, selon lesquels environ 80% des organisations ont déjà constaté des comportements à risque de la part de leurs agents IA. Cette évolution répond à un problème concret de sécurité: un agent autonome peut enchaîner des actions parfaitement légitimes prises individuellement mais problématiques une fois mises bout à bout. Amazon cite l'exemple d'un agent consultant le compte d'un client puis virant de l'argent vers un numéro de compte différent, chaque appel étant validé séparément sans qu'aucun contrôle ne vérifie la cohérence de la séquence. Autre cas évoqué: une série de commandes passées sous le seuil d'approbation individuel mais qui, cumulées, dépassent largement le budget alloué, ou encore un agent bloqué sur un outil défaillant qui relance ses requêtes toute la nuit et épuise son quota de tokens. Avec les politiques temporelles, une entreprise peut désormais exiger qu'une valeur transmise dans un appel corresponde à celle retournée par un appel précédent, plafonner les dépenses cumulées d'une session, imposer un ordre strict aux étapes d'un processus, ou encore exiger une approbation humaine enregistrée pour toute action significative. Cette annonce s'inscrit dans un contexte où la sécurité et la confiance sont devenues, selon McKinsey, le principal frein à l'adoption des agents IA en entreprise, davantage que les questions de performance ou de coût. Amazon défend une approche où les contrôles de sécurité sont intégrés directement dans la couche d'infrastructure plutôt que codés différemment par chaque équipe applicative, un principe qui guide la conception d'AgentCore depuis son lancement. En rendant ces garde-fous systématiques et fiables au niveau de la plateforme, l'entreprise cherche à transformer l'approbation d'un nouvel agent en un processus géré à grande échelle plutôt qu'en une négociation ponctuelle, ce qui pourrait accélérer le déploiement d'agents autonomes dans des environnements sensibles comme la finance ou les achats automatisés.

SécuritéActu

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