Sécurité des agents IA en entreprise : modèle de menaces et garde-fous avant d’ouvrir l’accès à vos outils

Donner un accès “outil” à un agent IA change la nature du risque. Le problème n’est plus seulement ce que le modèle répond, mais ce qu’il peut lire, déclencher, modifier, envoyer ou supprimer dans votre environnement. Avant d’autoriser un agent à agir sur des fichiers, une messagerie, un CRM ou une console SaaS, il faut cadrer quatre points : son identité, ses droits réels, les validations humaines exigées et la traçabilité de chaque action.

Dans la plupart des contextes B2B, la bonne décision n’est pas “ouvrir ou bloquer”. C’est définir un niveau d’autonomie par cas d’usage, puis imposer des garde-fous adaptés à la criticité de l’action et de la donnée. Un agent peut être utile en lecture, très risqué en écriture, et inacceptable en suppression ou en export externe.

 

 

Pourquoi un agent IA crée un risque différent d’un simple assistant
 

Un assistant conversationnel sans accès outillé peut produire une mauvaise réponse. Un agent IA connecté à vos outils peut produire une mauvaise action. La différence est décisive pour une DSI : dès qu’un agent dispose d’un connecteur, d’un webhook, d’un token API, d’un accès boîte mail, d’un lecteur de fichiers ou d’un droit d’écriture, il devient une interface opérationnelle sur votre système d’information.

Trois propriétés augmentent le risque :

• il interprète du langage naturel, donc il peut être influencé par des instructions malicieuses ou ambiguës ;
• il consomme des sources externes ou internes non fiables par défaut ;
• il peut enchaîner plusieurs actions, donc amplifier une erreur initiale.

Concrètement, un agent peut lire un email piégé, interpréter son contenu comme une instruction, récupérer un document sensible, puis l’envoyer via un outil autorisé. Le sujet n’est donc pas seulement le “prompt injection”, mais la combinaison entre compréhension imparfaite, droits trop larges et automatisation sans contrôle.

Ce que la direction doit arbitrer

La bonne question n’est pas “avons-nous confiance dans le modèle ?”. La bonne question est : “quelles actions sommes-nous prêts à laisser exécuter automatiquement, sur quelles données, avec quel niveau de validation et d’audit ?”

Ce raisonnement rejoint la logique de cadrage appliquée aux projets digitaux complexes : avant de brancher une nouvelle couche d’automatisation, il faut clarifier le périmètre fonctionnel, les contraintes et les responsabilités. Voir aussi l’expression de besoins d’un projet digital.

 

Quelles surfaces d’attaque cartographier avant tout déploiement

La première erreur consiste à raisonner “modèle” alors que le risque réel est “système”. Pour un agent IA en entreprise, la cartographie initiale doit couvrir les flux, les identités, les outils et les points de sortie.
 

1. Les entrées que l’agent peut interpréter

• prompts utilisateurs ;
• emails entrants ;
• documents joints ;
• pages web ;
• tickets support ;
• contenus de bases de connaissances ;
• mémoire ou historique de conversation.

2. Les systèmes sur lesquels il peut agir

• GED, SharePoint, Drive, DAM, intranet ;
• messagerie et calendrier ;
• CRM, marketing automation, CDP ;
• CMS, back-offices web, consoles d’administration ;
• outils BI, data warehouses, tickets, ITSM ;
• webhooks, APIs internes, connecteurs tiers.

3. Les sorties à surveiller

• envoi d’emails ;
• création ou modification de données ;
• suppression ;
• export ou téléchargement ;
• publication web ;
• appel vers un service externe.

Cette logique de cartographie des dépendances et des points de rupture rejoint des sujets déjà critiques sur les projets de plateforme, de refonte et de gouvernance technique. À ce titre, les risques de dépendances tierces et de gouvernance en refonte offrent une lecture utile pour structurer le cadrage.

 

