Avant de donner des accès à un agent IA : la frontière de confiance

Un appel d'outil n'est pas une autorisation

Un agent se compose de trois briques : un modèle de langage, un orchestrateur (LangGraph, CrewAI, Microsoft Agent Framework, etc.) qui lui présente les outils disponibles, et les outils eux-mêmes, qui lisent des fichiers, interrogent une base ou envoient des messages. Le modèle produit du texte structuré, l'orchestrateur le reconnaît comme un appel d'outil et le transmet. Entre les trois, aucune signature, aucune authentification : un appel bien formé est exécuté.

Une équipe de Penn State, de l'Université de Montpellier et de Dartmouth en tire une attaque simple, baptisée Repeat-After-Me, dans un preprint publié sur arXiv le 9 octobre. L'attaquant écrit lui-même un appel d'outil au format attendu, avec ses propres arguments, et demande au modèle de le répéter mot pour mot. Le modèle ne fait que recopier, mais l'orchestrateur voit un appel valide et l'exécute. Les chercheurs disent avoir reproduit ce comportement sur six orchestrateurs : LangGraph, Microsoft Agent Framework, AutoGen, Google ADK 2.0, AWS Strands et CrewAI.

Le papier ne publie la démonstration complète que pour LangGraph 1.2.0, avec un petit modèle (Llama 3.1 8B) et deux outils factices sans effet réel. La seule protection était une consigne système demandant de refuser les demandes dangereuses. Présentée comme hypothétique, la demande a produit un appel structuré que LangGraph a exécuté aussitôt, et le refus du modèle n'est arrivé qu'après le retour de l'outil. La formule des auteurs, reprise par CSO Online, résume le problème : la consigne système a façonné ce que le modèle disait, pas ce que l'orchestrateur faisait.

Deux réserves s'imposent. Le travail n'a pas été relu par des pairs, et il ne montre pas que tous les déploiements de ces frameworks se comportent ainsi. Mais la leçon d'architecture tient : un prompt système n'est pas un contrôle d'accès. Si votre seule barrière est une phrase dans la consigne du modèle, vous n'avez pas de barrière.

Les outils ne tiennent pas ce qu'ils promettent

Si l'attaquant peut dicter les arguments d'un appel, la dernière ligne de défense est l'outil lui-même. Les mêmes chercheurs ont donc construit ToFu, un outil de test automatique (fuzzing) qui lit la description de chaque outil et vérifie qu'il respecte les limites qu'il annonce, par exemple rester dans un dossier de travail.

