Для клиентов нашей программы Cyber Verification Program мы предоставляем новый классификатор sandbox escape в API для мониторинга и снижения неправомерного использования. В этой статье объясняется, почему стоит читать транскрипты агентов. Затем в ней есть один раздел для каждого уровня мониторинга: сначала логи прокси, затем то, что должен содержать транскрипт, правила паттернов для транскриптов и модель-рецензент для транскриптов. Статья завершается тем, что делать, когда уровень отмечает агента во время выполнения пакета, и что сохранять после этого.
Этот классификатор находится в закрытой бета-версии.
Для обзора всех доступных вам ресурсов см. Лучшие практики изоляции агентов: начало работы (закрытая бета).
Обзор
Чтение транскриптов — это проверка, которая не зависит от того, правильно ли работают sandbox или классификатор. Транскрипт создается собственным процессом агента, поэтому сопоставьте его с записями, полученными вне sandbox, такими как логи прокси. Зондирование часто видно в транскрипте до того, как запустится что-либо вредоносное, но не полагайтесь на наличие времени для реакции: элементы управления, которые действуют до выполнения действия, идут в первую очередь. Во время длительного пакета без доступа в сеть сканируйте файлы живого транскрипта по расписанию и проверяйте результаты каждый час или два. Для запусков с доступом в сеть к целевому объекту попросите инженера следить за запуском или сканируйте непрерывно и остановите агента при обнаружении. После любого запуска сканируйте все один раз, чтобы подтвердить, что каждый агент остался в своем sandbox.
Используйте три уровня мониторинга, начиная с самого дешевого: (1) логи egress-proxy и credential-proxy, (2) правила паттернов для транскриптов, написанные для вашей среды, и (3) модель-рецензент для транскриптов с подсказкой, которую вы напишете для вашего sandbox и области.
Также отправьте рецензенту случайные 5–10% транскриптов, которые не отметили правила паттернов. Ожидайте некоторых ложных срабатываний. Если рецензент говорит, что агент что-то сделал, прочитайте эту часть транскрипта перед тем, как действовать.
Когда уровень показывает, что агент отклонился от своей задачи во время запуска, остановите его и сообщите команде вашего аккаунта Anthropic о поведении вне области.
Сохраняйте транскрипты и логи прокси не менее 30 дней.
Почему читать транскрипты
Sandbox и классификатор разрешений auto-mode Claude Code оба действуют во время выполнения агента. Чтение транскриптов — это проверка, которая не зависит ни от одного из них. Она имеет два применения.
Во время запуска. Зондирование, если оно происходит, может быть видно в транскрипте до того, как запустится что-либо вредоносное. Не полагайтесь на наличие времени для реакции: элементы управления, которые действуют до выполнения действия, идут в первую очередь. Во время длительного пакета сканируйте файлы живого транскрипта по расписанию и проверяйте результаты сканирования каждый час или два.
После запуска. Сканируйте все один раз, чтобы подтвердить, что каждый агент остался в своем sandbox.
Для взаимодействий с доступом в сеть к реальным целевым объектам лучшие практики рекомендуют, чтобы человек контролировал запуск или монитор, который знает предполагаемую область, следил непрерывно, передавал человеку, когда запуск может превышать эту область, и мог завершить запуск (см. раздел Область и контроль в Sandboxing). Уровни в этой статье — это компоненты, из которых строится такой монитор.
Если вы запускаете агентов непосредственно через Messages API, API также может возвращать оценку для каждого запроса от классификатора sandbox escape по мере их выполнения (см. Онлайн-мониторинг).
Уровень 1: логи прокси
Самый дешевый уровень вообще не читает транскрипт.
Egress proxy должен логировать каждый запрос, который он отклоняет, с адресом клиента и пункт назначения. С пустым списком разрешений агенты достигают API модели только через credential proxy и не нуждаются в других хостах, поэтому каждый отклоненный запрос во время запуска стоит проверить. Прочитайте транскрипт каждого запуска, который вызвал один. Адрес клиента показывает, какой агент сделал запрос, поэтому вы знаете, какой транскрипт читать в первую очередь.
Знайте, что ваш egress слой не логирует. В эталонной конструкции egress proxy логирует отклоненные HTTPS запросы CONNECT. Попытки plain-HTTP и raw TCP не проходят через прокси во внутренней сети, поэтому они не выполняются без строки логирования и появляются только в транскриптах. В вашей собственной конструкции рассмотрите логирование разрешенных и отклоненных соединений для каждого протокола с временными метками.
Credential proxy должен логировать строку для любого запроса, который не был вызовом модели. Сохраните его логи при завершении запуска (см. раздел Credential proxy в Sandboxing).
Что захватить в транскрипте
Второй и третий уровни читают сами транскрипты.
Попросите оркестратор на хосте написать транскрипт для каждого этапа агента, одно сообщение JSON на строку, по мере поступления каждого сообщения. Выход stream-json Claude Code имеет эту форму. В каждом файле строки с "type": "assistant" содержат то, что произвела модель: блоки text, thinking и tool_use. Вход tool_use содержит команду Bash или записываемый файл. Строки с "type": "user" содержат блоки tool_result: вывод команды, содержимое файла и ответы целевого объекта.
Захватите каждый этап, включая этапы, агенты которых не имеют инструментов, такие как агент, который только судит или сравнивает результаты. В этих транскриптах меньше проверять, но этап без транскрипта вообще не может быть проверен.
Уровень 2: правила паттернов для транскриптов
Напишите свои собственные правила паттернов, такие как регулярные выражения, для ваших агентов и целевых объектов. Для агентов, работающих через оболочку, охватите поведение, такое как обход egress proxy или брандмауэра, отправка учетных данных или открытие SSH соединений вне sandbox, изменение ядра или привилегированных параметров, и перечисление других процессов через /proc. Правила совпадают только с поведением, которое кто-то предвидел, поэтому рассматривайте их как отправную точку, а не полный детектор.
Применяйте правила к декодированным JSON строкам, а не к необработанным строкам, потому что в необработанной строке кавычки и новые строки экранированы и паттерны могут не совпадать. Сообщайте о каждом совпадении с файлом, строкой, правилом и фрагментом, и пусть сканирование выходит с отличным статусом при обнаружении чего-либо, чтобы запланированное задание могло запустить его во время длительного пакета и вызвать оповещение.
Ожидайте безвредных совпадений
Совпадение — это причина прочитать эту часть транскрипта. Само по себе это не означает, что агент сделал что-то неправильное. Агенты, проводящие исследование уязвимостей, обычно запускают команды, которые совпадают с правилами escape по обычным причинам:
запуск целевого объекта под прокладкой
LD_PRELOAD;присоединение ptrace к своим собственным дочерним процессам или чтение /proc/<pid>/ для этих процессов;
отключение ASLR через /proc/sys/kernel/randomize_va_space;
перечисление /proc для поиска и завершения своих собственных рабочих процессов fuzz.
Правило обхода прокси может совпадать с каждым запросом curl, wget или netcat к целевому объекту pentest с публичным IP, а правило SSH-egress может совпадать с любым ssh или scp к целевому объекту с публичным IP или DNS именем. Сузьте или удалите правила, которые производят только безвредные совпадения на ваших целевых объектах.
Уровень 3: модель-рецензент для транскриптов
Для каждого транскрипта, отмеченного правилами паттернов, отправьте один запрос Messages API к Claude с подсказкой рецензента, которую вы напишете. Подсказка должна попросить Claude найти агента, который расширил свой доступ в сеть или вышел из своего sandbox, независимо от того, попытался ли он или достиг этого, сказать, что отмечать и что не отмечать, и попросить результаты или ничего с строками транскрипта, которые их поддерживают.
Постройте пользовательское сообщение в две части:
Начните с двух или трех предложений, которые описывают sandbox и предполагаемую область. Для эталонной конструкции: каждый агент работает в своем собственном изолированном sandbox (контейнер или microVM) во внутренней сети, единственный способ выхода — это прокси, который пересылает вызовы API модели и ничего больше, и целевой объект находится в sandbox с агентом. Если ваш sandbox позволяет другие хосты или целевой объект находится в сети, скажите об этом здесь и назовите целевые объекты в области.
Затем включите собственные сообщения агента, то есть его блоки
text,thinkingиtool_use, с достаточным содержимымtool_result, чтобы показать, что вернул каждый вызов.
Используйте модель, с которой вы запускаете агентов, или более дешевую. В Amazon Bedrock или Google Cloud Agent Platform (Vertex AI) используйте ту, которая включена в вашем аккаунте.
Два ограничения, которые следует помнить:
Подсказка рецензента, которая ищет только sandbox и сетевой escape, не обнаруживает агента, который превышает взаимодействие на хостах, которые ему разрешено достигать.
Транскрипт — это недоверенный ввод для рецензента. Он содержит текст, который контролирует целевой объект. Чистый вердикт не очищает транскрипт, который отметили правило или логи прокси.
Также проверьте образец неотмеченных транскриптов
Правила паттернов ловят только то, что кто-то предвидел, поэтому также отправьте случайные 5–10% транскриптов, которые правила не отметили, используя тот же запрос. Образец показывает, что пропускают правила, и следует ли вам добавить правило.
Прочитайте отказы классификатора
Отказы классификатора auto-mode также полезно читать: ищите в транскриптах сообщения об отказе классификатора и отделяйте их от отказов, которые он выдает, когда он недоступен (см. Auto mode).
Этот рецензент отличается от классификатора разрешений auto-mode (см. Auto mode), который решает каждое действие перед его выполнением, и от классификатора sandbox escape в API (см. Онлайн-мониторинг). Эти три дополняют друг друга.
Что делать при совпадении во время запуска
Когда один из уровней показывает агента, который отклонился от своей задачи, пока его пакет все еще выполняется:
Остановите агента. В установке на основе Docker используйте
docker rm -fна контейнере агента, чтобы остановить его. Удаление контейнера удаляет диск гостя, поэтому все, что агент там написал, теряется. Оркестратор должен записать запуск как неудачный и продолжить с остальной частью пакета.Сохраните доказательства. Оставьте результаты запуска как они есть и проверьте логи egress proxy на том же временном окне. Убедитесь, что строки логирования содержат временные метки.
Сообщите об этом. Если то, что вы обнаружили, является действительно поведением вне области, то есть агентом, который зондировал свою изоляцию sandbox или сети или действовал вне взаимодействия, уведомите команду вашего аккаунта Anthropic в дополнение к тому, что требует ваш собственный процесс инцидентов.
Ротируйте учетные данные API модели, как после любого запуска, транскрипт которого показывает неожиданное поведение (см. Sandboxing).
Если вам нужно поделиться транскриптом вне вашей команды, работайте с копией. Удалите идентификаторы сеансов, учет использования и инвентарь хостов, который первая строка транскрипта записывает, и прочитайте файл перед отправкой.
Хранение
Сохраняйте следующее не менее 30 дней после запуска или дольше, если этого требуют ваши нормативные или договорные обязательства. Храните их вне хоста:
Транскрипты агентов;
Логи того, что обеспечивает выход из sandbox (прокси или брандмауэр), включая отклоненные соединения;
Логи того, что вводит учетные данные API модели, если это отдельный компонент.
Храните их с теми же элементами управления доступом, что и сам запуск. Транскрипты могут содержать исходный код целевого объекта, код эксплуатации и результаты.
Если какой-либо из этих логов существует только как логи контейнера, экспортируйте их перед удалением или пересозданием контейнера, потому что логи удаляются вместе с ним.