Tu as connecté ton agent IA à Slack, GitHub et Jira. La plateforme a affiché une jolie boîte de dialogue : « Autoriser l'accès à Slack ? » Tu as cliqué oui. Tu te sentais responsable. Tu te sentais en contrôle.

Tu ne l'étais pas. L'agent venait d'envoyer en DM à ton PDG un brouillon de rapport de bug destiné à #engineering. La porte d'autorisation n'a jamais posé de question sur les destinataires, les canaux, ni sur ce que « accès Slack » signifie vraiment quand c'est une machine qui tient les clés.

Trois plateformes, un seul schéma, zéro profondeur

Il y a deux semaines, le débat portait sur les plateformes d'agents dépourvues de toute autorisation digne de ce nom — des agents avec un accès root et personne pour coder sudo. Cette conversation est déjà dépassée. Les trois grandes plateformes ont désormais livré leur réponse : des workflows d'approbation d'outils, ces dialogues « T'es sûr ? » qui s'affichent avant qu'un agent IA (un programme qui agit à ta place, pas juste un chatbot) fasse quelque chose de conséquent. Le trou de sécurité n'a pas été comblé. Il a été recouvert de papier peint.

L'ADK de Google a ajouté des confirmations d'action lors de Cloud Next (22-24 avril). Les Managed Agents d'Anthropic, lancés le 8 avril, incluaient des politiques de permission par outil dès le premier jour. Le SDK Agents d'OpenAI a livré des callbacks needs_approval dans sa mise à jour du 15 avril. Trois entreprises, convergeant vers la même idée — comme trois architectes concevant indépendamment le même toit percé.

Le schéma est identique chez les trois : tu approuves ou refuses l'accès au niveau de l'outil. « Autoriser Slack » ou « Refuser Slack ». Binaire. On ou off. Un videur qui vérifie les pièces d'identité à l'entrée de l'immeuble pendant que chaque porte d'appartement à l'intérieur reste grande ouverte.

Là où le vrai danger se cache

Le rayon d'explosion d'un mauvais appel d'outil — les dégâts qu'il peut réellement causer — se trouve dans les paramètres : vers quel canal Slack le message est envoyé, sur quelle branche Git quelqu'un fait un force-push, quelle requête SQL s'exécute sur ta base de production, quel projet Jira l'agent inonde de tickets auto-générés.

Soyons honnêtes, Google ADK et OpenAI transmettent bien les paramètres d'appel aux callbacks écrits par le développeur. Tu peux écrire du code comme return amount > 1000 pour bloquer les opérations coûteuses. Mais voici la distinction cruciale : la plateforme te donne un hook, pas un filet de sécurité. Tu écris les règles toi-même, en Python brut, pour chaque outil, chaque paramètre, chaque cas limite. Pas de moteur de politiques déclaratives. Pas d'allowlists intégrées. Pas de bouton « poster uniquement sur #engineering et #random » dans un tableau de bord.

L'implémentation d'Anthropic est encore plus simple — leurs politiques de permission opèrent uniquement sur les noms d'outils. L'événement user.tool_confirmation accepte exactement deux réponses : "allow" ou "deny". Pas de champ pour les contraintes sur les arguments. Pas de logique conditionnelle. L'agent peut utiliser Slack ou il ne peut pas. Point.

Comme l'a écrit le chercheur en sécurité Simon Willison en septembre 2024 : « Une fois qu'un agent LLM a ingéré une entrée non fiable, il doit être contraint de sorte qu'il soit impossible pour cette entrée de déclencher une action conséquente. » Les portes au niveau de l'outil n'y parviennent pas. Elles contraignent quelles actions existent, pas ce que ces actions font.

On a déjà vu ce film

Le schéma est un copier-coller des permissions mobiles circa 2008. Android 1.0 accordait un accès global « caméra » — aucune distinction entre une appli selfie et un scanner de documents photographiant silencieusement ton bureau. Il a fallu à Google sept ans et Android 6.0 Marshmallow (2015) pour livrer le scoping des permissions à l'exécution — des contrôles contextuels sur comment une appli utilise la caméra, pas seulement si elle le peut.

Les plateformes d'agents en sont au stade Android 1.0 aujourd'hui. La boîte de dialogue de permission existe. Elle ressemble à de la sécurité. Ce n'en est pas.

Microsoft a dit tout haut ce que tout le monde pense tout bas

Le 22 avril, le blog développeurs de Microsoft a publié un aveu sans détour : « Le suivi d'instructions seul ne devrait pas être traité comme une frontière de sécurité. » Leurs propres tests de red team — menés dans le cadre de l'Agent Governance Toolkit qu'ils ont open-sourcé plus tôt ce mois-ci — ont révélé un taux de violation de politique de 26,67 % en utilisant des garde-fous basés uniquement sur les prompts. Un appel dangereux sur quatre passe si tu comptes sur le LLM pour se policer lui-même.

AGT est ce qui se rapproche le plus d'une vraie solution : une couche middleware qui s'insère entre ton agent et ses outils, appliquant des règles de politique déclaratives écrites en YAML, OPA ou Cedar. Il inspecte réellement les paramètres. Il bloque réellement en fonction des valeurs des arguments. Mais c'est du middleware que tu boulonnes toi-même — ce n'est natif à aucune plateforme d'agents. Du bon chatterton, mais du chatterton quand même.

Le prix de faire les choses bien

Le contrôle au niveau des paramètres est vraiment difficile. Ça nécessite une compréhension sémantique — savoir que #général est un canal public tandis que #rémunération-direction ne l'est pas. Ça ajoute de la latence à chaque appel d'outil dans des systèmes qui se battent déjà avec les limites de fenêtre de contexte (la quantité de texte que l'IA peut « voir » en même temps). Et pire que tout, ça crée une fatigue d'approbation : plus les contrôles sont granulaires, plus vite les utilisateurs se conditionnent à cliquer « tout approuver » sans lire — exactement le comportement qui transforme les permissions en théâtre.

Ce que tu devrais vraiment faire

En attendant que les plateformes livrent des contrôles natifs sensibles aux paramètres, tu as deux options honnêtes. Un : construire un middleware qui vérifie les arguments d'appel d'outil contre des allowlists — canaux autorisés, branches autorisées, patterns de requêtes autorisés. Deux : accepter que cliquer « Autoriser Slack » signifie « autoriser l'agent à faire tout ce que l'API Slack permet », et planifier en conséquence.

La boîte de dialogue de permission sur ta plateforme d'agents est un placebo. Elle contrôle quelles portes l'agent peut ouvrir, mais pas ce qu'il fait une fois dans la pièce. Trois plateformes ont livré le même verrou en avril 2026, et aucune n'a inclus le pêne dormant.