【ITニュース解説】Safe Tools, Unsafe Session: Why Agent Permissions Need History

AIエージェントは私たちの仕事を手助けしてくれる便利な存在だが、その使い方によっては思わぬセキュリティ上のリスクを抱えることがある。この記事では、AIエージェントが複数のツールを使う際に生じる危険性と、それに対処するための新しいセキュリティ対策について解説する。

現代のAIエージェントは、メールの整理やコードのテスト実行といった多様なタスクをこなすために、さまざまなツールやサービスと連携する。例えば、Gmailに接続して受信トレイを処理し、同時にBashというコマンドラインツールを使ってプログラムのテストを実行するといった具合だ。個々のツールはそれぞれ安全な使い方を想定しているが、これらが同じ「セッション」の中で利用されると、予期せぬ脆弱性が生まれることがある。記事ではこれを「危険な三位一体（lethal trifecta）」と呼ぶ。これは、プライベートなデータにアクセスできるエージェントが、信頼できないコンテンツ（例えば、不審なメール）にさらされ、さらに外部と通信する手段（例えば、Bashコマンドの実行）を持っている場合に発生する。このような状況では、攻撃者が送ったたった一本のメールが、エージェントをだましてユーザーの機密情報を読み取らせ、それを外部に漏洩させる手段となり得るのだ。

実際、過去にはこのような攻撃が確認されている。2025年5月に報告されたInvariant Labsによる攻撃では、GitHubの公式エージェントが悪意のあるテキストを埋め込まれた公開リポジトリのIssueをレビューするよう指示された。その結果、エージェントはユーザーのプライベートなリポジトリから情報を読み取り、それを公開のプルリクエストとして流出させてしまった。この際、エージェントが行った操作は、ユーザーが許可した範囲内のツールの利用であり、GitHubサーバーのコード自体に欠陥があったわけではないという点が重要だ。問題は、個々のツールの権限ではなく、セッション全体でのツールの組み合わせとその利用順序にあった。

Meta社は、このような危険性を避けるための設計原則として「Rule of Two（2のルール）」を提唱している。これは、エージェントが持つべき機能として、「信頼できない入力の処理」「機密システムやプライベートデータへのアクセス」「外部との通信や状態変更」の3つを挙げ、1つのセッションにおいてエージェントが同時に持つのはこれらのうち最大2つまでとすべきだというものだ。もし3つ全てが必要なタスクであれば、人間の承認といった特別な監視が必要になる。このルール自体は有効だが、既存のエージェントに組み込まれた権限管理機能でこれを実現するのは難しいのが現状である。

現在一般的なエージェントの権限管理システムは、ツールごとに「許可」「拒否」「毎回確認」のいずれかを選択させる形式が多い。例えば、Bashの実行を許可するか、Gmailへのアクセスを許可するかといった設定だ。しかし、この方法では、セッションの過去の履歴を考慮できないという大きな課題がある。例えば、あるセッションで攻撃者からのメールを読んだ直後にBashを実行するリスクと、安全なコードレビューのセッションでBashを実行するリスクは全く異なるにもかかわらず、システムは同じ「Bashを実行する」というアクションとして扱う。その結果、「許可」を選択すれば常にリスクを受け入れることになり、「拒否」すれば安全な場面でもツールが使えなくなり、「毎回確認」では、セッションが安全か危険かに関わらず同じ内容のプロンプトが表示されるため、ユーザーは適切な判断ができない。

この問題に対処するために開発されたのが「TaintGuard」だ。TaintGuardは、個々のツールの権限だけでなく、「セッションがこれまでに何をしてきたか」という履歴に基づいてツールの呼び出しを制限する新しいアプローチである。その基本的な考え方は、セッションに入ってきたコンテンツがどのような種類の情報（機密性や信頼性）を持っているかを記録し、その「汚染（taint）」の履歴に基づいて、その後のツールの実行を制限するというものだ。これは、Perlというプログラミング言語が、外部から受け取ったデータを「汚染されている」とマークし、安全性が確認されるまでシェルコマンドなどに渡さないようにする「Taint mode」という機能に似ている。

