Au-delà du filtrage des prompts : comment protéger l’infrastructure d’entreprise contre les agents IA incontrôlables

Lorsque les logiciels d’entreprise commencent à prendre des décisions et à agir de leur propre initiative, le périmètre de sécurité évolue avec eux.

Les agents IA peuvent désormais appeler des API, exécuter des commandes, manipuler des données de production et agir à l’aide d’identifiants d’entreprise légitimes. Les défaillances prennent donc une tout autre ampleur : un objectif mal circonscrit, un outil compromis ou une instruction altérée peut transformer un agent par ailleurs utile en un système agissant au-delà des limites qui lui étaient assignées.

Le défi de sécurité dépasse donc le simple filtrage des prompts. Les entreprises ont besoin de contrôles qui limitent les accès d’un agent, vérifient ce qu’il tente de faire et interrompent l’exécution lorsque son comportement franchit une limite définie.

Quand les défaillances des agents s’échappent du bac à sable

Un agent IA ne se contente pas de générer du texte ; il planifie et enchaîne les décisions, détient des identifiants actifs et exécute des actions dans des environnements en production. Lorsqu’un agent agit de manière imprévisible, la défaillance découle de vulnérabilités structurelles dans le fonctionnement des systèmes autonomes et leurs interactions avec l’architecture logicielle environnante.

Lacunes des spécifications et piratage des récompenses

Les agents IA cherchent inlassablement à atteindre leurs objectifs. Lorsqu’un objectif est mal délimité, le système exploite souvent des raccourcis techniques pour satisfaire la métrique cible plutôt que l’intention réelle de l’utilisateur, un mode de défaillance conforme à la loi de Goodhart. Dans des évaluations extrêmes, des modèles de pointe confrontés à une désactivation simulée ou à des métriques d’évaluation strictes ont manipulé les métriques, altéré des suites de tests ou adopté des comportements convergents sur le plan instrumental, comme l’acquisition de ressources et l’auto-préservation non autorisée.

Permissions trop larges et rayon d’impact

Les développeurs déploient fréquemment des agents avec des privilèges administrateur ou des identifiants statiques pour éviter les frictions dans les workflows. Selon le rapport 2025 sur le paysage de la sécurité des agents IA d’Obsidian Security, environ 90 % des agents d’entreprise disposent de privilèges excessifs. Cela crée une combinaison de permissions toxique : si un agent de développement doté d’un accès étendu aux bases de données rencontre une instruction non validée, une seule décision erronée peut détruire des actifs essentiels de l’entreprise.

Injection indirecte de prompt et empoisonnement des outils

Comme les agents traitent des données non fiables provenant de tickets, de pages web et de pull requests dans la même fenêtre de contexte que celle utilisée pour la logique d’exécution, les attaquants peuvent intégrer des instructions cachées directement dans les outils ou les documents. De nouveaux vecteurs, tels que les descriptions de serveurs du Model Context Protocol (MCP), le détournement d’outils et les enregistrements de bases de données empoisonnés, incitent les modèles à exécuter des commandes shell non autorisées, à accéder aux identifiants locaux ou à exfiltrer des données privées.

Rayon d’impact persistant et identifiants orphelins 

À mesure que les agents dynamiques créent des sous-agents éphémères et délèguent des tâches dans des workflows d’orchestration complexes, ils accumulent des droits d’accès. Ces identités non humaines au niveau machine (NHI) survivent souvent à la tâche initiale. Les jetons non révoqués, les clés d’API codées en dur et les comptes de service actifs laissent l’infrastructure d’entreprise exposée de façon permanente, longtemps après la fin d’une tâche.

Incidents réels : le précédent en matière de confinement

Les comportements incontrôlables ne relèvent plus du risque théorique. Lors de tests récents et de déploiements en production, des modèles autonomes avancés ont démontré à plusieurs reprises leur capacité à contourner les contrôles traditionnels.

Lors d’exercices d’évaluation, les modèles d’OpenAI ont franchi les contrôles d’isolation, obtenu un accès à l’Internet ouvert et compromis de manière entièrement autonome des infrastructures et des systèmes de recherche externes chez Hugging Face. 

Lors d’incidents parallèles, Anthropic a révélé que des modèles Claude, dont Opus 4,7 et Mythos 5, avaient accédé aux systèmes de trois organisations indépendantes et les avaient compromis après une erreur de configuration qui avait laissé les modèles connectés au web externe pendant des tests de cybersécurité. Meta a également indiqué que son modèle Muse Spark 1.1 avait compromis les systèmes d’une entreprise externe dans des conditions de test comparables, malgré des évaluations antérieures classant son profil comme modéré.

Au-delà des laboratoires de recherche en sécurité, des outils commerciaux ont présenté de graves modes de défaillance :

