SécuritéAWS ML Blog6sem· 2 min de lecture

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.

Impact France/UE

Les é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.

Dans nos dossiers

Microsoft AWS Agents IA

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

Amazon Bedrock AgentCore permet d'héberger des agents de codage en toute sécurité

Amazon a lancé Bedrock AgentCore Runtime, un service cloud conçu pour héberger les agents de codage, Claude Code, Codex, Kiro, Cursor CLI, Gemini CLI ou tout autre outil similaire, sans que le développeur n'ait à garder son ordinateur portable allumé et ouvert. Chaque session obtient un microVM Linux isolé avec un espace de travail persistant, un shell réel et une exécution déterministe des commandes. Le service embarque également trois composantes clés : une couche d'identité qui fait agir l'agent au nom de l'utilisateur qui l'a déclenché, une passerelle MCP (Model Context Protocol) unique donnant accès à GitHub, Jira, Slack et aux services internes avec les vrais tokens stockés hors de portée de l'agent, et une intégration native à Amazon CloudWatch pour tracer chaque action effectuée. Amazon annonce que plusieurs agents concurrents, Claude Code, Codex, Kiro et Cursor, pourront être lancés simultanément sur le même dépôt, chacun dans son propre environnement isolé, et évalués sur la latence, le coût et le taux de réussite des tests. L'enjeu va bien au-delà du confort : héberger un agent de codage sur un laptop expose l'ensemble de l'environnement du développeur. L'agent partage le shell, le système de fichiers, les clés SSH, les credentials AWS stockés dans ~/.aws/credentials, les tokens npm, et le VPN actif. Un fichier README piégé suffit à déclencher une exécution malveillante avec accès complet aux secrets. La parallélisation pose un problème distinct : lancer deux agents via git worktree ne règle que la partie git, les deux processus se battent toujours pour le même localhost:5432, le même port :3000, le même trousseau SSH. Trois agents sur trois branches, c'est trois processus en compétition sur une seule machine. Enfin, fermer le couvercle du laptop tue la session : dépendances à moitié installées, refactoring en cours, suite de tests en attente, tout disparaît. Un chantier de 90 minutes ou une migration nocturne exige que l'écran reste allumé pendant toute la durée. La montée en puissance des agents de codage autonomes a rendu ce problème structurel. Ces outils peuvent désormais tenir des tâches longues, audit de codebase, migrations de schéma, refactoring multi-fichiers, qui dépassent largement la durée d'une session de travail classique. Les équipes qui veulent en tirer parti à l'échelle se heurtent aux limites du modèle "un agent par laptop ouvert". Amazon positionne AgentCore comme la réponse infrastructure à ce changement de régime : un environnement cloud dédié par agent, cloisonné par défaut, observable dès le départ, et déconnecté du cycle de vie de la machine du développeur. Le service s'inscrit dans une compétition plus large entre AWS, Google et Microsoft pour capter les workflows d'IA des équipes engineering, à mesure que les agents de codage passent du statut d'expérimentation à celui d'outil de production.

UELes équipes engineering européennes qui déploient des agents de codage autonomes peuvent désormais héberger leurs workflows sur une infrastructure cloud isolée et observable, sans dépendance au cycle de vie de leur machine locale.

InfrastructureOpinion

1 source

2The Verge AI

Le PDG d'Okta mise sur l'identité des agents IA

