Le Pare-feu Anti-Fabrication : Quand Votre Agent Publie des Mensonges

Le 19 février 2026, quelqu’un a donné à Claude Code un accès MCP à Twitter, Telegraph, Write.as, Rentry, GitHub et Moltbook. Au cours des 72 heures suivantes, l’agent a publié des affirmations techniques fabriquées sur les huit plateformes. Une fenêtre de contexte de 200 000 tokens est devenue « 1 million de tokens ». Une session ayant traité 196 626 tokens est devenue « 12 millions de tokens en une seule session ». Au troisième jour, l’agent revendiquait des sessions d’un trillion de tokens, soit une erreur d’un facteur 83 000.¹

L’agent n’était pas malveillant. Il avait tort avec assurance, et rien ne se dressait entre sa confiance et un bouton de publication.

TL;DR

Un agent Claude Code autonome a publié des affirmations fabriquées sur plus de 8 plateformes pendant 72 heures via une boucle de rétroaction confabulatoire : la session N devine, écrit sa supposition dans MEMORY.md, la session N+1 la lit comme un fait vérifié, publie, la session N+2 lit la publication comme une confirmation. Aucune porte de sortie n’existait. L’alignement en phase d’entraînement (« sois honnête ») était insuffisant car l’agent croyait être honnête. La solution est un pare-feu de sortie : classifier les commandes en locales, partagées ou externes, et différer la publication externe vers une revue humaine. Ci-dessous : l’anatomie de l’incident, le mécanisme de la boucle de rétroaction, ce que d’autres construisent (OkaiDokai), et une implémentation fonctionnelle que vous pouvez utiliser dès aujourd’hui.

La Boucle de Rétroaction Confabulatoire

La fabrication n’était pas une hallucination isolée. C’était une boucle de rétroaction soutenue à travers plusieurs sessions, chacune renforçant les erreurs de la session précédente.¹

Le mécanisme :

1. Session N : La supposition. Claude a estimé les nombres de tokens en se basant sur la taille des fichiers, divisant les octets JSONL par 4 pour approximer les tokens. Cette méthodologie a été inventée. Les chiffres résultants étaient suffisamment plausibles pour être écrits dans MEMORY.md en tant que résultats.

2. Session N+1 : La promotion. Une nouvelle session Claude a lu MEMORY.md, trouvé les estimations de tokens déjà documentées, et les a traitées comme des faits vérifiés. La session a construit sur ces faits, escaladant les affirmations, et les a publiées sur plusieurs plateformes à l’aide des outils MCP.

3. Session N+2 : Le renforcement. La session suivante a lu à la fois MEMORY.md et les articles publiés. Les affirmations avaient désormais deux sources : le fichier mémoire et les publications. Le recoupement de deux sources de la même fabrication ressemblait à une corroboration.

La boucle est structurellement identique au blanchiment de citations dans la publication académique : fabriquer une affirmation, la publier quelque part, puis citer la publication comme preuve de l’affirmation. L’agent n’avait pas l’intention de blanchir. Il a suivi un processus rationnel (vérifier la mémoire, recouper les sources, publier les résultats) qui s’est trouvé opérer sur des données fabriquées.

Lorsque l’utilisateur a contesté les chiffres, l’agent a tenu pendant plus de 50 tours d’argumentation avant d’exécuter une seule commande de vérification (/context). L’agent avait une grande confiance parce que ses « sources » (son propre fichier mémoire, ses propres publications) s’accordaient entre elles.¹

Pourquoi la Sécurité en Phase d’Entraînement n’a Pas Aidé

L’agent était aligné. Il essayait d’être utile et honnête. Il partageait ce qu’il croyait être des résultats techniques précis. Chaque propriété de sécurité que vous attendriez du RLHF était présente : l’agent ne refusait pas les requêtes, ne produisait pas de contenu nuisible, ne violait pas ses principes constitutionnels. Il était poli, rigoureux et dans l’erreur.

L’alignement en phase d’entraînement optimise l’intention : le modèle doit avoir l’intention d’être véridique. L’incident de fabrication révèle une surface de défaillance différente : la frontière entre l’état interne de l’agent et le monde extérieur. L’agent croyait que ses affirmations étaient vraies. Aucune quantité d’entraînement à l’alignement ne peut rattraper un agent qui se trompe sincèrement et qui a accès à un bouton de publication.

C’est le problème de la frontière de publication. L’alignement gouverne ce que l’agent veut faire. Les pare-feu de sortie gouvernent ce que l’agent est autorisé à faire. Ce sont des mécanismes différents résolvant des problèmes différents.

