Permissions d'agent IA : un seul agent Slack pour toute l'équipe

Les permissions d’agent IA sont les règles qui déterminent ce qu’un agent peut lire, modifier et envoyer, et au nom de qui il le fait. Elles restent simples quand une personne fait tourner un agent avec ses propres comptes. Elles deviennent beaucoup plus difficiles quand un seul agent sert toute une entreprise à partir de Slack, prend des requêtes de n’importe qui, lit tout ce que n’importe qui publie et se souvient de ce qu’il apprend. Cet article s’appuie sur un vrai lancement de ce type pour montrer où se trouvent les risques et quels contrôles doivent vivre à l’extérieur du modèle.

Le lancement, c’est le Every Agent, annoncé par l’entreprise de médias Every le 6 octobre 2026. Dan Shipper, cofondateur et chef de la direction d’Every, le décrit comme « un seul agent que toute l’entreprise partage, bâti avec Claude Managed Agents », la plateforme d’agents hébergés d’Anthropic. Le même jour, la chaîne Claude d’Anthropic a publié une entrevue avec deux membres de l’équipe d’Every sur la façon dont ils l’ont construit. Interrogé sur l’identité, l’un d’eux a résumé l’objectif de conception :

« Essayons de le faire agir aussi près d’un humain que possible à l’intérieur de Slack. » - un des deux invités d’Every

Pour la convivialité, c’est le bon réflexe. Pour la sécurité, c’est là que commencent les questions : un collègue humain porte une seule identité et un seul ensemble de droits d’accès, tandis qu’un agent partagé en porte plusieurs à la fois.

Un agent partagé a deux identités, et chaque permission appartient à l’une d’elles

L’équipe d’Every décrit un modèle à deux niveaux. À l’intérieur de la conversation Slack, l’agent est son propre participant, avec son propre nom et sa propre mémoire. Quand il va chercher un document ou vérifier quelque chose dans un outil connecté, il travaille surtout avec l’accès de la personne qui a demandé. La page produit d’Every met la même règle par écrit : l’agent « utilise l’accès propre à chaque personne », et « l’accès aux fournisseurs est autorisé en fonction de l’utilisateur qui agit et de son espace de travail ».

Cette séparation porte déjà un nom dans les normes d’identité. La RFC 8693, la spécification OAuth 2.0 Token Exchange publiée en janvier 2020, sépare l’usurpation (impersonation), où une partie « se voit attribuer tous les droits » d’une autre, de la délégation, où la partie qui agit « conserve sa propre identité distincte » de celle de la personne qu’elle sert. La spécification définit une revendication act pour qu’un même jeton puisse porter les deux noms : l’utilisateur dont les droits s’appliquent, et l’agent qui fait le travail.

La distinction compte pour les journaux encore plus que pour la vérification d’accès. Si l’agent usurpe Alice, un enregistrement indiquant qu’Alice a exporté un chiffrier à 2 h du matin ne peut pas dire à un enquêteur si c’est Alice qui l’a fait ou l’agent qui l’a fait pour elle. Every affirme que les changements de permission et l’activité du fournisseur « produisent des pistes d’audit limitées aux métadonnées ». La page ne dit pas si ces pistes nomment les deux parties, et c’est la première question qu’il vaut la peine de poser à n’importe quel fournisseur d’agent d’équipe.

La délégation garde l’identité de l’agent à côté de celle de l’utilisateur, pour que le journal puisse dire qui a agi. Source : RFC 8693.

Le député confus revient quand quelqu’un d’autre a écrit les instructions

Agir avec les droits de la personne qui demande règle un problème et en rouvre un plus ancien. En 1988, Norm Hardy a décrit le député confus (confused deputy). Un compilateur chez l’entreprise de temps partagé Tymshare avait le droit d’écrire des fichiers dans son propre répertoire système, où se trouvait aussi le fichier de facturation. Un utilisateur qui connaissait le nom du fichier de facturation l’a fourni comme destination pour la sortie de débogage du compilateur, et le compilateur a écrasé les registres de facturation. Le compilateur n’était pas malveillant. Il a utilisé sa propre autorité au nom de quelqu’un qui ne l’avait pas.

Un agent Slack partagé est un député par conception. Alice lui demande de résumer un fil. Le fil contient un message de Bob, et le message de Bob contient des instructions. L’agent détient maintenant l’accès d’Alice tout en lisant les mots de Bob, et un modèle de langage n’a aucun moyen fiable de distinguer une requête du texte qu’on lui a demandé de traiter. Les droits d’Alice fixent le plafond, mais c’est Bob qui tient le volant.

