Renforcez vos pratiques CloudSec
Découvrez des recommandations concrètes pour réduire les risques et sécuriser efficacement vos environnements cloud.
Les systèmes d’IA traditionnels sont généralement passifs. Ils reçoivent une entrée, génèrent un output, puis s’arrêtent. Du point de vue de la sécurité, cela correspond à des schémas connus : inference endpoints, artefacts de modèles et accès aux données. Vous les surveillez et les contrôlez comme des événements distincts.
Les systèmes d’IA agentique changent ce modèle en introduisant l’autonomie. Plutôt que de répondre à une seule requête, les agents poursuivent des objectifs dans la durée. Ils planifient des actions, invoquent des outils et interagissent avec les services cloud via des identités déléguées, souvent sans approbation humaine à chaque étape.
L’impact sur la sécurité vient de la capacité, pas de la cognition. Les systèmes agentiques nécessitent souvent :
un état persistant ou partagé pour suivre la progression ;
un accès aux API d’infrastructure, aux datastores et aux services externes ;
des identités non humaines dotées de larges permissions pour agir entre les systèmes.
Pris isolément, aucun de ces éléments n’est nouveau. Les équipes de sécurité gèrent déjà les comptes de service, l’automatisation et les workflows de longue durée. La différence tient à l’IA agentique : elle réunit ces éléments dans un seul système qui agit en continu et à travers les frontières.
C’est là que les hypothèses traditionnelles commencent à céder. Les contrôles conçus pour des actions courtes et pilotées par des humains peinent quand les décisions, l’exécution et l’état sont répartis entre les systèmes et exécutés automatiquement. Une action qui ressemble à de l’automatisation de routine représente parfois un risque réel, vue comme une séquence orientée vers un objectif.
En pratique, l’IA agentique n’introduit pas de techniques d’attaque exotiques. Elle réduit les frictions sur celles qui existent déjà. Les erreurs de configuration cloud connues (identités sur-privilégiées, limites de confiance floues et accès aux données excessif) deviennent alors plus faciles à exploiter et plus difficiles à analyser sans visibilité contextuelle.
Pourquoi l’IA agentique brise les hypothèses de sécurité traditionnelles
La plupart des contrôles de sécurité cloud reposent sur des hypothèses implicites : les actions sont initiées par des humains, limitées dans le temps et cantonnées à un seul domaine. L’usage des identités est censé être intermittent, les permissions sont revues périodiquement et les workflows suivent des chemins prévisibles.
Les systèmes d’IA agentique remettent en cause ces hypothèses. Le problème ne vient pas d’un comportement imprévisible, mais d’un fonctionnement continu et transversal. Un système autonome réutilise la même identité, invoque plusieurs services à la suite et conserve son état entre les sessions, dans le cadre de son fonctionnement normal.
Cela crée des angles morts pour les contrôles pensés autour d’événements isolés. Un simple appel d’API, une requête de database ou une modification de configuration paraît anodin isolément. Le risque n’apparaît que lorsque ces actions sont corrélées entre les identités, les ressources et le temps.
Les systèmes agentiques brouillent aussi les limites de confiance. Ils relient souvent des environnements non conçus pour se faire implicitement confiance : datastores et environnements d’exécution, outils internes et services externes, ou pipelines CI/CD et infrastructure de production. Quand ces limites sont franchies automatiquement, les erreurs de configuration se propagent plus vite et deviennent plus difficiles à contenir.
Du point de vue de la sécurité, le défi n’est pas que l’IA agentique introduise un comportement inconnu. C’est que les lacunes de contrôle existantes deviennent plus difficiles à analyser quand l’exécution est automatisée, persistante et distribuée.
Domaines de menaces de l’IA agentique selon OWASP (transposés au cloud)
Le projet OWASP Agentic AI classe ces risques en domaines de menaces précis. Pour les rendre exploitables, transposons-les dans les termes de sécurité cloud que vous connaissez déjà.
Le guide pratique des responsables sécurité
Accédez à des conseils opérationnels pour prioriser vos actions, aligner vos équipes et mieux maîtriser votre posture cloud.
Agentivité excessive et défaillances d’autorisation
L’agentivité excessive survient quand un agent reçoit plus d’autorité que nécessaire pour remplir sa fonction en toute sécurité. Dans les environnements cloud, cela se traduit le plus souvent par des comptes de service sur-privilégiés, des permissions d’API trop larges ou une exécution d’outils sans restriction.
Les systèmes agentiques ont souvent besoin d’accéder à plusieurs services pour fonctionner. Quand ces permissions ne sont pas strictement délimitées, l’agent hérite du même profil de risque que toute automatisation sur-privilégiée : lire des données sensibles, modifier l’infrastructure ou déclencher des actions en aval hors de son rôle prévu.
Ce mode de défaillance n’est pas nouveau. Il reflète la cause profonde de nombreux incidents de sécurité cloud actuels. Avec l’IA agentique, les permissions excessives s’exercent en continu et automatiquement, ce qui augmente le rayon d’impact en présence d’erreurs de configuration.
Défaillances d’intégrité de l’état et de la mémoire
De nombreux systèmes agentiques dépendent d’un état modifiable pour fonctionner : vector databases, stockage d’objets ou datastores de contexte partagés qui conservent l’information entre les interactions. Quand cet état est mal protégé, les agents consomment des données non fiables ou corrompues comme des entrées de référence.
L’impact de ce risque dépend fortement de l’architecture. Les systèmes qui conservent un état partagé ou de longue durée sont plus exposés, car un contexte corrompu persiste entre les exécutions. À l’inverse, les agents sans état ou strictement délimités sont bien moins touchés, puisqu’ils ne réutilisent ni état ni mémoire entre les tâches.
Du point de vue de la sécurité, il s’agit d’un problème d’intégrité des données et de contrôle d’accès, pas d’un comportement d’IA inédit. Protéger la mémoire d’un agent exige les mêmes contrôles que pour d’autres données applicatives sensibles : restreindre l’accès en écriture, valider les entrées et surveiller les modifications non autorisées.
Défaillances d’exécution d’outils et de franchissement des limites
Les systèmes agentiques interagissent souvent avec des outils et services externes pour accomplir des tâches : déployer de l’infrastructure, interroger des sources de données ou déclencher des workflows. Le risque apparaît quand les agents franchissent des limites de confiance non conçues pour une exécution automatique.
Dans les environnements cloud, cela inclut souvent :
des datastores qui déclenchent des chemins d’exécution ;
des systèmes CI/CD qui interagissent directement avec les ressources de production ;
des systèmes internes qui invoquent des API externes sans validation.
Lorsque ces limites sont franchies par programme, une erreur de configuration dans un domaine se propage rapidement à un autre.
Supply chain agentique et confiance déléguée
Les systèmes agentiques s’appuient souvent sur des composants externes (outils tiers, API, modèles ou workflows) pour accomplir des tâches. Quand ces dependencies sont invoquées automatiquement à l’exécution, des décisions de confiance autrefois revues par des humains s’intègrent aux chemins d’exécution.
Cela introduit un risque de supply chain, non parce que les composants sont dangereux par nature, mais parce que les agents consomment des ressources externes et agissent dessus sans validation contextuelle. Une dependency compromise, une intégration mal configurée ou une mise à jour malveillante se propage dans les workflows d’agents plus vite que les processus traditionnels validés par des humains.
Du point de vue de la sécurité cloud, cela reflète les enjeux existants de software supply chain security, amplifiés par l’automatisation. OWASP le présente comme un risque de supply chain agentique : l’incapacité à contrôler, valider et surveiller explicitement ce que les systèmes autonomes sont autorisés à importer, exécuter, ou ce dont ils dépendent.
Détournement des identités et des identités non humaines
Les systèmes agentiques dépendent fortement d’identités non humaines comme les comptes de service, les rôles et les tokens pour fonctionner de façon autonome. Ces identités sont souvent de longue durée et largement permissionnées pour soutenir l’automatisation.
Mal gérées, les identités non humaines deviennent un vecteur d’attaque majeur. L’abus de comptes de service, des tokens divulgués ou des erreurs de configuration OAuth donnent aux attaquants le même niveau d’accès qu’un agent de confiance.
Ce risque rejoint directement les schémas d’attaque connus sur les identités cloud. L’IA agentique n’introduit pas de nouvelles menaces sur les identités ; elle amplifie l’impact des défaillances d’identité en les liant à une exécution continue.
Défaillances de confiance et de coordination entre agents
À mesure que les organisations déploient plusieurs agents qui communiquent ou se délèguent des tâches, de nouvelles relations de confiance apparaissent. Ces interactions reposent souvent sur des files partagées, des workflows pilotés par les événements ou des hypothèses implicites sur l’intégrité des messages.
Quand les limites de confiance entre agents ne sont pas définies explicitement, la compromission ou une erreur de configuration d’un composant en influence d’autres. Il s’agit moins d’un comportement d’IA en cascade que de la confiance dans un système distribué.
Le risque sous-jacent reflète des problèmes anciens des microservices et des architectures pilotées par les événements, désormais appliqués aux systèmes agent-based.
Principes de détection et d’atténuation
L’approche d’OWASP en matière de sécurité de l’IA agentique privilégie la validation des contrôles plutôt que la prédiction. Plutôt que d’anticiper chaque comportement possible d’un agent, l’objectif est de garantir que les security controls essentiels restent efficaces quand l’autonomie, la persistance et l’automatisation entrent en jeu.
Sur le fond, les mêmes principes s’appliquent qu’en sécurité cloud traditionnelle, mais il faut les appliquer plus rigoureusement :
Principe du moindre privilège (PoLP) pour les systèmes autonomes. Les workloads agentiques opèrent avec des permissions strictement délimitées, une séparation explicite des rôles et une revue régulière des identités non humaines. En pratique, l’exercice est difficile : l’automatisation s’étend avec le temps et accumule des permissions plus vite qu’elles ne sont auditées.
Limites de confiance explicites entre les systèmes. Les datastores, les environnements d’exécution, les pipelines CI/CD et les services externes ne doivent pas se faire implicitement confiance. Quand les agents relient ces domaines automatiquement, les erreurs de configuration se propagent plus vite et deviennent plus difficiles à contenir.
Intégrité de l’état et contrôles d’accès. La mémoire persistante et l’état partagé doivent être traités comme des actifs sensibles. Les contrôles qui fonctionnent pour les données applicatives (restrictions d’accès, protections d’intégrité et surveillance) sont tout aussi nécessaires pour la mémoire des agents et les datastores de contexte.
La détection reste difficile pour de nombreuses organisations, surtout quand l’outillage de sécurité est optimisé pour des événements ponctuels initiés par des humains plutôt que pour une automatisation continue. Les actions individuelles d’un agent (appels d’API, accès aux données, modifications de configuration) paraissent souvent légitimes isolément.
Une détection efficace repose donc sur la corrélation plutôt que sur des signatures, notamment :
relier l’usage des identités à l’accès aux ressources dans le temps ;
comprendre comment les permissions, l’exposition et les données se croisent ;
identifier les séquences d’actions qui forment un risque réel, pas des anomalies isolées.
L’atténuation exige aussi une priorisation. Toutes les erreurs de configuration d’un système d’IA ne présentent pas le même danger. OWASP insiste sur les conditions qui créent de vrais chemins d’attaque, là où l’autonomie croise des permissions excessives, des services exposés ou l’accès à des données sensibles.
Comment Wiz opérationnalise le modèle de menaces OWASP pour l’IA agentique
Wiz opérationnalise le modèle de menaces OWASP pour l’IA agentique en validant les security controls cloud dont dépendent les systèmes autonomes. Plutôt que d’interpréter l’intention ou le comportement d’un agent isolément, Wiz se concentre sur les identités, les permissions, l’accès aux données et les chemins d’exposition qui déterminent ce qu’un système agentique fait réellement dans un environnement cloud.
Grâce à une découverte agentless et à un graphe de sécurité unifié, Wiz met en correspondance les domaines de menaces OWASP avec un risque cloud concret. Les workloads d’IA (services d’IA managés, notebooks, pipelines, stockage de modèles et datastores associés) sont traités comme des actifs cloud de premier plan et analysés avec l’infrastructure dont ils dépendent.
Cela permet d’évaluer le risque lié à l’IA agentique à travers des questions de sécurité familières :
Quels comptes de service et quels rôles les workloads d’IA utilisent-ils ?
Ces identités sont-elles sur-privilégiées ou réutilisées entre les environnements ?
À quelles données sensibles les systèmes d’IA accèdent-ils, et depuis où ?
Les services d’IA, les API ou les datastores de mémoire sont-ils exposés à des réseaux non fiables ?
Wiz Research renforce ce modèle avec des observations concrètes : datastores d’IA exposés, identités non humaines détournées et vulnérabilités d’infrastructure d’IA qui correspondent directement aux catégories de menaces OWASP. Ces enseignements ancrent le risque lié à l’IA agentique dans des modes de défaillance cloud observés, pas dans un comportement théorique.
En corrélant les workloads d’IA avec le contexte cloud, Wiz aide les équipes de sécurité à prioriser la remédiation là où les systèmes autonomes croisent de vrais chemins d’attaque cloud. Pour voir comment le risque lié à l’IA agentique devient visible et exploitable, Voir Wiz en action.
Découvrez Wiz en action
Voyez comment Wiz aide vos équipes à détecter les risques cloud critiques et à accélérer leur remédiation.