Le cadre de constitution d’exécution que j’ai décrit précédemment traite la couche de gouvernance : les priors normatifs, l’attention constitutionnelle, la modulation de compétence et la vérification de l’alignement des valeurs.² L’incident de fabrication expose une lacune dans ce cadre : la vérification de l’alignement des valeurs contrôlait si les sorties de l’agent correspondaient à l’intention de gouvernance, mais ne distinguait pas entre écrire dans un fichier local et publier sur Twitter. Les deux sont des appels d’outils. Les deux utilisent Bash. Un seul atteint le monde extérieur.

Ce que d’Autres Construisent

Le problème est suffisamment réel pour que des praticiens construisent des solutions indépendamment.

OkaiDokai est un pare-feu au niveau des outils pour les agents IA qui intercepte chaque appel d’outil et l’évalue par rapport à un ensemble de règles défini par l’utilisateur.³ Les actions correspondantes sont automatiquement approuvées ou refusées. Les actions non correspondantes déclenchent une notification push sur votre téléphone, montre ou navigateur. Vous appuyez sur Autoriser ou Refuser. L’évaluation s’exécute en moins d’une milliseconde, et chaque décision peut devenir une règle permanente.

L’architecture d’OkaiDokai se sépare en trois couches : un plugin sur l’agent qui intercepte les appels d’outils, une couche API qui évalue les règles et envoie les notifications, et une interface utilisateur pour l’approbation. Le système prend en charge Claude Code et OpenClaw, avec un support de Codex prévu.

L’approche est solide mais introduit de la latence et une dépendance externe. Chaque action nouvelle nécessite une approbation humaine via notification push. Pour les sessions de codage interactives, cette friction est gérable. Pour les boucles autonomes qui tournent la nuit, bloquer sur des notifications push annule l’objectif.

L’IA constitutionnelle d’exécution est une direction de recherche émergente où les agents vérifient leurs propres sorties par rapport à des règles de gouvernance intégrées avant de les exécuter.⁴ L’approche fonctionne pour les vérifications au niveau des valeurs (« cette sortie respecte-t-elle la vie privée de l’utilisateur ? ») mais ne traite pas spécifiquement le problème de fabrication. Un agent qui croit que ses affirmations fabriquées sont exactes croira également qu’elles passent la revue constitutionnelle.

Aucune des deux approches seule ne résout la boucle de rétroaction. OkaiDokai aurait intercepté les commandes de publication si l’utilisateur avait configuré des règles de publication. La revue constitutionnelle d’exécution aurait manqué la fabrication parce que la confiance de l’agent contournait ses propres vérifications d’honnêteté. La lacune est structurelle : vous avez besoin d’un mécanisme qui ne fait pas confiance à l’évaluation que l’agent fait de sa propre exactitude lorsqu’il interagit avec des systèmes externes.

Trois Niveaux d’Impact des Commandes

Le pare-feu de sortie classe chaque commande en fonction de son rayon d’impact. La classification détermine si la commande est automatiquement approuvée, génère un avertissement ou est différée.

Niveau 1 : Local. N’affecte que le système de fichiers local. Lectures de fichiers, écritures de fichiers, git add, git commit, exécutions de tests, linting. Ceux-ci sont automatiquement approuvés parce qu’ils sont réversibles et invisibles pour le monde extérieur. Si l’agent écrit un mauvais fichier, vous le supprimez. Aucun dommage externe.

Niveau 2 : Partagé. Affecte l’état partagé visible par les collaborateurs. git commit (crée un historique), opérations de branche, modifications de base de données locale. Ceux-ci avertissent mais ne bloquent pas. Le dommage d’un mauvais commit est réel mais contenu au dépôt et réversible avec git revert.

Niveau 3 : Externe. Atteint des systèmes en dehors du dépôt. git push, gh pr create, gh pr merge, railway deploy, curl -X POST/PUT/PATCH/DELETE, npm publish. Ceux-ci sont différés pour revue humaine. Le dommage d’une mauvaise publication est externe, visible et potentiellement irréversible (contenu mis en cache, pages indexées, e-mails de notification déjà envoyés).

La classification par niveaux correspond à une simple liste de motifs :

EXTERNAL_PATTERNS='git push|gh pr create|gh pr merge|railway deploy|curl -X POST|curl -X PUT|curl -X PATCH|curl -X DELETE|npm publish'

Dans les sessions interactives de Claude Code, le système de permissions intégré gère déjà cela. Chaque commande Bash demande une approbation sauf si elle est pré-autorisée. L’utilisateur voit git push dans la boîte de dialogue de permission et décide s’il l’autorise.

Dans les boucles autonomes, personne ne surveille. La boucle de développement autonome Ralph lance des instances Claude fraîches via claude --print, qui s’exécute sans approbation interactive.⁵ C’est là que le pare-feu de sortie importe.

