Qui appuie sur oui : où les outils d'agents d'IA demandent vraiment avant d'agir

Presque tous les outils d'agents promettent de vous consulter avant de faire quelque chose d'irréversible. La vraie question est de savoir où se trouve cette vérification. Elle peut figurer dans les instructions de l'agent, dans le client qui l'exécute, dans une passerelle entre l'agent et ce qu'il contrôle, ou nulle part. Une seule de ces options peut arrêter un agent qui a décidé de ne pas demander, et même celle-là a une porte dérobée.

Cet article relit les avis publiés cette semaine avec une seule question : qui appuie sur oui. Il ne traite ni des modèles de filtrage ni des filtres contre l'injection d'instructions, que couvre notre guide des garde-fous pour les applications et agents d'IA, ni des bacs à sable pour agents de code, présentés dans notre guide en cinq couches. Tous les faits ci-dessous viennent des avis et des documents de projet qu'ils citent ; nous n'avons pas fait tourner ces outils nous-mêmes.

Quatre endroits où peut se trouver un oui

• Dans le prompt. Une ligne dans un skill ou un prompt système qui demande au modèle de poser la question d'abord. Le modèle la lit comme un conseil.
• Dans le client. Claude Code, Codex, Cursor et les autres affichent une demande d'approbation avant qu'un outil ne s'exécute. Elle tient jusqu'à ce que quelqu'un la désactive, et la plupart des clients le permettent.
• Dans une passerelle. Un programme placé entre l'agent et le téléphone, le compte ou la maison sur lesquels il agit, qui retient l'action jusqu'à ce qu'une personne réponde. C'est le seul type que le modèle ne peut pas contourner par des mots.
• Nulle part. L'outil fait ce qu'on lui dit, et la seule vérification est celle que le client a activée à ce moment-là.

Le prompt : une demande, pas un verrou

Agent Autoloop (3.8) est d'une franchise inhabituelle sur ce point. Il exécute Claude Code ou Codex sans surveillance à partir de tâches cron et de webhooks, et chaque règle peut porter askFirst, une instruction de vous consulter avant les étapes risquées. Les notes de sécurité du projet disent elles-mêmes qu'askFirst n'est qu'une demande écrite dans le prompt : l'agent peut l'ignorer et le hub ne peut pas l'en empêcher. Ce qui limite réellement une exécution, c'est le niveau d'accès, qui correspond aux modes de permission du client, et le niveau full correspond à bypassPermissions dans Claude Code et à danger-full-access dans Codex, c'est-à-dire aucune approbation pour rien.

Google Agent Skills (4.2) montre la même faille sous l'autre angle. Son skill gcloud dit que les changements IAM, l'activation d'API et les suppressions exigent votre approbation explicite, et dans le même fichier demande à l'agent d'ajouter --quiet à chaque commande pour que gcloud ne s'arrête jamais à sa propre demande de confirmation. Le skill cloud-run-basics active des API, attribue un rôle IAM et déploie un service public avec --allow-unauthenticated, chaque fois avec --quiet. La seule confirmation qu'un programme imposait a été retirée, et celle qui reste est une phrase que le modèle suivra ou non.

Le client : la confirmation qu'on peut couper

Pour la plupart des serveurs MCP, la demande d'approbation du client constitue toute la sécurité. X MCP (3.8), le serveur officiel de X, n'a rien côté X qui demande avant qu'un post parte ; sans son interrupteur de lecture seule, la seule vérification est la demande de votre client, que la plupart des clients permettent de désactiver. Un post coûte $0.015 et un post avec lien $0.200 : un agent livré à lui-même dépense de l'argent autant que de la réputation.

Plusieurs outils examinés cette semaine sont à un réglage de voir cette demande disparaître. Le niveau full d'Autoloop en est un. llama-modchip (3.6) peut lancer Claude Code sur son modèle local, et son script n'ajoute --dangerously-skip-permissions que si MODCHIP_CLAUDE_SKIP_PERMS=1 est défini : c'est le bon réglage par défaut, et un réglage facile à changer. La demande du client est un vrai contrôle, mais elle appartient à celui qui modifie la configuration, et une installation sans surveillance se construit généralement en la désactivant.

