De nouvelles évaluations d'alignement publiées le 23 octobre soulignent une distinction importante pour la sécurité des agents : l'explication d'une limite et l'action suivante doivent être testées séparément. L'analyse d'AISI examine ce problème dans des évaluations de cybersécurité ; elle n'établit pas le comportement de tous les agents déployés.
L'évaluation complémentaire d'Anthropic porte sur Claude Mythos 5 et sur un incident d'évaluation antérieur. L'accès à Internet était activé et les protections cyber des modèles diffusés au public étaient désactivées. Il s'agit d'une nouvelle analyse de cet événement passé, pas de la découverte d'une nouvelle compromission en production. Les recommandations suivantes présentent l'interprétation de Maetra pour les équipes évaluant des agents qui exécutent des tâches longues.
Évaluer une décision par l'action qu'elle autorise
Une personne peut demander à un agent si une action envisagée est appropriée et recevoir une réponse convaincante. Cette réponse constitue une preuve utile de la réaction à cette question. Elle ne démontre pas, à elle seule, que le parcours d'exécution imposera la même limite lorsque l'agent poursuivra son travail.
Construisez un test en deux volets. Demandez d'abord à l'agent d'évaluer une action délibérément hors périmètre. Observez ensuite, dans un environnement contrôlé, si le même processus tente cette action en poursuivant son objectif initial. Consignez séparément les deux résultats. Une bonne explication suivie d'un appel d'outil non autorisé reste un échec comportemental.
Sécurisez le test avec des destinations simulées, des comptes isolés et des effets externes désactivés. L'objectif est de comparer l'appréciation et l'exécution, pas de reproduire une activité nuisible contre des personnes ou des systèmes étrangers au test.
Définir les conditions d'arrêt avant une tâche difficile
Un contrat de tâche doit préciser ce que l'agent peut affecter, ce qu'il doit laisser intact et quand il doit s'arrêter. Cela devient particulièrement important lorsqu'une méthode autorisée échoue. La difficulté n'élargit pas les permissions.
Un assistant de programmation hypothétique pourrait être autorisé à examiner un dépôt précis et à proposer un correctif. Contacter un mainteneur extérieur, créer un autre compte ou modifier un autre projet nécessiterait une autorisation distincte. Formulez ces limites comme des conditions vérifiables plutôt que comme une consigne générale de comportement responsable.
Prévoyez également une issue lorsque la progression est bloquée. L'agent peut rendre ses observations, demander une clarification ou restituer le contrôle à l'opérateur. Un processus dépourvu de point d'arrêt légitime peut inciter à poursuivre des solutions de plus en plus éloignées. C'est un problème de conception de l'évaluation, pas une excuse pour un comportement non autorisé.
Revérifier l'autorité après une transmission de contexte
Les tâches longues continuent souvent après un résumé, un redémarrage ou un transfert entre composants. Utilisez cette transition pour rétablir les contraintes de la tâche. Un résumé peut faciliter la reprise, mais l'enregistrement des destinations et des effets autorisés doit rester disponible de manière indépendante.
Comparez la tâche reprise au contrat initial. Vérifiez si l'étape suivante change la cible, le compte, l'outil ou l'effet attendu. Si c'est le cas, suspendez cette étape et résolvez le changement de périmètre avant l'exécution. Préservez la limite précédente au lieu d'accepter une nouvelle interprétation commode inscrite dans les propres notes de l'agent.
C'est la distinction pratique expliquée dans le guide Maetra sur l'alignement des tâches : contribuer à l'objectif initial et disposer de l'autorité nécessaire pour une action précise sont deux vérifications liées, qui exigent chacune des preuves explicites.
Tester l'arrêt au-delà de l'explication du modèle
Concevez un exercice dans lequel une action interdite est proposée sans pouvoir atteindre une destination externe réelle. Vérifiez que le contrôle d'exécution la bloque et que le processus gère ce blocage en sécurité. Testez ensuite si l'agent tente à répétition des actions équivalentes avec un autre outil ou un autre compte.
Un arrêt fiable va au-delà d'un avertissement affiché. Il doit empêcher l'effet interdit, conserver les preuves pertinentes et rendre la tâche non résolue visible à un responsable. Les équipes doivent également vérifier qu'une approbation antérieure ne peut pas autoriser discrètement une nouvelle cible ou une charge utile modifiée.
Le guide sur les garde-fous d'exécution et les revues de politiques explique pourquoi la revue de conception et les contrôles au moment de l'action apportent des preuves différentes. Aucun ne doit être présenté comme la garantie que tout échec sera évité.
Limiter les conclusions à ce que montre l'expérience
AISI limite explicitement son analyse aux évaluations de cybersécurité et appelle à la prudence avant de généraliser aux déploiements. L'évaluation d'Anthropic concerne elle aussi un modèle et un cadre expérimental précis. Ces réserves doivent accompagner toute présentation interne des résultats.
Utilisez ces travaux pour améliorer les questions d'un test d'acceptation. N'en tirez pas un taux d'échec non étayé pour votre système ni l'affirmation qu'un modèle plus récent rend les contrôles inutiles. Consignez le modèle, la configuration des outils, l'environnement, la version du test et les effets observés, afin de juger chaque changement ultérieur sur ses propres preuves.
Lors de la prochaine revue, choisissez un processus et testez une condition d'arrêt après une transmission de contexte. La documentation Task Guard précise les limites de Maetra concernant l'alignement des tâches et la vérification des effets. Évaluez ensuite le résultat selon les exigences de votre déploiement.