La pile logicielle agentique est le nouveau paradigme de l'audit en boîte blanche

La pile logicielle agentique est le nouveau paradigme

La fuite de Claude Code d'Anthropic est importante pour une raison avant toutes les autres : l'incident n'a pas exposé les poids des modèles et n'a pas été présenté par Anthropic comme une violation des données des clients. Les rapports publics ont indiqué qu'une carte de source livrée dans la CLI npm-distribuée exposait la source TypeScript reconstructible pour Claude Code, tandis qu'Anthropic a déclaré qu'il s'agissait d'un problème d'emballage de version causé par une erreur humaine et qu'aucune donnée sensible de client ou d'identifiant n'a été exposée. Cette distinction modifie la conversation technique. Elle déplace le centre de gravité du "modèle" vers le système beaucoup plus vaste qui l'entoure. (The Verge)

C'est ce système plus large qui nous intéresse aujourd'hui. La documentation de Claude Code le décrit comme un outil de codage agentique qui lit une base de code, édite des fichiers, exécute des commandes et s'intègre à des outils de développement. Le SDK Agent d'Anthropic va plus loin et indique que les développeurs peuvent utiliser les mêmes outils, la même boucle d'agent et la même gestion de contexte que Claude Code de manière programmatique à partir de Python et TypeScript. Une fois qu'un système peut lire l'état, modifier l'état, appeler des outils, conserver la mémoire, déléguer à des sous-agents et se connecter à des services externes, la frontière de sécurité n'est plus la frontière du modèle. Il s'agit d'une frontière d'exécution composée de code, de configuration, de mémoire, d'autorisation, d'orchestration et d'observabilité. (anthropic.com)

C'est pourquoi l'expression "audit de la boîte blanche" doit être redéfinie. Dans les anciens travaux sur la sécurité des logiciels, l'audit de la boîte blanche signifiait l'examen des sources, l'analyse du flux de données, l'inspection de la chaîne de construction et le raisonnement sur les limites de la confiance depuis l'intérieur de l'application. Dans la recherche sur l'alignement, le terme pointe souvent dans une direction différente : l'accès aux poids, aux activations ou aux outils d'interprétabilité. Les deux utilisations restent valables. Aucune n'est suffisante en soi pour les systèmes d'agents modernes. La leçon à tirer de l'après-fuite est qu'un audit sérieux de la boîte blanche d'un agent d'IA doit tenir compte de l'ensemble du logiciel agentique, des artefacts de publication et de la provenance aux crochets, aux fichiers de mémoire, aux autorisations MCP, à l'héritage des sous-agents, aux traces d'exécution et à la relecture post-incident. (arXiv)

Le code Claude a fait l'objet d'une fuite plus importante que la source

Les cartes de source sont banales jusqu'à ce qu'elles ne le soient plus. MDN définit une carte de source comme un format JSON qui renvoie le code transformé à la source originale non modifiée, ce qui permet de reconstruire le code original et de l'utiliser pour le débogage. Dans le cadre d'un travail d'ingénierie normal, c'est utile. Dans le cas d'une erreur d'emballage, cela devient une surface d'exposition à l'information. Le 31 mars, un rapport public a indiqué qu'une version de Claude Code était livrée avec un fichier de cartographie des sources qui permettait à des personnes extérieures de récupérer de grandes parties de la base de code TypeScript, et la déclaration publique d'Anthropic a souligné que le problème était lié à l'emballage plutôt qu'à une intrusion conventionnelle. (developer.mozilla.org)

C'est important parce que la fuite a rendu visible ce que de nombreuses équipes essaient encore de comprimer dans le mot "modèle". La surface exposée n'était pas une simple invite ou une enveloppe d'API étroite. Les rapports publics et les discussions de rétro-ingénierie décrivent des commandes de type "slash", des outils intégrés, des instructions internes et des comportements liés à la mémoire. Même sans prendre au pied de la lettre toutes les affirmations de la communauté, l'image générale est suffisamment claire : un agent de codage n'est pas un chatbot auquel est attachée une commande shell. Il s'agit d'un moteur d'exécution doté d'un contexte persistant, d'une médiation des autorisations, de schémas d'outils, de fichiers et d'une logique de flux de travail. (The Verge)

La documentation officielle le dit déjà. Claude Code est décrit comme pouvant lire du code, éditer des fichiers, exécuter des commandes et s'intégrer à des outils de développement. Le SDK de l'agent indique que la même boucle peut être intégrée dans des applications de production. La documentation sur la mémoire indique que CLAUDE.md et la mémoire automatique sont tous deux chargés au début de chaque conversation et traités comme un contexte plutôt que comme une configuration imposée. En d'autres termes, une partie importante du comportement du système n'est pas stockée uniquement dans le code ou uniquement dans les poids des modèles. Elle est répartie sur plusieurs couches avec état. (anthropic.com)

Cette répartition est précisément la raison pour laquelle l'audit de la boîte blanche doit se développer. Si une future équipe de sécurité déclare avoir "audité l'agent" parce qu'elle a inspecté une invite du système ou lancé quelques sondes d'interprétabilité, cette équipe a probablement audité la partie du système la moins prédictive sur le plan opérationnel. Les faits les plus lourds à porter résident désormais dans des questions comme celles-ci : quels fichiers ont été expédiés, quels champs de configuration étaient actifs, quelle mémoire a été chargée, quels crochets ont modifié les entrées ou les sorties, quels serveurs MCP étaient accessibles, quelles autorisations ont été héritées par les sous-agents d'arrière-plan, et quelles preuves d'exécution ont été préservées pour une reconstruction ultérieure. (Docs de l'API Claude)

L'audit "boîte blanche" signifiait autrefois quelque chose de plus simple

L'audit traditionnel des logiciels en boîte blanche part d'une intuition stable. Il existe un code source. Le code définit la limite de confiance. Les entrées se font à des points connus. La logique d'autorisation est représentée dans des fonctions, des classes ou des fichiers de politique. Les réviseurs raisonnent sur la propagation de l'altération, l'expansion des modèles, les limites du bac à sable, l'invocation du shell, la gestion des secrets et l'intégrité des dépendances. Même lorsque les systèmes sont de grande taille, il existe toujours une séparation relativement claire entre le code, la configuration, les artefacts de déploiement et le comportement en cours d'exécution.

