AIエージェントが有用なのは、それがアクションを取れるからです。それが要点です。エージェントにツールへのアクセス権を与えると、メッセージを送信する、レコードを更新する、ファイルを検索する、クエリを実行する、コミットをプッシュするといった操作を行えます。デモは印象的です。しかし、実際のデプロイメントを、その下にあるセキュリティモデルを詳しく見ると、話は違ってきます。
今、誰も十分に大きな声で問いかけていない質問はシンプルです。AIエージェントがデータベース、メール、カレンダー、Salesforceのインスタンス、GitHubリポジトリへの書き込みアクセス権を持っているとき、やってはいけないことをするのを何が止めているのか？ほとんどの場合、正直な答えはシステムプロンプトの一文です。
それが現状です。
モデルに行儀よくするよう伝えることの問題
今日AIエージェントをデプロイする際、標準的なセキュリティの実践はシステムプロンプトに指示を書き込むことです。モデルに何が許可されていないかを伝えます。どのツールが使用禁止かを伝えます。破壊的なアクションを取る前に確認するよう伝えます。一部のプラットフォームではUIを通じてこれらの指示を設定できますが、基本的なメカニズムは同じです。モデルにルールブックを与えて、それに従ってくれると信頼しています。
このアプローチには根本的な欠陥があります。言語モデルはルールを実行しません。トークンを予測します。その区別が重要なのは、十分に巧妙に作られたプロンプトがモデルが予測するものを変えられるからです。これがプロンプトインジェクションです。特定のモデルのバグではありません。これらのシステムすべての動作方法の特性です。攻撃者がモデルのコンテキストにテキストを注入できれば、その指示はあなたの指示と競合します。モデルは、信頼できるシステムプロンプトからの指示と、要約を依頼した悪意のあるドキュメントからの指示を識別するメカニズムを持っていません。トークンだけが見えるのです。
約30万のGitHub スターを獲得し、現在おそらく最も広くデプロイされているオープンソースの個人エージェントであるOpenClawプロジェクトは、この問題を完全に露わにしています。Ciscoのセキュリティチームはサードパーティのスキルを通じたデータの外部流出を実証しました。プロジェクト自身のメンテナーは、このソフトウェアは非技術者ユーザーには「危険すぎる」と公言しました。これは極端な懸念ではありません。最も人気のあるエージェントプラットフォームの認識された状況です。
そしてOpenClawがこの点で特別なわけではありません。マイナーな変形を加えた同じアーキテクチャが市場のほとんどのエージェントプラットフォームに現れています。プラットフォームはシステムプロンプトの洗練度で異なります。含めるガードレールの指示の数で異なります。共通しているのは、それらの指示がすべて保護するはずのものの中に置かれていることです。
「モデルの外側」が実際に意味すること
アーキテクチャの代替手段は、モデルのコンテキストから強制を完全に外に移動することです。モデルに何が許可されていないかを伝えて従ってくれることを願うのではなく、モデルが取れるすべてのアクションの間にゲートを置きます。モデルはリクエストを生成します。ゲートはそのリクエストをルールのセットに対して評価し、実行するかどうかを決定します。アクションが許可されるべきかどうかについてのモデルの意見は、その評価の一部ではありません。
声に出して言うと明白に聞こえます。他のすべてのセキュリティに敏感なソフトウェアシステムが機能する方法です。窓口係に「アカウントを持っていない人にはお金を渡さないでください」と伝えることで銀行のセキュリティを確保するわけではありません。不正な引き出しをアカウント保有者が何を伝えられても不可能にする技術的なコントロールを置くのです。窓口係の行動はソーシャルエンジニアリング攻撃によって影響を受ける可能性があります。コントロールは影響を受けません。なぜなら、コントロールは会話をしないからです。
Triggerfishでは、強制レイヤーはすべての重要な操作の前後で実行されるフックのセットを通じて機能します。ツール呼び出しが実行される前に、フックは現在のセッション状態を踏まえてその呼び出しが許可されているかどうかを確認します。出力がチャンネルに到達する前に、フックは流れ出るデータがそのチャンネルに適したレベルで分類されているかどうかを確認します。外部データがコンテキストに入る前に、フックはそれを分類してセッションのTaintレベルをそれに応じて更新します。これらのチェックはコードにあります。会話を読みません。何かを説得することはできません。
セッションのTaintとその重要性
データ分類はセキュリティでよく理解されているコンセプトです。それを処理すると主張するほとんどのプラットフォームは、リソースに分類を割り当て、要求元のエンティティがアクセスする権限を持っているかどうかを確認します。それはある程度役立ちます。見逃しているのは、アクセス後に何が起きるかです。
AIエージェントが機密文書にアクセスすると、その機密データは今やそのコンテキストにあります。それはセッションの残りの間、エージェントの出力と推論に影響を与える可能性があります。エージェントが別のタスクに移ったとしても、機密コンテキストはまだそこにあります。エージェントがより低く分類されたチャンネルでアクションを取るなら、パブリックのSlackチャンネルへの書き込み、外部アドレスへのメールの送信、webhookへのポスト、その機密データを一緒に運ぶことができます。これがデータ漏洩であり、元のリソースへのアクセス制御はそれを防ぐために何もしませんでした。
Taint追跡はこのギャップを埋めるメカニズムです。Triggerfishでは、すべてのセッションはPUBLICから始まるTaintレベルを持ちます。エージェントがより高い分類レベルのデータに触れた瞬間、セッションはそのレベルに汚染されます。Taintは上がるだけです。セッション内で下がることはありません。したがって、CONFIDENTIALな文書にアクセスしてからPUBLICチャンネルにメッセージを送ろうとすると、write-downチェックが汚染されたセッションレベルに対して発火します。モデルが言ったことのためではなく、システムがどのデータが関与しているかを知っているために、アクションはブロックされます。
モデルはこのメカニズムについての知識を持っていません。それを参照したり、推論したり、操作しようとしたりすることはできません。Taintレベルは、コンテキストではなく強制レイヤーに存在するセッションに関する事実です。
サードパーティツールは攻撃対象領域
現代のAIエージェントを本当に有用にする機能の1つは、その拡張性です。ツールを追加できます。プラグインをインストールできます。Model Context Protocolを通じてエージェントを外部サービスに接続できます。追加するインテグレーションのたびに、エージェントができることが広がります。追加するインテグレーションのたびに、攻撃対象領域も広がります。
ここでの脅威モデルは仮説的なものではありません。エージェントがサードパーティのスキルをインストールでき、そのスキルが未知の当事者によって配布されていて、エージェントのセキュリティモデルがコンテキスト内の指示をモデルが尊重することに完全に依存しているなら、悪意のあるスキルはインストールされるだけでデータを外部流出させることができます。スキルは信頼境界の内側にあります。モデルは、両方がコンテキストに存在する場合、正当なスキルと悪意のあるスキルを区別する方法を持っていません。
Triggerfishでは、MCPゲートウェイはすべての外部ツール接続を処理します。すべてのMCPサーバーは呼び出される前に分類されなければなりません。UNTRUSTEDサーバーはデフォルトでブロックされます。外部サーバーからのツールがデータを返すと、そのレスポンスはPOST_TOOL_RESPONSEフックを通じて、レスポンスを分類してセッションのTaintをそれに応じて更新します。プラグインサンドボックスはDenoとWebAssemblyのダブルサンドボックス環境でプラグインを実行し、ネットワークの許可リスト、ファイルシステムへのアクセスなし、システム認証情報へのアクセスなしで動作します。プラグインはサンドボックスが許可することしかできません。サイドチャンネルは利用できないため、サイドチャンネルを通じてデータを外部流出させることはできません。
これらすべての要点は、システムのセキュリティプロパティがプラグインが信頼できることに依存しないということです。サンドボックスと強制レイヤーに依存しており、それらはプラグインが含むものによって影響を受けません。
監査の問題
今日AIエージェントのデプロイメントで何かがうまくいかない場合、どのように知るのでしょうか？ほとんどのプラットフォームは会話をログに記録します。一部はツール呼び出しをログに記録します。セッション中に行われたセキュリティ上の決定を、どのデータがどこに流れたか、どの分類レベルで、ポリシーが違反されたかどうかを正確に再構築できる方法でログに記録しているものは非常に少ないです。
これは見た目以上に重要です。AIエージェントが安全かどうかという問題は、リアルタイムで攻撃を防ぐことだけではないからです。エージェントが定義された境界内で動作したことを事後的に示せることにも関わります。機密データを扱う組織にとって、その監査証跡はオプションではありません。コンプライアンスを証明し、インシデントに対応し、扱っているデータを持つ人々との信頼を構築する方法です。
Triggerfishはすべての操作に完全なデータ系列を維持します。システムに入るすべてのデータは出所メタデータを持ちます：どこから来たか、どの分類が割り当てられたか、どの変換を通過したか、どのセッションに結びついていたか。任意の出力を、それを生成した操作のチェーンを通じて遡ることができます。特定のレスポンスにどのソースが貢献したかを問うことができます。規制上のレビューのために完全な管理の連鎖をエクスポートできます。これは従来の意味でのロギングシステムではありません。データフロー全体を通じて最優先事項として維持される出所システムです。
実際の問題
AIエージェントのカテゴリーは急速に成長しています。プラットフォームはより有能になっています。ユースケースはより重要になっています。人々は本番データベース、顧客レコード、財務システム、内部コミュニケーションプラットフォームへの書き込みアクセス権を持つエージェントをデプロイしています。これらのデプロイメントの多くの基礎となる仮定は、よく書かれたシステムプロンプトが十分なセキュリティであるということです。
それは十分ではありません。システムプロンプトはテキストです。テキストは他のテキストによって上書きされる可能性があります。エージェントのセキュリティモデルがモデルが指示に従うというものであれば、確率的で制御できない入力によって影響を受ける可能性のある行動的なコンプライアンスに依存しています。
検討しているすべてのエージェントプラットフォームに問う価値のある質問は、強制が実際にどこにあるかです。答えがモデルの指示にある場合、それはエージェントが触れることのできるデータの機密性と、それを操作しようとする可能性のある人々の巧妙さに応じてスケールする意味のあるリスクです。答えがモデルとは独立して実行され、いかなるプロンプトでも到達できないレイヤーにある場合、それは別の状況です。
あなたのシステムのデータは本物です。エージェントがそれを外部流出させるのを誰が止めているかという問いに、本物の答えを与える価値があります。