Une demande du client ne prouve pas non plus qui a répondu. Call Me (3.6) appelle votre téléphone quand un agent s'arrête sur une question et renvoie votre réponse orale sous forme de transcription. Un « oui, déploie » arrive en texte brut sans rien qui prouve que c'était vous, le point d'accès hébergé n'a aucune authentification au-delà de votre numéro à 10 chiffres, et l'avis est clair : une seconde confirmation doit venir des réglages de permission de l'agent lui-même.

La passerelle : celle qui tient

Pinky (3.6) est la passerelle la plus nette que nous ayons étudiée. Chaque appui d'un agent sur votre téléphone passe par elle. Un appui sur Payer ou Envoyer revient à l'agent sous la forme approval_pending, rien ne se passe sur le téléphone tant que vous n'avez pas cliqué sur Allow, et l'absence de réponse en 60 secondes vaut un non. Les applications bancaires et les gestionnaires de mots de passe sont cachés aux agents, et les codes à usage unique leur parviennent sous forme de points. Deux limites comptent. Par défaut, seuls les paiements, les ordres de bourse et les virements vous attendent ; les envois, suppressions, appels et installations doivent être activés dans Settings. Et les boutons risqués sont repérés par leur libellé dans 10 langues, si bien qu'un libellé inhabituel peut passer, d'où un mode qui demande avant chaque étape.

Codex Security (4.1) place la frontière dans un bac à sable plutôt que chez une personne. La validation tourne en lecture seule et sans réseau ; la correction, l'étape qui écrit, vérifie que son bac à sable démarre et refuse avec SANDBOX_UNAVAILABLE sinon. L'option --external-sandbox désactive ce contrôle et laisse l'isolation à votre conteneur, et les workers de Deep scan sont en lecture seule mais, selon OpenAI, ne constituent pas un environnement isolé et hors ligne.

Stroq (3.8) s'installe dans les hooks de l'agent, vous interroge sur les commandes qui reprennent un texte que l'agent vient de lire dans une page, une issue ou un fichier, et refuse curl | sh d'emblée. Son propre README le décrit comme un filtre, pas un bac à sable : la comparaison porte sur le texte, donc une commande que le modèle écrit de zéro ne remonte à aucune source, et sur Codex et Windsurf le hook peut refuser mais pas demander.

Nulle part : les outils qui agissent, tout simplement

HomeMCPBridge (2.8) relie un agent à HomeKit d'Apple. Son outil control_device prend un nom d'appareil et une action, et parmi les actions figurent le déverrouillage d'une serrure et l'ouverture d'une porte de garage. D'après notre lecture du code, il n'y a ni étape de confirmation, ni liste d'autorisation, ni moyen de mettre les serrures en lecture seule. iPhone MCP (3.2) pilote un vrai iPhone via l'application de recopie d'Apple sans étape de confirmation, sans liste d'applications autorisées et sans mode lecture seule ; sa propre mise en garde cite des messages non voulus, des données supprimées et des achats.

La meilleure conception de ce groupe est un outil qui n'existe pas. WhatsApp MCP (finereli) (3.8) n'a pas d'outil d'envoi, à dessein, si bien que la pire défaillance d'un agent de messagerie ne peut pas se produire. Le read_only=true de X MCP fait de même côté serveur : les outils qui publient, envoient des messages ou modifient quoi que ce soit sont retirés de la liste, et le serveur refuse ces appels même si le jeton a des droits d'écriture. Un outil absent n'a besoin de personne pour appuyer sur quoi que ce soit.

Toute passerelle a une porte dérobée

Une passerelle ne tient que si elle est la seule entrée. La FAQ de Pinky le dit sans détour : un agent capable d'exécuter des commandes en votre nom peut atteindre un téléphone Android par adb et contourner toutes les règles. Elle conseille d'isoler ces agents dans un bac à sable sans accès au téléphone, ou de brancher le téléphone sur un autre ordinateur et de s'y connecter à Pinky en HTTP. Cela décrit Claude Code et Codex dans leur configuration habituelle : pour la plupart des lecteurs, la passerelle ne protège le téléphone qu'après cette étape supplémentaire.

La même logique joue dans l'autre sens. Un proxy sur le chemin voit tout ce qui passe. billion-context (3.4) se place entre un agent de code et l'API de son modèle pour replier l'ancien contexte, ce qui signifie que chaque prompt et chaque clé d'API passent par lui, sans authentification, et par défaut il interroge npm toutes les 3 minutes pour trouver une nouvelle version de lui-même. Avant de confier à une passerelle le soin de retenir des actions, demandez-vous ce qu'elle peut lire et qui peut modifier son code.