TaintGuardの仕組みは大きく3つの要素で構成される。

1. ラベル: コンテンツが持つリスクの種類を表す。例えば「private（プライベートな情報）」「untrusted（信頼できない情報）」「secret（機密情報）」といったものがある。
2. ソース: 特定のツールが呼び出された際に、セッションにラベルを追加する。例えば、メールサーバーからメッセージを読み込むと「private」と「untrusted」のラベルがセッションに追加される。ウェブサイトからデータを取得するWebFetchが成功すると「untrusted」が追加される。.envファイルやSSHキーの読み込みは「secret」を追加する。
3. シンク: 特定のラベル条件が満たされた場合に、特定のツールの実行をブロックしたり、承認を求めたり、監査ログに残したりするアクションを定義する。例えば、「private」と「untrusted」の両方のラベルがセッションに存在する場合、外部への書き込みを行うツール（Bash、WebFetch、メール送信など）の実行を承認待ちにする、といった設定が可能だ。

TaintGuardは、Claude Codeという開発環境の「Mod（拡張機能）」として動作し、エージェントが行うすべてのツール呼び出しを監視する。ツールが呼び出される前に、そのセッションがこれまでに保持しているラベルに基づいてシンクのルールを評価し、実行を許可するか、ユーザーに確認を求めるか、あるいは拒否するかを決定する。例えば、メールを読んだことでセッションが「private」と「untrusted」のラベルを持つようになった場合、その後に外部へデータを送るBashコマンドを実行しようとすると、ユーザーに承認を求めるプロンプトが表示される。もしユーザーが拒否すれば、そのコマンドは実行されない。セッションの履歴は、エージェントが再起動したり、会話履歴を再構築したりしても保持され、常に現在のリスク状態を反映する。

TaintGuardが導入された環境でのテスト結果は、その有効性を示している。従来のポリシーと比較すると、TaintGuardは情報漏洩のリスクを大幅に削減しつつ、通常のタスクの実行をほとんど妨げないことがわかった。例えば、全 outboundツールを常に「確認」する従来のポリシーでは、120件の通常タスクに対して176回の確認プロンプトが表示されたが、TaintGuardのデフォルト設定ではわずか22回に減少し、しかもそれらのプロンプトはすべて、実際にプライベートな第三者コンテンツがセッションに含まれている状況で表示された。これにより、ユーザーはより的確な状況で、より意味のある判断を下すことができるようになる。

ただし、TaintGuardにもいくつかの限界がある。一つは、シンク（制限の対象）が「ツール」であり、「データの転送先」ではない点だ。例えば、エージェントが内部のドキュメントフォルダにデータを書き込み、それが後からCI/CDパイプラインによって外部に公開されるようなケースは、TaintGuardのデフォルト設定では防ぎきれない。また、GitHubのような、メール以外の注入経路となる可能性のあるサーバーがデフォルトのソースとして認識されていないため、Invariant Labsによるような攻撃はデフォルト設定では防げない。これらはユーザーがカスタムポリシーを追加することで対応可能だが、設定の手間はかかる。さらに、「Rule of Two」の解釈を狭くしたことにより、ウェブページを閲覧した後に、プライベートデータを含まないセッションでBashがWebFetchなしで実行され、機密情報を外部に送信するような特定のシナリオでは、TaintGuardのデフォルト設定では阻止できない場合もある。これは、ウェブ検索の後でもBashを使いやすくするための設計上のトレードオフだが、より厳格な設定「strict」を使えば防ぐことはできる。

TaintGuardは現在、プラグインとして提供されており、Claude Codeに導入することができる。今後の課題としては、サブエージェント（親エージェントから呼び出される子エージェント）間での汚染情報の共有や、ファイルレベルでのより詳細な汚染追跡などが挙げられる。そして最も根本的な課題は、最終的にユーザーに提示される「確認プロンプト」の改善だ。TaintGuardはプロンプトの数を減らし、その内容をより文脈に沿ったものにすることでユーザーの判断を助けるが、最終的には人間がセキュリティの境界線の一部を担うことになる。AIエージェントを安全に利用するためには、技術的な対策と人間の判断力の両方が不可欠だ。