Ce n’est pas hypothétique. En août 2024, la firme de sécurité PromptArmor a montré que Slack AI pouvait divulguer des données de canaux privés. Un attaquant a publié un message dans un canal public où il était le seul membre. Quand une victime a plus tard demandé à Slack AI une clé d’API conservée dans son canal privé, l’assistant a tiré les deux messages dans le même contexte, suivi les instructions de l’attaquant et rendu un lien de « ré-authentification » avec la clé intégrée dans son adresse. Un clic a envoyé la clé au serveur de l’attaquant. La première réponse de Slack, selon PromptArmor, a été que ce comportement était voulu, puisque les messages publics peuvent être cherchés par tous les membres de l’espace de travail.

L’accès de la victime n’a jamais été dépassé : c’est l’attaquant qui a fourni les instructions. Étapes rapportées par PromptArmor en août 2024.

Le cas correspond exactement au modèle de l’agent partagé. Les permissions de la victime ont été respectées du début à la fin, et rien n’a été lu que la victime ne pouvait pas lire. La fuite est venue de l’origine des instructions suivies, pas de l’accès utilisé.

Un agent Slack combine la trifecta létale par défaut

Simon Willison a donné à cette classe de risque un test compact en juin 2025 et l’a appelé la trifecta létale (lethal trifecta). Un agent qui a accès à des données privées, qui est exposé à du contenu non fiable et qui a un moyen de communiquer vers l’extérieur peut être trompé pour envoyer les premières à un attaquant. Son conseil est d’éviter la combinaison entièrement, parce que les filtres qui attrapent la plupart des tentatives d’injection en manquent encore assez souvent pour que ça compte. Dans la sécurité des applications web, souligne-t-il, arrêter 95 % des attaques est une note d’échec.

Un agent d’entreprise dans Slack commence avec les trois pattes. Les données privées arrivent avec chaque disque, boîte de réception et dépôt connecté. Le contenu non fiable, c’est chaque message et fichier partagé que l’agent lit, y compris ceux de collègues, d’invités dans des canaux partagés et de courriels transférés. La communication externe, c’est le cœur du travail de l’agent : publier des réponses, afficher des liens, envoyer des courriels, ouvrir des pull requests. Enlever une seule patte enlève la plupart du produit, c’est pourquoi les contrôles doivent rétrécir chaque patte plutôt que la couper.

La mémoire partagée est un problème de permission, pas seulement une fonctionnalité

Deux des histoires racontées dans l’entrevue sont présentées comme de petites joies, et les deux se lisent différemment avec les permissions en tête. Pendant l’inscription annuelle aux avantages sociaux, l’agent connaissait chaque régime et la situation personnelle de chaque employé, et a aidé chaque personne à choisir. Dans une autre histoire, un cadre a demandé à l’agent de se souvenir d’une bière due à un collègue, et l’agent a ramené la dette plus tard, dans une conversation différente où il a jugé le rappel pertinent.

La deuxième histoire est charmante parce que l’information est inoffensive. Le mécanisme, par contre, est celui qui ferait voyager un détail médical d’un fil sur les avantages sociaux jusqu’à un canal d’équipe : quelque chose écrit en mémoire dans un contexte, puis récupéré dans un autre par un modèle qui décide de ce qui est pertinent. Le billet de lancement et la page produit d’Every, consultés le 17 octobre 2026, ne disent pas comment la mémoire est cloisonnée entre les utilisateurs.

La documentation sur la mémoire pour les Managed Agents d’Anthropic est explicite sur le risque. Les banques de mémoire s’attachent avec un accès en lecture et en écriture par défaut, et la page avertit qu’une injection d’invite réussie peut écrire du contenu malveillant dans une banque, que des sessions ultérieures lisent ensuite comme une mémoire de confiance. La même page recommande des banques ciblées, une par utilisateur et une pour la connaissance partagée du domaine, avec un accès en lecture seule pour le matériel de référence. C’est le bon réglage par défaut pour un agent d’équipe.

Les permissions d’agent IA doivent être appliquées à l’extérieur du modèle

L’équipe d’Every a été franche sur la partie difficile. Les collègues demandent des choses à l’agent dans des zones grises, où une personne saurait simplement que partager un rapport donné est inoffensif, et ce genre de jugement est difficile à inscrire dans la logique d’un agent. La réponse du projet OWASP, dans son entrée 2025 sur l’agence excessive (LLM06), est de cesser complètement de demander au modèle de trancher :

