Un agent IA ne se contente pas de produire du texte : il peut appeler des outils, lire des fichiers, interroger des services et enchaîner des actions jusqu’à atteindre un objectif. Cette autonomie ouvre des usages concrets, de l’assistance au support technique à l’automatisation de tâches internes. Elle élargit aussi la surface d’attaque. La bonne réponse n’est ni de tout autoriser, ni de soumettre chaque étape à une validation manuelle, mais de définir des limites proportionnées au risque.
Commencer par cartographier les capacités
Avant de choisir un modèle ou un cadre d’orchestration, inventoriez ce que l’agent peut réellement faire. Peut-il consulter une base de connaissances, modifier un ticket, exécuter une commande ou envoyer un message à l’extérieur ? Distinguez les capacités disponibles des actions effectivement nécessaires au cas d’usage. Un agent chargé de résumer des incidents n’a généralement pas besoin d’un accès en écriture à l’ensemble du système d’information.
Cette cartographie sert à construire un modèle de menace pragmatique. Pensez aux erreurs ordinaires — réponse incorrecte, outil mal choisi, boucle interminable — autant qu’aux tentatives délibérées. Un document récupéré peut contenir une instruction hostile ; un utilisateur peut demander à l’agent de divulguer des informations auxquelles il a accès. Le modèle doit donc être considéré comme un composant non fiable, même lorsque son fournisseur est réputé.
Réduire les permissions sans casser les usages
Appliquez le principe du moindre privilège à chaque outil, pas seulement au compte de service global. Préférez une API limitée à une opération et à un périmètre de données précis plutôt qu’un jeton administrateur. Séparez les droits de lecture et d’écriture, limitez la durée de vie des secrets et évitez de les inclure dans les prompts, les journaux ou les réponses du modèle.
Les permissions doivent aussi dépendre du contexte. Un agent peut consulter des dossiers sans pouvoir les supprimer ; il peut préparer un courriel sans l’envoyer. Pour les opérations réversibles et à faible impact, une exécution autonome peut être raisonnable. Pour une action financière, une suppression ou une diffusion externe, exigez une confirmation humaine explicite. Cette frontière rend le système contrôlable sans transformer chaque interaction en parcours d’approbation.
Isoler les actions et borner les ressources
Exécutez les outils dans un environnement cloisonné : conteneur éphémère, système de fichiers en lecture seule lorsque c’est possible, réseau sortant filtré et séparation entre données de test et production. Ajoutez des limites de durée, de nombre d’appels et de consommation. Un agent qui boucle doit s’arrêter proprement, plutôt que multiplier les requêtes ou épuiser un budget de calcul.
Les sorties des outils ne sont pas automatiquement fiables. Validez les paramètres côté serveur, échappez les contenus avant leur affichage et contrôlez les requêtes destinées aux systèmes aval. Le prompt peut orienter le modèle, mais il ne remplace jamais une règle d’autorisation appliquée par le code.
Se protéger contre l’injection de prompt
Une injection de prompt survient lorsqu’un contenu consulté par l’agent tente de détourner ses instructions : page web, pièce jointe, courriel ou ticket. Il est difficile de garantir que le modèle ignorera toujours ces consignes. La défense consiste donc à ne pas lui confier seul la décision de sécurité. Séparez les instructions système des données, étiquetez les sources et imposez des contrôles indépendants avant toute action sensible.
Un outil devrait recevoir une demande structurée et minimale, puis vérifier lui-même que l’action est autorisée. Évitez qu’un texte arbitraire issu d’une page puisse devenir une commande système. Pour les flux de récupération documentaire, filtrez les sources, contrôlez les permissions au moment de la recherche et ne mélangez pas les résultats de plusieurs utilisateurs dans un même contexte.
Observer, tester, puis ajuster
La sécurité d’un agent se mesure dans la durée. Journalisez les appels d’outils, les décisions, les identifiants de session et les erreurs, en masquant les secrets et les données personnelles inutiles. Ces traces doivent permettre de reconstituer une action, sans transformer les journaux en nouvelle fuite de données. Définissez des alertes sur les comportements inhabituels : hausse soudaine des appels, accès hors périmètre ou répétition d’une opération refusée.
Avant le déploiement, constituez un jeu de tests représentatif : instructions adverses, documents piégés, demandes hors sujet, pannes d’API et tentatives d’accès à des données d’un autre utilisateur. Mesurez à la fois les refus justifiés et les blocages excessifs. Une politique trop restrictive peut pousser les équipes à contourner l’outil ; une politique trop permissive expose les systèmes. Les retours d’usage permettent de resserrer les contrôles là où le risque est réel et d’alléger les frictions inutiles.
Une autonomie sous contrôle, pas sous cloche
Le bon niveau de protection se construit autour de quatre éléments : des permissions minimales, un environnement isolé, des validations proportionnées et une observabilité exploitable. Commencez par un périmètre restreint, examinez les traces et élargissez les capacités étape par étape. Chaque nouvelle permission devrait répondre à un besoin démontré, avec un responsable et une procédure de retrait.
Un agent efficace n’est pas celui qui peut tout faire, mais celui qui accomplit une tâche clairement définie et sait s’arrêter lorsqu’il atteint une limite. Pour suivre les autres évolutions de la cybersécurité et de l’IA, retrouvez nos analyses sur la page d’accueil de Galibyte.