Les collègues IA dans Slack ont besoin de leur propre identité

MintMCP fait tourner 40 à 50 agents IA dans Slack. Ils ont des noms (Max s’occupe des ventes, Leo du marketing, Peter des achats), les gens leur écrivent comme à des collègues, et aucun n’emprunte le login d’un humain. Chaque agent est son propre principal de sécurité, avec sa propre identité, sa propre liste d’outils autorisés et une piste d’audit au niveau de la gateway.

C’est tiré de The Context ft MintMCP, le livestream de l’Agentic AI Foundation, où Jiquan Ngiam, cofondateur et CEO de MintMCP, a montré comment son équipe travaille avec des agents. Ma propre conférence sur ma flotte d’agents se termine sur la partie qu’une installation maison peut se permettre de sauter : supervision, traçabilité, gestion des identités. Son intervention, c’est cette partie-là.

L’identité fait passer de l’outil au coéquipier

JQ (c’est comme ça qu’il se fait appeler) découpe l’adoption de l’IA en quatre niveaux. Le plus intéressant, ce sont les marches entre eux :

Le niveau 2, c’est là où en sont la plupart d’entre nous. Vous branchez Claude Cowork ou un outil du même genre sur le CRM et vous demandez une présentation de prévisions. Il abat des heures de travail, mais en solo.

Le niveau 3, c’est un agent qu’on n’ouvre pas comme une app. Il vit dans Slack ou Teams, peut-être avec son propre compte et sa propre adresse e-mail, et vous lui écrivez comme vous écririez à un collègue. C’est là que l’identité des agents, le contrôle d’accès et les messages d’agent à agent commencent à compter. Le niveau 4, c’est l’usine logicielle dont j’ai parlé le mois dernier.

Du solo au multijoueur

Quand je lance Claude Code ou Codex dans un terminal, personne d’autre ne voit la session. Personne ne peut l’orienter ni reprendre là où elle s’est arrêtée. JQ appelle ça l’IA en solo.

Dans un fil Slack, plusieurs humains et plusieurs agents travaillent au même endroit, tout le monde voit ce qui se passe, et n’importe qui peut intervenir. Les gens adoptent les agents plus vite quand ils les regardent travailler, et les agents gagnent un endroit où travailler ensemble.

Un chiffre m’a surpris. Sur la gateway de MintMCP, qui traite plus de deux millions d’appels MCP et d’agents par jour, les 20 connecteurs les plus installés sont des outils de travail du quotidien : Google, Slack, Notion, Figma, HubSpot. Les ingénieurs sont arrivés en premier, mais ce sont maintenant les non-ingénieurs qui gagnent le plus de temps. Chez Modern Treasury, les agents font gagner des heures par dossier aux technical account managers.

Un fil Slack est une sandbox

La démo en direct était simple. Il a demandé à Leo, l’agent marketing, à quels événements de l’AAIF ils étaient allés et lesquels arrivaient. Leo a ouvert un fil, lancé bash et une recherche, lu Slack via le serveur MCP de Slack, et diffusé chaque étape dans le fil. Sa réponse incluait le livestream qu’on était en train de regarder.

Voici l’installation telle qu’il l’a décrite :

Mon exemple préféré vient de l’ingénierie. Dan est un agent de code sur Claude, Sam en est un sur Codex. Un humain demande à Dan une modification de leur gateway LLM. Dan lit la base de code, propose un plan et attend un feu vert. Il construit une première version et écrit à Sam, et les deux se relisent mutuellement dans le canal jusqu’à tomber d’accord. Puis Dan notifie l’humain, l’humain relit et merge, et le bot se réveille une dernière fois pour demander si la doc a besoin d’une mise à jour.

Mon agent de code, Spark, fait déjà relire ses pull requests par un modèle d’une autre famille. La différence, c’est l’endroit : chez eux, tout l’aller-retour se trouve dans un canal où les gens peuvent regarder et intervenir.

Les autres qu’il a montrés : Peter relance les revues de sécurité, les documents manquants et les tenants d’essai sur les deals en cours, et notifie les gens de ce qui reste ouvert. JQ a dit qu’il ne savait plus très bien si c’est lui qui relance les bots ou eux qui le relancent. Minty répond aux clients dans leurs canaux partagés ; après un long fil sur le SSO, un client a écrit « vous avez été parfait, pas besoin d’humain, c’est tout bon pour moi ».

Leur premier agent, Max, a été mis en service en février. Ils sont vite passés d’un agent à cinq, puis à 20. Aujourd’hui, chaque nouvelle recrue crée un agent dès sa première semaine.

Chaque agent est son propre principal

Sans couche d’identité, un agent détient les identifiants d’un humain. Un agent commercial agit en tant que JQ dans le CRM, sur LinkedIn et dans Gmail, et vous perdez le contrôle, le journal d’audit et toute trace de qui a fait quoi. Son exemple : vous lui demandez de faire le ménage dans le CRM, et il comprend « faire le ménage » comme « tout supprimer ».

Chez MintMCP, chaque agent a donc :

• sa propre identité et son propre périmètre, avec une liste de ce qu’il a le droit de faire
• des identifiants explicites à chaque appel d’outil : un compte de service, ou un identifiant délégué qui agit pour un utilisateur, avec la chaîne de délégation enregistrée
• l’OAuth géré au niveau de la gateway, renouvellement compris, parce qu’un agent en arrière-plan ne peut pas s’arrêter pour cliquer sur un écran de connexion

Les permissions se décident à l’exécution