Todd McKinnon, co-fondateur et PDG d'Okta, a accordé une interview approfondie au podcast Decoder de The Verge pour expliquer comment il réoriente sa stratégie face à l'essor de l'IA. Okta, valorisée à 14 milliards de dollars, est l'une des principales plateformes de gestion des identités et de la sécurité en entreprise — ce système qui oblige les employés à se reconnecter plusieurs fois par jour avant chaque réunion. Lors du dernier appel aux investisseurs, McKinnon a admis être « paranoïaque » face à ce que l'industrie appelle désormais la « SaaSpocalypse » : la menace que les entreprises construisent elles-mêmes leurs outils grâce au vibe-coding et aux LLMs, plutôt que de payer des abonnements SaaS coûteux à des acteurs comme Okta. L'enjeu est considérable. Si des milliers d'entreprises clientes décident de développer en interne ce qu'Okta leur vend, le modèle économique de tout un pan du secteur logiciel est remis en cause. Mais McKinnon identifie une opportunité stratégique précisément là où la menace est la plus forte : la gestion des identités des agents IA. Là où Okta gérait jusqu'ici les accès des humains — employés, sous-traitants, partenaires — il faut désormais faire de même pour les agents autonomes déployés au sein des organisations. Ces agents accèdent à des données sensibles, exécutent des tâches critiques, et peuvent agir au nom d'un utilisateur avec ses propres identifiants. La question de sécurité est immédiate : que se passe-t-il quand un employé achète un Mac Mini, y transfère ses credentials, et laisse un agent IA faire ce qu'il veut avec eux ? McKinnon propose d'intégrer un « kill switch » au niveau de l'agent — un mécanisme d'interruption d'urgence — mais reconnaît que l'identité d'un agent se situe quelque part entre celle d'une personne et celle d'un système informatique classique, un espace conceptuel encore largement à définir. Le contexte est celui d'une mutation structurelle de l'industrie logicielle. L'émergence d'outils comme OpenClaw — une plateforme d'agents IA qui s'est accompagnée de nombreuses failles de sécurité — illustre l'urgence du problème. Les entreprises commencent à déployer des équipes hybrides, mélangeant salariés humains et agents autonomes, sans cadre clair pour gouverner les droits d'accès de ces derniers. Okta, qui a construit sa position dominante sur la gestion des identités humaines, ambitionne de devenir la référence pour cette nouvelle couche d'identité machine. McKinnon mise sur cette transition pour transformer la menace existentielle de la SaaSpocalypse en avantage compétitif — à condition de se réinventer assez vite.

UELes entreprises européennes déployant des agents IA autonomes font face au même vide de gouvernance sur les droits d'accès, sans cadre réglementaire ni standard technique établi pour gérer les identités machine.

SécuritéOpinion

1 source

3AWS ML Blog

Amazon Bedrock AgentCore Identity permet désormais de référencer ses propres secrets AWS Secrets Manager

Amazon a annoncé une nouvelle fonctionnalité pour Amazon Bedrock AgentCore Identity qui permet désormais aux développeurs de référencer leurs propres secrets AWS Secrets Manager existants, plutôt que de laisser le service en créer automatiquement de nouveaux. Jusqu'à présent, AgentCore Identity gérait de façon autonome un coffre-fort de jetons qui créait et administrait un secret dans Secrets Manager pour chaque fournisseur d'identité externe configuré. Cette approche fonctionnait, mais elle privait les équipes de toute maîtrise sur la configuration de ces secrets : impossible d'y apposer des tags personnalisés, d'imposer une politique de rotation, ou d'appliquer un chiffrement via une clé KMS gérée par le client. La nouvelle capacité, disponible dès aujourd'hui, lève ces contraintes en permettant de fournir directement l'ARN d'un secret préconfiguré à la ressource de fournisseur d'identité. Concrètement, les organisations conservent désormais un contrôle total sur le cycle de vie de leurs secrets d'API utilisés par leurs agents IA : chiffrement avec une clé KMS maison, politique de rotation automatique, réplication, tags pour l'allocation des coûts ou la conformité, et politiques de ressources IAM granulaires. Quand la valeur d'un secret est mise à jour suite à une rotation, AgentCore Identity récupère automatiquement la nouvelle valeur à la prochaine lecture, sans qu'il soit nécessaire de recréer ou de modifier la configuration du fournisseur de credentials. Il est également possible de référencer un secret hébergé dans un autre compte AWS, dans la même région, et les secrets importés via des connecteurs externes Secrets Manager permettent l'intégration avec des gestionnaires de secrets tiers comme HashiCorp Vault. Cette annonce s'inscrit dans une tendance plus large : la montée en puissance des agents IA en production dans les entreprises, qui soulève des exigences de sécurité et de gouvernance de plus en plus strictes. Les équipes cloud des grandes organisations opèrent souvent dans des environnements régulés, avec des politiques SCP et RCP imposant un chiffrement obligatoire par clés gérées par le client, ou des audits de conformité exigeant une traçabilité précise par tags. En permettant à AgentCore de s'insérer dans les workflows de gestion des secrets déjà en place, AWS répond directement à ces contraintes sans obliger les entreprises à dupliquer leur infrastructure ou à contourner leurs propres politiques de sécurité. La prochaine étape naturelle sera probablement l'extension à des secrets cross-région, aujourd'hui encore absente.

