エージェント型アーキテクチャにおけるセキュリティ境界

現在、ほとんどのエージェントは、あなたの機密情報に完全にアクセスできる状態で生成されたコードを実行しています。 より多くのエージェントがコーディングエージェントパターンを採用するにつれ、ファイルシステムの読み書き、シェルコマンドの実行、コード生成を行うようになり、それぞれ異なる信頼レベルを必要とするマルチコンポーネントシステムへと進化しています。 ほとんどのチームは、デフォルトのツールがそのように動作するため、これらすべてのコンポーネントを単一のセキュリティコンテキストで実行しています。しかし、私たちはこれらのセキュリティ境界について異なる考え方をすることを推奨します。 以下で説明する内容は以下の通りです: エージェントシステムにおけるアクター それらの間に設けるべきセキュリティ境界の位置 エージェントと生成コードを別々のコンテキストで実行するアーキテクチャ **すべてのエージェントがコーディングエージェントのようになりつつある** より多くのエージェントがコーディングエージェントアーキテクチャを採用しています。これらのエージェントはファイルシステムへの読み書きを行い、環境を探索するためにbashやPythonなどのプログラムを実行します。そしてますます、エージェントは特定の問題を解決するためにコードを生成するようになっています。 「コーディングエージェント」として販売されていないエージェントでさえ、最も柔軟なツールとしてコード生成を使用しています。アカウントデータを検索するためにSQLを生成して実行するカスタマーサポートエージェントは同じパターンを使用しており、単にファイルシステムではなくデータベースを対象としているだけです。スクリプトを書き、実行できるエージェントは、固定されたツール呼び出しセットに制限されたエージェントよりも、より広範な種類の問題を解決できます。 **境界がない場合の問題点** 本番環境の問題をデバッグするエージェントを考えてみてください。エージェントは、細工されたプロンプトインジェクションを含むログファイルを読み取ります。 そのインジェクションは、~/.sshと~/.aws/credentialsの内容を外部サーバーに送信するスクリプトを書くようにエージェントに指示します。エージェントはスクリプトを生成し、実行し、認証情報が失われます。 これがコーディングエージェントパターンの核心的なリスクです。プロンプトインジェクションは攻撃者にエージェントへの影響力を与え、コード実行はその影響力をあなたのインフラストラクチャに対する任意のアクションへと変えます。エージェントは、自身のコンテキストからデータを外部に送信させられたり、悪意のあるソフトウェアを生成させられたり、その両方をさせられたりする可能性があります。その悪意のあるソフトウェアは、認証情報を盗んだり、データを削除したり、エージェントが実行されているマシンから到達可能なあらゆるサービスを侵害したりする可能性があります。 この攻撃が機能するのは、エージェント、エージェントが生成するコード、およびインフラストラクチャがすべて同じレベルのアクセス権を共有しているためです。適切な場所に境界を引くには、これらのコンポーネントが何であり、それぞれがどのレベルの信頼に値するかを理解する必要があります。 **エージェントシステムにおける4つのアクター** エージェントシステムには4つの異なるアクターがあり、それぞれ異なる信頼レベルを持っています。 **エージェント** エージェントは、そのコンテキスト、ツール、モデルによって定義されるLLM駆動のランタイムです。エージェントはエージェントハーネス内で実行されます。ハーネスとは、標準的なSDLCを通じて構築・デプロイするオーケストレーションソフトウェア、ツール、外部サービスへの接続のことです。ハーネスは、他のバックエンドサービスを信頼するのと同じように信頼できますが、エージェント自体はプロンプトインジェクションや予測不可能な動作の影響を受けます。情報は必要に応じて開示されるべきです。つまり、エージェントはSQLを実行するツールを使用するためにデータベース認証情報を見る必要はありません。 **エージェントの機密情報** エージェントの機密情報は、システムが機能するために必要な認証情報であり、APIトークン、データベース認証情報、SSHキーなどが含まれます。ハーネスはこれらを責任を持って管理しますが、他のコンポーネントが直接アクセスできるようになると危険になります。以下のアーキテクチャ全体の議論は、どのコンポーネントがこれらの機密情報へのパスを持っているかに帰着します。 **生成コード実行** エージェントが作成・実行するプログラムはワイルドカードです。生成コードは言語ランタイムが許可するあらゆることを実行できるため、最も推論が難しいアクターとなります。これらのプログラムは外部サービスと通信するために認証情報を必要とするかもしれませんが、生成コードに直接機密情報へのアクセスを与えることは、プロンプトインジェクションやモデルエラーが認証情報の盗難につながる可能性があることを意味します。 **ファイルシステム** ファイルシステムとより広範な環境は、システムが実行される基盤であり、ラップトップ、VM、またはKubernetesクラスターなどです。環境はハーネスを信頼できますが、セキュリティ境界なしにエージェントが完全なアクセス権を持ったり任意のプログラムを実行したりすることを信頼することはできません。 これら4つのアクターは、すべてのエージェントシステムに存在します。問題は、それらの間にセキュリティ境界を引くか、すべてを同じ信頼ドメインで実行させるかです。 これらの信頼レベルから、いくつかの設計原則が導かれます: * ハーネスは自身の認証情報をエージェントに直接公開してはならない * エージェントはスコープ化されたツール呼び出しを通じて機能にアクセスすべきであり、それらのツールは可能な限り狭くあるべきです。特定の顧客のサポート業務を行うエージェントは、その顧客のデータにスコープ化されたツールを受け取るべきであり、顧客IDパラメータを受け入れるツールを受け取るべきではありません。なぜなら、そのパラメータはプロンプトインジェクションの影響を受ける可能性があるからです。 * 独自の認証情報を必要とする生成プログラムは別の問題であり、以下のアーキテクチャで対処します これらのアクターと原則を念頭に置いて、以下に、実践で見られるアーキテクチャを、最も安全でないものから最も安全なものの順に示します。 **ゼロ境界: 現在のデフォルト** Claude CodeやCursorのようなコーディングエージェントはサンドボックスを同梱していますが、これらはデフォルトではオフになっていることが多いです。実際には、多くの開発者がセキュリティ境界なしでエージェントを実行しています。 このアーキテクチャでは、4つのアクターの間に境界はありません。エージェント、エージェントの機密情報、ファイルシステム、生成コード実行はすべて単一のセキュリティコンテキストを共有しています。開発者のラップトップでは、エージェントが.envファイルやSSHキーを読み取れることを意味します。サーバーでは、環境変数、データベース認証情報、APIトークンへのアクセスを意味します。生成コードはこれらのいずれも盗んだり、データを削除したり、環境が到達可能なあらゆるサービスに到達したりできます。ハーネスは特定のアクションの前にユーザーに確認を求めるかもしれませんが、ツールが実行されると強制される境界はありません。 **サンドボックス化なしのシークレットインジェクション** シークレットインジェクションプロキシは、主要なセキュリティ境界の外側に位置し、外向きのネットワークトラフィックを傍受し、リクエストが目的のエンドポイントに移動する際にのみ認証情報を注入します。ハーネスは認証情報とドメインルールでプロキシを設定しますが、生成コードは生の機密情報の値を決して見ることはありません。 プロキシは外部への漏洩を防ぎます。機密情報は実行コンテキストからコピーされて他の場所で再利用されることはありません。しかし、プロキシはアクティブなランタイム中の誤用を防ぐことはできません。生成されたソフトウェアは、システムが実行中に注入された認証情報を使用して予期しないAPI呼び出しを依然として行う可能性があります。 シークレットインジェクションは、ゼロ境界アーキテクチャからの後方互換性のある経路です。コンポーネントの実行方法を再構築することなくプロキシを追加できます。トレードオフは、エージェントと生成コードが、機密情報自体を除くすべてにおいて依然として同じセキュリティコンテキストを共有していることです。 **すべてを一緒にサンドボックス化するだけでは不十分な理由** 自然な直感は、エージェントハーネスと生成コードを共有のVMまたはサンドボックスにラップすることです。共有サンドボックスは両方をより広範な環境から隔離し、それは確かに有用です。生成プログラムはより広範なインフラストラクチャに侵入できません。 しかし、共有サンドボックスでは、エージェントと生成プログラムは依然として同じセキュリティコンテキストを共有しています。生成コードは依然としてハーネスの認証情報を盗むことができます。または、シークレットインジェクションプロキシが配置されている場合、プロキシを通じて認証情報を誤用することができます。サンドボックスは環境をエージェントから保護しますが、エージェントを自身の生成コードから保護することはできません。 **エージェントコンピュートとサンドボックスコンピュートの分離** 不足している部分は、エージェントハーネスとエージェントが生成するプログラムを、独立したコンピュート上で、異なるセキュリティコンテキストを持つ別々のVMまたはサンドボックスで実行することです。ハーネスとハーネスの機密情報は一つのコンテキストに存在します。ファイルシステムと生成コード実行は別のコンテキストに存在し、エージェントの機密情報へのアクセスはありません。 Claude CodeとCursorの両方が現在サンドボックス実行モードを提供していますが、デスクトップ環境での採用は低いままです。なぜなら、サンドボックス化は互換性の問題を引き起こす可能性があるからです。クラウドでは、この分離はより実用的です。エージェントが実行する必要があるソフトウェアのタイプに合わせて調整されたVMを生成コードに与えることができ、実際に互換性を向上させることができます。 実際には、この分離は簡単な変更です。エージェントは抽象化レイヤーを通じてツール呼び出しを実行し、その抽象化により、エージェント自体を書き直すことなく、コード実行を別の環境にルーティングすることが自然になります。 これら2つのワークロードは非常に異なるコンピュートプロファイルを持っているため、それらを分離することでそれぞれを独立して最適化できます。エージェントハーネスは、ほとんどの時間をLLM API応答を待つことに費やします。Vercelでは、Fluid computeはこのワークロードに自然に適合します。なぜなら、課金はI/O中に一時停止し、アクティブなCPU時間のみをカウントするため、アイドル時間ではなく実際の作業に比例したコストを維持できるからです。 生成コードは逆のプロファイルを持っています。エージェントが作成するプログラムは短命で、予測不可能で、信頼されていません。各実行には、クリーンで隔離された環境が必要です。そうすることで、あるプログラムが別のプログラムが残した機密情報や状態にアクセスできないようにします。Vercel Sandboxのようなサンドボックス製品は、実行ごとに起動し、その後破棄されるエフェメラルLinux VMを通じてこれを提供します。VM境界がセキュリティコンテキストの分離を強制します。サンドボックス内の生成コードは、ハーネスの機密情報へのネットワークパスも、ホスト環境へのアクセスも持っていません。 サンドボックスは双方向に機能します。サンドボックスはエージェントの機密情報を生成コードから保護し、より広範な環境を生成コードが行うことから保護します。 **シークレットインジェクションを伴うアプリケーションサンドボックス** 最も強力なアーキテクチャは、アプリケーションサンドボックスとシークレットインジェクションを組み合わせたものです。この組み合わせは、どちらか一方だけでは達成できない2つの特性を与えます: 1. エージェントハーネスと生成プログラムの完全な分離、それぞれが独自のセキュリティコンテキストで実行される 2. 生成されたコードは、実行中にインジェクションプロキシを通じてシークレットを使用できますが、資格情報への直接アクセスはなく、それらを読み取ったり外部に流出させたりすることはできません。インジェクションされたヘッダーは、サンドボックスコードが同じ名前で設定したヘッダーを上書きし、資格情報の置き換え攻撃を防ぎます。 本番環境のエージェントシステムでは、両方を組み合わせることをお勧めします。エージェントハーネスは、標準的なコンピュート上で信頼されたソフトウェアとして実行されます。生成されたコードは、隔離されたサンドボックス内で実行されます。シークレットはネットワークレベルでインジェクションされ、生成されたコードがシークレットに直接アクセスできる場所に公開されることはありません。 エージェントコンピュートとサンドボックスコンピュートのこの分離は、エージェントシステムの標準アーキテクチャになるでしょう。デフォルトのツールがこれを強制しないため、ほとんどのチームはまだこの移行を行っていません。エージェントがより機密性の高いワークロードを引き受けるにつれて、今これらの境界線を引くチームは、意味のあるセキュリティ上の優位性を持つことになります。 安全なシークレットインジェクションは、Vercel Sandboxで利用可能になりました。詳細については、ドキュメントをお読みください。

エージェント型アーキテクチャにおけるセキュリティ境界

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト