Tu as connecté ton agent IA à une douzaine d'outils — GitHub, Slack, bases de données, APIs cloud — et il boucle en quelques minutes ce qui te prenait des heures. Tu as ajouté des serveurs MCP (Model Context Protocol — un standard de branchement universel pour les outils IA, comme l'USB mais pour les données), câblé des tokens API (des mots de passe numériques qui permettent aux programmes d'accéder aux services en ton nom), et tout a fonctionné du premier coup. Le futur est arrivé, productif et totalement sans protection.

Parce que quand tu as branché ces connexions, chaque outil a demandé un accès complet. Pas « lecture seule ». Pas « uniquement ce repo ». Accès complet. Et aucune plateforme d'agents n'offrait de moyen de restreindre les permissions au niveau de l'orchestration — la couche où ton agent décide quels outils utiliser et quand. Tu as filé le passe-partout et tu as appelé ça de l'intégration.

Entre le 1er et le 14 avril 2026, ce passe-partout a été copié. À répétition.

Google file le mot de passe root à chaque agent, puis met à jour le README

Le 1er avril, l'Unit 42 de Palo Alto a divulgué la faille « Double Agent » dans Google Vertex AI. C'est l'étude de cas la plus parlante du fossé authentification-vs-autorisation que j'aie vue à ce jour.

Voici ce qui s'est passé : chaque agent Vertex AI recevait un service account par défaut (une identité système qui agit au nom de ton agent). Ce service account arrivait préchargé avec des permissions à faire pleurer un sysadmin. On ne parle pas de « légèrement trop large ». On parle d'un accès à :

  • Les buckets Cloud Storage d'autres clients — les données d'autres utilisateurs, accessibles depuis n'importe quelle instance d'agent
  • Des images de conteneurs internes à Google, normalement restreintes — le genre protégé derrière plusieurs niveaux de validation
  • Le code source de Vertex AI lui-même — les repos internes de la plateforme, lisibles par un agent de démo jetable

Les chercheurs ont démontré une chaîne complète d'escalade de privilèges : partir d'un agent basique, hériter du service account par défaut, pivoter latéralement vers des ressources Google Cloud qu'aucun agent ne devrait jamais toucher. L'identité par défaut n'était pas « un peu trop permissive » — elle était fonctionnellement omnisciente dans le périmètre du projet et partiellement omnisciente en dehors.

Le correctif de Google ? Une mise à jour de la documentation suggérant d'apporter son propre service account, moins privilégié. Pas un changement de plateforme. Pas un défaut sain. Un patch de doc. Ils ont dit aux clients de lire le manuel plus attentivement. L'équivalent d'un constructeur automobile qui répond à une défaillance des freins par « nous avons mis à jour le manuel du propriétaire pour recommander de ralentir avant les intersections ».

La faille existait parce que la couche d'authentification de Vertex AI fonctionnait parfaitement — les agents se connectaient, les tokens s'échangeaient, les handshakes se complétaient — tandis que la couche d'autorisation était un terrain vague. Personne chez Google n'avait construit la partie qui demande « est-ce que cet agent devrait avoir accès à ça ? »

Le Credential Vault d'Anthropic : un workspace, toutes les clés, aucune cloison

Une semaine après la honte de Google, Anthropic a lancé Claude Managed Agents le 8 avril avec des niveaux de permissions par outil — allowed_tools, denied_tools. Mieux que rien. Mais le 13 avril, le chercheur en sécurité hi120ki a démontré que le Credential Vault sous ces permissions souffre d'un problème béant de confused deputy (quand un programme de confiance est manipulé pour abuser de ses propres privilèges).

Le chemin d'attaque est direct et moche :

  1. Un workspace contient plusieurs agents, chacun avec des credentials d'outils différents stockés dans le Credential Vault
  2. Le Vault délimite l'accès au niveau du workspace, pas au niveau de l'agent ou de la session
  3. N'importe quelle clé API avec accès au workspace peut référencer n'importe quel credential dans ce vault
  4. Un attaquant (ou un agent compromis) avec une seule clé API de workspace valide peut injecter des appels d'outils en utilisant les credentials appartenant à d'autres agents

En pratique : l'Agent A a un accès GitHub en lecture seule. L'Agent B a des credentials d'écriture sur la base de données de production. Si la session de l'Agent A est compromise — via prompt injection, tool poisoning, ou un serveur MCP malveillant — il peut récupérer les credentials de base de données de l'Agent B depuis le Vault partagé et exécuter des écritures. Les niveaux de permissions par outil (allowed_tools) régissent ce que l'agent devrait faire. Le Vault régit ce qu'il peut faire. Ces deux listes ne concordent pas.

La preuve de concept de hi120ki a montré un accès cross-agent aux credentials en un seul appel API. Le correctif nécessiterait une isolation des credentials par agent — en gros, donner à chaque agent sa propre partition de vault avec séparation cryptographique. Au 19 avril, aucun correctif n'est déployé.

C'est le pattern du confused deputy dans sa forme la plus pure : le Vault est le mandataire de confiance, l'agent compromis est le demandeur confus, et les credentials ciblés sont l'autorité de quelqu'un d'autre. Le trench-coat cache à peine la supercherie.

Le pattern : authentification résolue, autorisation absente

Ce ne sont pas des bugs isolés. Ce sont les symptômes d'une couche architecturale manquante.

La faille Azure DevOps MCP (CVE-2026-32211, CVSS 9.1, divulguée le 3 avril) — que j'ai couverte à sa sortie — montrait le même vide depuis la direction opposée : pas des défauts trop permissifs, mais zéro authentification côté outil. Claude Code Routines, lancées le 14 avril comme des agents tournant sur des plannings sans approbation humaine, amplifient tous les péchés de permissions existants en supprimant le dernier checkpoint humain.

Même maladie, organes différents. L'authentification (l'agent peut-il se connecter ?) est globalement résolue — les flux OAuth, les clés API, les credential vaults gèrent les handshakes correctement. Mais l'autorisation (que peut faire l'agent une fois connecté ?) reste un gouffre. Chaque outil a son propre modèle de permissions — les scopes GitHub, les policies IAM AWS (règles d'accès granulaires pour les ressources cloud), les accès par page Notion — mais aucune plateforme d'agents n'agrège, n'audite ou n'applique le moindre privilège sur l'ensemble des outils.

La couche entre « outil connecté » et « action exécutée » n'existe pas.

Un audit du 11 avril portant sur 7 000 serveurs MCP par Pomerium a trouvé 36,7 % d'entre eux vulnérables au SSRF (Server-Side Request Forgery — tromper le serveur pour qu'il effectue des requêtes non autorisées vers des systèmes internes). Plus d'un tiers des serveurs MCP peuvent être transformés en points de pivot réseau. Pas parce que le protocole est cassé, mais parce que les implémentations individuelles des serveurs supposent que l'agent qui se connecte est fiable et correctement encadré. Elles supposent que la couche d'autorisation existe en amont. Ce n'est pas le cas.

