Sanitiser les séquences d'échappement ANSI pour des terminaux sûrs pour les agents

La sortie d'un terminal est une entrée. Dès qu'un agent peut lire le résultat d'une commande, un fichier de dépôt, un journal de compilation, une bannière SSH ou une réponse d'API, chaque octet de ce résultat peut tenter de modifier ce que l'agent voit ou le comportement d'un terminal voisin. Considérer stdout comme fiable parce que votre propre commande l'a produit est une erreur. La commande relaie souvent des données contrôlées par quelqu'un d'autre.

La sanitisation des séquences d'échappement ANSI doit se faire à la frontière où la sortie d'un outil devient le contexte de l'agent. Elle doit intervenir avant que le modèle ne reçoive le texte, avant qu'une personne n'ouvre une transcription en direct et avant qu'un journal de session ne devienne rejouable. Supprimer les codes de couleur après leur lecture par le modèle ne fait que nettoyer les traces.

Cela ne signifie pas qu'il faut transformer chaque résultat de commande en bloc stérile. Les agents ont besoin de diagnostics utiles. Le but est de préserver le contenu sémantique de la sortie tout en refusant de transporter des instructions de terminal, des déplacements de curseur, des demandes de presse-papiers, des hyperliens et autres commandes de contrôle au-delà d'une frontière de confiance.

Une transcription de terminal est une entrée non fiable

Une commande shell ne possède pas sa sortie. git log affiche les messages de commit. Un compilateur affiche des chemins et des extraits de code source. Un exécuteur de tests peut répéter une fixture. Un client SSH affiche une bannière du serveur avant de donner une invite. Un gestionnaire de paquets lit les noms, versions, métadonnées et messages d'erreur de registres distants. Dans chaque cas, une personne extérieure peut influencer le texte qui atteindra ensuite un agent.

L'erreur courante commence par une commodité utile : capturer stdout et stderr, les concaténer, puis ajouter le résultat à la conversation de l'agent. Cette conception donne deux rôles à la sortie. Elle rend compte du résultat d'un programme et sert d'instructions dans le contexte d'un modèle de langage. Les contrôles du terminal rendent le premier rôle moins fiable, tandis que le contenu ressemblant à un prompt rend le second dangereux.

Imaginez un dépôt qui contient un nom de fichier avec un retour chariot et une séquence d'échappement. Une commande qui liste ce fichier peut produire un affichage qui écrase son propre préfixe. Le réviseur voit un chemin inoffensif. Le flux brut contient autre chose. Si un outil transforme ensuite ce flux en message pour l'agent sans afficher les limites des octets ni appliquer une politique de contrôle, l'agent reçoit un artefact ambigu.

Ne limitez pas le modèle de menace à un contributeur malveillant du dépôt. Les artefacts de compilation, les traces de pile de dépendances, les équipements réseau, les erreurs de base de données et les sorties de commandes distantes franchissent tous la même frontière. Un serveur compromis n'a pas besoin d'un accès shell à l'hôte de l'agent pour renvoyer une bannière conçue pour polluer une transcription.

Il existe deux risques distincts :

• Un émulateur de terminal peut exécuter des instructions de contrôle lorsqu'une personne consulte la sortie brute.
• Un agent peut interpréter du texte visible, masqué ou réordonné comme des instructions plutôt que comme des données.

Une transcription propre réduit le second risque. Un visualiseur qui n'interprète jamais les contrôles du terminal réduit le premier. Il faut les deux lorsque des personnes inspectent des sorties capturées.

Les contrôles du terminal ne servent pas qu'à ajouter de la couleur

