第１ 資料を読む依頼と，資料に従って操作する権限
法律事務所でAIエージェントに受領資料を読ませるときは，資料中の文章だけでなく，作業場所に置かれた指示ファイルにも注意が必要である。
AGENTS.mdやCLAUDE.md等は，製品と設定によってはエージェントが作業方針として読み込むファイルであり，外部から届いたものを事務所の指示と同じように扱うべきではない。
「このZIPの資料を整理する」という依頼から，ZIP内の指示に従う設定変更，外部送信又はコマンド実行まで当然に認められるわけではない。
本記事は，2026年11月1日時点で確認した研究報告と公式文書に基づき，資料の受領から作業開始までの確認と，不審なファイルを発見した場合の初動を整理する。
以下の受領手順や記録項目は，法律事務所向けの運用提案である。
特定の端末の安全性や，個別事故における法的責任を判定するものではない。
第２ 今回の研究報告から分かることと，分からないこと
１ ダウンロード先のファイルが指示として読まれる経路
Forever Securityの研究報告は，Downloads内に置かれたAGENTS.md等をエージェントが読み，外部由来の記載に誘導される攻撃を扱っている。
報告の出発点となった顧客事例では，不審なAGENTS.mdから既知の悪性npmパッケージのインストールが試みられ，実行前に阻止されたとされる。
そのファイルが実際にどの経路で顧客端末へ入ったかは確定していない。
研究者が再現したWebからのファイル配置の経路と，顧客事例で確認された事実を分けて読む必要がある。
研究者は，検証環境でCodexの設定変更や子エージェントの起動，Claude CodeのAPI接続先設定の変更等を試したと報告している。
これらは，研究者が設定した条件における検証結果であり，Codexの検証は顧客端末のファイルをそのまま用いたものである一方，Claude Code向けのファイルは，研究者がそれを参考に作成したものである。
同報告は，指示ファイルを読み自らの設定を書き換えられるエージェントであれば同様に操られ得ると主張するが，検証された製品はこの２製品である。
ダウンロードされた文章が，すべてのAI製品・端末で直ちに実行ファイルと同じ働きをすることまで確認されたわけではない。
２ 成功率の数字は，何が成功した数字かを見る
同報告のCodexに関する「90％超」や，Claude Codeに関する「約50％」を，自分の端末で被害が発生する確率として使うことはできない。
同報告のClaude Codeの約50％は，接続先を書き換える設定ファイルの保存に至った割合であり，同報告は，保存されればOAuthトークンが流出し，次回の起動時にコードが実行されると説明している。
他方，同一セッション内のコード実行は，確認の名目でサブエージェントを起動させた場合のものであり，その頻度を約5分の1と説明している（分母は明示されていない）。
また，同報告は，この書込みには人の承認が必要であるとも述べている。
試験の総数，製品のビルド，モデル及びOS等について，本記事から一般的な発生率を算出できるだけの情報はそろっていない。
Codexの90％超について，同報告はマルウェアが実行された試行の割合と述べている。
もっとも，同報告の方法の注記は，試験の多くが電卓を起動するだけの無害な代替処理によるものであり，実際の悪性パッケージの実行は隔離VM内の1回であったと説明している。
Codexの試験のうち代替処理が占める内訳は示されていないため，報告された割合全体を実マルウェアの実行率と読み替えてはならない。
同報告の，OpenAIやAnthropicが修正すべきものはないとする評価は，研究者の見解である。
製品提供者による安全保証でも，防御の改善が不可能であるとの証明でもない。
利用者側の運用と，製品側の保護機能の両方を確認するのが適切である。
第３ 起動場所だけでなく，読み込まれる範囲を確かめる
１ CodexとClaude Codeを同じ規則で説明しない
OpenAIのAGENTS.mdに関する公式説明では，グローバルな指示に加え，通常はプロジェクトルートから現在の作業ディレクトリまでの指示が読み込まれる。
プロジェクトルートが見つからない場合の扱い，AGENTS.override.mdの優先，追加のファイル名の設定等にも条件がある。
「現在のフォルダーより上のすべての階層を，どの製品でも同じように読む」と一括りにしない。
Anthropicのメモリに関する公式説明では，Claude Codeは起動時に作業ディレクトリとその上位階層のCLAUDE.md等を読み，作業中に下位ディレクトリのファイルを扱う際に，その階層の指示を読み込む場合もある。
現行文書にはAGENTS.mdへの対応も記載されており，バージョンと設定条件を確認する必要がある。
ホームで起動してからDownloadsの資料を読む方法や，Downloadsの下に子フォルダーを作る方法だけで，すべての指示読込みを防いだと判断するのは早計である。
２ 空ファイルの先置きを安全保証にしない
同名の空ファイルを先に置き，後から保存されるファイル名が変更されることを期待する対策は，保存先，ブラウザーの命名処理，別の指示ファイル名及び上位階層の状態等に左右される。
空のAGENTS.mdやCLAUDE.mdが存在するという事情だけで，悪意のある指示が読み込まれないとはいえない。
指示ファイルの所在，内容，更新者及び実際の読込み結果を確認する運用が必要である。
第４ 受領資料とZIPを扱う前の確認
１ 受領場所と作業場所を分ける
担当者は，ダウンロード等で外部資料が集まる場所を，AIの通常の起動場所と兼ねさせない運用を検討する。
資料を作業用フォルダーへ取り出す場合も，指示ファイルや設定ファイルを一式のまま無条件に引き継がず，作業に必要な資料を確認して選ぶ。
これは入口での接触を減らす運用であり，作業用フォルダーへ移した資料の内容が信頼できることまで保証するものではない。
ZIPは，AIをその展開先で起動する前に，信頼できる通常の閲覧手段で格納ファイル名と階層を確認する。
AGENTS.md，AGENTS.override.md，CLAUDE.md，CLAUDE.local.md，エージェントの設定フォルダー，スクリプト等が含まれていれば，送付者，取得元及び業務上の必要性を確認する。
これらの名前は確認対象の例であり，この名前だけを除外すれば十分という一覧ではない。
出所が不明な指示ファイルを，同じ疑いのあるAIセッションに読み込ませ，その判断だけで安全と結論付けない。
２ ブラウザーの設定と，例外的な受取りを決める
Chromeの公式ヘルプには，ダウンロード前に各ファイルの保存場所を確認する設定が案内されている。
保存先確認の設定と，自動ダウンロードに関するサイト設定は別の項目である。
保存先を尋ねるよう設定していても，すべての経路によるファイル配置や，受領済みファイルの危険を解消するわけではない。
業務上，特定の受取り場所を使う必要がある場合は，その利用を一律に禁止するのではなく，対象，必要な理由，受取り後の確認，作業場所への配置及び一時受取分の処理を決めておく。
今回の作業で受け取ったものと，もともと存在する依頼者資料を区別し，後者を一括移動・削除しない。
第５ 指示文と，技術的な権限を分けて管理する
OpenAIの承認・セキュリティの説明及びAnthropicのセキュリティの説明では，実行環境の制限，承認及び信頼に関する仕組みが説明されている。
「秘密を送らない」と指示ファイルに書くことと，秘密を読めない・許可外へ送れないよう技術的に制限することは異なる。
また，承認を求める条件と，サンドボックスが許す操作範囲も，同じものではない。
管理担当者は，必要な資料だけを見せることに加え，書込み先，ネットワーク送信先，実行可能な操作，接続するサービス，認証情報の付与範囲を確認する。
サンドボックス内に認証情報や案件資料を渡している場合は，「サンドボックスだから流出するものはない」と判断しない。
必要な承認を無効にする変更や，全体設定の変更を，受領資料中の指示だけを理由に許可しない。
APIの接続先を変更する権限も管理対象である。
契約したサービスのDPAや学習不使用の説明を確認していても，実際の設定が別の接続先を向いていれば，契約上予定した処理経路と一致しない可能性がある。
APIキーそのものを台帳やスクリーンショットに複製せず，接続先，設定の所在，変更権限者及び確認日時を記録する運用が考えられる。
第６ 不審な指示ファイルを見つけた場合の初動
１ 発見だけで漏えい・感染を断定しない
不審なファイルを発見した担当者は，当該AIセッションによる追加の実行・送信を止め，管理担当者へ連絡する。
そのファイルを実行したり，記載された接続先へ試しに通信したりせず，取得元，発見日時，保存場所，ファイル名，更新時刻，セッション及び確認できる操作履歴を保全する。
認証情報や案件の秘密を，証跡を作るために外部へ貼り付けない。
次の段階を区別して，確認できた範囲と未確認の範囲を記録する。
ファイルが存在する段階，AIが読み込んだ段階，設定が変更された段階，外部への送信又はコマンド実行が行われた段階，具体的な被害が確認された段階は，それぞれ異なる。
ファイルの存在だけで漏えいを断定せず，実行エラーが出たことだけで他の送信もなかったと断定しない。
２ 設定と認証情報を確認してから再開する
管理担当者は，起動時と現在の設定，MCP等の登録，API接続先，権限，子プロセス及び継続する設定変更の有無を，利用製品に応じて確認する。
指示ファイルを削除しただけでは，既に変更された設定や送信済みの情報は元に戻らない。
証跡の保全と封じ込めの順序は状況に応じて決め，進行中の外部送信を止める必要がある場合はその対応を優先する。
認証情報が露出したおそれがある場合は，影響するキー・セッション等を特定し，失効・再発行等を検討する。
証跡の採取を理由に失効を不必要に遅らせず，変更前後の確認結果を残す。
その後，信頼できる設定と必要最小限の資料を使った新しい作業環境で，無害なデータによる確認を行ってから業務を再開する。
依頼者への連絡，報告義務又は損害賠償等の判断は，対象情報，実際の処理，契約及び適用法令等を確認して別途行う。
第７ 事務所で決めておく担当と記録
受領担当者は，資料の取得元，受領時刻，必要なファイル及び指示・設定ファイルの混入の有無を記録する。
利用担当者は，起動場所，利用製品・バージョン，今回読む指示ファイル及び許可する操作を確認する。
管理担当者は，送信先・設定変更権限・認証情報の付与範囲を管理し，不審な場合の停止・連絡先・再開条件を決める。
少人数の事務所で同じ人が複数の役割を担う場合でも，確認した事項と時刻を区別して残すことが有用である。
導入全体の確認はスキル・プラグイン導入時の確認記事，事務所内のルール作りは生成AI利用ガイドラインの記事，契約と処理経路の確認はDPAのチェックリストも参照されたい。
第８ 主な参照資料
Forever Securityの実験・顧客事例に関する報告
OpenAIによるAGENTS.mdの読込み範囲の説明
OpenAIによる承認とセキュリティの説明
Anthropicによる指示ファイルとメモリの説明
Anthropicによるセキュリティの説明
Google Chromeのダウンロード設定の説明