Connecter un agent IA à un CRM, une base documentaire ou un outil de gestion change profondément son niveau de risque. Il ne produit plus seulement du texte : il consulte des informations internes, choisit des outils et peut parfois déclencher une action. Il devient donc un acteur du système d’information, soumis aux mêmes exigences d’identité, d’autorisation, de traçabilité et de résilience que les autres composants applicatifs.
La sécurité ne consiste pas à demander au modèle d’être prudent ni à placer un filtre devant sa réponse. Elle repose sur une architecture où chaque capacité est explicitement accordée, chaque donnée est sélectionnée selon le contexte et chaque action sensible demeure contrôlable. L’objectif réaliste n’est pas de rendre le modèle infaillible, mais de limiter les conséquences d’une erreur, d’une ambiguïté ou d’une instruction malveillante.
Cartographier les données, les outils et les effets
Le premier travail consiste à décrire les parcours réels de l’agent. Pour chaque cas d’usage, l’équipe liste les sources consultées, les données produites, les outils appelés et les personnes concernées. Elle distingue la lecture, la proposition et l’exécution, car résumer un contrat n’expose pas au même risque que modifier une fiche client. La cartographie couvre aussi les chemins indirects : document contenant de fausses consignes, confusion entre deux clients, paramètre incomplet ou enchaînement inattendu de plusieurs outils. Elle permet enfin de retirer les capacités sans rapport avec la tâche plutôt que de tenter de les encadrer uniquement par un prompt.
- Identifier les données personnelles, confidentielles ou réglementées.
- Décrire les entrées, sorties et effets de bord de chaque outil.
- Classer les actions selon leur impact et leur réversibilité.
- Associer un propriétaire métier à chaque capacité.
Appliquer le moindre privilège à chaque requête
L’agent ne devrait jamais utiliser un compte technique omnipotent. Ses droits sont limités au cas d’usage, à l’utilisateur courant et, si possible, à la durée de la tâche. L’identité de la personne accompagne chaque appel afin que les règles des systèmes sources continuent de s’appliquer. Si cette délégation est impossible, une API intermédiaire expose une opération étroite, par exemple récupérer les commandes d’un compte précis plutôt qu’exécuter une requête libre. Les secrets restent dans un coffre dédié et ne transitent ni dans le contexte du modèle ni dans les journaux. Une consigne telle que « ne montre que les dossiers autorisés » ne remplace jamais un contrôle côté serveur.
- Préférer des API métier ciblées aux accès directs aux bases.
- Utiliser des jetons courts et des permissions limitées.
- Séparer strictement test, recette et production.
Considérer les contenus externes comme non fiables
Courriels, pages web, pièces jointes et notes utilisateur peuvent contenir des instructions destinées à détourner l’agent. Il faut séparer les règles du système, la demande de l’utilisateur et les données documentaires, puis empêcher ces dernières de redéfinir les outils disponibles. La détection de formulations suspectes apporte un signal, mais ne suffit pas : une attaque peut prendre de nombreuses formes. La protection la plus robuste se trouve au moment de l’action, avec une liste fermée d’opérations, une validation stricte des paramètres et un nouveau contrôle d’autorisation. Même si le raisonnement du modèle est influencé, sa capacité à produire un dommage reste alors contenue.
Encadrer les actions et conserver une supervision humaine
Chaque outil possède un schéma d’entrée strict, des limites métier et des erreurs compréhensibles. Le service d’exécution vérifie l’existence de la ressource, son statut, son appartenance au bon périmètre et l’absence de doublon sans faire confiance au texte généré. Pour une action sensible, l’agent prépare un brouillon ou une prévisualisation indiquant clairement la cible et l’effet attendu ; une personne confirme ensuite l’exécution. Les transferts de données, changements de droits, paiements et communications externes justifient particulièrement ce contrôle. Une clé d’idempotence empêche par ailleurs une relance technique de répéter la même opération.
- Valider les paramètres côté serveur avec un schéma fermé.
- Exiger une confirmation pour les effets importants.
- Prévoir annulation, compensation et limitation de fréquence.
Observer, tester les abus et savoir arrêter
L’exploitation doit permettre de savoir qui a demandé quoi, quelles sources ont été consultées et quels outils ont été appelés. Les journaux privilégient les métadonnées, décisions d’autorisation, identifiants et erreurs ; ils masquent les secrets et limitent la conservation des contenus sensibles. Des scénarios d’abus sont rejoués à chaque évolution : tentative d’accès à un autre périmètre, document piégé, outil indisponible ou réponse contradictoire. Enfin, un interrupteur par outil, des quotas, un mode lecture seule et une procédure de révocation permettent de réduire rapidement les capacités. La reprise intervient après analyse des traces et vérification des contrôles.
- Corréler tous les événements d’une même tâche.
- Alerter sur les refus répétés et volumes anormaux.
- Documenter responsables, seuils et procédure d’escalade.
En conclusion
Un agent sécurisé n’est pas un modèle auquel on demande de bien se comporter. C’est un système dont les accès sont minimaux, les outils étroits, les contenus non fiables par défaut et les actions importantes explicitement validées. Des règles déterministes entourent ainsi le composant probabiliste et maintiennent une frontière claire entre proposition et autorisation.
La trajectoire la plus sûre commence par un périmètre utile en lecture seule, entièrement observable, puis ouvre progressivement des capacités après des tests ciblés. Chaque nouvelle action doit apporter une valeur métier identifiable tout en conservant un moyen simple de contrôle, d’audit et d’arrêt.