Comment construire un modèle de menaces utile pour une DSI

Un bon modèle de menaces n’est pas un document théorique. C’est une grille de décision. Pour chaque cas d’usage, documentez au minimum : objectif, données touchées, systèmes appelés, actions autorisées, mode de validation, journalisation, scénario d’abus et plan de repli.
 

Matrice simple à utiliser

• Cas d’usage : que doit faire l’agent, précisément ?
• Données : publiques, internes, sensibles, réglementées.
• Action : lire, résumer, créer, modifier, supprimer, envoyer.
• Contexte : qui demande, depuis quel outil, dans quel périmètre ?
• Droits : quels rôles IAM, quels scopes OAuth, quels comptes de service ?
• Validation : automatique, approbation humaine, double validation.
• Audit : quels logs, quelle conservation, quelle revue d’accès ?
• Sortie : où part le résultat, et peut-il quitter le SI ?
   

Les scénarios d’abus à documenter en priorité

• prompt injection indirect via email, document ou page web ;
• confused deputy : l’agent utilise ses privilèges pour exécuter une demande qu’un utilisateur ne pourrait pas exécuter lui-même ;
• exfiltration par pièce jointe, lien, export CSV ou appel API ;
• sur-collecte de données au-delà du besoin métier ;
• action irréversible lancée sans confirmation ;
• chaînage d’outils qui contourne la séparation des rôles ;
• clé, token ou secret exposé dans le code, le prompt ou les logs.

En pratique, la DSI peut classer les usages en trois niveaux :

• Niveau 1 : lecture seule sur données peu sensibles, sans action externe ;
• Niveau 2 : préparation d’action avec confirmation humaine obligatoire ;
• Niveau 3 : action sensible ou irréversible, interdite ou très fortement restreinte.

Ce besoin de mesure, de preuves et de pilotage est cohérent avec la manière dont Tuesday aborde les environnements digitaux complexes, l’analytics et la gouvernance de plateformes. Voir aussi SEO, AEO, GEO et pilotage search B2B pour la logique de mesure et de priorisation, ainsi que la maintenance et la sécurisation d’environnements CMS.

 

Quels garde-fous imposer avant l’accès aux fichiers, mails et SaaS

Les garde-fous utiles ne sont pas des slogans. Ce sont des contraintes de conception et d’exploitation.
 

Garde-fous d’identité et d’autorisations

• une identité dédiée par agent, jamais un compte partagé ;
• des droits minimaux par usage réel, pas par commodité ;
• des comptes distincts pour lecture, écriture et journalisation si nécessaire ;
• des secrets courts, rotatifs et sortis du code ;
• une séparation stricte entre environnements de test et de production.
   

Garde-fous d’exécution

• mode lecture seule par défaut ;
• confirmation humaine pour tout envoi externe, modification sensible ou suppression ;
• liste blanche d’outils et d’actions autorisées ;
• blocage des exports massifs et des destinations non approuvées ;
• quotas, timeouts et limites de volume par session.
   

Garde-fous sur les données et le contexte

• séparer instructions système et données métiers ;
• considérer tout contenu externe comme non fiable ;
• minimiser le contexte injecté au modèle ;
• masquer ou exclure les données sensibles non nécessaires ;
• définir des politiques explicites pour la mémoire et la rétention.
   

Garde-fous de contrôle

• logs d’accès, d’outils appelés, de décisions et de résultats ;
• alertes sur les actions à risque ;
• revues régulières des rôles, scopes et connecteurs ;
• tests de sécurité sur scénarios adverses ;
• kill switch clair pour désactiver un agent ou un connecteur.
   

Pour des organisations B2B avec stack marketing et sites interconnectés, il faut aussi traiter le cas spécifique des agents branchés sur CMS, CRM, analytics et automation. Un agent qui “optimise” un contenu, modifie un tracking ou exporte des listes peut créer autant de dégâts business que de risque sécurité. Sur ce point, la réflexion Tuesday sur AI Overview, la citabilité et la mesure rappelle une règle utile : automatiser sans gouverner fait perdre la maîtrise du narratif et des KPI.

 