Où se trouve le oui, outil par outil

Outil	Ce qu'il peut faire d'irréversible	Où se trouve la confirmation	Comment la renforcer
Pinky	Payer, envoyer, supprimer sur votre téléphone	Passerelle ; paiements seulement par défaut	Activer envois et suppressions ; tenir les agents avec shell loin d'adb
Agent Autoloop	Tout ce que peut faire la CLI de l'agent	Mode de permission du client ; askFirst est un prompt	Rester sur edit ; ne donner full que là où l'autonomie est acceptable
Codex Security	Écrit des correctifs	Bac à sable, sauf avec --external-sandbox	Garder le bac à sable intégré ; lire chaque correctif
Google Agent Skills	Déployer, attribuer des rôles IAM, activer des API	Le prompt seulement ; --quiet supprime celle de gcloud	Rôles de projet limités, budget de facturation, approbations du client activées
X MCP	Publier des posts et des Articles	Le client seulement, ou read_only=true	Commencer en lecture seule ; fixer un plafond de dépenses
HomeMCPBridge	Ouvrir serrures et portes de garage	Nulle part	Le tenir à l'écart des agents qui tournent seuls
Call Me	Transmet vos approbations orales	Réglages de permission de l'agent	Traiter un oui vocal comme non vérifié
Stroq	Interroge sur des commandes ou les refuse	Hooks de l'agent, comparaison de texte	L'associer à un conteneur ou un compte séparé

Des règles à appliquer cette semaine

1. Trouvez le oui de chaque action irréversible. Pour chaque paiement, envoi, suppression, déploiement ou action physique, notez quel programme la retient. Si la réponse est « le prompt dit de demander », comptez-le comme aucune confirmation.
2. Préférez un outil absent à un outil confirmé. Un interrupteur de lecture seule ou un serveur sans outils d'écriture vaut mieux que n'importe quel prompt. Lancez X MCP avec read_only=true, et choisissez des serveurs sans envoi ni suppression quand la tâche consiste à lire.
3. Activez ce que la passerelle laisse éteint. Les réglages par défaut sont étroits. Pinky ne demande qu'avant les paiements tant que vous n'ajoutez pas envois, suppressions, appels et installations.
4. Fermez la porte dérobée avant de faire confiance à la porte d'entrée. Un agent doté d'un shell atteint tout ce qu'atteint votre compte utilisateur, adb compris. Faites-le tourner dans un bac à sable ou sous un autre utilisateur qui ne voit ni l'appareil ni les identifiants que garde la passerelle.
5. Cherchez les interrupteurs dans vos configurations. bypassPermissions, danger-full-access, --dangerously-skip-permissions, --quiet et --external-sandbox suppriment chacun une confirmation. Sachez où chacun est défini, et pourquoi.
6. Doublez le prompt de limites qu'un modèle ne peut pas discuter. Des rôles cloud étroits, un budget de facturation et un plafond de dépenses sur les API payantes continuent de jouer quand l'agent saute une étape.
7. Traitez un oui à distance comme non vérifié. Un appel ou une réponse dans un chat ne prouve pas qui a répondu. Gardez déploiements et paiements derrière une approbation liée à votre propre connexion.

Le hic : les passerelles qui tiennent le mieux sont les plus jeunes. Pinky a une semaine, Autoloop dix jours, Stroq une dizaine de semaines, et leurs notes de sécurité viennent des mainteneurs, pas d'un examen externe. Les contrôles éprouvés, demandes d'approbation du client et permissions cloud, sont justement ceux qu'on désactive pour faire tourner un agent sans surveillance. Aucun outil de cette liste ne rend sûr le fait de laisser un agent seul avec votre argent ou votre porte d'entrée.

Notre avis : posez à chaque configuration d'agent la question que vous poseriez à un nouvel employé muni d'une carte d'entreprise : qui valide, et peut-il valider sans vous ? Si la réponse honnête est l'employé lui-même, il n'y a pas de validation. Placez le oui dans un programme que l'agent ne peut pas modifier, retirez les outils dont la tâche n'a pas besoin, et gardez votre attention pour les quelques clics qui comptent.