C’est la partie à laquelle je n’avais pas réfléchi. L’agent doit-il lire les données en son nom propre, ou au nom de la personne qui a demandé ? Ça dépend du système. Un assistant qui lit des agendas doit utiliser les identifiants de la personne qui demande. Un agent qui suit le monitoring DevOps doit utiliser un compte de service.

Un consentement OAuth, c’est un token statique, et c’est facile à appréhender. Dans un canal, les bonnes permissions dépendent du consentement, de qui a envoyé le message, de qui d’autre verra la réponse, et de la tâche. JQ appelle ça le passage des permissions statiques aux permissions dynamiques.

Environ 99 % des contrôles de MintMCP restent déterministes. Sa règle : ce que vous pouvez rendre déterministe, rendez-le déterministe. Le cas difficile, c’est un fil avec une personne A, qui peut voir certaines données, et une personne B, qui ne peut pas. Si A dit « vas-y, récupère-les », c’est sans doute acceptable, comme si les deux étaient dans une salle de réunion. Ils testent un peu d’IA pour cette décision, à deux conditions : tout le monde dans le fil voit que l’accès a été accordé, et A dispose d’un bouton pour annuler.

Verrouiller les outils à la gateway

Les scopes OAuth sont souvent trop larges, si bien qu’un agent hérite de tout ce que son utilisateur peut faire, y compris envoyer des e-mails et supprimer des enregistrements. La réponse de MintMCP se trouve dans la gateway MCP, et elle est déterministe :

• les outils risqués sont refusés d’office, comme supprimer des enregistrements ou envoyer des e-mails
• les agents ne détiennent jamais les clés finales, seulement un accès temporaire via la gateway
• la gateway journalise chaque appel, pour qu’on puisse retrouver quel agent a fait quoi
• les outils sont regroupés par rôle, pas par serveur : les ingénieurs ont Jira en lecture et écriture et Intercom en lecture seule, un agent marketing a droit à moins
• les données ont aussi un périmètre : Google Drive, mais seulement ces 10 dossiers

Deux détails qui m’ont plu. L’outil fork-repository du serveur MCP de GitHub est l’un des premiers que leurs clients désactivent. Et les clients de la finance et de la santé font passer leur DLP existant sur chaque appel MCP, ce qui ajoute 100 à 200 ms.

J’ai appris la partie déterministe à mes dépens. En août, j’ai interdit les outils MCP de mon app de finances à la plupart de mes agents avec un motif dans la config de ma gateway. Un mois plus tard, j’ai testé : le motif ne correspondait à rien, et un agent censé être bloqué se voyait proposer les 13 outils, outils d’écriture compris. Les noms d’outils utilisaient un autre séparateur que celui que j’avais supposé. Maintenant, je vérifie une règle de refus en demandant à l’agent de lister ses outils.

Personne n’avait demandé ce message de 6 h

La meilleure histoire est arrivée pendant les questions. À 6 h du matin, Max a posté dans le canal des deals qu’un même deal avait été attribué à deux commerciaux. JQ a commencé à déboguer le deal, puis s’est arrêté : pourquoi l’agent s’était-il réveillé pour poster ça, au fond ?

Il a fallu le journal d’audit pour le savoir. Un membre de l’équipe avait demandé quelque chose à son propre agent, cet agent avait délégué à Max, et Max avait remonté l’affaire à tout le canal. Sans la chaîne de délégation, personne ne l’aurait su.

C’est la prochaine phase qu’il voit venir : qui peut créer un agent, lui écrire et le modifier, qui les orchestre tous, et, selon ses mots, quel est l’équivalent des RH pour les agents.

La mémoire aussi a besoin d’un contrôle d’accès

Darren Shepherd, l’un des animateurs, a objecté. On ne peut pas étiqueter chaque phrase avec une classification de données, et à mesure que les modèles deviennent plus malins, l’IA devrait peut-être prendre davantage de ces décisions. Nous faisons confiance aux humains, a-t-il dit, à cause des processus qui les entourent, pas parce qu’ils sont fiables.

La réponse de JQ a été une seconde dimension : la mémoire. Quand son agent personnel parle à Darren, il ne doit pas partager les finances de JQ. La mémoire est donc cloisonnée (un silo par personne, par équipe, par entreprise, par client), et l’agent voit des silos différents selon la personne à qui il parle. Le même badge persistant à l’entrée, des livres différents qu’il a le droit de lire. Pour lui, cette partie relève encore largement de la R&D.

Où en est ma propre flotte

Chacun de mes agents a son propre fil Telegram. Sur la carte de JQ, c’est le niveau 2 : un humain et un agent par fil, personne d’autre pour regarder. Telegram ne transmet même pas les messages d’un bot à un autre bot, donc mes agents ne peuvent pas se parler là-bas.

Aujourd’hui, j’ai donné un compte Slack à deux d’entre eux : Nova, mon généraliste, et Spark, mon codeur. Ils vivent dans un espace de travail réservé aux agents, chacun avec sa propre app Slack, parce qu’une app correspond à un utilisateur bot. C’est la première brique d’identité. Prochaine étape : que Nova ouvre un canal pour une tâche de code et y fasse venir Spark, comme Dan fait venir Sam.

Le hic : l’offre gratuite de Slack autorise 10 apps par espace de travail, et j’ai 17 agents. Identifiants délégués, permissions à l’exécution et silos de mémoire : tout ça est encore devant moi.

L’intervention dure 40 minutes, et les questions-réponses sur les permissions en sont le meilleur moment. MintMCP a aussi écrit un billet sur comment construire un collègue IA dans Slack. Et si vous avez résolu le cas du fil avec la personne A et la personne B, je serais ravi de savoir comment.

Texte brut: ai-coworkers-slack-agent-identity.md · Flux Atom · Toutes les notes