La checklist d’achat avant de choisir une solution d’agent IA

Avant de signer, une DSI ou un responsable digital devrait exiger des réponses précises aux questions suivantes.

• Peut-on créer une identité dédiée par agent et limiter finement les scopes ?
• Les actions sensibles peuvent-elles être soumises à approbation humaine ?
• Les logs distinguent-ils lecture, préparation, exécution et échec ?
• Peut-on désactiver un connecteur ou un outil sans tout casser ?
• Le fournisseur documente-t-il les risques de prompt injection indirect et de tool abuse ?
• Les secrets, tokens et comptes de service sont-ils gérés hors prompts et hors code ?
• Les données envoyées au modèle sont-elles minimisées, chiffrées et gouvernées ?
• Le produit permet-il un mode “draft only” avant toute action réelle ?
• Les environnements sandbox et production sont-ils séparés ?
• Disposez-vous d’un plan de revue d’accès et d’un sponsor sécurité interne ?

Si plusieurs réponses restent floues, le bon choix n’est pas “non à l’IA”. Le bon choix est souvent un déploiement progressif : d’abord lecture et assistance, ensuite préparation d’action, puis seulement certains actes encadrés en production.

 

FAQ
 

Un agent IA est-il forcément plus risqué qu’un chatbot ?

Oui, dès qu’il peut appeler des outils, lire des fichiers, envoyer des emails ou modifier des données. Le risque porte alors sur l’exécution, pas seulement sur la réponse.

Le principal risque est-il le prompt injection ?

Le prompt injection compte, mais il devient surtout dangereux quand il rencontre des droits trop larges, des connecteurs sensibles et une absence de validation humaine.

Faut-il interdire l’écriture en production ?

Pas forcément. Il faut la réserver à des cas bornés, avec identité dédiée, périmètre restreint, journalisation et approbation adaptée à la criticité.

Quels usages autoriser en premier ?

Les usages de lecture, synthèse, recherche et préparation de brouillons, sur des données et outils à faible criticité, sont généralement les plus sûrs pour démarrer.

Pourquoi l’IAM est-il si central ?

Parce qu’un agent exécute ce que ses droits lui permettent. Si les rôles, scopes et comptes de service sont trop larges, l’agent devient un multiplicateur de risque.

La journalisation est-elle obligatoire ?

Oui en pratique. Sans traces d’accès, de décision et d’action, il devient très difficile d’auditer, d’investiguer ou d’industrialiser le déploiement.

Un connecteur “officiel” suffit-il à sécuriser l’usage ?

Non. Un connecteur officiel réduit certains risques d’intégration, mais ne remplace ni le moindre privilège, ni la validation humaine, ni les politiques de données.

Comment démarrer sans bloquer l’innovation ?

En classant les cas d’usage par criticité, en ouvrant d’abord la lecture seule, puis en ajoutant des actions progressivement, avec garde-fous et revues d’accès.

 

Passer à l’action

Avant d’ouvrir un agent IA à vos outils internes, l’objectif n’est pas de viser un risque zéro théorique. L’objectif est de rendre les usages acceptables, observables et réversibles. Cela suppose un cadrage interdisciplinaire : DSI, sécurité, digital, métiers, data et responsables d’outils doivent décider ensemble ce que l’agent peut voir, faire et escalader.

Dans beaucoup d’organisations, le bon point de départ n’est pas le choix du modèle, mais l’inventaire des connecteurs, des comptes de service, des rôles IAM, des actions à confirmation obligatoire et des journaux disponibles. C’est ce travail qui permet ensuite d’arbitrer un déploiement réaliste, compatible avec vos contraintes business, vos obligations de sécurité et votre niveau de maturité opérationnelle.