Les systèmes d'agents abolissent ces séparations. Un agent moderne peut contenir des règles rédigées par l'utilisateur dans CLAUDE.md, des notes rédigées par le modèle dans la mémoire automatique, une politique gérée rédigée par l'organisation, des règles rédigées par le référentiel, etc. .mcp.jsonIl peut s'agir d'un contexte injecté par une invite à partir d'un fichier, d'une sortie d'outil à partir d'un service externe ou d'un travail en arrière-plan délégué à un sous-agent qui hérite d'un sous-ensemble de permissions. Le chemin d'action qui en résulte n'est pas déterminé par le code seul. Il est déterminé par le code plus l'état accumulé plus la politique plus le comportement de l'outil externe. Un audit en boîte blanche qui ne peut pas reconstruire ces couches n'est plus en boîte blanche dans le sens pratique qui importe aux défenseurs. (Docs de l'API Claude)

L'ancienne image supposait également que l'examen du code était la principale voie vers une inférence fiable. Mais la littérature récente sur la sécurité de l'IA montre déjà pourquoi cette hypothèse s'effondre. Le travail d'Anthropic de mars 2025 sur les objectifs cachés a présenté les audits d'alignement comme des investigations systématiques visant à déterminer si les modèles poursuivent des objectifs cachés, et il a explicitement combiné l'analyse des données d'entraînement, les techniques comportementales et les méthodes de boîte blanche telles que les autoencodeurs épars. Ce document n'affirme pas que la visibilité interne est inutile. Il affirmait qu'une enquête plus approfondie était nécessaire, précisément parce que le comportement apparent seul peut être trompeur. (anthropic.com)

En mars 2026, les résultats de l'AuditBench d'Anthropic ont apporté une nuance importante. Leur rapport de benchmarking indique que les outils de boîte noire avec échafaudage sont les plus efficaces pour auditer les comportements cachés, tandis que les outils d'interprétabilité de boîte blanche peuvent aider, mais principalement sur des cibles plus faciles. Cette conclusion doit être lue attentivement. Il ne s'agit pas d'une rétrogradation du travail en boîte blanche. Elle signifie que le centre de gravité de l'audit réel se déplace vers les flux de travail des enquêteurs au niveau du système et de l'utilisation des outils, plutôt que vers une seule lentille privilégiée pour les poids ou les activations. (alignement.anthropic.com)

Les rapports publics d'Anthropic sur les risques vont dans le même sens. Dans le rapport sur les risques de février 2026, la société a déclaré qu'elle n'avait pas encore une compréhension suffisante des états internes du modèle pour procéder à une évaluation définitive en étudiant le modèle de manière isolée, et elle a décrit l'utilisation de sources de preuves convergentes à la place. Le même rapport indique également que de nombreuses transcriptions d'audits comportementaux automatisés intègrent l'invite et l'ensemble d'outils du système Claude Code tel qu'il est utilisé en interne. Il s'agit là d'un signal architectural clé. L'évaluation des frontières passe déjà de "tester le modèle dans le vide" à "tester la pile déployée dans des conditions réalistes". (anthropic.com)

La pile de logiciels agentiques a une surface d'audit plus large

Les documents de Claude Code sont particulièrement utiles car ils exposent, en termes concrets d'ingénierie, à quoi ressemble la nouvelle surface d'audit. Les documents sur la mémoire indiquent que chaque session commence avec une nouvelle fenêtre de contexte, mais que les connaissances sont transmises d'une session à l'autre par le biais de fichiers CLAUDE.md créés par l'utilisateur et d'une mémoire automatique créée par le modèle. Les deux sont chargés dans chaque conversation, et Anthropic dit explicitement que Claude les traite comme un contexte, et non comme une configuration imposée. La mémoire automatique est activée par défaut, stockée dans des fichiers markdown locaux à la machine, et vérifiable parce que ces fichiers peuvent être lus, édités ou supprimés directement. Cela signifie que la mémoire n'est pas un comportement émergent mystique. Il s'agit d'un plan d'entrée avec un état et une représentation sauvegardée dans un fichier. (Docs de l'API Claude)

Le système de crochets rend le plan d'exécution encore plus explicite. Listes de références d'Anthropic UserPromptSubmit, PreToolUse, Demande d'autorisation, PostToolUse, Échec de l'utilisation de l'outil, SubagentStart (Démarrage de l'agent secondaire), SubagentStop, Tâche créée, TaskCompletedet d'autres événements du cycle de vie. UserPromptSubmit peut ajouter un contexte ou bloquer une invite avant le traitement. PreToolUse peut autoriser, refuser ou demander avant l'exécution d'un outil, et peut modifier l'entrée de l'outil. Demande d'autorisation peuvent automatiquement autoriser ou refuser au nom de l'utilisateur et même réécrire l'entrée de l'outil qui sera exécutée. Pour les outils MCP, les crochets post-outil peuvent remplacer la sortie de l'outil par le biais de updatedMCPToolOutput. Il ne s'agit pas de petits détails. Ils signifient que la durée d'exécution contient déjà des points d'interception de premier ordre qui peuvent modifier la causalité. (Claude)

Les mêmes documents montrent comment l'utilisation des outils et l'utilisation du MCP se confondent. Anthropic dit que les outils du serveur MCP apparaissent comme des outils normaux dans les événements de crochet tels que PreToolUse, PostToolUse, Échec de l'utilisation de l'outilet Demande d'autorisation. MCP fait donc partie de la même surface de décision que les outils intégrés. Si un audit en boîte blanche ignore MCP parce qu'il vit "en dehors" de l'application, il manque l'une des transitions de confiance les plus importantes du système. MCP est le protocole qui relie les applications de l'agent aux sources de données, aux outils et aux flux de travail. Une fois que ce pont existe, les systèmes externes ne sont plus périphériques. Ils font partie du tissu d'exécution (Claude)

Les sous-agents étendent à nouveau la surface. La documentation sur les sous-agents d'Anthropic indique que les sous-agents basés sur des fichiers peuvent transporter leurs propres fichiers. mcpServers, crochets, mémoire, arrière-planet les paramètres liés à l'isolement. Un sous-agent peut se voir attribuer des serveurs MCP qui ne sont pas disponibles dans la conversation principale. Il peut conserver une mémoire persistante au niveau de l'utilisateur, du projet ou de la portée locale. Les sous-agents d'arrière-plan s'exécutent simultanément, reçoivent des autorisations en amont, héritent de ces autorisations en cours d'exécution et refusent automatiquement tout ce qui n'a pas été approuvé au préalable. Cette combinaison signifie qu'un véritable audit doit raisonner sur l'exécution déléguée et l'autorité héritée, et pas seulement sur une transcription linéaire de la conversation. (Docs de l'API Claude)

L'étendue de la configuration est tout aussi importante. Les documents de configuration d'Anthropic distinguent les champs d'application gérés, utilisateur, projet et local, et ils positionnent explicitement le champ d'application géré pour les politiques de sécurité à l'échelle de l'organisation et les exigences de conformité qui ne peuvent pas être remplacées. Le guide de déploiement de l'entreprise indique qu'une équipe centrale doit configurer les serveurs MCP et vérifier un .mcp.json dans la base de code pour une utilisation partagée. C'est le signal le plus clair que la gouvernance des agents devient un problème de configuration de l'entreprise autant qu'un problème de modèle. L'audit de la boîte blanche doit suivre cette évolution. Il doit tenir compte de la personne qui contrôle la politique, de l'endroit où la politique est stockée, de la façon dont elle est héritée et de la façon dont elle change entre les machines, les référentiels et les utilisateurs. (Docs de l'API Claude)

Les postes d'ingénierie de sécurité d'Anthropic ajoutent une autre pièce manquante : le confinement de l'exécution. La société affirme que Claude Code fonctionne sur un modèle basé sur les permissions et que le sandboxing ajoute une isolation du système de fichiers et du réseau. Anthropic affirme également que le sandboxing a permis de réduire de 84% les demandes d'autorisation en interne, tandis qu'un message ultérieur sur le mode automatique indique que les utilisateurs de Claude Code approuvent 93% des demandes d'autorisation et que des classificateurs ont été introduits pour réduire la fatigue liée à l'approbation. Ces deux chiffres sont importants pour les auditeurs car ils expliquent pourquoi les "invites de permission" ne sont pas suffisantes en tant que contrôle de sécurité. Si les humains approuvent presque tout, le point de contrôle significatif n'est pas la boîte de dialogue. C'est l'architecture qui entoure cette boîte de dialogue : les limites du bac à sable, les crochets de politique, les listes d'autorisation du domaine et la logique de décision traçable. (anthropic.com)

Une façon compacte d'envisager la nouvelle surface consiste à cesser de se demander où se trouve le modèle et à commencer à se demander où l'autorité change de mains. L'autorité se déplace lorsque le code est construit, lorsqu'un paquet est publié, lorsqu'un fichier mémoire est chargé, lorsqu'une portée de politique en remplace une autre, lorsqu'un serveur MCP reçoit un jeton, lorsqu'un sous-agent hérite de permissions, lorsqu'un crochet réécrit l'entrée d'un outil, et lorsque le système décide qu'une invite, une sortie d'outil ou une mémoire antérieure est suffisamment digne de confiance pour agir. C'est dans ces articulations que l'audit futur de la boîte blanche doit se dérouler. (modelcontextprotocol.io)

Audit "boîte blanche" hérité du passé	Audit de la pile logicielle agentique
Le code source est le principal artefact de comportement	Le comportement émerge du code, des invites, de la mémoire, des politiques, des crochets, des sorties d'outils et de la délégation.
L'autorisation se situe principalement dans la logique de l'application	L'autorisation est répartie entre les modes de permission, les crochets, l'authentification MCP, les règles du bac à sable et les champs d'application de la configuration.
Le pipeline de construction prouve l'origine du logiciel	Le pipeline de construction doit également prouver les paquets d'invites, les paquets de politiques, les manifestes d'outils et les artefacts expédiés.
Les journaux d'exécution sont généralement suffisants pour répondre aux incidents.	Les journaux d'exécution doivent inclure les appels d'outils, les lectures et écritures de mémoire, les décisions de crochet, le lignage des sous-agents et les sorties.
La validation post-fixe se concentre sur les itinéraires corrigés	La validation post-fixe doit également tester la contamination de la mémoire, l'utilisation abusive d'outils, les régressions de politiques et les chemins d'accès délégués.

Le tableau ci-dessus synthétise les documents et les notes techniques du code Claude d'Anthropic avec la spécification d'autorisation MCP, les conventions GenAI d'OpenTelemetry et les normes de la chaîne d'approvisionnement logicielle telles que SLSA et in-toto. Ensemble, ces sources montrent que la sécurité des agents est passée d'un examen étroit de la logique de l'application à une gouvernance de bout en bout de la provenance et de l'exécution du système. (Docs de l'API Claude)