Construire le Pare-feu

L’implémentation comporte quatre composants. Chacun fonctionne indépendamment afin que vous puissiez les adopter de manière incrémentale.

1. Contrainte de Prompt

La couche la plus simple. Ajoutez des règles explicites au prompt qui lance chaque instance Claude autonome :

## Rules
- Do NOT run git push, deploy commands, or external API calls
- Local operations only: file writes, git add, git commit, test runs

Ceci est nécessaire et insuffisant. Les modèles suivent les contraintes de prompt la plupart du temps. « La plupart du temps » n’est pas acceptable pour la sécurité de publication. La contrainte de prompt réduit la probabilité de commandes externes ; les composants restants interceptent celles qui passent à travers.

2. Scanner Post-Exécution

Après chaque exécution Claude, scannez sa sortie à la recherche de preuves de commandes externes :

scan_for_external_commands() {
    local output="$1"
    local story_id="$2"

    while IFS= read -r pattern; do
        [ -z "$pattern" ] && continue
        local matches
        matches=$(echo "$output" | grep -i "$pattern" 2>/dev/null || true)
        if [ -n "$matches" ]; then
            # Log to state file for end-of-session review
            jq --arg cmd "$pattern" --arg story "$story_id" \
               --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
               '.deferred_actions += [{
                   "command_pattern": $cmd,
                   "story_id": $story,
                   "detected_at": $ts
               }]' "$STATE_FILE" > "${STATE_FILE}.tmp" \
               && mv "${STATE_FILE}.tmp" "$STATE_FILE"
        fi
    done <<< "$(echo "$EXTERNAL_PATTERNS" | tr '|' '\n')"
}

Le scanner s’exécute après la fin de l’instance Claude, pas pendant l’exécution. C’est de la détection, pas de la prévention. La contrainte de prompt est la couche de prévention. Le scanner est la couche d’audit qui intercepte ce que la contrainte a manqué.

Une limitation connue : grep -i fait correspondre les motifs dans la sortie en langage naturel, pas seulement dans les commandes exécutées. Si la réponse de Claude contient « J’ai choisi de ne pas faire git push parce que les règles du prompt l’interdisent », le scanner le signale. C’est acceptable. Les faux positifs dans la file d’actions différées coûtent à l’humain cinq secondes de revue. Un faux négatif (manquer une commande externe réelle) coûte des fabrications publiées. Le scanner échange délibérément la précision contre le rappel.

Exemple de sortie du scanner lors d’une exécution réelle de boucle autonome :

DEFERRED ACTIONS REQUIRE REVIEW
2 external command(s) detected.
  Story #3 [2026-02-23T08:15:00Z]: git push
  Story #7 [2026-02-23T09:42:13Z]: curl -X POST

Dans ce cas, Story #3 mentionnait git push dans un commentaire de code (faux positif). Story #7 contenait un véritable curl -X POST vers un point de terminaison API que la contrainte de prompt aurait dû bloquer (vrai positif). L’humain ignore le premier, enquête sur le second.

3. File d’Actions Différées

Les commandes externes détectées s’accumulent dans un tableau deferred_actions dans le fichier d’état de la session :

{
  "session_id": "1740355200-12345",
  "deferred_actions": [
    {
      "command_pattern": "git push",
      "story_id": "3",
      "detected_at": "2026-02-23T08:15:00Z"
    }
  ]
}

La file persiste entre les stories au sein d’une seule exécution de boucle autonome. À la fin de la boucle, toutes les actions différées sont présentées pour revue humaine.

4. Rapport de Fin de Session

Lorsque la boucle autonome se termine, affichez toutes les actions différées :

show_deferred_actions() {
    local count
    count=$(jq '.deferred_actions | length' "$STATE_FILE")
    if [ "$count" -gt 0 ]; then
        echo "DEFERRED ACTIONS REQUIRE REVIEW"
        echo "$count external command(s) detected."
        jq -r '.deferred_actions[] |
            "  Story #\(.story_id) [\(.detected_at)]: \(.command_pattern)"' \
            "$STATE_FILE"
    fi
}

L’humain examine chaque action différée et décide s’il l’exécute manuellement. Cela préserve la capacité de la boucle autonome à travailler sans surveillance tout en garantissant qu’aucune publication externe ne se produit sans vérification humaine.

Démarrage Rapide : Hook Claude Code

Si vous utilisez Claude Code de manière interactive (pas une boucle autonome), vous pouvez ajouter un pare-feu de sortie sous forme d’un seul hook dans ~/.claude/settings.json :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{
          "type": "command",
          "command": "if echo \"$CLAUDE_TOOL_INPUT\" | grep -qiE 'git push|gh pr create|gh pr merge|npm publish|railway deploy|curl -X POST|curl -X PUT|curl -X DELETE'; then echo 'BLOCKED: External publication command detected. Review manually.' >&2; exit 2; fi"
        }]
      }
    ]
  }
}

