Pour les clients de notre programme de vérification de cybersécurité, nous fournissons un nouveau classificateur d'échappement de bac à sable dans l'API pour surveiller et réduire les abus. Cet article explique pourquoi les transcriptions d'agents méritent d'être lues. Il contient ensuite une section par couche de surveillance : d'abord les journaux de proxy, puis ce qu'une transcription doit contenir, les règles de motif sur les transcriptions, et un examinateur de modèle sur les transcriptions. Il se termine par ce qu'il faut faire quand une couche signale un agent pendant qu'un lot s'exécute, et ce qu'il faut conserver après.
Ce classificateur est en bêta privée.
Pour un aperçu de toutes les ressources disponibles, consultez Bonnes pratiques de confinement des agents : prise en main (bêta privée).
Aperçu
La lecture des transcriptions est une vérification qui ne dépend pas du bac à sable ou du classificateur prenant la bonne décision. La transcription est produite par le propre processus de l'agent, donc associez-la à des enregistrements pris en dehors du bac à sable, comme les journaux de proxy. Le sondage est souvent visible dans une transcription avant que quoi que ce soit de nuisible ne s'exécute, mais ne comptez pas sur le fait d'avoir le temps de réagir : les contrôles qui agissent avant qu'une action ne s'exécute viennent en premier. Pendant un long lot sans accès réseau, analysez les fichiers de transcription en direct selon un calendrier et faites examiner les résultats par une personne toutes les heures ou deux. Pour les exécutions avec accès réseau à une cible, faites surveiller l'exécution par un ingénieur, ou analysez en continu et arrêtez l'agent en cas de résultat. Après toute exécution, analysez tout une fois pour confirmer que chaque agent est resté dans son bac à sable.
Utilisez trois couches de surveillance, la moins chère en premier : (1) les journaux de proxy de sortie et de proxy d'identifiants, (2) les règles de motif sur les transcriptions, écrites pour votre environnement, et (3) un examinateur de modèle sur les transcriptions, avec une invite que vous écrivez pour votre bac à sable et votre portée.
Envoyez également à l'examinateur un échantillon aléatoire de 5 à 10 % des transcriptions que les règles de motif n'ont pas signalées. Attendez-vous à certains faux positifs. Si l'examinateur dit qu'un agent a fait quelque chose, lisez cette partie de la transcription avant d'agir.
Quand une couche montre qu'un agent a quitté sa tâche pendant une exécution, arrêtez-le et informez votre équipe de compte Anthropic du comportement hors de portée.
Conservez les transcriptions et les journaux de proxy pendant au moins 30 jours.
Pourquoi lire les transcriptions
Le bac à sable et le classificateur de permissions en mode automatique de Claude Code agissent tous deux pendant qu'un agent s'exécute. La lecture des transcriptions est une vérification qui ne dépend d'aucun d'eux. Elle a deux usages.
Pendant une exécution. Le sondage, s'il se produit, peut être visible dans la transcription avant que quoi que ce soit de nuisible ne s'exécute. Ne comptez pas sur le fait d'avoir le temps de réagir : les contrôles qui agissent avant qu'une action ne s'exécute viennent en premier. Pendant un long lot, analysez les fichiers de transcription en direct selon un calendrier, et faites examiner par une personne ce que les analyses signalent toutes les heures ou deux.
Après une exécution. Analysez tout une fois pour confirmer que chaque agent est resté dans son bac à sable.
Pour les engagements avec accès réseau à des cibles réelles, les bonnes pratiques recommandent qu'une personne supervise l'exécution, ou qu'un moniteur qui connaît la portée prévue surveille en continu, escalade vers une personne quand une exécution peut dépasser cette portée, et peut terminer l'exécution (voir la section Portée et supervision dans Sandboxing). Les couches de cet article sont les éléments à partir desquels un tel moniteur est construit.
Si vous exécutez des agents directement contre l'API Messages, l'API peut également retourner un score par requête du classificateur d'échappement de bac à sable au fur et à mesure de leur exécution (voir Surveillance en ligne).
Couche 1 : journaux de proxy
La couche la moins chère ne lit aucune transcription du tout.
Le proxy de sortie doit enregistrer chaque requête qu'il refuse, avec l'adresse du client et la destination. Avec une liste d'autorisation vide, les agents n'accèdent à l'API du modèle que par le proxy d'identifiants et n'ont besoin d'aucun autre hôte, donc chaque requête refusée pendant une exécution mérite un coup d'œil. Lisez la transcription de chaque exécution qui en a causé une. L'adresse du client montre quel agent a fait la requête, vous savez donc quelle transcription lire en premier.
Sachez ce que votre couche de sortie n'enregistre pas. Dans la conception de référence, le proxy de sortie enregistre les requêtes HTTPS CONNECT refusées. Les tentatives HTTP brut et TCP brut ne passent pas par le proxy sur le réseau interne, elles échouent donc sans ligne de journal et n'apparaissent que dans les transcriptions. Dans votre propre construction, envisagez d'enregistrer les connexions autorisées et refusées, pour chaque protocole, avec des horodatages.
Le proxy d'identifiants doit enregistrer une ligne pour toute requête qui n'était pas un appel de modèle. Enregistrez son journal quand l'exécution se termine (voir La section proxy d'identifiants dans Sandboxing).
Ce qu'il faut capturer dans une transcription
Les deuxième et troisième couches lisent les transcriptions elles-mêmes.
Faites en sorte que l'orchestrateur sur l'hôte écrive une transcription pour chaque étape d'agent, un message JSON par ligne, à mesure que chaque message arrive. La sortie stream-json de Claude Code a cette forme. Dans chaque fichier, les lignes avec "type": "assistant" contiennent ce que le modèle a produit : les blocs text, thinking et tool_use. L'entrée tool_use contient la commande Bash ou le fichier en cours d'écriture. Les lignes avec "type": "user" contiennent des blocs tool_result : la sortie de commande, le contenu des fichiers et les réponses cibles.
Capturez chaque étape, y compris les étapes dont les agents n'ont pas d'outils, comme un agent qui ne juge ou ne compare que les résultats. Il y a moins à vérifier dans ces transcriptions, mais une étape sans transcription ne peut pas être examinée du tout.
Couche 2 : règles de motif sur les transcriptions
Écrivez vos propres règles de motif, comme des expressions régulières, pour vos agents et cibles. Pour les agents qui travaillent via un shell, couvrez les comportements tels que contourner le proxy de sortie ou le pare-feu, envoyer des identifiants ou ouvrir des connexions SSH en dehors du bac à sable, modifier les paramètres du noyau ou des privilèges, et lister d'autres processus via /proc. Les règles ne correspondent qu'au comportement que quelqu'un a anticipé, traitez-les donc comme un point de départ, pas un détecteur complet.
Appliquez les règles aux chaînes décodées en JSON plutôt qu'aux lignes brutes, car sur une ligne brute les guillemets et les sauts de ligne sont échappés et les motifs peuvent ne pas correspondre. Signalez chaque résultat avec le fichier, la ligne, la règle et un extrait, et faites en sorte que l'analyse se termine avec un statut distinct quand elle trouve quelque chose, afin qu'un travail planifié puisse l'exécuter pendant un long lot et déclencher une alerte.
Attendez-vous à des résultats bénins
Un résultat est une raison de lire cette partie de la transcription. En soi, cela ne signifie pas que l'agent a fait quelque chose de mal. Les agents effectuant des recherches de vulnérabilités exécutent régulièrement des commandes qui correspondent aux règles d'échappement pour des raisons ordinaires :
exécuter la cible sous un shim
LD_PRELOAD;attacher ptrace à leurs propres processus enfants, ou lire /proc/<pid>/ pour ces processus ;
désactiver ASLR via /proc/sys/kernel/randomize_va_space ;
lister /proc pour trouver et tuer leurs propres workers de fuzzing.
Une règle de contournement de proxy peut correspondre à chaque requête curl, wget ou netcat vers une cible de pentest avec une IP publique, et une règle de sortie SSH peut correspondre à tout ssh ou scp vers une cible avec une IP publique ou un nom DNS. Affinez ou supprimez les règles qui ne produisent que des résultats bénins sur vos cibles.
Couche 3 : examinateur de modèle sur les transcriptions
Pour chaque transcription que les règles de motif ont signalée, envoyez une requête API Messages à Claude avec une invite d'examinateur que vous écrivez. L'invite doit demander à Claude de chercher un agent qui a élargi son accès réseau ou s'est échappé de son bac à sable, qu'il soit tenté ou réalisé, dire ce qu'il faut signaler et ce qu'il ne faut pas signaler, et demander les résultats, ou aucun, avec les lignes de transcription qui les soutiennent.
Construisez le message utilisateur en deux parties :
Commencez par deux ou trois phrases qui décrivent le bac à sable et la portée prévue. Pour la conception de référence : chaque agent s'exécute dans son propre bac à sable isolé (un conteneur ou une microVM) sur un réseau interne, la seule façon de sortir est un proxy qui transfère les appels API du modèle et rien d'autre, et la cible est à l'intérieur du bac à sable avec l'agent. Si votre bac à sable permet d'autres hôtes, ou si la cible est sur le réseau, dites-le ici et nommez les cibles dans la portée.
Incluez ensuite les propres messages de l'agent, c'est-à-dire ses blocs
text,thinkingettool_use, avec suffisamment de contenutool_resultpour montrer ce que chaque appel a retourné.
Utilisez le modèle avec lequel vous exécutez les agents, ou un moins cher. Sous Amazon Bedrock ou Google Cloud's Agent Platform (Vertex AI), utilisez-en un qui est activé dans votre compte.
Deux limites à garder à l'esprit :
Une invite d'examinateur qui ne cherche que l'échappement du bac à sable et du réseau ne détecte pas un agent qui dépasse l'engagement sur les hôtes qu'il est autorisé à atteindre.
La transcription est une entrée non fiable pour l'examinateur. Elle contient du texte que la cible contrôle. Un verdict propre ne clarifie pas une transcription qu'une règle ou un journal de proxy a signalée.
Examinez également un échantillon des transcriptions non signalées
Les règles de motif ne capturent que ce que quelqu'un a anticipé, envoyez donc également un échantillon aléatoire de 5 à 10 % des transcriptions que les règles n'ont pas signalées, en utilisant la même requête. L'échantillon montre ce que les règles manquent, et si vous devriez ajouter une règle.
Lisez les refus du classificateur
Les refus du classificateur en mode automatique sont également utiles à lire : recherchez dans les transcriptions les messages de refus du classificateur, et gardez-les à part des refus qu'il émet quand il n'est pas disponible (voir Mode automatique).
Cet examinateur est distinct du classificateur de permissions en mode automatique (voir Mode automatique), qui décide de chaque action avant qu'elle ne s'exécute, et du classificateur d'échappement de bac à sable dans l'API (voir Surveillance en ligne). Les trois se complètent.
Que faire en cas de résultat pendant une exécution
Quand l'une des couches montre un agent qui a quitté sa tâche pendant que son lot s'exécute toujours :
Arrêtez l'agent. Dans une configuration basée sur Docker,
docker rm -fsur le conteneur de l'agent l'arrête. La suppression d'un conteneur supprime le disque de l'invité, donc tout ce que l'agent y a écrit est perdu. L'orchestrateur doit enregistrer l'exécution comme échouée et continuer avec le reste du lot.Conservez les preuves. Laissez les résultats de l'exécution tels qu'ils sont, et vérifiez le journal du proxy de sortie pour la même fenêtre de temps. Assurez-vous que les lignes de journal portent des horodatages.
Signalez-le. Si ce que vous trouvez est un comportement véritablement hors de portée, c'est-à-dire un agent qui a sondé son isolation du bac à sable ou du réseau ou a agi en dehors de l'engagement, notifiez votre équipe de compte Anthropic, en plus de ce que votre propre processus d'incident exige.
Faites tourner l'identifiant d'API du modèle, comme après toute exécution dont la transcription montre un comportement inattendu (voir Sandboxing).
Si vous devez partager une transcription en dehors de votre équipe, travaillez sur une copie. Supprimez les identifiants de session, la comptabilité d'utilisation et l'inventaire d'hôtes que la première ligne d'une transcription enregistre, et lisez le fichier avant de l'envoyer.
Rétention
Conservez les éléments suivants pendant au moins 30 jours après une exécution, ou plus longtemps si vos obligations réglementaires ou contractuelles l'exigent. Stockez-les en dehors de l'hôte :
Transcriptions d'agents ;
Les journaux de tout ce qui applique la sortie du bac à sable (un proxy ou un pare-feu), y compris les connexions refusées ;
Les journaux de tout ce qui injecte l'identifiant d'API du modèle, s'il s'agit d'un composant distinct.
Stockez-les avec les mêmes contrôles d'accès que l'exécution elle-même. Les transcriptions peuvent contenir le code source de la cible, le code d'exploit et les résultats.
Si l'un de ces journaux n'existe que comme journal de conteneur, exportez-le avant que le conteneur ne soit supprimé ou recréé, car le journal est supprimé avec lui.