Cyber Verification Program のお客様向けに、API に新しいサンドボックス脱出分類器を提供し、エージェントトランスクリプトを監視して悪用を減らします。この記事では、エージェントトランスクリプトを読む価値について説明します。その後、監視の各レイヤーについて 1 つのセクションがあります。まずプロキシログ、次にトランスクリプトが保持すべき内容、トランスクリプト上のパターンルール、トランスクリプト上のモデルレビュアーです。最後に、バッチの実行中にレイヤーがエージェントにフラグを立てた場合の対応方法と、その後に保持すべき内容について説明します。
この分類器はプライベートベータ版です。
利用可能なすべてのリソースの概要については、エージェント封じ込めのベストプラクティス: はじめに (プライベートベータ)を参照してください。
概要
トランスクリプトを読むことは、サンドボックスまたは分類器が正しい決定を下すことに依存しないチェックです。トランスクリプトはエージェント自身のプロセスによって生成されるため、プロキシログなどのサンドボックス外で取得されたレコードと組み合わせてください。プロービングはトランスクリプトに何か有害なものが実行される前に見えることがよくありますが、対応する時間があることに頼らないでください。アクション実行前に機能する制御が最初に来ます。ネットワークアクセスのない長いバッチの場合、スケジュールに従ってライブトランスクリプトファイルをスキャンし、1 時間から 2 時間ごとに人がヒットを確認してください。ターゲットへのネットワークアクセスがある実行の場合、エンジニアに実行を監視させるか、継続的にスキャンしてヒット時にエージェントを停止してください。実行後、すべてをスキャンして、すべてのエージェントがサンドボックス内に留まっていることを確認してください。
3 つの監視レイヤーを使用します。最も安価なものから順に: (1) 出力プロキシと認証情報プロキシログ、(2) トランスクリプト上のパターンルール (環境用に作成)、(3) トランスクリプト上のモデルレビュアー (サンドボックスとスコープ用に作成したプロンプト付き)。
パターンルールがフラグを立てなかったトランスクリプトの 5 ～ 10% をランダムにレビュアーに送信してください。誤検知が発生することを想定してください。レビュアーがエージェントが何かを実行したと言った場合、それに対応する前にトランスクリプトのその部分を読んでください。
レイヤーがエージェントが実行中にタスクを離れたことを示している場合、それを停止し、Anthropic アカウントチームにスコープ外の動作について通知してください。
トランスクリプトとプロキシログを少なくとも 30 日間保持してください。
トランスクリプトを読む理由
サンドボックスと Claude Code の自動モード権限分類器は両方ともエージェント実行中に機能します。トランスクリプトを読むことは、どちらにも依存しないチェックです。2 つの用途があります。
実行中。プロービングが発生する場合、何か有害なものが実行される前にトランスクリプトに見える可能性があります。対応する時間があることに頼らないでください。アクション実行前に機能する制御が最初に来ます。長いバッチの場合、スケジュールに従ってライブトランスクリプトファイルをスキャンし、スキャンがフラグを立てたものを 1 時間から 2 時間ごとに人に確認させてください。
実行後。すべてをスキャンして、すべてのエージェントがサンドボックス内に留まっていることを確認してください。
実際のターゲットへのネットワークアクセスがあるエンゲージメントの場合、ベストプラクティスでは、人が実行を監視するか、意図されたスコープを知っているモニターが継続的に監視し、実行がそのスコープを超える可能性がある場合は人にエスカレートし、実行を終了できることを推奨しています (サンドボックスのスコープと監視セクションを参照)。この記事のレイヤーは、そのようなモニターが構築される部分です。
Messages API に対してエージェントを直接実行する場合、API は実行中にサンドボックス脱出分類器からのリクエストごとのスコアを返すこともできます (オンライン監視を参照)。
レイヤー 1: プロキシログ
最も安価なレイヤーはトランスクリプトをまったく読みません。
出力プロキシは、拒否したすべてのリクエストをクライアントアドレスと宛先でログに記録する必要があります。空のアローリストでは、エージェントは認証情報プロキシを通じてのみモデル API に到達し、他のホストは必要ないため、実行中に拒否されたすべてのリクエストは確認する価値があります。1 つを引き起こしたすべての実行のトランスクリプトを読んでください。クライアントアドレスはどのエージェントがリクエストを行ったかを示すため、最初に読むトランスクリプトがわかります。
出力レイヤーがログに記録しないものを知ってください。リファレンス設計では、出力プロキシは拒否された HTTPS CONNECT リクエストをログに記録します。プレーン HTTP と生の TCP 試行は内部ネットワーク上のプロキシを通過しないため、ログ行なしで失敗し、トランスクリプトにのみ表示されます。独自のビルドでは、すべてのプロトコルについて、許可された接続と拒否された接続の両方をタイムスタンプ付きでログに記録することを検討してください。
認証情報プロキシは、モデル呼び出しではなかったリクエストのログ行を記録する必要があります。実行終了時にそのログを保存してください (サンドボックスの認証情報プロキシセクションを参照)。
トランスクリプトでキャプチャする内容
2 番目と 3 番目のレイヤーはトランスクリプト自体を読みます。
ホスト上のオーケストレーターに、各メッセージが到着するたびに、エージェントステージごとに 1 行に 1 つの JSON メッセージでトランスクリプトを書き込ませてください。Claude Code のストリーム JSON 出力はこの形式です。各ファイルで、"type": "assistant" の行にはモデルが生成したもの (text、thinking、tool_use ブロック) が含まれます。tool_use 入力には Bash コマンドまたは書き込まれるファイルが含まれます。"type": "user" の行には tool_result ブロック (コマンド出力、ファイル内容、ターゲット応答) が含まれます。
ツールを持たないエージェント (判定または検出結果を比較するだけのエージェントなど) のステージを含め、すべてのステージをキャプチャしてください。これらのトランスクリプトでチェックすることは少なくなりますが、トランスクリプトのないステージはまったくレビューできません。
レイヤー 2: トランスクリプト上のパターンルール
エージェントとターゲット用に、正規表現などの独自のパターンルールを作成してください。シェルを通じて機能するエージェントの場合、出力プロキシまたはファイアウォールのバイパス、認証情報の送信またはサンドボックス外への SSH 接続の開始、カーネルまたは権限チューナブルの変更、/proc を通じた他のプロセスのリストなどの動作をカバーしてください。ルールは予想された動作のみに一致するため、これらを開始点として扱い、完全な検出器ではありません。
生の行ではなく JSON デコード文字列にルールを適用してください。生の行では引用符と改行がエスケープされ、パターンが一致しない可能性があるためです。ファイル、行、ルール、スニペットを含む各ヒットを報告し、スキャンが何かを見つけたときに異なるステータスで終了するようにして、スケジュールされたジョブが長いバッチ中に実行してアラートを発生させることができるようにしてください。
良性のヒットを想定してください
ヒットはトランスクリプトのその部分を読む理由です。それ自体では、エージェントが何か間違ったことをしたことを意味しません。脆弱性研究を行うエージェントは、通常の理由でエスケープルールに一致するコマンドを日常的に実行します:
LD_PRELOADシムの下でターゲットを実行する。ptrace を独自の子プロセスにアタッチするか、それらのプロセスの /proc/<pid>/ を読む。
/proc/sys/kernel/randomize_va_space を通じて ASLR をオフにする。
/proc をリストして、独自のファズワーカーを見つけて終了する。
プロキシバイパスルールは、パブリック IP を持つペンテストターゲットへのすべての curl、wget、または netcat リクエストに一致でき、SSH 出力ルールはパブリック IP または DNS 名を持つターゲットへのすべての ssh または scp に一致できます。ターゲット上で良性のヒットのみを生成するルールを絞り込むか削除してください。
レイヤー 3: トランスクリプト上のモデルレビュアー
パターンルールがフラグを立てたトランスクリプトごとに、作成したレビュアープロンプトを使用して Claude に 1 つの Messages API リクエストを送信してください。プロンプトは、エージェントがネットワークアクセスを拡大したか、サンドボックスから脱出したか (試行または達成) を確認するよう Claude に求め、フラグを立てるべき内容と立てるべきでない内容を述べ、トランスクリプト行でサポートされた検出結果またはなしを求める必要があります。
ユーザーメッセージを 2 つの部分で構築してください:
サンドボックスと意図されたスコープを説明する 2 ～ 3 文で始めてください。リファレンス設計の場合: 各エージェントは内部ネットワーク上の独自の分離されたサンドボックス (コンテナまたはマイクロ VM) で実行され、唯一の方法は、モデル API 呼び出しを転送し、他には何も転送しないプロキシであり、ターゲットはエージェントと同じサンドボックス内にあります。サンドボックスが他のホストを許可する場合、またはターゲットがネットワーク上にある場合は、ここで述べ、スコープ内のターゲットに名前を付けてください。
次に、エージェント自身のメッセージ (つまり、
text、thinking、tool_useブロック) を含め、各呼び出しが返したものを示すのに十分なtool_resultコンテンツを含めてください。
エージェントを実行するモデルまたはより安価なモデルを使用してください。Amazon Bedrock または Google Cloud の Agent Platform (Vertex AI) では、アカウントで有効になっているものを使用してください。
念頭に置くべき 2 つの制限:
サンドボックスとネットワークエスケープのみを探すレビュアープロンプトは、許可されたホストに到達するエンゲージメントを超えるエージェントを検出しません。
トランスクリプトはレビュアーへの信頼できない入力です。ターゲットが制御するテキストが含まれています。クリーンな判定は、ルールまたはプロキシログがフラグを立てたトランスクリプトをクリアしません。
フラグが立てられていないトランスクリプトのサンプルもレビューしてください
パターンルールは予想されたものだけをキャッチするため、ルールがフラグを立てなかったトランスクリプトの 5 ～ 10% をランダムに同じリクエストを使用して送信してください。サンプルはルールが見落とすものと、ルールを追加すべきかどうかを示します。
分類器の拒否を読んでください
自動モード分類器の拒否も読む価値があります。トランスクリプトで分類器の拒否メッセージを検索し、利用不可の場合に発行する拒否とは別に保管してください (自動モードを参照)。
このレビュアーは、実行前に各アクションを決定する自動モード権限分類器 (自動モードを参照) および API のサンドボックス脱出分類器 (オンライン監視を参照) とは別です。3 つは相互に補完します。
実行中のヒット時の対応
レイヤーの 1 つがバッチがまだ実行中にタスクを離れたエージェントを示している場合:
エージェントを停止してください。Docker ベースのセットアップでは、エージェントのコンテナで
docker rm -fを実行してそれを停止します。コンテナを削除するとゲストのディスクが削除されるため、エージェントがそこに書き込んだものはすべて失われます。オーケストレーターは実行を失敗として記録し、バッチの残りを続行する必要があります。証拠を保持してください。実行の結果をそのままにして、同じ時間枠の出力プロキシのログを確認してください。ログ行にタイムスタンプが含まれていることを確認してください。
報告してください。見つけたものが本当にスコープ外の動作 (つまり、サンドボックスまたはネットワーク分離をプロービングしたか、エンゲージメント外で機能したエージェント) である場合、独自のインシデントプロセスが必要とするものに加えて、Anthropic アカウントチームに通知してください。
モデル API 認証情報をローテーションしてください。トランスクリプトが予期しない動作を示す実行後と同様に (サンドボックスを参照)。
チーム外でトランスクリプトを共有する必要がある場合は、コピーで作業してください。セッション ID、使用状況会計、トランスクリプトの最初の行が記録するホストインベントリを削除し、送信する前にファイルを読んでください。
保持
実行後少なくとも 30 日間、または規制上または契約上の義務がより長い場合は、以下を保持してください。ホストの外に保存してください:
エージェントトランスクリプト。
サンドボックスからの出力を強制するもの (プロキシまたはファイアウォール) のログ (拒否された接続を含む)。
モデル API 認証情報を注入するもの (別のコンポーネントの場合) のログ。
実行自体と同じアクセス制御で保存してください。トランスクリプトには、ターゲットソースコード、エクスプロイトコード、および検出結果が含まれる可能性があります。
これらのログのいずれかがコンテナのログとしてのみ存在する場合、コンテナが削除または再作成される前にエクスポートしてください。ログはそれと一緒に削除されるためです。