Les agents IA forcent le zéro confiance à sortir du réseau
Les dernières recommandations sur la gestion du risque cyber des IA agentiques insistent sur un point que les équipes de sécurité d'entreprise devraient déjà appliquer : un agent IA n'est pas un simple utilisateur d'application.
Il lit du contenu non fiable, élabore un plan et utilise des identifiants pour agir sur plusieurs systèmes. Cette combinaison remet en cause une hypothèse confortable de nombreux programmes zéro confiance : qu'une identité authentifiée, dans un workflow approuvé, est suffisamment prévisible.
Ce n'est pas le cas.
Un employé humain peut avoir un rôle large. Un service classique a une fonction étroite. Un agent occupe un terrain intermédiaire délicat et risqué. Il peut hériter des accès d'une personne, consommer un email ou document malveillant, appeler un outil connecté et essayer plusieurs variantes d'une action. Son identité peut être valide alors que sa prochaine étape est totalement hors de l'intention de la personne qui l'a lancé.
C'est pourquoi la conversation sur l'IA en entreprise évolue. La question n'est plus seulement de savoir si le modèle est approuvé. C'est de savoir si chaque action que le modèle peut déclencher est explicitement autorisée, limitée et observable.
Le zéro confiance doit s'appliquer à chaque appel d'outil
Un bon programme zéro confiance demande une vérification avant d'accorder l'accès. L'IA agentique nécessite le même principe à un niveau plus fin : avant chaque appel d'outil conséquent.
Considérez un agent aidant une équipe achats à examiner des contrats fournisseurs. Lire un document et produire un résumé est peu risqué. Créer un brouillon dans le système de contrats est plus conséquent. Modifier un enregistrement de paiement fournisseur, exporter un dossier de contrats ou envoyer un message externe est encore différent.
Ces actions ne devraient pas être protégées par la même autorisation OAuth permanente simplement parce qu'elles apparaissent dans un même workflow.
Considérez chaque action comme une décision avec cinq entrées :
- **Identité de l'agent :** Quel agent spécifique et quelle version font la requête ?
- **Contexte humain et métier :** Qui l'a initiée et quelle tâche approuvée accomplit-elle ?
- **Contexte des données :** Quelles données seront lues, écrites ou envoyées, et quelle est leur sensibilité ?
- **Outil et environnement :** Quel connecteur est impliqué, et s'agit-il d'un système sandbox ou de production ?
- **Impact de l'action :** La requête est-elle réversible, limitée et interne, ou modifie-t-elle de l'argent, des permissions, des enregistrements ou des communications externes ?
Un moteur de politique n'a pas besoin de ralentir chaque workflow à faible risque. Il doit distinguer une recherche d'un changement de paiement. Sinon, l'organisation a accordé une autorité ambiante : des identifiants techniquement valides mais trop larges pour la tâche.
Le prompt n'est pas la limite de la politique
Les équipes tentent encore de gérer le risque agent par de meilleures instructions. Elles écrivent une règle « Ne jamais envoyer de données clients à l'extérieur », puis connectent l'agent à l'email, un stockage de fichiers et un CRM avec un jeton à longue durée.
C'est une directive, pas une application.
L'injection indirecte de prompt révèle clairement la faille. Un agent peut rencontrer des instructions hostiles intégrées dans une page web, un ticket, un tableur ou un document. Même un modèle bien conçu peut être manipulé pour choisir un appel d'outil non sécurisé. Le contrôle important n'est pas que l'agent ait reçu un ordre de comportement, mais que le connecteur rejette une action violant la politique.
Pour les travaux à fort impact, déplacez la limite hors du chat vers l'identité et les contrôles d'accès. Utilisez des identités dédiées aux agents. Émettez des identifiants à courte durée liés à une tâche. Restreignez les périmètres d'outil au plus petit ensemble utile. Exigez un point d'approbation pour les actions irréversibles, visibles à l'extérieur ou de grande valeur.
C'est de l'ingénierie de sécurité familière. La différence est la rapidité avec laquelle les créateurs d'agents peuvent désormais créer un workflow franchissant toutes ces limites sans demande de changement traditionnelle.
L'IA fantôme devient une autorité fantôme
La plupart des organisations ont commencé leur gouvernance IA en inventoriant les modèles et outils de chat approuvés. Cela reste important. Mais le problème plus difficile est de découvrir où l'IA a acquis une autorité.
Un assistant basé sur navigateur pouvant ouvrir un document cloud, un workflow no-code avec connecteur de boîte mail, un agent de codage utilisant un jeton développeur, et un outil commercial pouvant mettre à jour un CRM présentent des risques différents. Aucun n'a besoin de ressembler à une « plateforme IA » formelle pour devenir proche de la production.
C'est la prochaine forme d'IA fantôme : non seulement l'utilisation non approuvée de modèles, mais l'accès non observé de l'IA aux systèmes.
Un inventaire utile doit donc enregistrer plus que le fournisseur et le propriétaire. Pour chaque agent ou workflow IA, les responsables sécurité doivent pouvoir répondre :
- Quelles données peut-il accéder, y compris via des connecteurs en aval ?
- Quelles actions peut-il effectuer, et dans quels environnements ?
- Quelle identité, jeton ou contexte utilisateur délégué rend ces actions possibles ?
- Quel événement le déclenche, et quel contenu non fiable peut l'influencer ?
- Qu'est-ce qui l'arrête quand la tâche, l'accès utilisateur ou l'approbation métier expirent ?
Si la réponse ne vit que dans une console admin fournisseur ou la mémoire d'un chef de projet, la gouvernance n'a pas suivi l'adoption.
Construisez un registre d'actions, pas un autre tableur
La réponse pratique est un registre d'actions : un enregistrement vivant qui relie découverte, identité, accès aux données, permissions d'outil et décisions politiques. Il doit montrer le chemin depuis un utilisateur initiateur et un but métier jusqu'à l'action exacte tentée par un agent et si le contrôle l'a autorisée, bloquée ou escaladée.
Cela donne aux équipes de sécurité un outil opérationnel. Cela soutient la réponse aux incidents quand un agent agit de façon inattendue. Cela permet aux équipes conformité de démontrer leur supervision. Et cela offre aux équipes métier un moyen de déployer des agents utiles sans attendre un oui ou non global.
Commencez par quatre niveaux d'action :
1. Lire et rédiger : Autoriser dans les limites de données approuvées ; journaliser. 2. Recommander : Laisser l’agent préparer un changement, mais garder l’exécution humaine. 3. Exécution limitée : Permettre des actions réversibles avec limites de transaction, destination et temps. 4. Exécution à fort impact : Exiger un approbateur explicite et une autorité just-in-time pour les mouvements d’argent, changements de privilèges, modifications en production, exportations massives, suppressions ou envois externes.
Le mot important est exécution. Une revue de risque modèle peut dire si un outil est adapté. Elle ne peut pas, seule, contrôler ce qu'un agent connecté fait à 2h du matin avec un jeton valide.
Rendez l'autorité visible avant qu'elle ne devienne un incident
L'IA agentique peut rendre les équipes beaucoup plus rapides. La réponse sensée n'est pas de l'interdire ou de forcer chaque requête à passer par une revue manuelle. C'est de rendre l'autorité délibérée.
Aona aide les équipes sécurité et gouvernance à découvrir l'utilisation de l'IA dans l'environnement, identifier où agents et outils peuvent toucher des données sensibles, et appliquer des contrôles exécutables aux niveaux données, identité et action. [Découvrez comment Aona aborde la gouvernance IA](https://aona.ai/?utm_source=blog&utm_medium=internal&utm_campaign=agent-zero-trust) et [explorez nos ressources sur l'IA fantôme](https://aona.ai/resources?utm_source=blog&utm_medium=internal&utm_campaign=agent-zero-trust).
Les recommandations de cette semaine sont une invitation claire : votre équipe peut-elle tracer la prochaine action conséquente d'un agent jusqu'à un propriétaire nommé, une approbation en cours et une permission limitée dans le temps ? Sinon, vous n'avez pas encore de zéro confiance pour les agents IA. Vous avez une confiance non testée.
