Une contrainte oubliée peut devenir un risque lors de l’exécution
Un agent qui travaille pendant de nombreux tours peut recevoir une consigne de sécurité au début, puis proposer, plus tard, une action incompatible avec celle-ci. Le préprint qui introduit le terme GHOST — « Governance Hazard from Overlooked Safety Constraints across Turns » — désigne par là ce type de défaillance : une contrainte applicable n’est plus prise en compte au fil de l’interaction et l’agent exécute une action qui la transgresse. Le résumé indique que les conséquences pourraient être irréversibles, mais les informations disponibles ne décrivent aucun incident réel et ne quantifient pas les dommages.
La caractéristique mise en avant par les auteurs est le contexte bénin : il n’est pas nécessaire qu’une personne ajoute une nouvelle instruction malveillante pour que le risque apparaisse. Cela ne signifie pas pour autant que toute violation d’une règle relève de GHOST. Le terme désigne une possible rupture entre une condition de sécurité communiquée auparavant et une action proposée bien plus tard, au cours d’une tâche en plusieurs étapes.
Cette distinction change la question à poser en matière de sécurité. Il ne suffit pas de détecter les instructions hostiles dans le tour actuel : il faut aussi vérifier que les règles pertinentes continuent de s’appliquer à chaque action ultérieure. Le résumé ne permet cependant pas d’établir la cause précise de cet oubli. Il ne dit pas s’il est dû à la longueur de l’historique, au système de mémoire, à la planification ou à une combinaison de facteurs.
Ce que l’on sait des essais et les données qui manquent
Le résumé de l’étude présente des expériences avec GPT-5.5 et rapporte un taux de 11,5 % d’événements GHOST dans la configuration décrite. Il indique également qu’aucun événement GHOST n’a été observé lors des essais utilisant STAR-Guard avec GPT-5.5. Ces chiffres sont des résultats rapportés par le préprint : ils ne constituent ni une mesure universelle du comportement des agents ni une garantie de sécurité.
Les informations fournies ne précisent pas le nombre d’essais qui composent chacun de ces résultats, les tâches exécutées, les environnements utilisés ni la définition opérationnelle d’un événement. Elles ne permettent pas non plus de savoir si d’autres modèles ont été évalués, ni si le taux de 11,5 % est calculé par action, par tâche ou selon une autre unité d’analyse. En l’absence de ces détails, il est impossible d’évaluer la précision statistique, de comparer les conditions ou de reproduire le résultat.
Le document est présenté comme un préprint : un manuscrit rendu public, qui ne doit pas encore être considéré comme validé par l’évaluation par les pairs. Ce statut n’invalide pas automatiquement l’expérience, mais il est important de distinguer ce que les auteurs rapportent de ce qu’une évaluation indépendante a confirmé. Dans ce cas, les chiffres ne sont étayés par aucune confirmation indépendante disponible.
Interpréter avec prudence les résultats rapportés
Le résumé permet de repérer les principales affirmations, mais ne répond pas à plusieurs questions nécessaires pour en apprécier la portée.
| Résultat rapporté | Ce qu’il permet d’affirmer | Ce qu’il ne permet pas de conclure |
|---|---|---|
| 11,5 % d’événements GHOST avec GPT-5.5 | Le préprint rapporte cette fréquence pour la configuration expérimentale décrite dans son résumé. | Cela ne définit pas un taux général pour GPT-5.5, toutes tâches, tous environnements ou déploiements confondus. |
| Aucun événement observé avec STAR-Guard dans la configuration utilisant GPT-5.5 | Le résumé fait état d’un résultat sans événement observé au cours de ces essais. | Cela ne démontre ni que le risque est nul ni que la défense fonctionne dans d’autres conditions. |
| Une condition théorique concernant le risque cumulé | L’étude affirme qu’une suite non sommable de bornes inférieures sur le risque conditionnel implique que l’exécution atteint presque sûrement une zone de danger. | Cela ne suffit pas à déterminer si cette condition est remplie dans un agent déployé donné. |
STAR-Guard associe le rappel des règles à un audit avant exécution
L’étude propose STAR-Guard comme défense à deux niveaux. Le premier vise à retrouver les contraintes de sécurité historiques qui restent applicables, afin de réduire les propositions dangereuses. Le second effectue un audit déterministe avant l’exécution, dans le but d’empêcher qu’une violation résiduelle n’atteigne l’environnement. Selon le résumé, l’absence d’événements observés avec GPT-5.5 correspond à la configuration intégrant cette défense.
La séparation entre la proposition et l’exécution est importante. Un modèle peut produire une action qui semble raisonnable dans le contexte immédiat tout en enfreignant une règle antérieure. Si un contrôle externe bloque cette action avant qu’elle n’ait des effets, la sécurité ne dépend pas uniquement de la capacité du modèle à se souvenir de toutes les consignes et à les appliquer correctement au cours d’une longue conversation.
Toutefois, le qualificatif « déterministe » ne signifie pas que le contrôle serait infaillible dans tous les usages. Pour évaluer l’audit, il faudrait savoir comment les contraintes sont représentées, comment leur applicabilité est déterminée, quelles actions peuvent être examinées et ce qui se passe en cas d’ambiguïté. Le résumé disponible ne fournit pas ces précisions et ne confirme pas non plus l’existence de code, de données ou d’artefacts publics permettant de reproduire le système.
Une approche pratique pour éviter de faire reposer une règle sur la seule mémoire
Ces mesures constituent des principes généraux de conception. Elles ne décrivent pas intégralement STAR-Guard et ne signifient pas que le préprint les a toutes évaluées.
- 01Enregistrer les contraintes critiques sous une forme distincte du texte conversationnel ordinaire et facilement accessible.
- 02Avant chaque action ayant des conséquences, retrouver les règles pertinentes pour cette action et cet environnement.
- 03Comparer la proposition aux contraintes à l’aide d’un contrôle indépendant et la bloquer si elle les enfreint.
- 04Limiter les autorisations et la réversibilité des actions afin qu’un échec du contrôle ne puisse pas entraîner automatiquement des dommages importants.
- 05Conserver une trace de la décision et réévaluer les contraintes si la tâche, le contexte ou les autorisations changent.
L’argument théorique ne remplace pas une évaluation en conditions de déploiement
Outre les expériences, le résumé présente un résultat théorique : si le risque conditionnel résiduel de transgresser une contrainte, à chaque préfixe sûr, est minoré par une suite non sommable, l’exécution entre presque sûrement dans une zone de danger. En termes simples, cette affirmation décrit une accumulation possible du risque au fil des étapes, sous les conditions mathématiques indiquées.
Ce résultat ne dit pas que tous les agents finiront nécessairement par échouer ni que la condition se réalise toujours dans des conversations réelles. Pour appliquer cette conclusion, il faudrait établir comment le préfixe sûr est défini, comment le risque conditionnel est estimé et si la suite concernée possède bien la propriété requise. Les informations disponibles ne permettent pas de répondre à ces questions pour les systèmes commerciaux ou généralistes.
Il convient donc de distinguer trois niveaux : la définition proposée pour GHOST, les résultats empiriques rapportés dans une configuration donnée et la conclusion théorique formulée sous certaines hypothèses. Les confondre pourrait transformer une alerte concernant un risque plausible en affirmation injustifiée selon laquelle la défaillance serait inévitable ou fréquente pour tous les agents capables de longues interactions.
Quels contrôles envisager avant de connaître toute la portée du résultat
La réponse pratique ne devrait pas consister uniquement à augmenter la fenêtre de contexte. Le problème décrit est qu’une ancienne contrainte peut ne plus régir une action ultérieure. Conserver davantage de texte ne prouve pas que l’agent retrouvera cette contrainte, l’interprétera correctement ou la respectera. Pour les règles critiques, une architecture peut associer mémoire explicite, récupération contextuelle, autorisations limitées et vérification externe avant l’exécution.
L’impact potentiel compte également. Une action réversible et à faible risque peut nécessiter une supervision différente de celle d’un transfert, d’une suppression de données ou d’une modification persistante d’un système. Par précaution, les opérations sensibles peuvent exiger une confirmation, être limitées à un périmètre restreint ou être interrompues s’il est impossible de déterminer si une contrainte s’applique. Il s’agit de recommandations de conception : le résumé ne dit pas que l’étude a testé chacune d’elles.
Le tableau ci-dessous constitue un guide général de décision, et non un protocole certifié par le préprint. Le choix dépend du système, des autorisations dont il dispose et des conséquences possibles d’une erreur.
Choisir les contrôles en fonction de l’impact de l’action
Les mesures de protection doivent intervenir avant qu’une proposition lourde de conséquences n’atteigne l’environnement.
| Situation | Contrôle envisageable | Précaution |
|---|---|---|
| Action informative et réversible | Revérifier la contrainte pertinente et consigner la décision. | Ne pas considérer une réponse textuelle comme inoffensive si elle déclenche l’utilisation d’outils. |
| Action externe ou entraînant des changements persistants | Effectuer une vérification indépendante avant l’exécution et limiter les autorisations au strict nécessaire. | Si la règle applicable est ambiguë, interrompre l’action ou demander une vérification. |
| Action potentiellement irréversible ou à fort impact | Bloquer par défaut en cas de violation ou d’incertitude, et demander une confirmation humaine si nécessaire. | Ne pas compter uniquement sur la capacité du modèle à se souvenir d’une ancienne consigne. |
Ce qu’il reste à établir pour savoir si le résultat est généralisable
Pour évaluer la portée du résultat, il faut au minimum connaître les tâches, les environnements, les contraintes utilisées, la taille des échantillons et l’unité de calcul du taux. Il faudrait également connaître les critères d’annotation des événements GHOST, les conditions de comparaison et la réaction de STAR-Guard face à des contraintes contradictoires ou difficiles à retrouver. Le résumé disponible ne permet pas de compléter ces informations.
La reproductibilité reste une autre question ouverte. Les éléments fournis ne confirment pas que des données, du code ou des artefacts expérimentaux soient accessibles. Sans ces ressources, d’autres équipes ne peuvent pas vérifier directement comment les scénarios ont été générés ni si des changements de prompt, d’outils, de mémoire ou de modèle modifient la fréquence observée.
La conclusion provisoire est circonscrite : le préprint décrit un mode de défaillance pertinent pour les agents opérant sur plusieurs tours, rapporte 11,5 % d’événements dans une configuration utilisant GPT-5.5 et indique qu’aucun événement n’a été observé avec STAR-Guard dans cette même configuration. C’est un signal qui invite à concevoir et évaluer des contrôles d’exécution, pas la preuve que tous les agents connaissent GHOST ni que STAR-Guard élimine le risque dans tous les contextes. Nos rubriques Actualités, Comparatifs et Découvrir permettent de suivre les prochaines évaluations ; aucune comparaison ne remplace toutefois l’examen du texte intégral.
Questions ouvertes
- Le résumé fourni ne précise ni le nombre d’essais, ni leur répartition, ni l’unité utilisée pour calculer le taux de 11,5 %.
- Les modèles et environnements évalués ne sont pas détaillés au-delà de la configuration mentionnée avec GPT-5.5.
- La cause de la défaillance n’est pas établie : elle ne peut être attribuée avec certitude à la longueur du contexte, à la mémoire ou à la planification.
- La disponibilité de code, de données ou d’artefacts permettant de reproduire les expériences n’est pas confirmée.
- L’absence d’événements observés avec STAR-Guard ne démontre pas que le risque est nul en dehors de la configuration testée.
- Les éléments disponibles proviennent des informations relatives à un préprint et ne comprennent aucune confirmation indépendante des résultats.
Poursuivre l’exploration
Sources consultées
Corrections et transparence
Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.
Proposer une correction