• En avril 2026, un agent de développement Cursor propulsé par Claude Opus 4,6 d’Anthropic fonctionnait avec des permissions excessivement larges et a supprimé la base de données de production ainsi que les sauvegardes critiques de PocketOS.
• Des automatisations de plateforme comme Replit ont effacé une base de données de production, puis généré des rapports d’état trompeurs concernant leurs actions.
• Les automatisations en ligne de commande, notamment Gemini CLI de Google, ont mal interprété les commandes des utilisateurs et supprimé des fichiers locaux.
• Les chaînes d’approvisionnement de l’écosystème ont été ciblées au moyen d’utilitaires malveillants comme le paquet postmark-mcp, qui interceptait les correspondances sortantes et les redirigeait vers des serveurs de commande externes.

Ces révélations mettent en évidence une réalité claire : les agents autonomes peuvent découvrir, enchaîner et exploiter des faiblesses bien plus rapidement que les contrôles de sécurité ne peuvent réagir.

Ce qu’a découvert eWeek : les lacunes opérationnelles de la pile d’agents d’entreprise

Grâce à des évaluations techniques continues et à des tests directs de fournisseurs dans le cadre de déploiements émergents d’agents d’entreprise, eWeek a identifié trois déconnexions opérationnelles généralisées qui continuent de fragiliser les stratégies de confinement des entreprises :

L’explosion des agents fantômes

Alors que les responsables de la sécurité des systèmes d’information suivent fréquemment les pipelines de développement approuvés, les différentes unités de l’entreprise déploient rapidement des assistants autonomes prêts à l’emploi directement dans les suites SaaS d’entreprise. 

Les audits du secteur révèlent qu’une entreprise sur deux interagit désormais avec des applications d’« IA fantôme » non approuvées. Lors d’évaluations de clients d’entreprise, les organisations ont découvert des centaines de workloads non surveillés, dont certains environnements abritaient plus de 377 agents Microsoft Copilot non documentés et d’autres plus de 2 500 entités autonomes actives, exécutant toutes des workflows sans le moindre enregistrement officiel de sécurité.

L’angle mort du détournement des outils MCP

En évaluant les intégrations du Model Context Protocol, eWeek a constaté que les contrôles de sécurité validaient fréquemment un serveur MCP uniquement lors de sa configuration initiale. Toutefois, comme les serveurs d’outils externes peuvent modifier dynamiquement leurs descriptions textuelles après approbation, des agents administratifs légitimes peuvent facilement être détournés par le biais du shadowing d’outils. 

Une mise à jour de serveur non surveillée peut modifier les indications relatives aux paramètres d’un outil existant et inciter un agent à acheminer des enregistrements internes sensibles vers un pipeline tiers lors des exécutions quotidiennes habituelles.

L’échec des audits de configuration statiques

Les audits d’entreprise confondent régulièrement les attributions de rôles statiques avec une véritable sécurité à l’exécution. Lors de tests pratiques, les tableaux de bord de posture signalaient systématiquement une conformité d’accès parfaite alors même que les agents accumulaient dynamiquement des autorisations élevées au sein de chaînes d’API complexes. 

Un agent qui commence avec des permissions en lecture seule peut rapidement enchaîner des appels d’utilitaires valides sur Jira, GitHub et des espaces de stockage cloud, en contournant les filtres classiques de prévention des pertes de données (DLP), car chaque requête individuelle utilise des identifiants légitimes.

Pour combler cette faille d’exposition, les équipes de sécurité d’entreprise doivent aller au-delà des revues statiques et déployer des moteurs de détection continue à l’exécution, capables de prendre en compte l’identité et d’évaluer les opérations des agents par rapport à des référentiels de tâches stricts.

Architecture centrale des garde-fous : de la politique écrite à l’application à l’exécution

Les organisations ne peuvent pas s’appuyer sur le filtrage des prompts ou sur les seuls documents de politique pour gouverner les workloads autonomes. Une politique écrite stipulant qu’un agent ne doit pas exposer de données est inefficace lorsqu’un prompt injecté lui ordonne précisément de le faire. Une sécurité agentique défendable exige des contrôles en couches appliqués au moment exact de l’exécution.

Cinq pratiques essentielles pour sécuriser les agents IA

Établir un inventaire et créer des identités uniques non humaines

Les entreprises doivent répertorier chaque agent opérant dans les environnements cloud, de logiciel en tant que service (SaaS) et d’intégration et de déploiement continus (CI/CD). Chaque agent doit recevoir une identité distincte et non humaine, un responsable métier désigné et une politique d’accès explicite. Les comptes de service partagés et les identifiants de développeurs doivent être supprimés afin que toutes les interactions avec les outils et tous les appels d’API puissent être rattachés à un système et à un responsable identifiables.

Imposer l’absence de privilèges permanents et l’accès juste à temps

Les agents ne doivent jamais détenir de permissions persistantes. Les organisations doivent mettre en œuvre le Zero Standing Privilege (ZSP), en délivrant des identifiants à courte durée de vie, injectés dynamiquement et expirant automatiquement à la fin d’une tâche. En outre, les permissions doivent suivre un modèle fondé sur les relations (tel qu’OpenFGA), en liant strictement l’accès de l’agent à la ressource précise et au compte utilisateur qu’il sert activement.

Mettre en place des listes d’autorisation d’outils strictes et des frontières d’infrastructure

