Les extensions d'agents IA ont besoin de l'équivalent de pilotes signés
Les équipes IA en entreprise passent de la question « cet agent est-il sûr ? » à une question plus urgente : qu'a installé, connecté ou appris l'agent avant d'agir ?
Ce changement est important car l'agent utile n'est rarement une application scellée. C'est un système qui s'étend vers l'extérieur. Il appelle un serveur MCP, charge une compétence, récupère un document, utilise un connecteur, suit des instructions sur une page web et agit dans des systèmes contenant des données réelles de l'entreprise. L'agent n'est pas juste un logiciel. C'est une chaîne d'approvisionnement en mouvement.
Cette semaine, la startup de sécurité des agents AIR s'est révélée publiquement avec 50 millions de dollars en financement initial axé sur cette chaîne d'approvisionnement. Sa prémisse est simple : compétences d'agents, plugins, serveurs MCP, sous-agents, sites web et données internes peuvent tous devenir des entrées dans le contexte d'un agent, et chaque entrée peut modifier ce que fait l'agent. Ce n'est pas un problème de sécurité de niche. C'est le modèle opérationnel que les entreprises adoptent rapidement.
L'analogie la plus utile n'est pas un autre chatbot IA. C'est le pilote signé.
Pourquoi une extension d'agent ressemble plus à un pilote qu'à une application
Une application traditionnelle est généralement revue comme un logiciel distinct. Une extension d'agent se comporte différemment. Elle peut exposer des outils, injecter des instructions, demander des identifiants, diriger des récupérations et orienter les actions en aval. Un connecteur apparemment inoffensif peut devenir un chemin vers des données sensibles ou un vecteur d'attaque par injection de prompt.
Le PDG d'AIR, Yair Saban, a clairement fait la comparaison lors du lancement : les systèmes d'exploitation modernes attendent des pilotes qu'ils soient signés car ils chargent du code dans une partie sensible de la machine. Les compétences et plugins d'agents peuvent modifier une partie tout aussi sensible d'un agent : son contexte de travail et ses actions autorisées. Pourtant, les entreprises les installent souvent avec bien moins de preuves de provenance, de périmètre ou de contrôle des modifications.
Ce fossé est plus grand qu'un simple scan de vulnérabilité. Un paquet peut être exempt de malwares connus et rester dangereux pour un agent particulier. Une compétence peut être légitime mais demander plus d'outils que nécessaire. Un serveur MCP peut être fiable aujourd'hui et recevoir des instructions différentes demain. Un connecteur peut avoir un but commercial valide mais être inapproprié pour un agent gérant contrats, dossiers clients ou workflows financiers.
La question clé n'est donc pas simplement « Cette extension est-elle malveillante ? » mais « Cet agent doit-il pouvoir consommer ce composant, avec cette identité, ces données et cette autorité, à ce moment précis ? »
Le problème caché : les achats se font dans les workflows
La plupart des programmes de sécurité d'entreprise ont déjà un processus d'approbation des fournisseurs SaaS. Ils peuvent avoir une analyse de composition logicielle pour les dépendances des développeurs. Mais les extensions d'agents sont souvent acquises de manière beaucoup moins visible.
Un employé crée un workflow. Ce workflow a besoin d'une nouvelle capacité. Le créateur d'agents sélectionne un serveur MCP ou une compétence dans un catalogue, un dépôt Git, une marketplace ou sur recommandation d'un collègue. Une demande d'autorisation apparaît. Le travail continue.
C'est un achat, une intégration et un déploiement en production compressés en quelques clics.
Cela produit aussi une nouvelle forme d'IA fantôme. Le problème n'est plus seulement des employés collant des données sensibles dans un modèle non approuvé. Ce sont des composants d'agents non approuvés ayant accès aux systèmes d'entreprise, souvent par des équipes bien intentionnées cherchant à aller plus vite. L'équipe de sécurité ne peut pas gouverner ce qu'elle ne découvre pas, ni prendre de bonnes décisions à partir d'un tableau obsolète dès le lendemain.
Construisez un processus de confiance pour les extensions d'agents, pas une revue ponctuelle
La réponse n'est pas d'interdire tous les connecteurs. Cela pousserait l'adoption hors de vue. La réponse est de rendre le chemin sûr plus rapide que le chemin invisible.
Commencez par quatre contrôles pratiques.
1. Créez un inventaire des composants IA
Suivez les agents, compétences, serveurs MCP, plugins, connecteurs, modèles, sources de données, propriétaires et les systèmes accessibles par chaque composant. Incluez composants sanctionnés et découverts. Un inventaire listant seulement les outils approuvés est un registre de politique, pas un registre de risque.
Le [cadre AI-BOM d'Aona](/blog/ai-bom-shadow-ai-enterprise-security-inventory) est un bon point de départ : traitez les dépendances et intégrations de l'agent comme des objets de gouvernance à part entière, pas comme un détail d'implémentation.
2. Exigez provenance et finalité avant connexion
Pour chaque composant externe, capturez qui le maintient, sa source, sa fonction, les données accessibles, les outils invoquables et le workflow métier supporté. Cela doit être proportionné. Une recherche de connaissance en lecture seule n'est pas un connecteur pouvant envoyer des emails, modifier un CRM ou déclencher un paiement.
L'essentiel est la preuve. « C'est populaire » et « l'équipe en avait besoin » ne sont pas des décisions de risque.
3. Liez l'autorité à la tâche, puis faites-la expirer
Un agent doit recevoir l'autorité minimale nécessaire pour une tâche spécifique, pas un ensemble permanent de permissions larges. Utilisez des identités distinctes si possible. Ciblez précisément les outils. Fixez des limites temporelles. Exigez une approbation humaine pour les actions à fort impact.
Cette approche s’appuie sur un principe que nous avons abordé dans [les autorisations des agents IA](/blog/ai-agent-expiring-permissions-enterprise-governance) : la révocation doit être conçue avant un incident, pas improvisée après. Elle empêche également un module complémentaire compromis ou modifié d’hériter d’un pouvoir supérieur à ce que son travail justifie.
4. Vérifier en continu les changements et le comportement à l’exécution
Signer ou examiner un composant une seule fois ne suffit pas. Les modules complémentaires des agents évoluent. Leurs dépendances changent. Leurs instructions et points de terminaison externes peuvent changer. Surveillez les dérives de configuration, les nouvelles demandes d’autorisations, les appels d’outils modifiés, les accès inattendus aux données et les actions hors du cadre approuvé de l’agent.
C’est là que la gouvernance devient opérationnelle. Les alertes doivent avoir un responsable et un chemin décisionnel : autoriser, restreindre, mettre en quarantaine ou enquêter. L’observabilité sans capacité d’intervention est un meilleur rapport d’incident, pas un contrôle.
Ce que les RSSI doivent demander ce trimestre
Un examen exécutif utile est court et précis :
- Quels agents IA et modules complémentaires sont actuellement connectés à nos systèmes ?
- Lesquels de ces composants ont été découverts plutôt qu’approuvés formellement ?
- Pouvons-nous identifier les données, outils, identités et responsables associés à chacun ?
- Que se passe-t-il lorsqu’un composant change après approbation ?
- Quelles actions nécessitent une approbation humaine avant exécution ?
Si les réponses exigent une recherche manuelle impliquant plusieurs équipes, l’entreprise a déjà dépassé le point où l’adoption des agents dépasse la gouvernance.
Le lancement d’AIR est un signal opportun, non pas parce qu’un nouveau fournisseur change le marché, mais parce qu’il nomme un vrai changement architectural. La surface d’attaque est désormais la chaîne de contexte, d’outils et de composants sur laquelle un agent s’appuie. Les contrôles de sécurité conçus pour des applications statiques manqueront ce mouvement.
Les entreprises n’ont pas besoin de ralentir leurs programmes IA. Elles doivent traiter les modules complémentaires des agents comme des composants informatiques de confiance : les découvrir, les vérifier, les contraindre et continuer à les vérifier après déploiement.
Si vous essayez de cartographier la Shadow IA et les connexions d’agents déjà en fonctionnement dans votre environnement, [parlez à Aona](/contact-us?utm_source=blog&utm_medium=organic&utm_campaign=agent-add-on-governance). Nous aidons les équipes de sécurité à transformer la découverte IA en politique, preuves et actions.