La provenance de la construction et de la mise en production fait désormais partie de la sécurité "boîte blanche".

La leçon la plus directe à tirer de l'incident Claude Code est que la provenance de la construction et de la publication ne peut plus être considérée comme secondaire. SLSA décrit la provenance comme une information vérifiable sur les artefacts logiciels qui indique où, quand et comment ils ont été produits. In-toto va plus loin et décrit la chaîne d'approvisionnement comme une série d'étapes dont l'intégrité et l'ordre peuvent être attestés, rendant transparent ce qui s'est passé, par qui et dans quel ordre. Ces idées étaient déjà importantes pour les logiciels ordinaires. Les systèmes agentiques les rendent plus importantes parce que l'artefact ne contient plus seulement du code, mais aussi une politique, un câblage d'outil et des possibilités d'exécution. (SLSA)

La porte dérobée xz reste l'avertissement historique le plus clair. L'entrée de la NVD pour CVE-2024-3094 indique qu'un code malveillant a été découvert dans des fichiers tarballs en amont et que le processus de construction a extrait un fichier objet préconstruit à partir d'un fichier de test déguisé pour modifier des fonctions spécifiques pendant la construction. Cet incident a montré, avec des détails douloureux, que ce qui est construit et livré peut diverger sensiblement de ce que les réviseurs pensent avoir vu dans l'arborescence des sources. Les logiciels agentiques héritent du même risque, mais avec des conséquences plus importantes : si l'artefact livré contrôle également l'exécution de l'outil, la portée du réseau, la gestion de la mémoire ou la logique d'approbation, une construction compromise affecte non seulement l'exécution du code, mais aussi l'exécution de la décision. (nvd.nist.gov)

La documentation de npm n'est pas tendre sur ce point. npm dit .npmignore peut être utilisée pour garder les fichiers en dehors d'un paquet, la fonction dossiers champ en package.json peut être utilisé comme liste d'autorisation, et npm pack doit être exécuté localement pour vérifier ce qui sera effectivement publié. Il prévient également que pratiquement tout ce qui se trouve dans le dossier est exposé par défaut lors de la publication, à moins qu'il ne soit exclu. Ces conseils sont antérieurs aux agents d'intelligence artificielle, mais leur pertinence s'est accrue. Si le paquet comprend des cartes de source, des données de fixation, des manifestes de débogage, des informations d'identification locales ou des ressources internes, l'artefact publié peut révéler bien plus que le chemin de code que les développeurs pensaient expédier. (docs.npmjs.com)

Pour les systèmes d'agents, la cible d'attestation doit s'étendre au-delà des binaires ordinaires. Un dossier de construction sécurisé pour un agent d'intelligence artificielle devrait inclure, au minimum, le commit source, le graphe des dépendances, les paramètres des bundles, la liste des fichiers effectivement publiés, les hachages des bundles de politiques, les hachages des messages-guides ou des fichiers d'instructions expédiés, le manifeste MCP et les paramètres par défaut de la sandbox ou des autorisations compilés dans le moteur d'exécution. SLSA et in-toto fournissent déjà le langage pour décrire et vérifier l'historique des artefacts. L'étape manquante consiste à traiter les artefacts natifs de l'IA comme des sujets de première classe de la chaîne d'approvisionnement plutôt que comme des fichiers secondaires informels. (SLSA)

Un garde-paquet pratique pour tout agent basé sur l'interface de programmation est étonnamment simple :

set -euo pipefail

