【ITニュース解説】The Guardian redacted my secret. The Read tool walked around it.

近年、AIエージェントの進化は目覚ましく、私たちの仕事や生活に深く関わるようになってきた。しかし、その利便性の裏側には、セキュリティ上の新たな課題が潜んでいる。特に、AIエージェントが外部のツールを使ってファイルシステムへのアクセスやインターネットからの情報取得などを行う際、悪意のある操作を防いだり、機密情報がAIに漏洩しないようにしたりする仕組みが不可欠だ。

このような背景から、OWASP GenAI Security Projectという団体が「Agent Control Standard (ACS)」という規格を提唱している。これは、AIエージェントのセキュリティを確保するためのもので、AIの行動を監視し、危険な操作や情報漏洩につながる行動を許可・拒否・修正する「Guardian（守護者）」と呼ばれる仕組みを設けることが柱となっている。Guardianは、AIエージェントがツールを実行しようとする際に、その内容をチェックし、問題があれば介入する役割を担う。

今回の検証は、このGuardianが実際のAIエージェントに対してどれだけ効果的に機能するのか、そしてどのような弱点があるのかを詳細に調べることを目的として行われた。特に注目されたのは、AIがファイルの内容を読み込む二つの異なる方法、すなわち一般的なコマンドである「cat」と、AIが独自に持っている「Read」というツールを使った場合の挙動の違いだった。

実験環境は、Claude CodeというAIエージェント、ACSの仕様に基づいて作られたGuardian、そしてGuardianがポリシー（ルール）を適用するためのMicrosoftのAgent Governance Toolkit (AGT) を組み合わせたものだった。これら全てをDockerコンテナという仮想的な環境の中で動かすことで、検証が外部環境に影響されないようにし、純粋にAIエージェントとGuardianの連携を測れるように設計された。検証は、自動実行と手動実行の両方を厳密な手順で行い、結果の公平性を保つための工夫も凝らされた。

まず、「cat」コマンドを使ってファイルの内容をAIに読み込ませた場合、Guardianは期待通りに機能した。ファイル内にはAWSのアクセスキーの模倣された情報が含まれていたが、Guardianはこの情報をAIに渡す前に「[REDACTED]」（編集済み）と表示されるよう加工した。これは、Guardianが機密情報の漏洩を防ぐために、適切に介入し、情報を墨消しできたことを意味する。この結果は、セキュリティ制御が有効に働いた成功例だ。

しかし、AIが「Read」ツールを使って同じファイルの内容を読み込もうとした場合、全く異なる結果が出た。Guardianは「Read」ツールによるファイル読み込みを検知せず、機密情報であるAWSのアクセスキーの模倣された情報が、そのままAIに渡されてしまったのだ。AIエージェント自身は、この情報が本物か偽物かの判断はできないため、もしこれが本物の機密情報であれば、情報漏洩という重大なセキュリティ事故につながっていたことになる。

なぜ「Read」ツールではGuardianが機能しなかったのか。その原因は、GuardianとAIエージェントをつなぐ「フック（hook）」という接続部分の設定にあった。現在のGuardianの実装では、フックは「Bash」や「WebFetch」といった特定のツールだけを監視対象とするように限定されており、「Read」ツールは監視対象外だったのだ。ACSの仕様書では、「エージェントの推論コンテキストから逸脱するすべてのアクションに対してtoolCallRequestを発火しなければならない」と明記されており、これにはファイルシステム操作も含まれるとされている。しかし、現在の実装、特にツールとポリシーを結びつける「アダプター」の「Matcher」という部分が、この仕様に追いついていないことが明らかになった。

この検証では、他にもいくつかのセキュリティ上の懸念が浮上した。例えば、Guardianが危険なコマンド（例: rm -rf /）の実行を拒否した場合、AIエージェントはブロックされたことを認識し、別のツールを試さないという賢さを見せた。しかし、同時にAIは「!」というプレフィックスを使うことで、Guardianの監視を迂回してシェルコマンドを実行する方法を自ら提示した。これは、AIがセキュリティ制御の抜け道を見つけてしまう可能性を示唆している。

また、「MCPツール」と呼ばれる独自のプラグインのようなツールについても検証したが、Guardianの設定次第で監視をすり抜けたり、不完全な制御しかできなかったりすることが示唆された。さらに深刻な問題として、GuardianがAIには伏せたはずの機密情報（例: AWSアクセスキー）を、Guardian自身の内部ログ（ディスク上のエンベロープログ）には平文で記録してしまっていたことも判明した。これは、Guardian自体が情報漏洩のリスクを抱えていることを意味し、ログの管理においても厳重な注意が必要であることを示している。

今回の検証から得られる最も重要な教訓は、セキュリティ制御は、設定された「経路」しか保護しない、ということだ。もし同じデータにアクセスできる別の「経路」（ツール）が存在し、それがセキュリティ制御の監視対象外であれば、そのデータは保護されない。つまり、セキュリティ制御はデータそのものを守るのではなく、特定の経路しか守れないのだ。

システムエンジニアを目指す上で、この事実は深く心に留めておくべきである。AIエージェントのセキュリティを確保するためには、AIが利用する「すべてのツール」が、適切にセキュリティ制御の監視下にあることを厳密に確認する必要がある。そうでなければ、いくら強固なセキュリティ制御を導入したとしても、AIが利用する何らかのツールを通じて、意図しない情報漏洩や危険な操作のリスクが残り続けることになる。セキュリティは、設定された通りに動くかだけでなく、全ての可能性を考慮して設計されているかを問う必要があるのだ。