En septembre 2025, Anthropic a détecté et déjoué la première cyberattaque à grande échelle documentée menée principalement par un agent d’IA. Un groupe soutenu par l’État chinois (GTG-1002) a manipulé Claude Code pour cibler environ 30 entreprises dans les secteurs des services financiers, des technologies, de la fabrication et du gouvernement. (Rapport d’Anthropic) L’IA a exécuté de manière autonome 80 à 90 % des opérations tactiques : reconnaissance, découverte de vulnérabilités, exploitation, collecte d’identifiants, déplacement latéral et exfiltration de données. L’intervention humaine s’est limitée aux moments stratégiques critiques, avec environ 20 minutes de direction pratique par phase. Une poignée de cibles ont été compromises avec succès.
Ce n’était pas une démonstration de faisabilité (PoC). Il s’agissait d’une campagne opérationnelle exploitant les mêmes failles architecturales que celles que la plupart des entreprises connaissent aujourd’hui : aucun filtrage au niveau de la couche modèle n’a détecté les invites manipulées, aucun framework d’identité des agents n’a identifié un fonctionnement autonome non autorisé, et aucun relais d’agent n’a appliqué de contrôles au niveau de l’outil pendant l’exécution. Le Top 10 de l’OWASP pour les applications agentiques, publié en décembre 2025 avec la contribution de plus de 100 experts du secteur, codifie précisément ces modes de défaillance — détournement des objectifs d’un agent (ASI01), utilisation abusive d’outils (ASI02) et abus d’identité et de privilèges (ASI03) — comme les trois principaux risques.
CHAÎNE D’ATTAQUE DE SEPTEMBRE 2025 | OÙ L’ARCHITECTURE INTERVIENT | |
|---|---|---|
▶ Jailbreaking Tromperie par jeu de rôle et décomposition des tâches | ← | ✓ MODÈLE : le filtrage des invites détecte la manipulation |
▶ Reconnaissance Énumération des services, analyse du réseau | ↓ | |
▶ Exploitation Collecte d’identifiants, exploitation de vulnérabilités | ← | ✓ IDENTITÉ : aucune chaîne de délégation valide, agent bloqué |
▶ Déplacement latéral Réutilisation des identifiants entre les systèmes | ↓ | |
▶ Exfiltration de données Requêtes de base de données, extraction de données en masse | ← | ✓ DONNÉES : le relais d’agent applique les contraintes des outils/paramètres |
Ce n’est pas un événement isolé. 88 % des entreprises ont signalé des incidents de sécurité confirmés ou présumés impliquant des agents d’IA au cours de l’année écoulée (enquête Gravitee), et parmi les entreprises ayant subi des brèches liées à l’IA, 97 % ne disposaient pas de contrôles d’accès appropriés pour leurs systèmes d’IA (IBM/Ponemon). Seulement 22 % considèrent les agents d’IA comme des entités indépendantes dotées d’une identité (Gravitee).
Autrement dit, si vous avez des agents en production et que vous n’avez pas encore rencontré d’incident, c’est probablement que vous ne l’avez pas encore détecté.
La bonne architecture
Les entreprises déploient des agents dans trois zones de confiance distinctes. Les agents internes (bots de support IT, agents RH, bots financiers extrayant des rapports ERP) opèrent à l’intérieur du périmètre de l’entreprise. Les agents orientés clients (assistants de support, IA en libre-service interrogeant les bases de connaissance internes pour le compte des utilisateurs finaux) font le lien entre les ressources internes et les consommateurs externes. Les agents partenaires (intégrations de la chaîne logistique, prestation de services interorganisationnelle) opèrent entièrement au-delà des frontières organisationnelles. Les exigences de sécurité augmentent avec chaque modèle. Les agents internes ont besoin d’une gouvernance des identités et du cycle de vie. Ajoutez un agent orienté client et vous aurez besoin de processus d’autorisation déléguée et de consentement. L’extension aux partenaires implique la gestion de la confiance interdomaine et des contrôles du flux de données. Les trois zones de confiance nécessitent la même architecture de base.
AWS, Google, Anthropic et Microsoft ont chacun intégré des contrôles de sécurité des agents dans leurs propres plateformes, qui peuvent être associés à ces trois mêmes couches. Cela valide l’architecture. Mais les entreprises n’exécutent pas d’agents sur une seule plateforme. Elles ont besoin d’une identité et d’une autorisation qui fonctionnent sur l’ensemble des plateformes. Gartner prévoit que 25 % des brèches d’entreprise seront attribuées à l’utilisation abusive d’agents d’IA d’ici 2028. McKinsey qualifie les agents d’IA d’« acteurs numériques internes » nécessitant la même gouvernance que les collaborateurs. L’architecture converge. La question est de savoir si votre entreprise adoptera cette approche de manière proactive ou réactive.
Couche 1 Sécurité des modèles | Couche 2 Identité des agents | Couche 3 Autorisation des données |
|---|---|---|
|
|
|
« Ce modèle est-il approuvé et agit-t-il dans les limites autorisées ? » | « Cet agent est-il autorisé à agir au nom de cet utilisateur ? » | « Cet outil doit-il s’exécuter avec ces paramètres maintenant ? » |
Couche 1 : sécurité des modèles, sécurisation des renseignements
Lors de la campagne de septembre 2025, des pirates ont contourné les dispositifs de sécurité grâce à la tromperie par jeu de rôle et à la décomposition des tâches, divisant les attaques en plusieurs étapes en requêtes discrètes qui semblaient légitimes individuellement (Anthropic). Aucun humain ne vérifie des milliers d’invites par minute. La sécurité de la couche modèle est ce qui se dresse entre une invite manipulée et un réseau compromis.
L’évaluation des modèles et les simulations d’attaque permettent de détecter les vulnérabilités avant la mise en production. La défense contre l’injection d’invites détecte les instructions malveillantes cachées dans des documents, des e-mails ou des réponses d’outils, tandis que les garde-fous de sortie et la DLP empêchent les fuites de données sensibles. La surveillance continue des E/S relie tous les éléments, signalant les comportements anormaux en temps réel. Il ne s’agit pas de risques théoriques. Des chercheurs ont découvert de véritables vulnérabilités MCP en environnement réel : l’empoisonnement d’outils via des serveurs MCP malveillants, l’injection d’invites via des réponses d’outils, et les attaques de la chaîne logistique sur des packages MCP (OWASP). AWS Bedrock Guardrails et Google Cloud Model Armor offrent tous deux un filtrage configurable et indépendant du modèle lors de l’exécution. Si le modèle est compromis, rien de ce que vous créez avec celui-ci n’a d’importance.
Couche 2 : identité des agents, sécurisation de l’acteur
Une fois que le modèle est fiable, l’agent a besoin d’une identité, et non d’un compte de service partagé ou d’une clé API statique. Une véritable identité, avec un propriétaire qui répond en cas de problème, des autorisations délimitées et temporaires, et un cycle de vie qui se termine quand il le doit.
Avant l’IA, le code régnait en maître. Vous saviez de manière déterministe ce qui allait se passer. Mais maintenant, avec les agents d’IA, vous donnez une instruction… il n’y a aucune garantie quant aux systèmes auxquels ils accéderont en réaction. Vous ne savez pas s’ils vont utiliser un niveau d’accès supérieur pour accéder à un système que vous n’aviez même pas prévu.
Harish Peri, SVP et GM, Okta
L’identité des agents commence par la découverte : combien d’agents fonctionnent, qui les a créés, quels identifiants détiennent-ils ? L’étude AI at Work d’Okta a révélé que 91 % des entreprises déploient déjà des agents d’IA, mais que seulement 10 % d’entre elles disposent d’une stratégie de gouvernance efficace. Lors de chaque atelier client que nous organisons, la première question est toujours la même : « Combien d’agents avons-nous réellement ? ». La réponse est presque toujours la suivante : « Nous ne savons pas ». Chaque agent reçoit une identité durable, un propriétaire désigné et une classification. L’autorisation suit la délégation : l’agent agit au nom d’un utilisateur spécifique, avec un ensemble spécifique d’autorisations, pour une tâche spécifique. Okta Cross App Access (XAA), un protocole ouvert étendant OAuth désormais intégré à MCP sous le nom d’Enterprise-Managed Authorization, rend ces chaînes de délégation auditables. Lorsque la chaîne se brise, l’accès s’arrête. La gestion du cycle de vie via SCIM offre la même gouvernance que pour les identités humaines : évaluations des accès, déprovisioning automatisé, responsabilité des propriétaires. Lorsque l’utilisateur déléguant est désactivé ou qu’une politique change, la révocation se propage à tous les systèmes en aval.
Mais l’identité seule ne suffit pas à combler ce fossé. Savoir qu’un agent est autorisé ne revient pas à savoir s’il doit transférer 50 000 $ à partir de ce compte, à cet instant, à 2 h du matin, à un destinataire avec lequel il n’a jamais interagi auparavant.
Couche 3 : autorisation des données, sécurisation de l’action
Les politiques OAuth vérifient le token. Champs d’application valides, profil cible valide, non expiré. C’est nécessaire, mais loin d’être suffisant. Le token indique que l’agent peut effectuer des transferts. Cela ne dit rien sur la pertinence de ce transfert, à ce destinataire, pour ce montant.
L’identité et les périmètres ne fournissent que des contrôles peu granulaires sur les actions des agents. Les garde-fous liés à l’utilisation des outils offrent davantage de pouvoir pour contrôler avec précision les actions à autoriser.
Google Cloud, documentation sur la sécurité du kit de développement d’agents
Le comportement des agents n’est pas déterministe. Le LLM sélectionne des outils lors de l’exécution, remplit les paramètres en fonction de son raisonnement, et enchaîne les opérations dans des séquences que personne n’avait anticipées lors de la rédaction de la politique. C’est là que se trouve un relais d’agent : le point d’application entre l’agent et les outils qu’il invoque. Le relais d’agent d’Okta applique des contrôles d’exécution granulaires : accès au niveau de l’outil (quels outils cet agent peut-il invoquer ?), contraintes des paramètres (le montant est-il dans les limites ?), approbation « humain dans la boucle » via CIBA (Client-Initiated Backchannel Authentication) pour les opérations à haut risque, gouvernance du flux de données entre applications (la sortie de l’outil A est-elle autorisée comme entrée de l’outil B ?) et piste d’audit d’invocation complète.
Le relais d’agent ne remplace pas l’identité. Il prend le relais là où l’identité s’arrête. L’identité détermine ce qui doit être inclus dans le token. Le relais d’agent décide de ce qui se passe au moment de l’exécution, en utilisant ce qui se trouve dans ce token. Les revendications transmettent le contexte d’une couche à l’autre. Il n’y a pas d’écart entre l’identité de l’agent et ce qu’il est autorisé à faire.
Les conséquences de l’absence de chaque couche
Sans sécurité des modèles | Sans identité des agents | Sans autorisation des données |
|---|---|---|
|
|
|
Une étude de Kiteworks menée auprès de 225 responsables de la sécurité a révélé que 100 % d’entre eux ont l’IA agentique sur leur roadmap, mais que 63 % ne peuvent pas imposer de limitations d’usage et que 60 % ne peuvent pas mettre fin à un agent qui se comporte mal. Les contrôles manquants sont ceux qui comptent le plus.
L’avenir de l’architecture
L’architecture à trois couches comble les lacunes structurelles que la plupart des entreprises connaissent aujourd’hui. Trois domaines évoluent rapidement et définiront la prochaine phase :
- Délégation récursive : l’agent A délègue à l’agent B, qui délègue à l’agent C. Jusqu’où l’autorité se propage-t-elle ? Qui révoque en profondeur ? Okta Cross App Access (XAA) avec ID-JAG maintient la chaîne de traçabilité en intégrant l’identité de l’utilisateur et celle de l’agent dans chaque échange de tokens, avec une réduction de la portée à chaque étape de délégation. La gestion du cycle de vie SCIM permet de garantir que lorsqu’un utilisateur déléguant est désactivé, la révocation se propage. La dernière étape consiste à standardiser les limites de profondeur de délégation et la signalisation de révocation multisauts, un travail auquel la spécification OAuth Identity and Authorization Chaining s’attaque activement.
- Dérive des autorisations : un agent est autorisé au moment de l’invocation, mais les autorisations de l’utilisateur changent en cours de chaîne. Comment la révocation atteint-elle une opération déjà en cours ? Les token à courte durée de vie avec des fenêtres d’expiration courtes limitent l’impact. L’authentification renforcée basée sur CIBA peut revérifier l’autorisation aux points de décision à haut risque. Les politiques d’accès d’Okta appliquent les attributions de champ d’application par appartenance à des groupes, ce qui fait qu’une modification des autorisations au niveau de l’annuaire prend effet lors du prochain échange de tokens. Le défi réside dans la signalisation de révocation en temps réel sur les chaînes d’exécution actives, sans interruption des opérations légitimes.
- Zones de confiance interdomaines : un agent enchaîne des outils à travers deux applications SaaS comportant des modèles de confiance et des schémas de classification des données différents. Qu’est-ce qui régit la frontière ? Dans un domaine de confiance unique, Okta XAA et les serveurs d’autorisation personnalisés par ressource appliquent déjà un accès délimité à chaque changement de zone. Auth0 Token Vault étend cette fonctionnalité aux ressources OAuth tierces (Google, GitHub, Salesforce) grâce au consentement géré par un intermédiaire et à la conversion de tokens. La question des limites interorganisationnelles, où deux IdP indépendants doivent établir une confiance mutuelle pour la délégation d’agents, constitue le prochain défi. La spécification OAuth Identity Chaining fournit la base architecturale et Okta contribue activement à son développement.
Ce sont des problèmes complexes avec des voies architecturales claires à suivre. L’OWASP Agentic Security Initiative et l’OpenID Foundation développent toutes deux des frameworks. Les entreprises qui établissent un socle à trois couches dès maintenant seront bien positionnées pour adopter ces contrôles à mesure qu’ils se développent.
Où en êtes-vous aujourd’hui ?
Évaluez la situation de votre entreprise au niveau de chaque couche. La plupart des entreprises sont au niveau « Réactif » dans au moins deux couches.
Sécurité des modèles | Identité des agents | Autorisation des données | |
|---|---|---|---|
Réactif | Pas de registre de modèles ; aucun filtrage des entrées ou des sorties | Les agents utilisent des clés API partagées ou des identifiants personnels | Aucune application au niveau de l’outil ; pas de journalisation des invocations |
Géré | Registre ; garde-fous sur les modèles principaux ; simulations d’attaque périodiques | Agents enregistrés ; tokens statiques ; vérifications manuelles du cycle de vie | Relais d’agent sur certains outils ; piste d’audit partielle |
Solution adaptative | Gouvernance de tous les modèles ; surveillance en temps réel ; évaluation continue ; DLP appliquée | Délégation OAuth ; cycle de vie SCIM ; propagation de la révocation entre applications | Mise en œuvre complète des outils ; contraintes des paramètres ; CIBA ; audit complet |
Okta et Auth0 fournissent l’infrastructure d’identités et d’autorisations nécessaire pour passer d’une approche réactive à une approche adaptative aux couches 2 et 3. En tant que seule plateforme d’identité indépendante spécialement conçue pour la gestion des identités des collaborateurs et des clients, Okta considère les identités des agents comme une priorité nécessitant la même gouvernance que les identités humaines, basée sur des standards ouverts tels que XAA et SCIM, plutôt que sur une dépendance propriétaire.
Si vous vous êtes évalué comme étant au niveau « Géré » dans les trois couches, vous êtes probablement généreux.
Le parcours de 90 jours
Jours 1 à 30 : évaluation | Jours 31 à 60 : implémentation | Jours 61 à 90 : opérationnalisation |
|---|---|---|
|
|
|
Conclusion
L’attaque de septembre 2025 a prouvé que les menaces liées à l’IA agentique sont opérationnelles. Les données du secteur confirment que la plupart des entreprises ne sont pas prêtes. L’architecture à trois couches n’est pas une idée nouvelle. C’est ce que les plus grandes entreprises de plateforme au monde ont développé indépendamment, ce que les organismes de normalisation codifient et ce qu’exigent les données relatives aux incidents. La seule question qui reste est celle de la rapidité.
Le contexte est la nouvelle référence. L’intention est le nouveau périmètre. L’avenir de la sécurité de l’IA repose sur la connexion de la sécurité des modèles, de l’identité des agents et de l’autorisation des données dans une chaîne de confiance unique.
Aujourd’hui, des technologies existent pour résoudre ce problème. Découvrez comment Okta et Auth0 sécurisent les agents d’IA sur okta.com/fr-fr/ai et auth0.com/fr/ai. Nous pouvons vous aider. Collaborez avec nous.
Parcourez davantage d’informations sur la sécurité de l’IA :
- Sécurité des agents d’IA : développer une confiance autonome à la vitesse des machines. Série Perspectives en sept parties par Okta.
- Les agents d’IA imposent un choix fondamental. Mais vous n’êtes pas obligé de choisir. L’identité est l’élément de base qui permet d’éviter ce dilemme. Les agents peuvent être soit utiles, soit sécurisés.