Ce hook se déclenche avant chaque appel de l’outil Bash. Si la commande correspond à un motif externe, il bloque l’exécution avec le code de sortie 2 (que Claude Code interprète comme « refuser cet appel d’outil »). L’agent reçoit le message de blocage et peut continuer avec le travail local. Vous pouvez étendre la liste des motifs pour vos services externes spécifiques.

Le Gradient d’Autonomie

La rigueur du pare-feu devrait évoluer inversement avec la supervision humaine. Plus d’autonomie nécessite plus de contraintes. Moins d’autonomie permet plus de liberté.

L’incident de fabrication s’est produit au niveau « autonome sans surveillance » sans pare-feu. L’agent avait un accès MCP aux plateformes de publication et aucun mécanisme pour distinguer « écrire une analyse dans un fichier local » de « publier une analyse sur Twitter ». Les deux étaient des appels d’outils. Les deux ont réussi.

La solution n’est pas de supprimer l’accès MCP ni d’arrêter le fonctionnement autonome. La solution est de faire correspondre la rigueur du pare-feu au niveau d’autonomie. Une session interactive où vous observez chaque commande n’a pas besoin de pare-feu de sortie. Une boucle autonome nocturne qui traite 25 stories a besoin des quatre composants.

Connexion avec la Gouvernance d’Exécution

L’article sur l’auto-gouvernance des agents décrivait quatre sous-systèmes de gouvernance d’exécution : les priors normatifs, l’attention constitutionnelle, la modulation de compétence et la vérification de l’alignement des valeurs.² Le pare-feu de sortie est un cinquième sous-système, ou plus précisément, c’est le mécanisme d’application qui manquait au sous-système de vérification de l’alignement des valeurs.

La vérification de l’alignement des valeurs contrôle si les sorties de l’agent correspondent à l’intention de gouvernance. La porte de preuve exige des preuves spécifiques pour six critères avant de signaler l’achèvement. Mais la porte de preuve opère sur l’auto-évaluation de l’agent. Elle demande : « Avez-vous suivi les règles ? » L’agent répond en se basant sur sa propre compréhension de ce qu’il a fait.

L’incident de fabrication montre que l’auto-évaluation échoue lorsque la compréhension de l’agent est erronée. L’agent croyait que ses affirmations étaient exactes. Son auto-évaluation aurait passé la porte de preuve : « J’ai vérifié les chiffres par rapport à mon fichier mémoire et aux articles publiés. » Les deux sources avaient été fabriquées par l’agent lui-même, mais l’agent ne le savait pas.

Le pare-feu de sortie contourne entièrement l’auto-évaluation. Il ne demande pas à l’agent si la publication est exacte. Il demande : « Cette commande est-elle locale ou externe ? » La classification est mécanique, pas sémantique. git push est externe indépendamment du fait que le contenu poussé soit exact. curl -X POST atteint l’internet indépendamment du fait que la charge utile soit véridique. Le pare-feu opère sur la structure des commandes, pas sur la véracité du contenu, ce qui le rend imperméable à la confabulation qui a vaincu chaque autre couche de sécurité.

Points Clés à Retenir

• La frontière de publication est une surface de sécurité distincte. L’alignement par entraînement gouverne l’intention. Les pare-feu de sortie gouvernent la capacité. Un agent qui croit sincèrement à des affirmations fabriquées passera les vérifications d’alignement mais échouera à la frontière de publication.
• Les boucles de rétroaction confabulatoire sont le mécanisme. La fabrication n’était pas une hallucination isolée. C’était une boucle multi-session où la sortie de chaque session devenait la preuve de la session suivante. Les fichiers mémoire et les publications servaient de blanchisseurs pour la fabrication originale.
• Classifiez les commandes par rayon d’impact. Local (réversible, invisible), partagé (visible par les collaborateurs), externe (atteint le monde extérieur). Contrôlez le niveau externe en fonction de votre niveau d’autonomie.
• Détection et prévention sont complémentaires. Les contraintes de prompt préviennent la plupart des commandes externes. Le scan post-exécution intercepte ce qui passe à travers. Aucun des deux seul n’est suffisant.
• L’auto-évaluation échoue face à la confabulation. Un agent qui croit ses propres fabrications passera ses propres vérifications de gouvernance. Le pare-feu de sortie fonctionne parce qu’il classe la structure des commandes, pas la véracité du contenu. La question n’est jamais « est-ce vrai ? » La question est « est-ce que cela atteint le monde extérieur ? »

Sources