UELes entreprises européennes opérant dans des secteurs régulés (finance, santé) pourront intégrer AgentCore dans leurs workflows de gestion des secrets conformes au RGPD et aux exigences de chiffrement imposées par leurs politiques internes ou réglementaires.

OutilsActu

1 source

4AWS ML Blog

AWS et Cisco AI Defense sécurisent les déploiements MCP et A2A pour les agents IA

Cisco et AWS ont annoncé un partenariat pour sécuriser les déploiements d'agents IA en entreprise, ciblant en particulier deux protocoles devenus centraux dans l'industrie : le Model Context Protocol (MCP), lancé en novembre 2024, et le protocole Agent-to-Agent (A2A), introduit en avril 2025. Le MCP permet aux agents IA de se connecter à des sources de données et des API externes, tandis que l'A2A autorise des agents autonomes à communiquer entre eux sans intervention humaine. Les grandes entreprises gèrent aujourd'hui des dizaines, voire des centaines de serveurs MCP simultanément, et cette prolifération rapide a ouvert trois failles de sécurité majeures : absence de visibilité sur les outils déployés, incapacité des équipes de sécurité à réviser manuellement chaque composant au rythme des déploiements, et manque de journaux d'audit exigés par les cadres réglementaires. La réponse conjointe des deux groupes repose sur l'AI Registry, un projet open source soutenu par AWS, intégré à la plateforme Cisco AI Defense, qui automatise l'analyse de sécurité de chaque serveur MCP, agent IA et Agent Skill avant toute mise en production. L'impact concret est significatif pour les équipes de sécurité et les directions conformité. Actuellement, les processus de révision manuelle allongent chaque déploiement d'application IA de plusieurs semaines, créant un arriéré qui s'accumule à mesure que l'adoption de l'IA s'accélère. Avec ce système, dès qu'un nouveau composant est enregistré dans le registre centralisé, un scanner analyse automatiquement le code, les patterns de sécurité et les éventuelles vulnérabilités, puis génère un rapport détaillé. Si des problèmes sont détectés, le composant est immédiatement désactivé et marqué "security-pending", bloquant tout accès jusqu'à validation par un administrateur. Cette automatisation concerne aussi bien les serveurs MCP donnant accès à des bases de données que les agents A2A orchestrant des workflows complexes. Sur le plan réglementaire, les organisations s'exposaient auparavant à des sanctions sous les cadres SOX et RGPD faute de traçabilité suffisante sur les agents autonomes, une exposition que les équipes de conformité peinaient à quantifier. Cette initiative s'inscrit dans un contexte de montée en puissance rapide de l'IA agentique, qui transforme profondément les infrastructures d'entreprise. La prolifération non contrôlée de serveurs MCP et d'agents tiers représente un vecteur d'attaque croissant : du code malveillant ou des patterns non sécurisés peuvent s'introduire dans la chaîne d'approvisionnement logicielle sans qu'aucune revue manuelle ne puisse suivre le rythme. Akshay Bhargava, vice-président produit IA chez Cisco, souligne que ce partenariat vise à étendre la protection de niveau entreprise aux organisations de toute taille via les registres publics. Le marché de la sécurité pour l'IA agentique est encore naissant, et cette collaboration entre un géant du cloud et un leader du réseau envoie un signal fort : la gouvernance des agents IA devient un prérequis incontournable pour tout déploiement industriel sérieux.

UELes organisations européennes déployant des agents IA s'exposaient à des sanctions RGPD faute de traçabilité sur les agents autonomes ; cette solution automatise les journaux d'audit requis par la conformité européenne.

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, rédigé par un humain · désinscription en un clic