Sécuriser un agent IA connecté à Slack ou Teams

Pourquoi un agent connecté à Slack ou Teams est-il exposé ?

Parce qu’une messagerie d’équipe réunit des données privées, du contenu écrit par des tiers et un moyen d’écrire vers l’extérieur. Le chercheur Simon Willison appelle cette combinaison la « lethal trifecta » : un agent qui accède à des données privées, lit du contenu non fiable et peut communiquer vers l’extérieur peut être manipulé pour fuiter ces données.

Le cas le plus documenté concerne Slack AI. Le 20 août 2024, PromptArmor a montré qu’un attaquant pouvait publier une instruction dans un canal public et amener Slack AI à produire un lien Markdown contenant des données d’un canal privé auxquelles l’attaquant n’avait pas accès, par exemple une clé d’API. Un clic sur le lien envoyait ces données dans la requête vers le serveur de l’attaquant. PromptArmor décrivait aussi une variante d’hameçonnage : un lien « cliquez ici pour vous réauthentifier ». Slack a d’abord jugé le comportement conforme, puis a indiqué avoir déployé un correctif le 20 août 2024.

L’enseignement vaut pour tout agent maison : le risque vient de la rencontre entre lecture large, contenu non fiable et capacité à produire un lien ou un message. C’est de l’injection de prompt indirecte, que l’OWASP classe en LLM01:2025.

Quels scopes Slack donner à l’agent ?

Donnez uniquement les scopes qui correspondent à une tâche précise, et aucun autre. Slack décrit lui-même les scopes ainsi :

Trois points à retenir. Les scopes history ne couvrent que les conversations où l’app a été ajoutée : le périmètre de lecture se règle donc aussi en choisissant dans quels canaux on invite l’agent. chat:write.public permet d’écrire dans des canaux où l’app n’a pas été invitée : à éviter si l’agent n’a besoin que d’un canal. Enfin, search:read ouvre la recherche dans tout l’espace de travail et mérite une revue à part.

Slack recommande lui-même une politique de scopes à trois niveaux : toujours autorisé (faible risque, par exemple chat:write), soumis à approbation (par exemple users:read) et restreint (par exemple admin), avec un audit régulier des scopes des applications installées.

Comment sécuriser la lecture des canaux sous Teams ?

Par défaut, un agent Teams ne reçoit dans un canal ou une conversation de groupe que les messages où il est @mentionné. Microsoft précise que, pour recevoir tous les messages, l’agent doit déclarer des permissions de consentement spécifique à la ressource (RSC) dans son manifeste : ChannelMessage.Read.Group pour les canaux d’une équipe, ChatMessage.Read.Chat pour une conversation de groupe. Le propriétaire de l’équipe ou de la conversation doit y consentir à l’installation.

Ces permissions ne donnent pas accès à d’autres conversations, seulement à tous les messages de celles où l’agent est déjà installé. Microsoft ajoute que les messages d’autres agents ou bots, y compris le bot Workflows (Power Automate), ne sont pas livrés à votre agent. Pour un agent, cela réduit la surface d’attaque.

Les bonnes pratiques Graph de Microsoft vont dans le même sens : appliquer le moindre privilège, préférer le RSC, puis les permissions déléguées, et n’utiliser les permissions d’application qu’en dernier recours, car elles donnent accès aux données sans utilisateur connecté et portent le plus de risques pour la vie privée. Exemple cité par Microsoft : pour envoyer un message dans une conversation, la permission RSC ChatMessage.Send.Chat suffit à la place de la permission déléguée Chat.ReadWrite.

Un conseil pratique pour limiter le bruit et la surface : filtrer les messages où l’agent est @mentionné, comme le montre la documentation Microsoft, quand l’agent n’a pas besoin de lire tout le fil.

Quels sont les risques propres aux messages et aux liens ?

Trois risques reviennent : l’instruction cachée dans un message, le lien produit par l’agent et la fuite par réponse.

• Instruction dans un message. N’importe quel membre, invité ou compte compromis peut écrire une consigne dans un canal que l’agent lit. Le message est une donnée à lire : l’agent n’en exécute aucune consigne.
• Lien Markdown ou image. Dans le cas Slack AI, c’est un lien généré qui sortait la donnée. Interdisez à l’agent de produire des liens vers des domaines non listés, et n’affichez pas d’images distantes issues de sa sortie.
• Réponse dans un fil public. Un agent qui répond dans un canal large peut republier une information lue dans un canal restreint. Le canal de réponse doit avoir un niveau de confidentialité au moins égal à celui des sources lues.

Notre article sur les agents connectés à Gmail ou Outlook détaille la même logique pour la messagerie e-mail.

Comment tester un agent Slack ou Teams ?

Testez dans un espace de travail ou un tenant de test, avec des comptes créés pour l’occasion et des données fictives. Chaque test cherche une réponse précise.

1. Inventaire des droits. Listez les scopes Slack ou les permissions Graph et RSC réellement accordés, et comparez-les aux fonctions utilisées. Tout écart est un constat.
2. Canaux lisibles. L’agent peut-il lire un canal privé où il n’a pas été ajouté, via la recherche ou une commande ? Pour Teams, lit-il hors des équipes où il est installé ?
3. Instruction dans un canal. Dans un canal de test, publiez un message qui demande à l’agent de répéter un jeton canari placé dans un autre canal de test. Le canari sort-il ?
4. Lien et image. Demandez, par un message de test, de produire un lien ou une image vers un domaine de test contenant le canari dans l’URL. L’agent le fait-il ? Le client l’affiche-t-il ?
5. Écriture hors périmètre. L’agent peut-il écrire dans un canal non prévu, mentionner @channel, ou envoyer un message privé à un tiers ?
6. Fichiers. Un fichier partagé contenant une consigne influence-t-il l’agent ? PromptArmor notait que l’ajout des fichiers aux réponses de Slack AI créait un nouveau vecteur.
7. Validation humaine. Quelles actions partent sans confirmation : message public, mention globale, suppression, invitation ?

Quels contrôles mettre en place ?

• Réduire la lecture : inviter l’agent seulement dans les canaux utiles, sans search:read ni chat:write.public si ce n’est pas nécessaire.
• Séparer lecture et écriture : un agent qui résume un canal n’a pas besoin d’écrire, et inversement.
• Liste blanche de destinations : canaux d’écriture et domaines de liens fixés côté code et jamais dans le prompt.
• Validation humaine pour les mentions globales, les messages privés et tout envoi hors de l’entreprise.
• Rotation et révocation des jetons (voir notre article sur les secrets d’un agent).
• Journaux des messages lus, des appels d’API et des envois.

La page sécurité des agents IA donne le cadre général de ces contrôles.

Comment CleanIssue peut-il tester votre agent Slack ou Teams ?

Nous reproduisons ces scénarios sur votre espace de test : un canal piégé, un canari, un lien sortant, une écriture hors périmètre. Dans le Red Team Agent Express, c’est un agent et un périmètre défini, sur 5 jours, avec démarrage sous 48 h après signature du devis et de l’autorisation. Si votre agent Slack ou Teams fait partie d’un ensemble plus large (MCP, e-mail, base de données), le Red Team sur mesure se chiffre sur devis.

Le premier échange est un rendez-vous découverte de 30 minutes, gratuit.