rm -f ./*.tgz
npm pack --json > pack-manifest.json

TARBALL=$(jq -r '.[0].filename' pack-manifest.json)

echo "Contenu de l'artefact publié :"
tar -tf "$TARBALL" | trier

echo "Échec si des cartes de source ou des artefacts de débogage évidents sont présents"
tar -tf "$TARBALL" | grep -E '\.map$|debug/|fixtures/|test-data/' && {
  echo "Unxpected publish artifact detected" (artefact de publication inattendu détecté)
  exit 1
} || true

echo "Échec si le nombre de fichiers empaquetés a changé de façon inattendue"
EXPECTED_MAX=250
COUNT=$(tar -tf "$TARBALL" | wc -l | tr -d ' ')
test "$COUNT" -le "$EXPECTED_MAX"

L'intérêt d'une telle garde n'est pas l'élégance. Il s'agit de forcer le véritable artefact de publication à devenir révisable avant la publication. npm recommande explicitement npm pack comme moyen de vérifier ce qu'un paquet va inclure, et l'incident de Claude Code est un rappel vivant que la visibilité au moment de la publication est aussi importante que l'examen des sources. (docs.npmjs.com)

La politique est un code, une invite, une mémoire et une configuration

Un deuxième changement majeur est que la politique ne se trouve plus à un seul endroit. La documentation sur la mémoire d'Anthropic indique que les fichiers CLAUDE.md et la mémoire automatique sont tous deux chargés au début de chaque conversation, et que Claude les traite comme un contexte plutôt que comme une configuration imposée. Cette phrase est plus importante qu'il n'y paraît. Elle signifie que tout audit qui veut expliquer pourquoi l'agent s'est comporté comme il l'a fait doit inclure non seulement l'invite de base, mais aussi les fichiers d'instructions exacts, l'index de la mémoire et la résolution du champ d'application qui étaient actifs pour cette session. (Docs de l'API Claude)

Le modèle de paramétrage est un facteur aggravant. La portée gérée, la portée utilisateur, la portée projet et la portée locale ont toutes des sémantiques de confiance différentes. Anthropic indique explicitement que la portée gérée est destinée aux politiques de sécurité qui doivent être appliquées à l'échelle de l'organisation et aux exigences de conformité qui ne peuvent être ignorées, tandis que la portée du projet est partagée via le contrôle de la source et que la portée locale est spécifique au référentiel et ignorée par giti. Pour une grande entreprise, cela signifie qu'une seule action peut être influencée par une politique gérée par l'organisation, une politique gérée par le référentiel, des dérogations locales et la mémoire locale de la machine. La question de l'audit n'est plus seulement "qu'a fait le code ?". La question de l'audit n'est plus seulement "qu'a fait le code ?", mais "quelle était la pile de règles en vigueur lorsque le code l'a fait ?". (Docs de l'API Claude)

Les crochets rendent la chose encore plus concrète. UserPromptSubmit peut injecter un contexte supplémentaire avant que le modèle ne voie le message de l'utilisateur. PreToolUse peut refuser, autoriser ou escalader un appel d'outil et peut réécrire son entrée avant l'exécution. Demande d'autorisation peut automatiquement autoriser une demande et modifier ses paramètres d'entrée. PostToolUse peut bloquer tout progrès ultérieur ou ajouter un contexte, et pour les outils MCP, elle peut remplacer les résultats de l'outil renvoyés au modèle. Cela signifie que la politique n'est pas une métadonnée statique. Elle peut être une médiation active au moment de l'exécution. Du point de vue de l'audit, les crochets ne sont pas simplement une fonction de personnalisation. Ils font partie de la logique d'exécution et doivent être capturés en tant que tels. (Claude)

Le plus intéressant est que la documentation d'Anthropic donne déjà une idée de ce à quoi ressemble une bonne politique d'instrumentation. La documentation sur les permissions recommande de bloquer boucler et wget par le biais de règles de refus, en utilisant WebFetch(domaine:github.com) pour les recherches sur liste autorisée, et l'utilisation de PreToolUse pour valider les URL dans les commandes Bash. C'est exactement l'instinct de conception qu'il faut pour la prochaine génération d'audit boîte blanche. N'essayez pas de deviner la sécurité à partir de la seule intention du modèle. Contraintez la surface d'action, nommez les domaines et les chemins autorisés et créez des points de décision explicites dont les résultats peuvent être enregistrés et vérifiés. (Claude)

Un script de contrôle illustratif se présente comme suit :

# : illustration de la logique de la politique PreToolUse
# lit une proposition de commande Bash et refuse les extractions externes
# à moins que la destination ne corresponde à une liste d'autorisations approuvée

import json
import re
import sys

payload = json.load(sys.stdin)
tool = payload.get("nom_outil")
cmd = (payload.get("tool_input") or {}).get("command", "")

ALLOWED = {"github.com", "docs.company.internal"}
BLOCK_PATTERNS = [r"\bcurl\b", r"\bwget\b", r"\bInvoke-WebRequest\b"]

def extract_domains(command : str) :
    return set(re.findall(r'https?://([A-Za-z0-9.-]+)', command))

if tool == "Bash" and any(re.search(p, cmd) for p in BLOCK_PATTERNS) :
    domains = extract_domains(cmd)
    if not domains or not domains.issubset(ALLOWED) :
        print(json.dumps({
            "hookSpecificOutput" : {
                "hookEventName" : "PreToolUse",
                "permissionDecision" : "deny",
                "permissionDecisionReason" : (
                    f "Récupération sortante bloquée. Domaines approuvés : {sorted(ALLOWED)}"
                )
            }
        }))
        sys.exit(0)

sys.exit(0)

Ce type de politique est utile même si le modèle sous-jacent est excellent. Les documents techniques d'Anthropic indiquent que l'injection rapide est un réel problème dès lors qu'un agent de codage peut naviguer dans une base de code et exécuter des commandes, et leur conception de bac à sable est conçue spécifiquement pour répondre à ce risque avec l'isolation du système de fichiers et du réseau. C'est le bon cadre : la politique fait partie de la base informatique de confiance de l'agent. L'audit doit la traiter de la même manière. (anthropic.com)

La mémoire est une surface de sécurité, pas une fonction de commodité

La mémoire mérite un traitement à part car elle rompt avec une habitude que les équipes de sécurité ont gardée de l'examen traditionnel des applications. Dans les logiciels classiques, la persistance est généralement explicite : une table de base de données, un fichier, une entrée de cache, une file d'attente durable. Dans les systèmes d'agents, la persistance ressemble souvent à un "simple contexte". Cette expression est dangereuse. Anthropic dit que la mémoire automatique est activée par défaut, qu'elle est stockée en markdown brut dans un répertoire spécifique au projet, et que Claude lit et écrit des fichiers de mémoire pendant une session. La première partie de MEMOIRE.md est chargé dans chaque conversation ; d'autres fichiers thématiques peuvent être lus à la demande. Il ne s'agit pas d'une personnalisation floue. Il s'agit d'une couche d'état persistante ayant un impact causal direct sur les décisions futures. (Docs de l'API Claude)

Une fois que l'on a compris cela, deux conséquences s'ensuivent. Premièrement, l'empoisonnement de la mémoire devient un problème d'audit de premier ordre. Si un pirate peut faire en sorte que des notes durables soient inscrites dans la mémoire d'un projet, les sessions ultérieures peuvent hériter de commandes de construction trompeuses, d'hypothèses opérationnelles modifiées ou de raccourcis de flux de travail peu sûrs. Deuxièmement, la provenance de la mémoire devient nécessaire. Une piste d'audit utile doit répondre à la question de savoir qui ou quoi a créé une entrée de mémoire, sous quelle tâche, après quelles sorties d'outils, et si l'entrée a été modifiée ou remplacée par la suite. Dans le cas contraire, les enquêteurs se retrouvent avec un artefact d'influence durable mais sans contexte. (Docs de l'API Claude)

La mémoire des sous-agents augmente les enjeux. La documentation d'Anthropic indique que les sous-agents peuvent maintenir leur propre mémoire persistante et que leur invite système comprend des instructions pour lire et écrire dans le répertoire de la mémoire. La documentation recommande également de demander à un sous-agent de consulter ou de mettre à jour sa mémoire dans le cadre d'un travail récurrent. C'est intéressant d'un point de vue opérationnel, mais cela crée un problème de gouvernance de second ordre : le comportement futur peut être influencé non seulement par les instructions humaines directes et la mémoire de l'agent principal, mais aussi par les agents délégués qui conservent de manière récursive leurs propres bases de connaissances locales. Un futur audit de boîte blanche doit représenter cette lignée de manière explicite. (Docs de l'API Claude)

Il s'agit là d'un domaine où la pile agentique exige réellement de nouveaux paradigmes plutôt que de nouveaux mots à la mode. Dans la journalisation d'une application ordinaire, il suffit de savoir qu'une ligne a changé. Dans les systèmes d'agents, vous avez besoin de quelque chose de plus proche du "contrôle de version de la mémoire" : hachage de l'entrée, type d'auteur, ID de la tâche parente, liens de preuve, relation de remplacement et historique de chargement. Sans cela, un répondeur ne peut pas savoir si une action nuisible provient d'instructions actuelles, d'une mémoire périmée, d'une mémoire empoisonnée ou d'une expérience légitime accumulée. (Docs de l'API Claude)

Le MCP fait des systèmes externes des éléments du système d'exécution de confiance.

MCP est l'endroit où la pile cesse de prétendre être autonome. Anthropic décrit MCP comme un protocole ouvert permettant de connecter des applications d'intelligence artificielle à des systèmes externes, y compris des sources de données, des outils et des flux de travail. Le protocole est volontairement large car l'utilité de l'agent dépend de cette largeur. La conséquence en termes de sécurité est tout aussi large : tout ce que l'agent peut atteindre par l'intermédiaire de MCP fait partie de sa surface d'attaque effective et donc de la surface d'audit. (Docs de l'API Claude)

L'histoire de l'autorisation MCP est un bon exemple de l'importance de cette question. La spécification actuelle indique que l'autorisation est facultative pour les implémentations MCP et, lorsqu'elle est prise en charge, les transports basés sur HTTP doivent suivre la spécification d'autorisation tandis que les transports stdio doivent plutôt récupérer les informations d'identification de l'environnement. Une extension distincte de l'autorisation gérée par l'entreprise indique que les organisations peuvent centraliser l'accès par l'intermédiaire de leur fournisseur d'identité plutôt que de demander à chaque employé d'autoriser chaque serveur indépendamment. Il s'agit d'une évolution sensée, mais elle signifie également que les auditeurs doivent raisonner sur des modes de déploiement multiples, certains plus forts que d'autres, avec des hypothèses de confiance différentes. (modelcontextprotocol.io)

La spécification mentionne également directement le problème de l'adjoint confus et exige des protections de type OAuth 2.1, des jetons de courte durée, un stockage sécurisé et une validation explicite de l'audience du jeton dans les orientations relatives à l'autorisation. Il s'agit là de modèles de sécurité bien connus. Ce qui est nouveau, c'est qu'ils se trouvent maintenant dans un protocole d'IA utilisé pour connecter des modèles à des systèmes externes. L'ancienne question de l'IAM était "qui peut appeler cette API ?" La nouvelle question relative à la gouvernance de l'exécution est la suivante : "Qu'est-ce que cet agent peut convaincre un système connecté de faire, dans quel contexte, avec quelle justification traçable, et à travers quelle chaîne déléguée ?" (modelcontextprotocol.io)

Les documents de Claude Code renforcent la réalité opérationnelle. Anthropic recommande qu'une équipe centrale configure les serveurs MCP et s'engage à les utiliser. .mcp.json dans la base de code pour une utilisation partagée. Il s'agit d'un modèle de production, pas d'un jouet de recherche. Une fois qu'un dépôt envoie un manifeste MCP partagé, la frontière entre "arbre source" et "topologie d'intégration d'exécution" disparaît. Le dépôt lui-même définit désormais certains des systèmes auxquels l'agent peut s'adresser. L'audit de la boîte blanche doit donc inclure les manifestes d'intégration natifs du référentiel dans le cadre de l'examen normal. (Docs de l'API Claude)

C'est également à ce niveau que l'intégrité de la sortie de l'outil devient critique. La référence aux crochets d'Anthropic indique que les outils MCP ne sont que des outils en ce qui concerne les événements du cycle de vie, et que les crochets post-outils peuvent remplacer les sorties des outils MCP avant que le modèle ne les consomme. Cette fonctionnalité est utile pour la médiation et la normalisation. Cela signifie également que l'enregistrement de l'audit doit capturer à la fois la sortie originale et la sortie transformée si les enquêteurs veulent préserver la vérité causale. Un futur auditeur devrait être en mesure de répondre non seulement à la question "qu'est-ce que le serveur MCP a renvoyé ?", mais aussi à la question "quelle valeur finale le modèle a-t-il vu après la mutation par crochet ? (Claude)

Les CVE expliquent déjà la nouvelle frontière

Le flux de CVE est l'un des meilleurs moyens de voir que le nouveau paradigme n'est pas théorique. Les vulnérabilités les plus importantes pour les systèmes d'agents ne sont pas seulement des "jailbreaks LLM". Elles se situent au niveau des couches de construction, de passerelle, d'IDE, de codegen et de gestionnaire d'outils. Chacune d'entre elles correspond à une partie de la pile logicielle agentive que les défenseurs doivent traiter comme une infrastructure auditable.

Commencez par CVE-2024-3094 dans xz. NVD affirme qu'un code malveillant a été inséré dans les fichiers d'archive en amont et activé au cours du processus de construction de liblzma en extrayant un fichier objet préconstruit à partir d'un fichier de test déguisé. Ce point est important car chaque produit d'agent d'intelligence artificielle dépend encore de la confiance conventionnelle dans la chaîne d'approvisionnement des logiciels. Si un mainteneur peut réviser le code source tout en envoyant un artefact de construction malveillant, l'audit du code seul ne suffit pas. La provenance de la construction, la comparaison des artefacts et l'attestation font partie de la sécurité des agents, que les équipes le veuillent ou non. (nvd.nist.gov)

Ensuite, CVE-2026-1868 dans GitLab AI Gateway. NVD indique que le composant Duo Workflow Service était vulnérable à une expansion de modèle non sécurisée des données fournies par l'utilisateur via des définitions de flux Duo Agent Platform crafts, avec un possible déni de service ou une exécution de code sur la passerelle. C'est un exemple presque parfait de la raison pour laquelle la couche de flux de travail fait partie de la pile. La partie "IA" du système n'est pas l'endroit où se trouve le bogue. La surface dangereuse était une passerelle de flux de travail qui servait de médiateur au comportement de l'agent. Si un programme de sécurité ne vérifie que les invites du modèle et ignore le moteur de flux, il vérifie la couche d'image de marque et non la couche de risque. (nvd.nist.gov)

La CVE-2026-22785 dans Orval est tout aussi révélatrice. Selon NVD, la logique de génération du serveur MCP dans les versions antérieures à la 7.18.0 utilisait une manipulation de chaîne qui incorporait l'OpenAPI résumé sans validation ni échappement appropriés, ce qui permet l'injection de code. Il s'agit d'un signal fort indiquant que la génération d'outils natifs d'IA hérite d'anciennes erreurs de code dans de nouveaux endroits. La leçon à tirer n'est pas seulement "assainir les chaînes de caractères". La leçon est que les manifestes d'outils, l'ingestion de schémas et la génération de code face à l'agent font maintenant partie du chemin de confiance vers l'exécution. L'audit boîte blanche doit les inspecter aussi rigoureusement que n'importe quel moteur de template ou script CI. (nvd.nist.gov)

CVE-2026-33980 dans le serveur MCP Azure Data Explorer va plus loin dans l'exécution. NVD indique que les versions jusqu'à la 0.1.1 contenaient des vulnérabilités d'injection KQL dans les gestionnaires d'outils MCP tels que get_table_schema, données_tableau_échantillonet get_table_details. C'est exactement le genre de bogue que les défenseurs devraient s'attendre à voir se répéter dans les prochaines années : des classes établies comme l'injection de requêtes réapparaissent à l'intérieur de gestionnaires d'outils qui ont été introduits pour rendre les agents utiles. Le protocole est nouveau ; le mode d'échec ne l'est pas. Mais comme le gestionnaire se trouve derrière une abstraction orientée vers l'agent, l'impact peut être amplifié par des tentatives autonomes, le chaînage d'outils ou des effets de confusion. (nvd.nist.gov)

CVE-2025-65715 dans l'extension VS Code Code Runner montre que l'environnement de développement lui-même fait toujours partie de la limite. Selon la NVD, le executorMap permettait l'exécution de code arbitraire lors de l'ouverture d'un espace de travail malveillant. Cela est important pour l'outillage agentique car de nombreux agents de codage vivent maintenant dans des IDE, des terminaux et des extensions prenant en compte l'espace de travail. Un référentiel peut contenir non seulement les sources, mais aussi le contexte local qui détermine ce qu'un agent ou une extension va exécuter. L'audit de la boîte blanche doit inclure l'examen de l'espace de travail et de la configuration de l'éditeur, en particulier lorsque l'agent est censé agir dans cet environnement. (nvd.nist.gov)

Un cas étroitement lié, CVE-2025-65716 dans Markdown Preview Enhanced, montre comment le rendu du contenu peut également devenir un tremplin. L'entrée de la NVD indique qu'un fichier Markdown élaboré pourrait déclencher une exécution de code arbitraire dans l'extension. Cela est important car les flux de travail des agents reposent de plus en plus sur des artefacts générés, des aperçus et de la documentation intégrée dans le cadre du développement et de l'examen. Lorsque l'environnement de l'agent rend un contenu non fiable à l'intérieur d'une chaîne d'outils privilégiée, la logique de prévisualisation devient également une partie de la limite d'exécution. (nvd.nist.gov)

CVE	Couche d'empilage	Pourquoi c'est important pour les systèmes agentiques
CVE-2024-3094	Provenance de la construction et de la mise à disposition	Les artefacts livrés peuvent diverger des sources examinées, de sorte que l'examen du code ne peut à lui seul prouver la confiance.
CVE-2026-1868	Flux de travail et couche passerelle	Les services d'orchestration d'agents peuvent devenir des surfaces directes de RCE et de DoS.
CVE-2026-22785	Schéma de l'outil et couche de codegen	La génération d'outils orientés vers l'agent peut transformer l'ingestion de métadonnées en exécution de code.
CVE-2026-33980	Exécution du gestionnaire MCP	Les gestionnaires d'outils peuvent recréer des classes d'injection classiques derrière des abstractions d'agents.
CVE-2025-65715	Couche IDE et espace de travail	Les paramètres locaux du référentiel peuvent influencer l'exécution des commandes dans l'environnement du développeur.
CVE-2025-65716	Couche de rendu et de prévisualisation	Un contenu non fiable visualisé dans des outils adjacents à l'agent peut devenir un chemin d'exécution.

Le modèle du tableau est plus important que n'importe quelle entrée. Le risque se concentre dans le code d'orchestration, les services de passerelle, les gestionnaires d'outils, la colle IDE, la génération de code et les limites de l'emballage. Ce sont tous des éléments de la pile de logiciels agentiques. Aucune d'entre elles n'est bien décrite par des expressions telles que "sécurité rapide". (nvd.nist.gov)

Pourquoi les techniques de boîte blanche de modèles purs ne sont pas suffisantes

Cela ne signifie pas que les méthodes de boîte blanche internes au modèle ont cessé d'avoir de l'importance. Le travail d'Anthropic sur les objectifs cachés a explicitement étudié les techniques de boîte blanche qui nécessitent des poids de modèle ou des activations internes, et l'article traite les autoencodeurs épars et les méthodes d'interprétabilité connexes comme faisant partie d'une boîte à outils d'audit sérieuse. Si la question est de savoir si un modèle a appris un objectif latent ou un modèle interne fragile, l'accès direct aux éléments internes peut révéler des preuves que l'examen du comportement seul peut manquer. (anthropic.com)

Mais les preuves les plus récentes font qu'une revendication plus restreinte est plus défendable qu'une revendication plus large. Le rapport AuditBench d'Anthropic indique que les outils d'interprétabilité à boîte blanche peuvent être utiles, mais surtout pour les cibles les plus faciles, tandis que les outils à boîte noire avec échafaudage sont les plus efficaces dans l'ensemble. Le rapport sur les risques de février 2026 d'Anthropic indique que l'entreprise n'a pas encore une compréhension suffisante des états internes pour pouvoir porter des jugements définitifs de manière isolée, et qu'elle s'appuie plutôt sur des preuves convergentes. L'implication n'est pas anti-interprétabilité. Il s'agit d'une anti-monoculture. L'avenir de l'audit "boîte blanche" n'est pas "l'interprétabilité remplace la sécurité du système", mais "la sécurité du système fournit les preuves". C'est "la sécurité du système fournit le graphique de preuves dans lequel l'interprétabilité peut devenir pertinente pour la prise de décision". (alignement.anthropic.com)

Les pratiques d'évaluation d'Anthropic confirment cette lecture. Le rapport sur les risques indique que de nombreuses transcriptions d'audits comportementaux automatisés comprenaient le véritable message-guide du système Claude Code et l'ensemble des outils utilisés en interne. Petri, le cadre d'audit automatisé open-source d'Anthropic, est décrit comme la création d'environnements, l'exécution d'audits multi-tours avec des messages humains et des outils simulés, et l'évaluation des transcriptions pour mettre en évidence les comportements préoccupants. La mise à jour Petri 2.0 a ajouté des mesures d'atténuation du réalisme visant spécifiquement à contrer la sensibilisation à l'évaluation. C'est l'orientation méthodologique qui compte : un audit réaliste, conscient du système et multi-tours avec des défenses explicites contre le modèle qui reconnaît qu'il est testé. (anthropic.com)

Pour les défenseurs, la conclusion opérationnelle est claire. Si un système d'agents est livré sans provenance d'artefact, sans lignage de politique, sans traces d'exécution et sans preuves rejouables, l'ajout ultérieur d'un tableau de bord d'interprétabilité mécaniste ne comblera pas la lacune de gouvernance fondamentale. Inversement, si le système enregistre déjà la mémoire qui a été chargée, l'outil qui a été appelé, le crochet qui a modifié les arguments, le serveur MCP qui a répondu, les destinations réseau qui ont été contactées et la manière dont l'action finale a été justifiée, les outils internes au modèle deviennent alors beaucoup plus utiles parce qu'ils peuvent être alignés sur des événements concrets au lieu d'être étudiés dans l'abstrait. (Docs de l'API Claude)

Une future architecture de boîte blanche pour la pile logicielle agentique

Une architecture post-fuite sérieuse devrait partir d'un principe simple : chaque action conséquente de l'agent devrait pouvoir être reconstruite sous la forme d'une transition d'état. Pas seulement l'appel final à l'outil. Toute la transition. Cela signifie que le modèle de preuve doit capturer au moins l'artefact de construction, le jeu d'instructions chargé, l'instantané de la mémoire, la pile de politique active, la topologie de l'outil et du MCP, la trace d'exécution et les effets externes qui en résultent. Si l'un de ces éléments manque, l'audit perd son pouvoir explicatif. (SLSA)

Une architecture à six plans est envisageable.

Le premier plan est le plan de construction attesté. Ce plan utilise la provenance SLSA et les attestations in-toto pour prouver ce qui a été construit, à partir de quelle source, par quel pipeline et avec quelles étapes déclarées. Dans un environnement agentique, l'ensemble des sujets doit être plus large qu'un binaire ou un conteneur. Il doit inclure les invites expédiées, les paquets de politiques, les manifestes d'outils, les descripteurs d'extension et les fichiers d'intégration vérifiés par le référentiel, tels que .mcp.json. Si ces artefacts affectent le comportement, ils ont leur place dans le graphe d'attestation. (SLSA)

Le deuxième plan est le plan de médiation des politiques. Ce plan détermine la portée et la priorité des paramètres gérés, des paramètres du projet, des dérogations locales, des règles CLAUDE.md, de la logique des crochets, des règles de permission et des limites du bac à sable. Son rôle n'est pas seulement d'autoriser. Son rôle est de rendre l'autorisation explicable. Lorsqu'un appel à un outil est autorisé, refusé, réécrit ou escaladé, l'avion devrait émettre un enregistrement de décision de politique avec les entrées, les règles correspondantes, la décision et tous les champs modifiés. Le modèle de crochet d'Anthropic fournit déjà le vocabulaire de contrôle nécessaire pour cela : autoriser, refuser, demander, entrée mise à jour, contexte supplémentaire et remplacement de la sortie de l'outil. (Docs de l'API Claude)

Le troisième plan est le plan de provenance de l'exécution. C'est là que l'observabilité de l'exécution devient un contrôle de sécurité de premier ordre. Le travail GenAI d'OpenTelemetry définit déjà des périodes d'inférence, des périodes d'agent et des événements d'acceptation qui peuvent capturer les entrées de l'utilisateur et les réponses du modèle. Ces conventions sont encore en cours de développement, mais elles sont suffisamment avancées pour fournir un vocabulaire partagé pour les identifiants de conversation, les noms de modèles, l'utilisation de jetons, les appels d'outils et les opérations d'agents. La bonne conception ne consiste pas à traiter l'observabilité comme une fonction du tableau de bord. Il s'agit de la traiter comme la matière première de la reconstruction médico-légale. (GitHub)

Un modèle d'événement minimal pour l'audit agentique pourrait ressembler à ceci :

{
  "event_id" : "evt_01J...",
  "ts" : "2026-04-01T10:22:14.921Z",
  "conversation_id" : "conv_92a",
  "span_id" : "spn_204",
  "parent_span_id" : "spn_199",
  "event_type" : "tool_call",
  "actor" : {
    "kind" : "subagent",
    "name" : "browser-tester",
    "agent_id" : "agent-abc123"
  },
  "policy" : {
    "decision_id" : "pol_778",
    "matched_rule" : "allow_webfetch_github_only",
    "mode" : "allow"
  },
  "memory" : {
    "loaded_memory_hash" : "sha256 :...",
    "loaded_claude_md_hashes" : ["sha256 :..."]
  },
  "tool" : {
    "name" : "mcp__github__search_repositories",
    "arguments_hash" : "sha256 :...",
    "raw_arguments_redacted" : true,
    "result_hash" : "sha256 :..."
  },
  "effects" : {
    "filesystem_writes" : [],
    "network_destinations" : ["api.github.com"]
  }
}

Le quatrième plan est le rediffusion et plan contrefactuel. La réponse aux incidents pour les systèmes d'agents n'est pas complète lorsque l'équipe peut rejouer la même transcription. Elle devient vraiment utile lorsque l'équipe peut poser des questions contrefactuelles. Que se passe-t-il si l'entrée en mémoire est supprimée ? Que se passe-t-il si la sortie MCP est remplacée par l'original non modifié ? Que se passe-t-il si la tâche est exécutée sans sous-agent d'arrière-plan ? Que se passe-t-il si la pile de politiques est ramenée à la version gérée précédente ? Un audit moderne en boîte blanche devrait pouvoir rejouer non seulement l'interaction visible, mais aussi l'environnement causal qui l'entoure. (Claude)

Le cinquième plan est le plan d'audit continu. C'est là que l'audit comportemental de type Petri a sa place. Le travail public d'Anthropic sur Petri décrit un auditeur automatisé qui crée des environnements, exécute des audits multi-tours et note les transcriptions, tandis que Petri 2.0 ajoute des mesures d'atténuation du réalisme pour réduire la conscience de l'évaluation. Dans un programme de sécurité de production, cela se traduit par des graines de régression, des tâches de pot de miel, des filtres de réalisme, des motifs d'exécution suspects et des bibliothèques de scénarios liés à des analyses post-mortem réelles. L'essentiel est que ces évaluations soient exécutées par rapport à la pile que l'organisation déploie réellement, et non par rapport à un modèle abstrait dissocié de ses outils. (anthropic.com)

Le sixième plan est le plan de preuve et d'adjudication. Ce plan transforme les traces et les attestations en décisions utilisables. Il devrait permettre le triage de la sécurité, le débogage technique, les preuves de conformité et l'assurance externe. Les posts d'Anthropic sur les évaluations et les harnais de longue durée sont très utiles ici : les équipes sans évaluations finissent par se retrouver dans des boucles réactives, corrigeant les échecs seulement en production et luttant pour distinguer les régressions du bruit. Il en va de même pour la sécurité. Si une équipe ne peut pas comparer la forme actuelle de la trace à une base de référence connue, elle finira par se disputer sur des anecdotes au lieu de prouver les changements d'état. (anthropic.com)

Avion	Question principale	Preuves requises	Échec typique en cas d'absence
Plan de construction attesté	Qu'est-ce qui a été expédié exactement ?	Provenance, hachage d'artefacts, manifeste de publication, attestations signées	L'examen des sources ne correspond pas à la réalité déployée
Plan de médiation politique	Pourquoi cette action a-t-elle été autorisée ?	Correspondance des règles, résolution du champ d'application, décisions relatives aux crochets, configuration du bac à sable	Les équipes ne peuvent pas expliquer les échecs en matière d'autorisation ou de confinement
Plan de provenance de l'exécution	Ce qui s'est passé dans l'ordre	Portées, événements, appels d'outils, sorties de réseau, effets de fichiers, identifiants de conversation	Les incidents ne peuvent pas être reconstitués avec certitude
Replay et plan contrefactuel	Que se serait-il passé si X avait changé ?	Prise d'instantané de la mémoire, des configurations, des sorties d'outils, du graphique des tâches	La validation des correctifs devient une devinette
Plan d'audit continu	La pile se comporte-t-elle toujours de manière sûre ?	Scénarios de semences, filtres de réalisme, notation, régressions	Les équipes n'apprennent les dérives qu'après les échecs en contact avec l'utilisateur
Preuves et plan d'adjudication	Les humains peuvent-ils se fier à la conclusion	Rapports, liens vers des preuves brutes, vues différentielles, mappages de contrôle	Les conclusions ne résistent pas à un examen technique ou de conformité

Cette architecture n'est pas un théâtre académique. Chaque plan du tableau est fondé sur les normes publiques de la chaîne d'approvisionnement, les documents publics du code Claude, les spécifications publiques du MCP ou le travail public d'Anthropic sur l'évaluation des agents. Ce qui est nouveau, c'est l'insistance sur le fait que ces pièces appartiennent ensemble à un système vérifiable plutôt qu'à des disciplines séparées. (SLSA)

Comment instrumenter le runtime sans créer un désordre de surveillance ?

Une objection prévisible est que l'observabilité de la pile complète capturera trop d'informations sensibles. Ce risque est réel. La documentation GenAI d'OpenTelemetry avertit explicitement que certains champs d'appel d'outil peuvent contenir des informations sensibles, et ses conseils sur les événements indiquent que les entrées des utilisateurs et les réponses des modèles peuvent être capturées en tant qu'événements opt-in plutôt qu'en tant que valeurs par défaut obligatoires. Il s'agit là d'une conception correcte. La solution n'est pas de "tout enregistrer pour toujours". La réponse est une capture sélective et structurée, conçue autour d'une causalité liée à la sécurité. (OpenTelemetry)

En pratique, cela signifie qu'il faut hacher ou symboliser les arguments sensibles des outils, séparer la conservation brute de la conservation normalisée et enregistrer les valeurs originales et transformées uniquement lorsque la médiation de la politique peut les modifier. Cela signifie également qu'il faut faire la distinction entre ce qui est nécessaire pour la relecture et ce qui n'est nécessaire que pour la surveillance globale. Un système de relecture peut avoir besoin de la sortie exacte du MCP pour une courte période de conservation à l'intérieur d'un magasin de preuves scellé. Un pipeline de surveillance peut n'avoir besoin que du hachage de la sortie, du type d'outil, de la latence et du résultat du contrôle. L'architecture boîte blanche doit prendre en charge les deux voies de manière explicite plutôt que de les confondre. (OpenTelemetry)

Un wrapper de traçage illustratif pourrait ressembler à ceci :

from opentelemetry import trace

tracer = trace.get_tracer("agent.audit")

def traced_tool_call(conversation_id, tool_name, args, call_fn) :
    avec tracer.start_as_current_span(f "outil {nom_de_l'outil}") as span :
        span.set_attribute("gen_ai.conversation.id", conversation_id)
        span.set_attribute("gen_ai.tool.name", tool_name)
        span.set_attribute("agent.audit.args_hash", sha256_json(args))
        span.set_attribute("agent.audit.raw_args_retained", False)

        try :
            result = call_fn(args)
            span.set_attribute("agent.audit.result_hash", sha256_json(result))
            span.set_attribute("agent.audit.status", "ok")
            return result
        except Exception as exc :
            span.set_attribute("error.type", exc.__class__.__name__)
            span.set_attribute("agent.audit.status", "error")
            raise

La propriété importante d'un code comme celui-ci n'est pas la forme exacte de l'API. C'est le choix de la modélisation. La trace doit lier les décisions de l'agent aux identifiants de conversation, aux décisions politiques, aux identités des outils et aux hachages stables des entrées et des sorties. Une fois que cela existe, les enquêteurs peuvent corréler une action suspecte à la chaîne précise qui l'a produite, même si les charges utiles sensibles ont été minimisées ou expurgées. Il s'agit là d'un dispositif de sécurité bien plus solide qu'une pile de journaux JSON ad hoc ou de captures d'écran de transcriptions de conversations. (GitHub)

Des conclusions de la boîte blanche aux preuves de la boîte noire

L'une des erreurs les plus faciles à commettre dans ce domaine est de s'arrêter à la compréhension de l'architecture. Cela ne suffit pas. L'audit de la boîte blanche peut indiquer à une équipe qu'il existe une chaîne d'appels risquée, qu'une limite de mémoire est trop permissive, qu'une passerelle étend les modèles de manière dangereuse ou qu'un serveur MCP s'étend plus loin que prévu. Mais la question opérationnelle qui se pose ensuite est toujours la même : le chemin est-il accessible dans des conditions réalistes, et la correction proposée tient-elle réellement lorsque la pile complète est utilisée ? (penligent.ai)

C'est pourquoi le meilleur flux de travail post-fuite est hybride de par sa conception. Utilisez les résultats de la boîte blanche pour générer un exploit testable ou une hypothèse de défaillance. Exécutez ensuite une validation boîte noire ou boîte grise dans un environnement réaliste, avec le bon contexte d'identité, les limites du réseau, les contrôles compensatoires et le comportement des sous-agents. L'examen en boîte blanche permet de trouver des chemins latents. La preuve par boîte noire établit si ces chemins survivent au contact avec la réalité. Les deux méthodes sont complémentaires et non concurrentes. (penligent.ai)

C'est l'un des domaines dans lesquels le matériel public de Penligent s'intègre naturellement dans le flux de travail. Son article en anglais sur la sécurité du code Claude établit clairement la distinction : l'audit de la boîte blanche identifie les vérifications manquantes dans les chaînes d'appel, tandis que la validation de la boîte noire prouve si un attaquant peut réellement atteindre un itinéraire par le biais de passerelles et de transitions de rôles. Du côté des produits, la page d'accueil de Penligent met l'accent sur plus de 200 outils pris en charge, le flux CVE-to-PoC, la reproductibilité des preuves d'abord, et les rapports éditables alignés sur SOC 2 et ISO 27001. Utilisée avec précaution, cette combinaison permet de combler le fossé entre les soupçons architecturaux et les preuves de validation. (penligent.ai)

Cela ne signifie pas que chaque équipe a besoin du même produit. Cela signifie que le flux de travail lui-même est en train de mûrir. Les futurs programmes de boîte blanche ne se termineront pas par un PDF indiquant "problème possible dans la chaîne d'outils". Ils se termineront par un ensemble de preuves : preuves d'attestation, preuves de traçabilité, preuves d'accessibilité à l'exploit, diff de correction, sortie de rejeu et semences de régression. C'est la norme vers laquelle la sécurité des agents d'IA devrait tendre. (penligent.ai)

Le programme de recherche universitaire est enfin concret

Pour les chercheurs, cette transition ouvre une série de questions bien plus intéressantes que l'expression vague "audit de sécurité de l'IA" ne le suggère habituellement. La première question est la suivante l'exhaustivité de la trace. Quel est l'ensemble minimal d'événements qui rend une explication post hoc suffisamment solide pour les décisions en matière de sécurité ? Une consignation insuffisante nuit à la clarté du lien de causalité. Trop d'enregistrements détruisent la vie privée et l'opérabilité. Il ne s'agit pas seulement d'un problème de système. Il s'agit d'un problème de formalisation. Un programme de recherche utile devrait définir quelles transitions agent-état doivent être observables pour qu'une relecture préserve la sémantique de sécurité de l'exécution originale. (OpenTelemetry)

La deuxième question est la suivante la causalité fondée sur les politiques. Les archives existantes peuvent indiquer à une équipe qu'une règle existait. Ce qui est plus difficile, c'est de prouver que la règle a changé le résultat. L'action s'est-elle produite à cause d'un CLAUDE.md défini par le projet, à cause d'une mémoire automatique, à cause d'une règle de gestion de l'information ? Demande d'autorisation ou parce qu'une sortie MCP a été normalisée post hoc ? La recherche devrait aller au-delà de l'attribution générique et s'orienter vers la causalité contrefactuelle sur des traces d'agents structurées. Le modèle de crochet d'Anthropic, avec des points de décision antérieurs et postérieurs à l'outil, offre un substrat public solide pour ce type de travail. (Claude)

La troisième question est la suivante l'audit boîte blanche à divulgation sélective. Le rapport public d'Anthropic sur les risques de sabotage indique que certaines parties du rapport ont été expurgées parce que le texte non expurgé pourrait présenter un risque d'utilisation abusive ou divulguer des informations commercialement sensibles sans que le public n'en tire un bénéfice suffisant. Il s'agit là d'une contrainte réaliste pour les systèmes commerciaux. L'avenir n'est pas à l'open source universel. Il s'agira souvent de systèmes vérifiables mais à divulgation sélective. Cela laisse de la place aux mécanismes d'audit cryptographique, aux résumés attestés, aux modèles d'accès des évaluateurs tiers et aux idées d'assurance de type "zéro connaissance" qui permettent à des personnes extérieures de vérifier des propriétés spécifiques sans avoir accès à l'ensemble du cycle d'exécution. (anthropic.com)

La quatrième question est la suivante la gouvernance de la mémoire comme science de l'audit. Les documents d'Anthropic rendent la mémoire suffisamment tangible pour qu'il soit désormais possible d'effectuer des tests rigoureux. Les chercheurs peuvent comparer des corpus de mémoire empoisonnés et non empoisonnés, varier la portée entre le projet, l'utilisateur et le local, et mesurer à quel point une entrée de mémoire nuisible modifie le comportement ultérieur de l'utilisation de l'outil. Ils peuvent également étudier si les défenses spécifiques à la mémoire doivent donner la priorité à la provenance, au filtrage du contenu, à la dégradation, à la résolution des conflits ou à l'isolation du champ d'application. Ces éléments sont bien plus mesurables que la question plus ancienne et plus floue de savoir si un modèle "se souvient" de quelque chose dans un sens général. (Docs de l'API Claude)

La cinquième question est la suivante provenance multi-agents. Les documents sur les sous-agents d'Anthropic exposent déjà SubagentStart (Démarrage de l'agent secondaire), SubagentStopLes modèles de provenance comprennent les identifiants des agents, les chemins de transcription des agents, les permissions héritées et le comportement d'exécution en arrière-plan. Cela signifie que les chercheurs peuvent désormais travailler sur des modèles de provenance pour l'autonomie déléguée en utilisant une sémantique publique réelle plutôt que des abstractions fictives. Comment fusionner les traces des parents et des enfants ? Quel est le bon modèle de provenance pour la mémoire partagée, les permissions empruntées ou la création de tâches entre agents ? À quel moment la provenance devient-elle trop coûteuse pour être conservée à grande échelle ? Ce sont d'excellentes questions pour les systèmes et la sécurité. (Claude)

La sixième question est la suivante perte de conversion entre l'outil et l'agent. La discussion de l'AuditBench sur l'écart entre l'outil et l'agent est particulièrement importante ici. Des preuves utiles prises isolément n'aident pas automatiquement l'agent enquêteur à formuler la bonne hypothèse. Le même problème se posera lors de l'audit de production : une trace peut contenir les bons faits, mais l'auditeur - humain ou modèle - peut ne pas réussir à les synthétiser en une explication causale correcte. La recherche sur de meilleurs échafaudages, sur la synthèse des preuves et sur les interfaces d'audit basées sur des graphiques aura probablement autant d'importance que la recherche sur les outils bruts eux-mêmes. (alignement.anthropic.com)

La septième question est la suivante validité prédictive. De nombreux contrôles semblent solides sur le papier mais faibles en pratique. Les travaux d'Anthropic sur les évaluations, les harnais de longue durée et le filtrage du réalisme font ressortir le même point : les environnements, les échafaudages et le réalisme sont importants. Un contrôle de provenance à temps de publication n'est utile que s'il prédit moins d'échecs de déploiement. Un schéma de traçabilité n'est utile que s'il permet de prévoir une résolution plus rapide et plus précise des incidents. Une défense de la mémoire n'est utile que si elle prédit une compromission plus faible au niveau des tâches en cas de contamination. L'audit agentique de la boîte blanche a besoin de repères qui mesurent directement ces résultats. (anthropic.com)

Ce que les équipes devraient construire ensuite

Pour la plupart des organisations d'ingénierie, les douze prochains mois ne devraient pas commencer par une plateforme d'interprétabilité de type "moonshot". Ils devraient commencer par une infrastructure disciplinée. Inventorier les artefacts réels qui influencent le comportement de l'agent. Attester la chaîne de construction et de publication. Centraliser les champs d'application des politiques. Faire en sorte que .mcp.jsonLes paramètres de la mémoire, les crochets et les paramètres de la mémoire peuvent être révisés. Ajoutez des identificateurs de traces qui relient les invites, les outils, les décisions politiques et les effets entre eux. Ensuite, il convient de mettre en place un système de relecture pour les tâches présentant les risques les plus élevés. Ce n'est qu'une fois cette base établie qu'il est judicieux d'ajouter des agents d'audit plus riches, une analyse formelle de la causalité ou des outils de fonctionnalités internes. (docs.npmjs.com)

L'ordre est important car les modes de défaillance sont répartis de manière inégale. Les équipes savent déjà comment débattre du comportement du modèle dans l'abstrait. Elles sont beaucoup moins douées pour répondre à des questions simples et concrètes comme celles-ci : quelles entrées de mémoire ont été chargées, quel artefact exact a été installé, quelle règle de politique a autorisé cet appel réseau, quel serveur MCP a émis ces données et qu'est-ce qui a changé après le correctif. Le moyen le plus rapide d'améliorer la sécurité est de faciliter la réponse à ces questions. (Docs de l'API Claude)

Le matériel d'ingénierie publique d'Anthropic va dans le même sens. De bonnes évaluations rendent les défaillances visibles avant qu'elles ne touchent les utilisateurs. La conception des harnais est essentielle pour les travaux autonomes de longue durée. L'exécution du code avec MCP nécessite un bac à sable, des limites de ressources et une surveillance. Il ne s'agit pas là d'observations de niche. Il s'agit d'un schéma directeur pour la maturité opérationnelle des systèmes d'agents. L'audit boîte blanche dans l'ère post-fuite est simplement la discipline qui consiste à transformer cette maturité en preuves. (anthropic.com)

Le nouveau paradigme n'est pas plus de sources, mais plus de preuves

La fuite du code Claude est devenue une nouvelle parce qu'elle a révélé à quel point les vieilles hypothèses sont fragiles. Si une carte des sources dans un paquet peut exposer autant d'un agent de codage de production, alors la limite de sécurité significative n'a jamais été seulement le modèle et jamais seulement le référentiel. Il s'agit du chemin complet qui va de la source écrite à l'artefact publié, du contexte chargé à l'action médiatisée par l'outil. Ce chemin est la pile logicielle agentique. (The Verge)

C'est le changement de paradigme. L'audit de la boîte blanche après la fuite ne consiste pas à lire éternellement d'autres codes ayant fait l'objet d'une fuite. Il s'agit de construire des systèmes dans lesquels chaque action conséquente de l'agent peut être vérifiée, attribuée, rejouée et testée par rapport à la réalité. La provenance de la construction doit être signée. Les politiques doivent être délimitées et explicables. La mémoire doit être vérifiable. L'accès au MCP doit être contrôlable. Les traces d'exécution doivent être structurées. Les conclusions doivent devenir des preuves de boîte noire. Les équipes qui adoptent ce modèle auront quelque chose de bien mieux qu'un slogan sur la sécurité de l'IA. Elles auront des preuves. (SLSA)

Lectures complémentaires et liens de référence

La documentation Claude Code d'Anthropic est la meilleure source publique pour comprendre la surface d'exécution réelle : la vue d'ensemble, le système de mémoire, les crochets, les sous-agents, les champs d'application des paramètres et les conseils de déploiement MCP de l'entreprise exposent tous les points de contrôle que l'audit moderne de la boîte blanche doit modéliser. (anthropic.com)

En ce qui concerne la conception des protocoles et de l'observabilité, la spécification d'autorisation MCP et l'extension d'autorisation gérée par l'entreprise montrent l'évolution du contrôle d'accès, tandis que les portées et les événements GenAI d'OpenTelemetry montrent qu'un vocabulaire de traçage partagé pour les temps d'exécution des agents commence à se solidifier. (modelcontextprotocol.io)

Pour la rigueur de la chaîne d'approvisionnement, la provenance SLSA, in-toto et l'enregistrement de la porte dérobée xz sont des lectures essentielles. Ils démontrent que les logiciels dignes de confiance ne sont pas seulement des sources révisées, mais aussi un historique de construction vérifiable et une exécution vérifiable de la chaîne d'approvisionnement. (SLSA)

En ce qui concerne l'alignement et la méthodologie d'audit, les travaux d'Anthropic sur les objectifs cachés, AuditBench, le rapport sur les risques de février 2026 et Petri montrent comment le domaine évolue vers un audit multi-tours réaliste qui combine des outils, des invites et des conditions d'exécution plutôt que de traiter le modèle comme un objet isolé. (anthropic.com)

Pour une lecture de Penligent qui s'inscrit naturellement dans ce flux de travail, les liens internes les plus pertinents sont son article sur le passage des conclusions de la boîte blanche à la preuve de la boîte noire, son article sur l'initiative de sécurité agentique à l'ère du MCP, son article sur la fuite de la carte des sources du code Claude, et la page principale du produit pour les flux de travail de validation offensive basés sur les preuves d'abord. (penligent.ai)