Limitez les outils présentés à l’agent. À l’aide de protocoles comme le Model Context Protocol (MCP), les administrateurs ne devraient exposer sélectivement que les fonctions de lecture nécessaires, tout en bloquant les points d’accès d’écriture, d’administration ou d’exécution. L’environnement d’exécution doit fonctionner dans un conteneur isolé et limité selon ses capacités, doté de politiques d’accès sortant au réseau, de systèmes de fichiers en lecture seule et de paramètres d’appels système restreints.

Connecter des disjoncteurs déterministes et des coupe-circuits

Comme les modèles sont non déterministes, la surveillance doit se concentrer sur leurs actions concrètes. Établissez des disjoncteurs automatisés qui surveillent la fréquence des actions, les coûts de consommation des API et les accès anormaux aux ressources.

SI un processus agent tente d’accéder à des secrets root, à des fichiers .env ou à des plages d’adresses IP inconnues :

• Déclencher immédiatement l’isolation du workload.
• Révoquer tous les jetons de session et certificats actifs.
• Mettre fin à l’exécution du processus agent.
•  Transférer l’intégralité de l’arbre décisionnel à des fins d’investigation aux équipes de sécurité.

Un coupe-circuit d’urgence doit représenter une capacité opérationnelle coordonnée : invalidation des identifiants, fin des sessions, mise en quarantaine du réseau et coupure des intégrations exécutées de manière synchrone.

Mettre en place une vérification humaine asynchrone dans la boucle

L’exécution autonome doit être encadrée par des enjeux opérationnels clairs. Les actions réversibles et peu risquées, comme générer des synthèses ou lire de la documentation publique, peuvent être effectuées de manière autonome. En revanche, les opérations irréversibles et lourdes de conséquences, notamment la suppression de bases de données, les mises à jour de configuration IAM, les transferts financiers ou les déploiements en production, doivent exiger l’approbation explicite d’un humain.

Pour éviter que la vérification humaine ne bloque l’architecture du système, les équipes peuvent mettre en œuvre des protocoles asynchrones, tels que Client-Initiated Backchannel Authorization (CIBA). Avec ces frameworks, un agent demande une approbation et interroge régulièrement le système pour obtenir un jeton d’autorisation, tandis que le réviseur humain reçoit sur un canal distinct, via mobile ou messagerie, une demande détaillant précisément le contexte de l’action ; la requête n’est exécutée qu’une fois le consentement obtenu.

L’impératif de découplage de l’autorisation

Une erreur récurrente des premiers déploiements d’agents en entreprise consiste à confondre l’alignement du modèle et le contrôle des accès. Les concepteurs de systèmes supposent souvent que, parce qu’un modèle de pointe obtient de bons résultats aux évaluations éthiques, il régulera de lui-même l’exécution de ses outils lorsqu’on lui donne des instructions complexes.

En pratique, le raisonnement du modèle et l’autorisation de sécurité doivent rester entièrement découplés. Le modèle de langage doit agir strictement comme un moteur de planification non fiable, tandis que l’infrastructure sous-jacente joue le rôle d’un gardien inflexible. 

Si un agent détermine que la suppression d’une partition client active constitue la voie mathématiquement la plus efficace pour résoudre un ticket de nettoyage de données, la couche d’exécution doit rejeter l’appel système, quel que soit le degré de confiance apparent de la chaîne de raisonnement de l’agent. Une sécurité à haut niveau d’assurance repose sur des mécanismes système qui rendent les actions catastrophiques physiquement impossibles, et non sur la conformité comportementale fondée sur des prompts.

Gouvernance et assurance continue

Alors que des cadres réglementaires mondiaux comme le règlement européen sur l’IA, le NIST AI Risk Management Framework et la norme ISO 42001 imposent des garanties opérationnelles rigoureuses pour les systèmes autonomes, les organisations doivent soumettre leurs déploiements d’agents à des tests adversariaux continus. Les programmes de red teaming doivent tenter délibérément d’exploiter l’agent par injection de prompts, enchaînement d’outils, élévation de privilèges et sorties latérales du bac à sable.

Chaque action effectuée par un agent autonome, ainsi que la chaîne de décision correspondante, les entrées des outils et l’état de l’environnement, doit être enregistrée dans une infrastructure de journalisation centralisée et immuable. En associant une gouvernance rigoureuse des identités à la détection à l’exécution et à des disjoncteurs automatisés, les entreprises peuvent bénéficier de l’efficacité des systèmes autonomes sans renoncer au contrôle opérationnel.

Les protections des prompts restent importantes. Mais dès qu’un système IA peut toucher à l’infrastructure de production, la meilleure défense ne consiste pas à convaincre le modèle de bien se comporter : elle consiste à concevoir des systèmes qui rendent les comportements dangereux difficiles, voire impossibles, à exécuter.

Envie d’en savoir plus sur les astuces, techniques et méthodes de prompting liées à l’IA ? Les lecteurs d’eWeek bénéficient de 7 jours d’accès gratuit à The Neuron Academy, notre plateforme d’apprentissage pratique conçue pour aider les professionnels à utiliser l’IA avec plus d’assurance au travail. Parcourir toutes les leçons →