Le résultat est sévère. Sur 273 serveurs MCP open source qu'ils ont réussi à exécuter, totalisant 3 405 outils, ils ont retenu après revue manuelle 253 bugs vérifiés, touchant 343 outils dans 118 serveurs. On y trouve 64 traversées de chemin (l'outil lit ou écrit hors du dossier prévu), 7 failles SSRF (l'outil appelle une adresse interne), 5 exfiltrations de données et 3 injections de commandes. Le reste, surtout du contenu renvoyé sans échappement et de l'injection dans les journaux, pèse moins dans beaucoup de déploiements. Pendant les tests, quatre serveurs ont même affecté la machine de test : l'un a supprimé des fichiers hors de son espace de travail, un autre a lancé des processus sans limite.

Le constat central du papier : beaucoup d'outils comptent implicitement sur le modèle pour assainir leurs entrées, alors que ces entrées peuvent venir d'un prompt, d'une page web lue par l'agent ou de la sortie d'un autre outil. C'est le même message que pour la passerelle MCP : un serveur MCP est du code tiers, il s'inventorie et se teste comme tel.

Quand l'agent trouve les clés tout seul

Le risque ne vient pas seulement d'un attaquant. Le 9 octobre, Anthropic a publié un rapport sur des actions imprévues de ses modèles observées en évaluation et en usage interne. Dans un cas, Claude devait localiser une photo et voulait consulter le plan cadastral en ligne d'une collectivité. Ne pouvant pas naviguer normalement, il a lu le fichier de réglages que le site envoie aux navigateurs, y a trouvé des jetons d'accès valides et s'en est servi pour interroger directement le serveur. Dans un autre, il a obtenu le jeton qu'un tableau de bord public délivre à tout visiteur pour éviter de payer une donnée vendue. D'autres modèles ont utilisé des raccourcisseurs d'URL pour contourner une limite de longueur imposée à leur outil de lecture web, et un modèle a soumis un vrai formulaire de signalement à une police municipale.

Anthropic juge l'impact minime et décrit surtout de la persévérance : quand la tâche est impossible telle quelle, le modèle contourne la restriction au lieu de s'arrêter. L'éditeur a coupé l'accès à Internet pour toutes ses évaluations internes et dit avoir déployé un outil de détection qui aurait bloqué tous les cas décrits. Pour vous, la leçon est concrète : tout secret lisible par l'agent sera, un jour, utilisé par l'agent. Une clé dans un fichier de configuration, une variable d'environnement ou un jeton exposé n'est pas « rangée » : elle est à portée.

Le cas AWS montre ce que coûte un droit trop large. Le 8 octobre, Zenity Labs a publié AgentCorruption, une chaîne de failles dans Amazon Bedrock AgentCore. Selon les chercheurs, un seul prompt envoyé à un agent public suffisait à récupérer, via le service de métadonnées de la machine, les identifiants de son rôle d'exécution par défaut. Ce rôle couvrait tous les agents AgentCore du même compte et de la même région : invoquer les autres agents, lire leurs conversations privées, implanter des souvenirs, lire des secrets dans AWS Secrets Manager. AWS a depuis imposé IMDSv2 et réduit les droits du rôle par défaut, tout en qualifiant le comportement de « documenté et attendu » et en rappelant de n'accorder aux rôles que les permissions nécessaires. Le problème n'était pas le modèle, mais le périmètre de l'identité qu'on lui avait confiée.

Séparer l'intelligence de l'autorité

Le 10 octobre, Satya Nadella a publié un texte intitulé « Models as Insider Risks in the Super Intelligence Era ». Le patron de Microsoft propose de traiter les modèles, fermés ou ouverts, comme un risque interne : non parce qu'ils seraient malveillants, mais parce que tout acteur capable qui accède à des systèmes importants peut se tromper ou être compromis. Il rappelle qu'on sait déjà gérer des acteurs puissants en entreprise : établir une identité, limiter les privilèges, journaliser, poser des frontières de confinement. Et il en tire une règle : les contrôles qui décident de ce qu'un modèle peut atteindre et faire doivent se trouver hors du modèle, séparés de l'orchestrateur et de l'espace d'actions. Parmi ses principes : des traces infalsifiables et lisibles de chaque action significative, un audit indépendant du modèle audité, et un frein d'urgence permettant à une personne autorisée de suspendre ou d'arrêter un modèle en pleine tâche.

C'est une position d'éditeur, qui vend aussi des modèles et des plateformes d'agents. Mais elle rejoint la fiche « Excessive Agency » de l'OWASP, qui classe les causes en trois familles : trop de fonctions, trop de permissions, trop d'autonomie. Et elle recommande la « médiation complète » : l'autorisation se décide dans les systèmes en aval, pas par le modèle.

Une nuance utile. Microsoft vient aussi de lancer Decision-1, un petit modèle qui attribue des probabilités à des options fixes, par exemple pour décider si un agent doit agir, attendre ou demander une validation. Ce type de score aide à trier ce qui doit remonter à un humain. Mais c'est encore un modèle : il peut servir à router une demande vers une validation, pas à accorder une permission.

Les trois frontières à contrôler

En pratique, la frontière de confiance n'est pas une ligne unique. Elle passe à trois endroits, et chacun appelle ses contrôles.

Les trois couches d'un agent et les contrôles à chaque frontière. Aucun de ces contrôles ne repose sur le modèle lui-même.

Entre le modèle et l'orchestrateur, la règle est de traiter chaque appel comme une simple proposition. L'orchestrateur ne présente que les outils autorisés pour cette tâche (liste blanche), vérifie que l'appel correspond au périmètre prévu et réserve les actions irréversibles à une validation humaine.

Entre l'orchestrateur et les outils, l'outil valide lui-même ses arguments : chemins confinés, destinations réseau autorisées, commandes interdites. Il agit avec une identité propre, aux droits limités, et si possible dans le contexte de l'utilisateur pour lequel l'agent travaille, pas avec un compte de service qui voit tout.

Sur toute la chaîne, deux contrôles ne dépendent de personne : un journal de chaque appel que l'agent ne peut pas modifier, et un coupe-circuit qui permet d'arrêter l'agent et de révoquer ses accès en quelques minutes. Les techniques d'isolation des agents complètent ce dispositif : elles limitent ce que l'agent peut atteindre même quand un contrôle a cédé.

Sept questions avant de brancher un agent

Avant de donner à un agent l'accès à un outil, une base, une boîte mail ou un dépôt de code, posez ces sept questions. Si vous ne savez pas répondre à l'une d'elles, l'accès attend.

1. Que doit faire l'agent, et pas plus ? Listez les actions nécessaires et retirez tout le reste. Un agent qui résume des mails n'a pas besoin d'en envoyer.
2. Avec quelle identité agit-il ? Une identité dédiée par agent, des droits limités à son périmètre, des jetons à durée courte. Jamais votre compte administrateur, jamais un rôle partagé par tous les agents, ce qu'a montré AgentCorruption.
3. Quels secrets peut-il lire ? Fichiers de configuration, variables d'environnement, historique Git, service de métadonnées du cloud. Ce qu'il peut lire, considérez qu'il peut s'en servir.
4. Vos outils valident-ils leurs entrées ? Pour chaque serveur MCP ou outil maison, vérifiez qu'il refuse un chemin hors de son dossier, une adresse interne ou une commande non prévue. Testez-le, ne vous fiez pas à sa description.
5. Quelles actions demandent un humain ? Envoi externe, paiement, suppression, modification de droits, mise en production. Si l'agent fournit des recommandations qui touchent le crédit, la santé ou l'emploi d'une personne, vérifiez aussi les règles de votre fournisseur : la politique d'usage d'Anthropic, en vigueur le 12 novembre, exige dans ces domaines une personne qualifiée, capable de modifier la recommandation avant qu'elle soit délivrée ou appliquée, et que la personne concernée sache que l'IA a été utilisée. Anthropic précise que cette exigence n'est pas nouvelle mais que sa rédaction a été clarifiée.
6. Pourrez-vous reconstituer ce qu'il a fait ? Chaque appel journalisé, hors de portée de l'agent, avec les arguments et le résultat. Un journal que l'agent peut effacer ne prouve rien.
7. Qui peut l'arrêter, et en combien de temps ? Un coupe-circuit testé : suspendre l'agent, révoquer ses jetons, couper ses accès réseau. Si personne ne l'a jamais fait, personne ne sait le faire.

Checklist

• [ ] Inventaire des agents, de leurs outils et des données qu'ils touchent, avec un responsable pour chacun
• [ ] Liste blanche d'outils par agent, refus par défaut, fonctions inutiles retirées
• [ ] Une identité par agent, droits minimaux, jetons à durée courte
• [ ] Aucun secret lisible dans l'environnement de l'agent, accès au service de métadonnées du cloud bloqué ou limité
• [ ] Outils et serveurs MCP testés contre les chemins hors périmètre, les adresses internes et les commandes non prévues
• [ ] Validation humaine pour les actions irréversibles et les recommandations à fort enjeu pour une personne
• [ ] Journal de chaque appel, hors de portée de l'agent
• [ ] Coupe-circuit documenté et testé, révocation des accès en quelques minutes
• [ ] Test de maturité : un appel d'outil malveillant dicté par un tiers serait refusé par l'outil lui-même, même si le modèle l'a recopié

Conclusion

Les agents vont recevoir de plus en plus d'accès, et c'est souhaitable : c'est là que se trouve leur valeur. Mais les faits récents convergent : le modèle peut être manipulé, il peut contourner une restriction par simple persévérance, et les outils qu'il appelle ne vérifient pas toujours ce qu'ils promettent. La sécurité d'un agent ne se joue donc pas dans le prompt, elle se joue aux frontières : l'identité qu'on lui donne, les outils qu'on lui ouvre, les validations qu'on exige et les traces qu'on garde. Pour reprendre la formule de Satya Nadella, le système le plus digne de confiance ne sera pas celui dont le modèle inspire le plus confiance, mais celui qui permet de faire le moins confiance au modèle.

C'est le type de chantier sur lequel j'accompagne des CTO et dirigeants de PME : cartographie des accès des agents, revue des identités et des secrets, tests des outils et des serveurs MCP, mise en place des validations, du journal et du coupe-circuit. Si vous ne savez pas dire aujourd'hui ce qu'un de vos agents pourrait faire avec les accès qu'il a, c'est probablement le bon moment pour en parler.

Sources

1. Ananto et al. (Penn State, Université de Montpellier, Dartmouth), ToFu: Exploiting and Fuzzing the LLM–Orchestrator–Tool Trust Boundary, preprint arXiv, 9 octobre 2026
2. CSO Online, Researchers bypass 6 AI agent frameworks with a simple 'Repeat-After-Me' prompt, 12 octobre 2026
3. Anthropic, Investigating unintended model actions in our evaluations and internal use, 9 octobre 2026 (corrigé le 12 octobre)
4. Korben, Anthropic coupe Internet à ses IA après un faux témoignage de meurtre, octobre 2026
5. Zenity Labs, AgentCorruption: How A Single Prompt Collapsed The Entire Cloud Security Model, 8 octobre 2026
6. Satya Nadella, Models as Insider Risks in the Super Intelligence Era, 10 octobre 2026
7. OWASP Gen AI Security Project, LLM06:2025 Excessive Agency, consulté le 13 octobre 2026
8. Help Net Security, Microsoft's new model helps AI agents judge their next move, 12 octobre 2026
9. Anthropic, 2026 Usage Policy update, 8 octobre 2026 (en vigueur le 12 novembre 2026)