Les agents IA ne sont plus de simples assistants de démonstration. Dans les entreprises, ils accèdent déjà à des applications métier, manipulent des données, déclenchent des actions via API et interagissent avec des systèmes critiques. Mais selon une enquête VentureBeat Pulse Research menée auprès de 107 entreprises de plus de 100 salariés, les garde-fous censés encadrer cette autonomie avancent moins vite que les déploiements.
Le signal le plus parlant est aussi le plus préoccupant : 54 % des organisations interrogées ont déjà connu un incident de sécurité lié à un agent IA ou un quasi-incident. Dans le détail, 18 % déclarent un incident confirmé et 36 % indiquent un événement évité de justesse avant qu’il ne cause des dommages.
Le problème n’est pas seulement le nombre d’incidents. Il tient surtout à la manière dont les agents sont intégrés au système d’information. Beaucoup disposent d’accès réels, mais partagent encore des identifiants, des clés API ou des comptes de service. Résultat : lorsqu’un agent est compromis, mal configuré ou trop permissif, son rayon d’action peut dépasser largement ce qui était prévu.
Un écart grandissant entre autonomie et sécurité
L’étude met en évidence ce que l’on peut appeler un écart de sécurité des agents IA : les entreprises accordent davantage d’autonomie à leurs agents, mais ne disposent pas toujours des contrôles d’identité, d’isolation et d’application des permissions nécessaires pour les contenir.
Cette situation rappelle les premières années du cloud ou de l’adoption massive des API : les usages progressent rapidement, les équipes métiers expérimentent, les plateformes rendent le déploiement facile, puis la sécurité doit rattraper l’existant. Avec les agents IA, la difficulté est plus aiguë, car ces systèmes peuvent enchaîner des tâches, prendre des décisions opérationnelles et agir dans plusieurs environnements à la fois.
- 54 % des entreprises interrogées ont déjà connu un incident ou un quasi-incident lié à un agent IA.
- 32 % seulement attribuent à chaque agent une identité propre, gérée et limitée à un périmètre précis.
- 69 % signalent une forme de partage d’identifiants dans leur flotte d’agents.
- 30 % isolent leurs agents les plus risqués dans des environnements de type sandbox.
- 59 % prévoient d’adopter, compléter ou remplacer leurs outils de sécurité des agents IA dans les douze mois.
Des incidents déjà bien réels, surtout dans les grandes organisations
L’enquête distingue les incidents confirmés des quasi-incidents. Cette distinction est importante : un quasi-incident n’a pas forcément causé de dommage, mais il révèle qu’un agent IA a été proche de franchir une limite de sécurité. Il peut s’agir, par exemple, d’un agent qui tente d’accéder à des données non prévues, d’une automatisation qui utilise un compte trop permissif ou d’une action bloquée au dernier moment par un contrôle existant.
Le taux d’exposition augmente avec la taille des entreprises. D’après les données rapportées, les organisations de taille intermédiaire affichent un taux d’incident ou de quasi-incident de 49 %, contre 63 % pour les entreprises de plus de 1 000 employés. C’est logique : plus une entreprise possède d’applications, de données, de workflows et d’agents en production, plus les surfaces d’attaque et les erreurs de configuration se multiplient.
Mais l’étude souligne un paradoxe : les grandes organisations, pourtant plus exposées, semblent moins enclines à isoler leurs agents les plus risqués. Le recours à la sandbox pour les agents à haut risque tombe à 20 % dans les plus grandes structures, contre 35 % dans le mid-market. Autrement dit, celles qui ont le plus à contenir ne disposent pas toujours du contrôle le plus utile pour limiter les dégâts.
L’identité des agents IA devient le maillon faible
La question de l’identité est centrale. Dans une architecture sécurisée, chaque agent devrait disposer d’une identité propre, avec des droits précisément définis, une traçabilité claire et une révocation simple en cas de problème. Or ce modèle reste minoritaire : seules 32 % des entreprises donnent à chaque agent une identité dédiée et limitée.
À l’inverse, 48 % expliquent que certains agents disposent d’identités limitées, mais que beaucoup partagent encore des identifiants. Et 32 % indiquent que les agents fonctionnent surtout avec des clés API partagées, des comptes humains ou des comptes de service. Comme les réponses pouvaient se chevaucher, l’étude estime que 69 % des entreprises ont du partage d’identifiants quelque part dans leur flotte d’agents.
Pourquoi le partage d’identifiants est dangereux
Le partage d’identifiants pose trois problèmes majeurs. D’abord, il augmente le rayon d’impact : si un agent utilise une clé API très permissive, toute compromission de cet agent peut donner accès à bien plus de ressources que nécessaire. Ensuite, il complique l’investigation : après un incident, il devient difficile de savoir quel agent a réellement effectué quelle action. Enfin, il empêche une application propre du principe du moindre privilège.
Dans les faits, un agent IA devrait être traité comme une identité non humaine à part entière, au même titre qu’un service, un workload cloud ou un script d’automatisation sensible. Cela implique des permissions minimales, une rotation régulière des secrets, une surveillance comportementale et la possibilité de désactiver rapidement l’agent sans casser l’ensemble du système.
L’étude observe d’ailleurs une corrélation nette : les organisations où les identifiants sont partagés ont connu un incident ou quasi-incident dans 63,5 % des cas, contre 40,9 % pour celles où chaque agent possède une identité propre et limitée. La taille de l’échantillon ne permet pas de conclure à une causalité absolue, mais l’écart est suffisamment fort pour alerter les directions sécurité.
Observer et bloquer ne suffit pas : il faut aussi isoler
Les entreprises ne sont pas totalement démunies. Près de la moitié déclarent surveiller l’activité des agents IA, et une proportion comparable applique des permissions limitées à l’exécution. Selon l’étude, 47 % observent l’activité des agents et 49 % appliquent des permissions cadrées au runtime.
Ces contrôles sont utiles, mais ils ne suffisent pas. La surveillance permet de comprendre ce qui s’est passé. L’application de règles peut empêcher certaines actions. Mais lorsque la prévention échoue, l’isolation reste le contrôle qui limite concrètement les dégâts.
Or seuls 30 % des répondants indiquent isoler leurs agents les plus risqués dans des environnements de type sandbox. C’est peu, surtout pour des agents capables d’interagir avec des données sensibles, des workflows financiers, des outils de support client, des CRM, des systèmes RH ou des environnements de développement.
Quels agents doivent être isolés en priorité ?
Tous les agents IA n’exigent pas le même niveau de confinement. Un agent chargé de résumer des documents publics n’a pas le même profil de risque qu’un agent capable de modifier des tickets de production, d’interroger une base clients ou de déclencher des actions commerciales automatisées.
Les entreprises devraient prioriser l’isolation des agents qui :
- accèdent à des données personnelles, financières, médicales ou confidentielles ;
- peuvent écrire, modifier, supprimer ou transférer des informations ;
- disposent d’un accès à plusieurs applications ou API ;
- interagissent avec des utilisateurs externes, des clients ou des fournisseurs ;
- peuvent exécuter du code, lancer des workflows ou déclencher des actions irréversibles.
Dans ces cas, la sandbox, le cloisonnement réseau, les environnements d’exécution temporaires et les politiques d’approbation humaine ne doivent pas être vus comme des freins, mais comme des mécanismes de limitation du risque.
Les entreprises s’appuient surtout sur les garde-fous des fournisseurs
Autre enseignement important : la sécurité des agents IA repose majoritairement sur les contrôles fournis par les plateformes déjà utilisées. Les garde-fous d’OpenAI sont cités par 51 % des répondants, devant les contrôles cloud de Google et Microsoft, ainsi que les mécanismes d’agents managés d’Anthropic. Lorsqu’il faut désigner la couche principale de sécurité, 82 % des répondants citent une solution native d’un fournisseur de modèle ou d’un hyperscaler.
Cette dynamique est compréhensible. Les contrôles intégrés sont faciles à activer, proches des outils déjà déployés et souvent inclus dans les offres existantes. Pour les équipes qui veulent aller vite, ils constituent le premier réflexe.
Mais cette approche a une limite : les garde-fous natifs ne couvrent pas toujours l’ensemble du cycle de sécurité des agents. Les besoins dépassent la modération de contenu ou les politiques de plateforme. Il faut aussi gérer les identités non humaines, l’isolation, la journalisation, les secrets, les permissions dynamiques, les flux inter-applicatifs et la réponse à incident.
Les fournisseurs spécialisés dans la sécurité des agents IA ou des identités non humaines restent encore peu adoptés dans l’échantillon. Des acteurs comme Palo Alto Networks, CrowdStrike, Cisco, Zenity, HiddenLayer, Check Point avec Lakera, Okta ou d’autres plateformes dédiées apparaissent, mais restent loin derrière les solutions natives des grands fournisseurs.
Une satisfaction élevée, mais peut-être trompeuse
L’un des points les plus surprenants de l’enquête est le niveau de satisfaction déclaré. Les entreprises attribuent en moyenne une note de 4,2 sur 5 à leurs outils actuels de sécurité des agents IA, et 4,1 sur 5 pour le rapport qualité-prix.
À première vue, cela semble rassurant. Mais ce score coexiste avec un taux élevé d’incidents, une gestion incomplète des identités et une faible adoption de l’isolation. La satisfaction pourrait donc refléter davantage la simplicité d’usage des contrôles natifs que leur efficacité réelle face à des scénarios complexes.
Il existe ici un risque de faux sentiment de sécurité. Une entreprise peut être satisfaite parce que ses outils sont faciles à utiliser, bien intégrés et peu coûteux, tout en restant vulnérable à des incidents d’ampleur si un agent obtient trop de droits ou agit hors de son périmètre.
Les budgets n’ont pas encore rattrapé le risque
Malgré la montée des incidents, la sécurité des agents IA ne représente encore qu’une part limitée des budgets cybersécurité. L’allocation la plus courante se situe entre 6 % et 10 % du budget sécurité, citée par 46 % des répondants. Un tiers des entreprises, soit 34 %, y consacre 5 % ou moins. Seul un quart dépasse 10 %.
Cette répartition montre que le risque est identifié, mais pas encore pleinement financé. Beaucoup d’organisations semblent encore dans une phase intermédiaire : elles déploient des agents IA, activent les contrôles disponibles, observent les premiers incidents, mais n’ont pas encore restructuré leur budget sécurité autour de cette nouvelle surface d’attaque.
Pour les RSSI, le sujet devient difficile à ignorer. La sécurité des agents IA ne peut pas rester une ligne annexe si ces agents accèdent à des systèmes métier critiques. Elle doit s’intégrer aux budgets IAM, cloud security, sécurité applicative, gouvernance des données et réponse à incident.
Face aux attaquants dopés à l’IA, les entreprises doutent
L’étude montre également que les entreprises ne sont pas convaincues d’avoir l’avantage face aux attaquants utilisant eux aussi l’intelligence artificielle. Seules 35 % estiment que leurs défenses IA sont en avance. À l’inverse, 32 % jugent la situation à peu près équilibrée, 21 % pensent que les attaquants ont l’avantage et 21 % considèrent qu’il est trop tôt pour trancher.
Ces chiffres révèlent une forme de lucidité : l’IA améliore aussi bien la défense que l’attaque. Les équipes sécurité peuvent automatiser l’analyse, détecter plus vite certains signaux faibles et orchestrer des réponses. Mais les attaquants peuvent également industrialiser le phishing, accélérer la reconnaissance, générer des leurres plus crédibles ou tester plus rapidement des chemins d’exploitation.
Dans ce contexte, une course “à égalité” n’est pas vraiment rassurante. Si les agents IA d’entreprise se multiplient sans identité propre, sans isolation et sans supervision adaptée, ils deviennent eux-mêmes des cibles et des relais potentiels pour des attaques plus sophistiquées.
Un renouvellement des outils de sécurité se prépare
Malgré la satisfaction affichée, la majorité des entreprises ne compte pas rester avec son dispositif actuel. Selon l’enquête, 59 % prévoient d’adopter, d’ajouter ou de remplacer une solution de sécurité des agents IA dans les douze prochains mois. Parmi elles, 29 % envisagent un changement dès le prochain trimestre.
Les incidents semblent accélérer fortement cette décision. Parmi les organisations ayant déjà été touchées, 42,1 % prévoient une évolution de leur outillage dans les 90 jours, contre 14 % seulement chez celles qui n’ont pas connu d’incident. Après un incident confirmé, cette intention devient majoritaire, à 52,6 %.
Cette dynamique laisse penser que le marché de la sécurité des agents IA va rapidement se structurer. Les contrôles natifs des grands fournisseurs conserveront probablement une place importante, mais ils pourraient être complétés par des couches spécialisées dédiées à l’identité, au confinement, à la traçabilité et à la gouvernance.
Ce que les entreprises devraient faire maintenant
Pour les organisations qui déploient déjà des agents IA, l’enjeu n’est pas de bloquer l’innovation, mais d’éviter que l’autonomie ne dépasse la capacité de contrôle. La priorité consiste à traiter les agents comme de véritables acteurs du système d’information, avec des droits, des responsabilités et des limites explicites.
1. Cartographier tous les agents en production
La première étape consiste à savoir quels agents existent, qui les a créés, quelles applications ils utilisent, quelles données ils consultent et quelles actions ils peuvent déclencher. Sans inventaire, il est impossible de prioriser les risques.
2. Attribuer une identité unique à chaque agent
Chaque agent devrait disposer de ses propres identifiants, avec des permissions limitées à sa mission. Les clés API partagées, les comptes humains réutilisés et les comptes de service trop larges doivent être progressivement éliminés.
3. Appliquer le moindre privilège au runtime
Les permissions ne doivent pas seulement être définies au moment de la configuration. Elles doivent être contrôlées pendant l’exécution, en fonction du contexte, du type de donnée, de l’action demandée et du niveau de risque.
4. Isoler les agents à haut risque
Les agents capables d’écrire dans des systèmes critiques, d’accéder à des données sensibles ou d’interagir avec l’extérieur doivent fonctionner dans des environnements cloisonnés. L’objectif est simple : si un agent échoue, se trompe ou est compromis, l’incident reste contenu.
5. Journaliser les actions dans un format exploitable
Les logs doivent permettre de répondre rapidement à des questions concrètes : quel agent a agi, avec quelle identité, sur quelle ressource, à quel moment, avec quelle entrée utilisateur et quel résultat. Cette traçabilité est indispensable pour l’audit, la conformité et la réponse à incident.
6. Tester les scénarios d’abus
Les équipes sécurité devraient simuler des attaques spécifiques aux agents IA : injection de prompt, usage abusif d’outils, exfiltration via API, escalade de permissions, contournement de politiques ou enchaînement d’actions non prévu. Ces tests doivent devenir aussi naturels que les tests d’intrusion applicatifs.
Méthodologie de l’enquête
L’enquête citée provient de la série VentureBeat Pulse Research et porte sur 107 organisations de plus de 100 employés. Les réponses ont été collectées lors d’une vague unique en juin 2026. Les entreprises de 1 à 100 salariés ont été exclues de l’analyse.
L’échantillon est composé de profils impliqués dans les décisions d’achat IA : 45 % sont décisionnaires finaux et 30 % sont prescripteurs ou influenceurs. La population interrogée est surtout orientée mid-market, avec 42 % d’organisations de 251 à 1 000 employés et 25 % de 101 à 250 employés. Les secteurs les plus représentés sont la technologie et le logiciel, l’industrie, le retail/e-commerce et la santé/sciences de la vie.
Comme l’échantillon est auto-sélectionné et limité à 107 répondants, les résultats doivent être lus comme un signal directionnel plutôt que comme une mesure statistique universelle. La tendance reste néanmoins claire : les agents IA sont déjà connectés à des systèmes réels, tandis que les contrôles d’identité, d’isolation et de gouvernance restent incomplets.
Le vrai défi : sécuriser l’autonomie avant qu’elle ne devienne incontrôlable
Les agents IA promettent des gains de productivité importants, mais ils introduisent aussi une nouvelle classe de risques. Contrairement à un chatbot classique, un agent peut agir. Il peut appeler des outils, manipuler des données, déclencher des workflows et prendre des décisions opérationnelles dans un environnement complexe.
La conclusion est donc simple : plus un agent IA devient utile, plus il devient nécessaire de le sécuriser comme un composant critique. Les entreprises qui attendront le premier incident majeur risquent de découvrir trop tard que leurs garde-fous étaient conçus pour des modèles conversationnels, pas pour des agents autonomes connectés au cœur du système d’information.
La prochaine étape de maturité ne consistera pas seulement à déployer plus d’agents IA. Elle consistera à leur donner des identités propres, des permissions minimales, des environnements isolés et une surveillance exploitable. C’est à ce prix que l’autonomie pourra devenir un avantage opérationnel plutôt qu’un nouveau risque systémique.