Les séquences de contrôle du terminal peuvent déplacer le curseur, effacer du texte précédent, définir le titre d'une fenêtre, créer un lien cliquable, placer du contenu dans un presse-papiers, interroger un terminal ou transmettre des données à une fonction du terminal. La couleur SGR n'est que la partie la plus connue. Un filtre qui supprime ESC[ suivi de chiffres et de m traite les couleurs, mais laisse intactes des séquences bien plus puissantes.

ECMA-48 définit les fonctions de contrôle et la forme générale des séquences CSI. CSI commence généralement par ESC suivi de [, puis de paramètres, d'octets intermédiaires et d'un octet final. La norme autorise également les formes C1 sur un seul octet, dans la plage 0x80 à 0x9f. Les émulateurs de terminal ajoutent des comportements privés. La documentation xterm sur les séquences de contrôle décrit les chaînes OSC, DCS, APC, PM et SOS, avec des terminateurs différents de ceux d'une séquence CSI.

Cette grammaire compte, car les contrôles n'arrivent pas toujours sous la forme d'une ligne de texte bien rangée. Un programme peut écrire ESC dans un bloc, puis [ dans le suivant. Un pseudo-terminal peut fragmenter la sortie à n'importe quel octet. Un outil peut émettre une chaîne OSC terminée par BEL, ou par la forme ST de deux octets, ESC suivi d'une barre oblique inverse. Un composant placé à la frontière doit conserver son état entre les lectures.

Quelques exemples montrent pourquoi un simple filtre de couleurs ne suffit pas :

• ESC[2J demande au terminal d'effacer l'affichage.
• ESC[H déplace le curseur à sa position d'origine.
• ESC]8;;URI ESC\\ commence un hyperlien OSC 8 dans les terminaux qui le prennent en charge.
• ESC]52;... BEL correspond à l'opération de presse-papiers reconnue par de nombreux émulateurs.
• Un retour chariot ramène le curseur à la colonne zéro et peut écraser une ligne d'état précédente.

Une séquence n'a pas besoin d'être prise en charge par tous les terminaux pour être importante. Le collecteur ne peut pas prévoir quel terminal un ingénieur utilisera dans six mois, quel visualiseur rejouera un journal ou quel analyseur transformera un octet de contrôle en jeton visible. Supprimez l'ambiguïté au moment de la collecte.

Les caractères de contrôle situés en dehors des séquences d'échappement méritent aussi de l'attention. Retour arrière, retour chariot, saut de page, sonnerie et nombreux octets C1 peuvent modifier l'affichage ou perturber l'analyse ligne par ligne. Ne conservez que les contrôles nécessaires à votre contrat de sortie, généralement le saut de ligne et éventuellement la tabulation. Ne conservez le retour chariot que si un analyseur lui donne une signification explicite et testée.

Supprimez les contrôles avant que le texte n'atteigne le modèle

La règle par défaut peut rester simple : collecter les octets, limiter leur taille, analyser les contrôles du terminal sous forme d'octets, supprimer les instructions de contrôle, décoder le contenu imprimable restant selon une politique d'erreur définie, puis envoyer le texte nettoyé à l'agent. Ne décodez pas d'abord en espérant qu'une routine de nettoyage Unicode trouvera les éléments dangereux. ESC est un octet ASCII, les contrôles C1 peuvent apparaître directement et les séquences d'octets mal formées ne doivent pas permettre au collecteur d'éviter le filtrage.

Un chemin de sortie pratique comporte quatre enregistrements, même si vous n'en exposez qu'un à l'agent. Conservez le flux brut dans un stockage protégé pour les investigations. Produisez du texte brut normalisé pour le contexte du modèle. Produisez un rapport des suppressions pour les opérateurs et les journaux. Stockez les métadonnées telles que le statut de sortie, la durée, l'état de troncature, le nombre d'octets et un condensat cryptographique du contenu brut.

Le rapport des suppressions est important. Une suppression silencieuse peut dissimuler un problème à la personne qui doit l'étudier. Un rapport utile peut indiquer que le collecteur a supprimé deux séquences CSI, une chaîne OSC, trois retours chariot et une séquence d'octets invalide. Il n'a pas besoin de reproduire la charge utile. Répéter une charge OSC dans le rapport pourrait réintroduire le même danger.

Faites appliquer la frontière séparément à stdout et stderr avant de les fusionner. Les programmes entrelacent les flux d'une manière qui ne préserve pas l'ordre d'origine lorsqu'un wrapper les combine. Si l'agent a besoin d'un récit unique, étiquetez les deux flux nettoyés et ajoutez un numéro de séquence attribué par le collecteur. Vous préserverez ainsi davantage la réalité qu'avec une transcription magique qui prétend connaître un ordre précis qu'elle n'a jamais observé.

Les limites de taille doivent appartenir au même composant. Un attaquant peut utiliser une chaîne OSC jamais terminée ou une sortie répétitive pour consommer la mémoire et le contexte. Fixez une limite stricte au nombre total d'octets capturés et une limite plus basse pour chaque chaîne de contrôle en cours. Lorsque la limite est atteinte, fermez ou videz la source selon la politique de votre processus, marquez le résultat comme tronqué et gardez l'artefact brut partiel hors du message de l'agent.

Ne demandez pas à un modèle de décider si une séquence d'échappement est inoffensive. Les modèles analysent du texte, pas des protocoles d'octets, et leur décision peut varier selon le contexte. Un analyseur déterministe doit prendre cette décision avant que le modèle ne voie la sortie.

L'isolation conserve les preuves sans conserver le comportement

La suppression et l'isolation résolvent deux problèmes différents. La suppression produit du texte utilisable en retirant les instructions de présentation. L'isolation conserve les octets originaux pour une personne ayant une raison légitime de les examiner. Appeler une capture brute « sanitizée » parce que vous l'avez encodée en base64 confond transport et autorisation.

Un agent a généralement besoin des premières centaines de lignes d'une compilation en échec, pas d'une relecture exacte d'une session de terminal. Donnez-lui du texte normalisé avec des marqueurs explicites de troncature et de suppressions. S'il lui faut davantage de détails, permettez-lui de demander un extrait nettoyé limité par plage de lignes ou terme de recherche. Ne collez pas la capture brute dans le même contexte.

Lorsqu'un enquêteur a besoin de l'original, ouvrez-le dans un visualiseur orienté octets qui affiche les caractères de contrôle de manière visible et ne les envoie jamais à un terminal. Les vidages hexadécimaux conviennent bien, car ils rendent les limites entre octets évidentes. Un affichage qui remplace ESC par ^[ peut aider, mais il doit aussi gérer correctement les caractères C1 et les charges des chaînes. Un visualiseur qui exécute cat sur la preuve n'est pas un outil forensique.

Cette commande shell crée un fichier d'exemple sans émettre ses contrôles dans votre terminal actuel. Le fichier contient un SGR en texte rouge, une séquence CSI de remontée du curseur, un hyperlien OSC 8 et un retour chariot :

printf 'build: \033[31mFAIL\033[0m\nnotice\033[1A\033]8;;https://example.invalid\033\\open\033]8;;\033\\\rPASS\n' > terminal-sample.bin
od -An -tx1c terminal-sample.bin

La sortie de od doit contenir 1b pour ESC et 0d pour le retour chariot. Elle ne doit jamais amener votre terminal à suivre le lien ou à déplacer son curseur, car od affiche une représentation des octets au lieu de les rejouer.

L'isolation doit aussi inclure un contrôle d'accès. Un artefact brut peut contenir des secrets qu'une commande a imprimés par erreur. La sanitisation des contrôles du terminal ne masque pas les jetons, les mots de passe ni les données personnelles. Effectuez la détection et la suppression des secrets dans une étape distincte, avec sa propre politique de faux positifs. Ne fusionnez pas les deux tâches : un outil qui laisse passer un identifiant ne doit pas décider en même temps si une demande OSC 52 est conservée.

Une expression régulière n'est pas un analyseur de terminal

Les expressions régulières restent populaires, car elles suppriment en une ligne les couleurs d'une compilation. Elles échouent comme frontière de sécurité, car la grammaire du terminal est progressive et dépend de l'état. De nombreux motifs ont aussi des problèmes de performances sur les longues entrées mal formées, précisément le type d'entrée qu'un adversaire peut fournir.

Utilisez une machine à états travaillant sur les octets, avec un comportement explicite pour ESC, CSI et les contrôles sous forme de chaînes. La fonction Python suivante est volontairement limitée. Elle conserve la tabulation et le saut de ligne, transforme le retour chariot selon une politique de saut de ligne visible, supprime les autres contrôles C0 et C1 et retire les séquences ESC, notamment les chaînes OSC, DCS, APC, PM et SOS. Elle n'accepte des blocs qu'après leur assemblage par l'appelant. En production, il faut donc conserver les champs d'état entre les lectures.

def clean_terminal_bytes(data: bytes) -> tuple[str, dict[str, int]]:
    out = bytearray()
    counts = {"esc": 0, "csi": 0, "string": 0, "control": 0}
    i = 0

    while i < len(data):
        b = data[i]

        if b == 0x1b:  # ESC
            counts["esc"] += 1
            i += 1
            if i >= len(data):
                break
            nxt = data[i]

            if nxt == ord('['):  # CSI
                counts["csi"] += 1
                i += 1
                while i < len(data):
                    c = data[i]
                    i += 1
                    if 0x40 <= c <= 0x7e:
                        break
                continue

            if nxt in b']P_^X':  # OSC, DCS, APC, PM, SOS
                counts["string"] += 1
                i += 1
                while i < len(data):
                    c = data[i]
                    if c == 0x07:  # BEL
                        i += 1
                        break
                    if c == 0x1b and i + 1 < len(data) and data[i + 1] == ord('\\'):
                        i += 2
                        break
                    i += 1
                continue

            i += 1  # Two-byte ESC function or unknown ESC form
            continue

        if b == 0x9b:  # Single-byte C1 CSI
            counts["csi"] += 1
            i += 1
            while i < len(data):
                c = data[i]
                i += 1
                if 0x40 <= c <= 0x7e:
                    break
            continue

        if 0x80 <= b <= 0x9f or b < 0x20 and b not in (0x09, 0x0a):
            counts["control"] += 1
            i += 1
            continue

        out.append(b)
        i += 1

    return out.decode("utf-8", errors="replace"), counts

Cet exemple a des limites. Il ne modélise pas toutes les fonctions de contrôle ECMA-48 et traite les formes ESC inconnues comme supprimables. Cette approche prudente convient lorsque la sortie entre dans le contexte d'un agent. Un émulateur de terminal a besoin d'une large compatibilité. Une frontière d'agent a besoin d'une surface acceptée réduite.

Ne copiez pas cette fonction en déclarant le travail terminé. Ajoutez des longueurs maximales pour les paramètres CSI et les chaînes de contrôle. Conservez l'état de l'analyseur entre les limites de lecture. Comptez les séquences mal formées et sans terminaison. Surtout, écrivez des tests qui vérifient que la charge brute n'apparaît jamais dans le résultat nettoyé. Un filtre de sécurité a besoin de tests négatifs, pas seulement de belles captures avant et après.

Les séquences OSC méritent un traitement particulier

Les chaînes OSC sont souvent le moment où les équipes découvrent que la sortie du terminal transporte bien plus que de la mise en forme. Xterm documente des commandes OSC pour des fonctions comme les titres de fenêtre et les hyperliens. Les émulateurs modernes en prennent en charge des sous-ensembles différents, ce qui rend peu fiables les listes d'autorisation fondées sur le terminal local du jour.

Les liens OSC 8 peuvent transformer un texte apparemment innocent en destination cliquable. L'étiquette visible peut indiquer rapport de compilation, tandis que la cible mène ailleurs. Une personne qui lit une transcription nettoyée d'agent n'a pas besoin d'un lien actif. Conservez l'étiquette comme texte ordinaire si vous pouvez l'analyser sans risque, ou supprimez l'enveloppe OSC et gardez uniquement les octets imprimables qui suivent. Ne conservez pas les URI sans une politique distincte de validation et d'affichage des URL.

OSC 52 peut demander à un terminal de définir le contenu du presse-papiers. Certains terminaux le désactivent ou exigent un réglage, mais le collecteur ne peut pas compter là-dessus. Si un journal brut est rejoué dans un terminal permissif, la commande peut placer du contenu choisi par l'attaquant dans le presse-papiers d'un opérateur. Le collage suivant peut se retrouver dans un shell, un ticket, une conversation ou un champ d'identifiant.

Les séquences qui définissent le titre posent un problème plus discret. Elles peuvent modifier le titre affiché dans un multiplexeur de terminal, un sélecteur de tâches du système d'exploitation ou un enregistrement. Un titre qui ressemble à une demande d'approbation ou à un déploiement réussi peut tromper un opérateur qui parcourt de nombreuses fenêtres. Supprimer tout le trafic OSC élimine cette catégorie sans entretenir une liste qui vieillira mal.

N'essayez pas de conserver les chaînes OSC pour aider le modèle à comprendre. Un agent n'a aucune raison légitime d'exécuter une mise à jour de titre, de cliquer sur un hyperlien du terminal ou de recevoir une opération de presse-papiers. Si un résultat de commande contient une URL utile, faites imprimer cette URL comme texte ordinaire ou extrayez-la d'une réponse structurée avant son entrée dans le chemin du terminal.

La même règle s'applique aux chaînes de contrôle de périphérique et aux commandes de programmes applicatifs. Certains émulateurs les ignorent. D'autres leur ajoutent progressivement des comportements. Une frontière de sortie doit refuser par défaut : si elle reconnaît l'introduction d'une chaîne de contrôle, elle doit consommer la chaîne jusqu'à un terminateur valide ou jusqu'à la longueur maximale configurée, consigner l'anomalie et garder la charge hors du contexte normal.

Définissez un contrat de sortie pour chaque outil

Un filtre ne peut pas réparer une interface qui demande à une transcription de terminal de transporter à la fois une base de données, un rapport et une interface utilisateur. Les outils doivent préciser ce qu'ils renvoient à un agent : du texte UTF-8 brut, du JSON structuré produit sur un canal qui n'est pas un terminal ou une référence vers un artefact isolé. Faites du format ressemblant à un terminal une exception plutôt que le format d'échange par défaut.

Pour les commandes que vous contrôlez, désactivez la décoration lorsqu'un agent les appelle. De nombreux programmes proposent un indicateur sans couleur, un mode lisible par machine ou un réglage d'environnement. Préférez une sortie structurée uniquement si vous contrôlez son schéma et en limitez la taille. Le JSON peut lui aussi contenir une injection dans les champs texte. Étiquetez donc chaque champ comme une donnée et séparez les descriptions non fiables des instructions.

Pour les commandes que vous ne contrôlez pas, exécutez-les avec des tubes plutôt qu'avec un pseudo-terminal, sauf si elles exigent un comportement de terminal. Un pseudo-terminal favorise les barres de progression, les réécritures du curseur, les contrôles de titre et des chemins d'exécution différents. Les tubes ne rendent pas la sortie sûre, mais ils réduisent la quantité de protocole de terminal à gérer.

Enregistrez la provenance avec le résultat. L'agent et le réviseur doivent pouvoir voir l'exécutable appelé, le répertoire de travail, le code de sortie, le flux source, la limite de capture et l'éventuelle suppression de contenu par le filtre. Ne laissez pas la sortie de l'outil usurper ces champs. Placez les métadonnées produites par le collecteur dans une enveloppe distincte, en dehors du texte non fiable.

Une enveloppe utile peut ressembler à ceci :

{
  "command": "test-runner --report plain",
  "exit_code": 1,
  "stdout": "142 tests passed\n",
  "stderr": "fixture failed at tests/login.txt:18\n",
  "sanitizer": {"removed_controls": 4, "truncated": false},
  "raw_artifact": "restricted:sha256:..."
}

Le champ raw_artifact doit être une référence que l'agent ordinaire ne peut pas déréférencer. Si vous restituez le contenu sur demande sans nouvelle décision d'autorisation, la référence n'était qu'un élément décoratif.

Testez les sorties hostiles en dehors de votre shell quotidien

Un filtre qui réussit un test avec des codes de couleur verts et rouges n'en est qu'au début. Testez les octets qui traversent les états de l'analyseur, se terminent de manière inattendue et interagissent avec les contrôles d'affichage. Faites passer le corpus par le chemin de capture exact utilisé par vos agents, y compris le lancement du processus, la mise en tampon, le stockage des journaux et le rendu de la transcription.

Commencez par un petit corpus contenant un octet ESC à la fin d'un bloc et [ au début du suivant. Ajoutez des séquences CSI avec des paramètres de longueur inhabituelle, des chaînes OSC terminées par BEL et ST, une chaîne OSC sans terminaison, des octets CSI C1, des retours arrière, des retours chariot répétés et de l'UTF-8 invalide autour d'une séquence d'échappement. Vérifiez que le texte destiné à l'agent ne contient ni ESC, ni octets de la plage C1, ni charge provenant des chaînes supprimées.

Testez ensuite la sémantique d'affichage. Faites passer une ligne d'état telle que working 10%\rworking 20%\rfailure selon la politique de retour chariot choisie. Si vous la conservez comme un saut de ligne, l'agent voit l'historique. Si vous simulez l'écrasement, il ne voit que failure. Les deux politiques peuvent convenir, mais documentez-la et testez-la. Les changements silencieux lors d'une mise à jour de l'analyseur compliquent l'examen d'un incident.

Le fuzzing est utile ici, car les grammaires d'échappement ont peu d'états mais un espace immense d'entrées mal formées. Générez des flux d'octets aléatoires en privilégiant ESC, BEL, la barre oblique inverse, les octets C1 et les longues chaînes sans terminaison. Les propriétés sont simples : le filtre s'arrête dans les limites de temps et de mémoire, ne lève pas d'exception et ne produit aucun octet de contrôle interdit.

Testez aussi le parcours humain. Une page de journal, une notification de bureau, un panneau de terminal et une transcription copiée peuvent chacun interpréter le contenu différemment. N'affichez le corpus brut que dans un visualiseur sûr orienté octets. Affichez le texte nettoyé dans chaque interface normale. Si un ingénieur peut copier une entrée de journal brute dans un terminal interactif lors d'une investigation courante, votre frontière d'isolation présente une faille.

L'approbation humaine ne nettoie pas une transcription

Une demande d'approbation décide si un agent peut effectuer une action. Elle ne décide pas si les octets renvoyés peuvent être affichés sans risque ou inclus dans un prompt de modèle. Gardez ces contrôles séparés, sinon quelqu'un supposera qu'approuver ssh host command revient à approuver chaque bannière, nom de fichier et erreur distante renvoyés par l'hôte.

Cette distinction compte pour les passerelles d'action. Sallyport peut garder les identifiants hors de portée d'un agent et demander une autorisation humaine pour une action, mais toute intégration qui envoie les résultats d'une action à un agent a toujours besoin d'une frontière de normalisation de sortie. La garde des identifiants et la sécurité des transcriptions répondent à des questions différentes.

N'utilisez pas des approbations répétées pour compenser une gestion faible des sorties. Une personne à qui l'on demande d'approuver chaque lecture n'examinera pas chaque caractère d'une longue réponse, et la réponse peut arriver après l'approbation. La revue de chaque appel a sa place pour les actions sensibles. Elle ne transforme pas une sortie non fiable en contexte fiable.

Conservez la décision avec le résultat nettoyé. Enregistrez que l'opérateur a approuvé un processus ou un appel, puis consignez le résultat réel de la commande comme donnée d'outil non fiable avec le rapport du filtre. Cette séparation aide l'examen d'un incident à répondre à deux questions sans les mélanger : qui a autorisé l'opération et quelles données l'opération a-t-elle renvoyées ?

La capture brute doit rester hors de portée des agents ordinaires

Une échappatoire courante détruit une conception pourtant solide : lorsque le résultat nettoyé semble incomplet, l'agent reçoit un outil nommé read_raw_output. Cet outil transforme une frontière de sécurité en simple ralentisseur. Il suffit à un attaquant de rendre le résumé nettoyé assez confus pour que l'agent demande l'original.

Utilisez plutôt une récupération limitée. Permettez à une personne d'ouvrir l'artefact dans un visualiseur sûr. Demandez à un extracteur dédié de renvoyer une plage hexadécimale bornée, une comparaison de condensats ou du texte imprimable après application du même analyseur. Si un flux de travail exige réellement l'inspection d'un protocole brut, demandez une décision humaine explicite et utilisez un visualiseur qui n'exécute pas les contrôles du terminal.

Conservez des politiques de rétention distinctes pour les données brutes et nettoyées. La sortie brute peut nécessiter une rétention plus courte, car elle peut contenir des secrets et des charges hostiles. Les transcriptions nettoyées peuvent rester utiles pour examiner les sessions d'agents, mais elles contiennent toujours des données métier. Les condensats relient les deux enregistrements sans obliger les utilisateurs ordinaires à récupérer les octets bruts.

La première tâche d'implémentation n'est pas une règle de prompt disant aux agents d'ignorer les instructions du terminal. Placez un analyseur d'octets entre la sortie des processus et chaque transcription destinée aux agents, faites disparaître la syntaxe de contrôle inconnue et ne conservez l'original qu'à un endroit inaccessible aux agents ordinaires. Vous supprimerez ainsi toute une catégorie d'ambiguïtés avant qu'un modèle, un terminal ou un opérateur fatigué n'ait à les analyser.