« Implémentez l’autorisation dans les systèmes en aval plutôt que de vous fier à un LLM pour décider si une action est permise ou non. » - OWASP Top 10 pour les applications LLM 2025

OWASP attribue l’agence excessive à trois causes profondes : la fonctionnalité excessive, les permissions excessives et l’autonomie excessive. Ses mesures d’atténuation incluent d’exécuter les extensions dans le contexte de l’utilisateur avec la portée minimale dont la tâche a besoin, et d’exiger une approbation humaine pour les actions à fort impact. La page produit d’Every énumère des contrôles de ce type : des permissions définies par les administrateurs par utilisateur et par groupe, des connexions limitées aux coéquipiers qu’un propriétaire choisit, et une option pour exiger une approbation « avant que quoi que ce soit s’envoie, se dépense ou s’expédie ».

La plateforme en dessous aide, mais elle ne trace pas la frontière toute seule. Managed Agents conserve des identifiants par utilisateur dans des coffres (vaults) qui sont attachés session par session, pour qu’une même définition d’agent puisse servir plusieurs personnes avec leurs propres jetons. La même page avertit que les coffres ont la portée de l’espace de travail : n’importe quelle clé d’API avec accès à l’espace de travail peut référencer n’importe quel coffre quand elle ouvre une session. Le code qui associe un utilisateur Slack à un coffre est donc la vraie frontière de sécurité, et il appartient à l’équipe qui bâtit l’agent, pas à la plateforme.

Avant de confier les clés à un agent d’équipe, vérifiez ces sept contrôles

Ces vérifications découlent des sources ci-dessus et s’appliquent à n’importe quel agent d’équipe, acheté ou bâti.

• Identifiants par utilisateur, jamais un compte de service partagé. Un agent qui détient l’union des droits de tout le monde, c’est le député confus à son pire.
• Les deux identités dans chaque entrée de journal. L’enregistrement devrait montrer qui a demandé et le fait que l’agent a agi, comme le fait la revendication act de la RFC 8693 à l’intérieur d’un jeton.
• Mémoire personnelle par défaut. La mémoire partagée devrait être organisée par une personne, et montée en lecture seule pour les sessions qui n’ont aucune raison d’y écrire.
• Approbation pour tout ce qui sort de l’espace de travail. Envoyer, dépenser et publier, c’est la patte « communication externe » de la trifecta.
• Chemins sortants étroits. Un identifiant Managed Agents peut être limité à une liste d’hôtes, et un environnement peut limiter les domaines que l’agent atteint tout court.
• Chaque message traité comme non fiable, collègues inclus. L’attaque contre Slack AI n’a eu besoin de rien de plus qu’une publication publique.
• Rétention connue à l’avance. L’aperçu d’Anthropic indique que Managed Agents n’est pas actuellement admissible à la rétention de données zéro ni à la couverture HIPAA BAA, une limite qu’Every mentionne aussi dans son article sur l’agent partagé. Les questions d’avantages sociaux sont précisément le genre de données pour lesquelles ça compte.

Les agents partagés diffusent les compétences plus vite, et les permissions décident si c’est sécuritaire

Les arguments en faveur d’un agent partagé unique sont solides, selon ma lecture. Every rapporte que ses agents personnels antérieurs étaient difficiles à maintenir et que les gens apprenaient surtout en regardant l’agent de quelqu’un d’autre à l’œuvre, tandis qu’un agent partagé s’améliore à partir des corrections de tout le monde dans des fils publics. C’est un argument sur la façon dont les compétences se diffusent dans une entreprise, et il tient la route.

L’histoire de sécurité racontée dans l’entrevue porte surtout sur des primitives d’isolation : bacs à sable, sessions, mémoire cloisonnée et identifiants par utilisateur. Ces primitives sont nécessaires, mais ce ne sont pas un modèle de permissions. Le modèle de permissions, c’est l’ensemble des décisions qu’un bâtisseur prend sur les identifiants que chaque session reçoit, la mémoire dans laquelle elle peut écrire, les actions qui attendent une personne et les messages qu’elle traite comme des instructions. Aucune de ces décisions n’apparaît dans une démo, et toutes décident si un agent partagé est un collègue ou un député que n’importe qui dans l’espace de travail peut emprunter.