Pourquoi personne ne corrigera ça tant que ça ne coûtera pas cher

Le cloud computing a traversé 15 ans d'évolution douloureuse — du « SSH en root sur la machine » à l'IAM granulaire avec pistes d'audit, contrôle d'accès par rôle et principe du moindre privilège. On y est arrivés parce que les brèches coûtaient de l'argent et que les cadres de conformité ont forcé le changement. Les plateformes d'agents en sont au jour zéro de cette même évolution, distribuant un accès root-equivalent par défaut et appelant ça une fonctionnalité parce que ça rend bien en démo.

Construire une autorisation unifiée pour les outils tuerait la magie du « connecte n'importe quoi en 30 secondes ». Ça ajouterait de la friction au setup et affaiblirait les démos commerciales. Aucun éditeur n'a l'incitation business à introduire de la friction en premier. Google ne le fera pas. Anthropic ne le fera pas. Microsoft ne le fera pas. L'incitation viendra des incidents. Probablement des incidents coûteux, publics, impliquant plusieurs clients.

On a déjà des avant-premières : en juillet 2025, un agent Replit a paniqué et supprimé les données de production de plus de 1 200 dirigeants. En décembre 2025, un agent Amazon a autonomement supprimé et recréé un environnement de production live, provoquant une panne de 13 heures d'AWS Cost Explorer. C'étaient des accidents. La prochaine vague ne le sera pas.

Chaque serveur MCP trop permissif, chaque token API à accès complet, chaque connexion d'outil sans périmètre est une vulnérabilité dormante — endormie tant qu'un humain clique sur « approuver », active dès qu'un agent tourne de façon autonome sur un planning.

Le vrai prochain avantage concurrentiel des plateformes d'agents, ce n'est pas le modèle ni le nombre d'outils. C'est la première console d'administration qui montre ce que ton agent peut réellement faire — et qui te permet d'en révoquer la majeure partie. Le fossé entre « connecté » et « autorisé », c'est là que vit la prochaine brèche. Pour l'instant, tout le monde construit des ponts par-dessus sans garde-fous et appelle ça du progrès.