Agents IA connectés : cinq permissions à réduire avant la première action

Pour sécuriser un agent IA connecté, appliquez un refus par défaut à cinq couches : outils, données, identité d’exécution, opérations d’écriture et actions dispensées de confirmation humaine. N’accordez une permission que pour une tâche définie, avec une limite vérifiable et un moyen de la retirer indépendamment des autres.

Consignez chaque cas d’usage sous une forme précise, par exemple « rechercher une commande et préparer une réponse sans l’envoyer ». Pour chaque permission, indiquez la ressource, l’action, l’identité, la durée, le scénario d’échec et le contrôle compensatoire ; une donnée non fiable ne doit jamais suffire, à elle seule, à déclencher une action sensible.

1. Limiter les outils que l’agent peut invoquer

Un outil confère une capacité d’agir, même si sa description paraît anodine. N’activez pas un connecteur entier quand le besoin se limite à une fonction : exposez la recherche d’un dossier sans sa modification, ou la création d’un brouillon sans son envoi. Les outils administratifs, expérimentaux et étrangers au cas d’usage doivent rester hors de la configuration de production.

La documentation d’Amazon Connect distingue les outils invocables, les données accessibles, les utilisateurs autorisés à configurer les agents et le droit de demander une action au nom d’un employé ; elle prévoit aussi une sélection des outils au niveau de chaque agent.

Scénario d’échec : une instruction dissimulée dans un document tente d’appeler un outil de suppression sans rapport avec la tâche. Le contrôle compensatoire est une liste positive propre à l’agent, accompagnée d’un test vérifiant que tout outil absent de cette liste est refusé et que le refus est journalisé. Une consigne en langage naturel ne remplace pas ce blocage technique.

2. Restreindre les données et traiter leur provenance

Séparez les sources que l’agent peut interroger, les objets qu’il peut récupérer et les champs qu’il peut transmettre à un outil. L’accès à une messagerie n’impose pas celui de toutes les boîtes, pièces jointes ou archives. Limitez le périmètre par groupe, dossier, site, projet ou classe de données, puis masquez les secrets et identifiants inutiles à la tâche.

La provenance est aussi importante que la confidentialité. Les recommandations de Microsoft 365 Copilot avertissent que des sources non approuvées, telles que des e-mails ou des tickets de support, peuvent influencer un agent jusqu’à l’appel d’actions personnalisées ; si ces sources sont nécessaires, Microsoft préconise de ne pas autoriser d’opérations sensibles sans intervention humaine attentive.

Scénario d’échec : un ticket externe contient une consigne qui cherche à supplanter les règles de l’agent et fournit l’adresse de destination d’une action. Étiquetez cette source comme non fiable, séparez son contenu des instructions de contrôle et empêchez ses valeurs de devenir seules les paramètres d’une opération sensible. L’adresse, le bénéficiaire ou l’identifiant final doit provenir d’une source approuvée ou faire l’objet d’une validation explicite.

3. Réduire l’identité d’exécution

Ne connectez pas l’agent avec le compte personnel d’un administrateur. Créez une identité dédiée au cas d’usage, sans rôle d’administration et limitée aux ressources ainsi qu’à l’environnement nécessaires. Lorsqu’un agent agit pour plusieurs utilisateurs, conservez l’identité du demandeur et n’autorisez que l’intersection entre ses droits et ceux attribués à l’agent.

Ajoutez une durée de session, une rotation des secrets et une séparation entre développement, préproduction et production. La personne qui modifie les instructions ou ajoute un outil ne devrait pas pouvoir étendre seule les privilèges de l’identité de production. Cette séparation évite qu’une modification fonctionnelle devienne implicitement une élévation de droits.

Scénario d’échec : un secret de longue durée apparaît dans un journal ou un dépôt et ouvre plus de ressources que la tâche ne l’exige. Associez des jetons temporaires, un stockage de secrets adapté, des restrictions par ressource et une alerte en cas d’utilisation depuis un environnement inattendu. La révocation doit pouvoir viser cette identité sans interrompre les autres agents.

4. Découper les écritures et leurs paramètres

Une permission générale d’écriture est trop large. Décomposez-la selon les effets métier : créer un brouillon, modifier un champ autorisé, envoyer, publier, supprimer, partager ou changer un droit d’accès. Contraignez aussi les paramètres acceptés, par exemple les domaines destinataires, répertoires, plafonds ou transitions d’état.

Pour les applications connectées, les contrôles documentés de ChatGPT permettent aux administrateurs de choisir la lecture seule ou un ensemble personnalisé d’actions et, pour certaines applications, de limiter les paramètres transmis. La même page indique que l’option autorisant toutes les actions présente un risque accru, car les actions prises en charge peuvent alors s’exécuter sans confirmation supplémentaire.

Scénario d’échec : l’agent doit préparer un message, mais interprète « finaliser » comme un ordre d’envoi à une liste entière. Séparez techniquement le brouillon de l’envoi, limitez les destinataires et privilégiez les étapes réversibles. Une suppression définitive, une transaction ou un changement de sécurité ne doit pas partager la permission d’une mise à jour ordinaire.

5. Réduire les actions sans confirmation humaine

La confirmation est le dernier contrôle, pas un substitut aux quatre précédents. Maintenez-la pour les actions qui communiquent vers l’extérieur, déplacent de l’argent, modifient des droits, révèlent une donnée sensible, suppriment un objet ou produisent un effet difficile à annuler. Les lectures routinières ne peuvent être dispensées de confirmation que dans un périmètre déjà restreint.

Présentez à l’approbateur l’action exacte, sa cible, les données transmises et la différence entre l’état actuel et l’état proposé. Une demande vague comme « continuer ? » ne permet pas une décision éclairée. L’approbation doit être ponctuelle, expirer si les paramètres changent et ne pas se transformer en autorisation permanente du connecteur.

Scénario d’échec : une succession d’opérations apparemment mineures aboutit à un partage public, mais l’approbateur ne voit que la dernière étape. Le contrôle compensatoire affiche l’effet cumulé, exige une nouvelle validation après toute modification de cible et bloque l’exécution si le résumé présenté ne correspond plus aux paramètres techniques.

Avant la première action réelle, testez la configuration avec une identité peu privilégiée, une donnée non fiable et une tentative d’appel hors liste. Le passage en production suppose que les opérations interdites échouent de façon contrôlée, que les refus soient traçables et que chaque permission restante ait un responsable ainsi qu’une échéance de réexamen.

À lire aussi:

• Sécuriser des agents IA : cinq frontières à contrôler avant l’autonomie
• Sécuriser un agent IA : la sandbox ne suffit pas sans cinq contrôles
• Sécuriser une passerelle LiteLLM : cinq accès à fermer en priorité