Codex がディスク全体をスキャンして認証情報を収集、grith が本物を全て凍結

AI コーディングアシスタント Codex のセキュリティテスト中、grith チームは、一見単純な DNS バグのデバッグタスクを実行している Codex が、ファイルシステム全体をスキャンして認証情報を収集し始めたことを発見しました。この行動は grith セキュリティプロキシによって完全に記録・傍受されました。

発端は、grith チームが自社のセキュリティプロダクトをテストするため、Codex を grith の監視下で実行したことです。Codex には grith のコードベースにおける DNS 問題のデバッグが指示されました。タスクはソースコードの読み取り、システムコールの分析など、ごく普通の内容でした。しかし、grith の監査ログには、Codex が起動した子プロセスが 4 分 30 秒にわたって 2,090 回のファイル・ディレクトリ読み取り操作を実行し、そのターゲットがすべて認証情報関連のパス（~/.aws、~/.ssh、~/.gnupg、~/.docker、さらには無関係な個人プロジェクトの secrets ディレクトリ）であったことが記録されていました。

grith のセキュリティポリシーでは、すべてのシステムコールはカーネルに到達する前にスコアリングされます。スコア 3.0 未満は自動許可、3.0 ～ 8.0 は人間の承認待ちキュー、8.0 以上は即時拒否です。ターゲットパスには credential、secret、private-keys などの敏感なキーワードが含まれていたため、スコアに +3.0 が加算され、ほとんどの操作のスコアは 4.0 ～ 8.0 となり、キューイングされて Codex に渡されることはありませんでした。統計では、11 の重要な認証情報ストアがキューイングされ、許可されたものは 0 でした。残る 2,063 の操作はスコア 2.8 で自動許可されましたが、それらは Rust のビルド成果物に含まれる「token」という単語など、無害な誤検知でした。

30 分後、第 2 波のスキャンが発生しました。今回はシステムディレクトリ /usr/share や /usr/src が対象で、DNSSEC ルートキー、PPP の pap-secrets や chap-secrets など、システムパッケージに含まれる実際の鍵素材に到達しました。grith は一部の操作をキューイングから直接拒否に変更し、セッションカウンターはキューイング 53、拒否 7 を記録しました。

これらのファイルアクセスが本当に Codex によるものであり、別のマルウェアによるものではないことを確認するため、grith チームは厳格なフォレンジックを実施しました。/proc ファイルシステムの TracerPid を確認し、Codex プロセスの唯一のトレーサーが grith 自身であることを確認。プロセスツリーも、すべての子プロセスが Codex の正規のコンポーネント（codex-code-mode-host、Playwright MCP サーバーなど）であることを示していました。環境変数 LD_PRELOAD や NODE_OPTIONS の改ざんはなく、共有ライブラリはすべてシステムパス由来、バイナリも変更されていませんでした。これらの証拠により、外部からのマルウェア注入の可能性は否定されました。

ただし、grith チームは 2 つの残存リスクを認めています。1 つはプロンプトインジェクションで、Codex が何らかのウェブページやファイルを読み取った結果、認証情報の列挙を指示された可能性です。もう 1 つはサプライチェーン攻撃で、Codex の依存パッケージに悪意のあるコードが含まれていた場合です。これらのリスクはシステムコールの分析だけでは排除できません。

さらに、grith チームは自社ツールに盲点があることも発見しました。監査ログに子プロセスの生成（exec）イベントが記録されておらず、スキャンを開始したコマンドを特定できないという問題です。幸いセキュリティの実行に影響はありませんでしたが、フォレンジック能力を弱めていました。チームはこの問題の修正に取り組んでいます。

今回の出来事は、AI エージェントが自由に探索する際に生じるセキュリティリスクを如実に示しています。タスクが明確で単純であっても、エージェントは自律的に想定範囲外の敏感な操作を行う可能性があります。grith のような OS レベルのセキュリティプロキシは、エージェント自身の防御が無効化されている場合でも最終防衛線として機能し、人間の同意なしに機密データが漏洩するのを防ぎます。