Agents IA : les permissions à vérifier avant de les connecter

Par Ethan Ben Amram · 3 min de lecture

Résumer un email et envoyer une réponse sont deux responsabilités différentes. Dès qu’un assistant peut modifier un CRM, partager un fichier ou déclencher une action, la question des accès devient aussi importante que la qualité de ses réponses.

Commencer par préciser ce que l’agent peut faire

Le mot « agent » recouvre des outils très différents. Certains suivent un enchaînement prévu ; d’autres choisissent leurs prochaines actions à partir d’un objectif. Anthropic distingue ainsi les workflows et les agents et recommande de partir de la solution la plus simple adaptée au besoin.

Pour votre entreprise, une fiche suffit à lancer la discussion : quels documents peut-il lire ? Quelles applications peut-il utiliser ? Peut-il écrire, envoyer, supprimer ? Sous quelle identité agit-il ? Qui peut l’arrêter ? Une démonstration réussie ne répond pas à ces questions.

Quand un document essaie de donner des ordres

Un agent peut rencontrer des instructions malveillantes dans une page web, un email ou un document qu’il consulte. C’est une forme d’injection indirecte de prompt, décrite par l’OWASP. Le contenu à analyser cherche alors à influencer le comportement du système.

Exemple fictif : un assistant chargé de préparer une réponse commerciale lit une pièce jointe qui tente de lui faire transmettre d’autres documents. Le danger dépend notamment des accès dont il dispose et de la possibilité d’envoyer des informations sans validation.

Le NCSC souligne la difficulté à séparer totalement données et instructions dans ces systèmes. Une phrase « ignore les instructions malveillantes » n’est donc pas une barrière suffisante. Il faut aussi limiter ce qu’une erreur peut provoquer.

Cinq garde-fous à définir avant le lancement

1. Commencer en lecture seule. Faites produire un brouillon ou une proposition d’action. Observez les résultats avant d’autoriser des modifications.
2. Limiter le périmètre. Un assistant commercial n’a pas besoin de tous les dossiers RH. Utilisez des accès dédiés et restreints, en respectant aussi les droits de l’utilisateur qui pose la question.
3. Valider les actions sensibles. Avant un envoi, un partage externe, une suppression ou un paiement, montrez à la personne responsable le destinataire, le contenu et les conséquences exactes.
4. Poser des limites techniques. Les applications et services doivent contrôler les droits, destinations et volumes autorisés. Ces restrictions ne doivent pas dépendre seulement du bon comportement du modèle.
5. Prévoir l’arrêt et la traçabilité. Identifiez qui coupe les accès et comment retrouver les actions réalisées. Protégez les journaux : ils peuvent eux-mêmes contenir des données sensibles.

Ces choix répondent notamment au risque d’autonomie excessive décrit par l’OWASP : trop de fonctionnalités, trop de permissions ou trop peu de supervision pour le besoin réel.

Le petit exercice à faire avant la production

Dans un environnement de test, utilisez des données fictives et des comptes sans accès aux dossiers réels. Vérifiez un mauvais destinataire, une demande hors périmètre, un document contenant des consignes parasites, une panne d’outil et deux demandes identiques successives.

Le résultat attendu doit être écrit à l’avance : demander une validation, refuser l’accès, conserver un brouillon ou signaler l’échec. Vérifiez aussi qu’une action interrompue n’est pas relancée automatiquement de manière dangereuse. Un test réussi sur cinq cas n’établit pas une sécurité absolue ; il révèle déjà des défauts concrets à corriger.

Les permissions ne règlent pas les erreurs de contenu. Prévoyez également une méthode pour vérifier les réponses produites par l’IA.