AIエージェントの隠れた脅威: Y Combinatorで7つのエージェントを30分でハッキングしたCascoのレッドチームが語る、現代のセキュリティ課題

AI技術の進化は目覚ましく、私たちの働き方、生活、そしてビジネスのあり方を根本から変えようとしています。特に「AIエージェント」と呼ばれる自律的なシステムは、その複雑なタスク遂行能力によって、新たな生産性のフロンティアを切り開くと期待されています。しかし、この革新の波の裏側で、私たちは新たな、そして見過ごされがちなセキュリティの課題に直面しています。

「AI Engineer World's Fair」でCascoのファウンダー兼CEOであるRene Brandel氏が披露した衝撃的なプレゼンテーションは、その警鐘を鳴らすものでした。彼らはY Combinatorの内部でローンチされた16のAIエージェントのうち、わずか30分という制限時間内に7つをハッキングしてみせたのです。この「レッドチーム演習」によって浮き彫りになったのは、AIエージェントが持つ一般的なセキュリティ上の盲点であり、今後のAI開発において私たちが真剣に向き合うべき喫緊の課題です。

本記事では、Cascoの経験から得られた洞察をもとに、AIエージェントのセキュリティに関する重要性、具体的な脅威ベクトル、ビジネスへの影響、そして将来の展望について、専門的かつ分かりやすく解説します。

講演者紹介とCascoのミッション: AIセキュリティの最前線から

Rene Brandel氏は、AI分野における深い経験を持つ人物です。かつてAWSとMicrosoftでAIエージェントの開発に携わった後、Cascoを設立し、現在はY Combinatorの支援を受ける企業としてAIエージェントのレッドチーム化（敵対的テスト）を専門としています。

彼のAIへの情熱は10年以上前から始まりました。彼は10年前に開催されたハッカソンで、音声からコードを生成する「Voice-to-Code」システムを開発し、ヨーロッパ最大のハッカソンで優勝しました。当時はまだ「生成AI」という言葉は存在せず、APIも極めて遅く、複雑なシステムを構築するのは至難の業でした。しかし、彼はその時から技術が向上すれば、この種のシステムが未来を形作るであろうと予感していました。

この経験は、CascoがなぜAIエージェントのセキュリティに特化するに至ったかの根源にあります。AI技術の可能性を深く理解しているからこそ、その危険性にも誰よりも敏感なのです。

AIエージェントシステムの進化: 複雑なアーキテクチャから標準化されたスタックへ

Rene氏が10年前に開発したハッカソンエージェントのアーキテクチャは、その時代の技術的制約を反映したものでした。Reactアプリケーションを核に、ChromeのSpeech Recognition API、AzureのMicrosoft LUIS、Google Natural Language API、さらにはIBM Watsonといった複数のクラウドプロバイダーのAPIを複雑に連携させていました。これらのパーツを組み合わせる作業は困難を極め、一つの機能を実現するためにも多くの労力を要しました。

しかし、現代のAIエージェントのアーキテクチャは大きく進化し、ある程度の「正規化」が進んでいます。現在の典型的なエージェントスタックは、以下のような要素で構成されています。

Frontend: ユーザーが直接操作するインターフェース。
API Server: フロントエンドからのリクエストを受け付け、バックエンド処理を調整するハブ。
LLM (Large Language Model): エージェントの「脳」として機能し、ユーザーの意図を理解し、思考や行動計画を生成。
Tools: LLMが利用できる外部サービスや内部機能（例：データベース操作、コード実行、外部API呼び出し）。
Database: 永続的なデータストレージ。
Containers (code execution): 必要に応じてコードを実行するための隔離環境。
External Data Sources: 外部のデータプロバイダー。

このスタックの正規化は、AIエージェントの開発を以前よりもはるかに容易にしました。しかし、同時に新たなセキュリティの課題も生み出しています。

LLMセキュリティの落とし穴: エージェントセキュリティの全体像

LLMのセキュリティに関する議論は、これまで「プロンプトインジェクション」や「有害コンテンツの生成」といったLLMモデル自体への攻撃に焦点が当てられることがほとんどでした。これらは確かに重要な問題ですが、Rene氏は「Agent SecurityはLLM Securityよりも大きい」と警鐘を鳴らします。

真のエージェントセキュリティは、システム全体を包括的に捉える必要があります。LLMだけでなく、APIサーバー、データベース、ツール、外部データソースなど、図で示される全てのコンポーネントとその間のデータフロー（矢印）がセキュリティ評価の対象となります。これらのインタラクションのどこかに脆弱性が潜んでいる可能性があり、そこから深刻なダメージが発生するのです。

Cascoのハッキングプロセスと驚くべき結果: 3つの共通の脆弱性

CascoがY Combinator内でAIエージェントのハッキングを行った目的は、単に悪用するためだけではありませんでした。彼らは、Y Combinatorの社内ローンチで「ハッキング」というキャッチーな見出しで注目を集め、自分たちのセキュリティ専門知識をアピールすることを狙いました。結果として、彼らのローンチポストはY Combinatorの歴史上2番目に多くアップボートされるという成功を収めました。

彼らのハッキングプロセスは以下の通りです。

タイマー設定: 各エージェントにつき30分という時間制限を設定。
偵察 (Recon): 企業が最も避けたいであろう事態（例：システムプロンプトの漏洩）を特定。
計画 (Plan): エージェントが利用するツールやパラメータを分析し、セキュリティ上のギャップを特定。
悪用 (Exploit): 特定した脅威パターンに対して実際に攻撃を試行し、結果を確認。

この迅速なプロセスにより、彼らはローンチされた16個のAIエージェントのうち、実に7個をハッキングすることに成功しました。そして、これらのハッキングから、AIエージェントシステムに共通する3つの重大なセキュリティ問題が浮上しました。

問題1: 不注意な情報共有 - Cross-User Data Access (IDOR)

最初の問題は「Cross-User Data Access」、すなわち不適切なユーザー間データアクセス、より具体的には「IDOR（Insecure Direct Object Reference）」でした。

具体的な脆弱性: Cascoの調査により、多くの場合、エージェントシステムが持つツール（例：_DOCUMENT、_USER_INFO）が、特定のID（例：document_id、user_id）を介して情報（ドキュメントコンテンツやユーザー情報）を取得できることが判明しました。ここで問題なのは、IDの有効性のみを検証し、リクエスト元のユーザーがそのIDによって示されるリソースにアクセスする権限（認可）を持っているかを適切に確認しない点です。

悪用シナリオ: Rene氏は、ある企業のプロダクトデモ動画から、URLバーに表示されているユーザーIDを抽出しました。そのIDをエージェントのチャットインターフェースにペーストするだけで、エージェントは即座にそのユーザーのフルネームやメールアドレスといった個人情報を取得してしまいました。さらに、チャットIDや他のドキュメントIDも取得可能であることが判明し、この脆弱性を通じてシステム全体を横断的に調査し、機密情報にアクセスできる可能性が示唆されました。

本質的な問題: これはWebアプリケーションセキュリティの古典的な問題であり、システムがユーザーの「認証（Authentication）」は確認するが、「認可（Authorization）」を怠ることで発生します。つまり、「あなたは誰か」は確認しても、「あなたは何ができるか」を適切にチェックしていない状態です。

対策: この問題に対する解決策は明確です。「認証だけでなく、認可も行うこと」。API呼び出しが行われる際には、リクエスト元のユーザーがそのリソースに対する適切なアクセス権を持っているか、ロールレベルセキュリティ（RLS）などの厳格なアクセス制御メカニズムを用いて確認する必要があります。エージェントシステムの設計段階から、この二段階のチェックを徹底することが不可欠です。

問題2: 危険なコードサンドボックス - 自由は諸刃の剣

2つ目の問題は「Bad Code Sandboxes」、すなわち不適切なコード実行環境の隔離です。これは、深刻な被害につながる可能性が高い脆弱性です。

本質的な原則: Rene氏は、AIエージェントを構築する上で最も重要な原則の一つとして、「エージェントはユーザーのように振る舞うべきであり、APIサーバーのように振るべきではない」と強調します。開発者はしばしば、エージェントに広範な「サービスレベルの権限」を与えがちですが、これはユーザーが持つべき最小限の権限とは大きく異なります。エージェントは過剰な権限を持つことで、悪用された際にシステム全体に甚大な被害をもたらす可能性があります。

エージェントが避けるべきこと:

LLMが認証パターンを決定すること。
サービスレベルの権限で動作すること。
LLMへのあらゆる入力を無制限に受け入れること。
LLMの出力をサニタイズ（無害化）なしに転送すること。

具体的な脆弱性: AIエージェントがコードを生成し、それを実行するための「コーディングツール」を持つ場合、その実行環境（サンドボックス）が適切に隔離されていないと大きなリスクが生じます。Anthropicの調査（AI usage by job type）によれば、コンピュータ・数学分野のAI利用率が突出して高いことから、多くのAIエージェントがコード生成・実行能力を持っていることが伺えます。

ここで問題となるのは、エージェントがツールを通じて別のコンテナ（コードサンドボックス）と連携し、そのコンテナ内で任意のコードが実行可能になる経路です。コンテナは「任意の計算」を実行できるため、セキュリティ対策が不十分だと、攻撃者にとって格好の足がかりとなります。

悪用シナリオ: Cascoは、あるエージェントのシステムプロンプトから「コーディングツール」がバックグラウンドで使用されていることを特定しました。そのプロンプトには、「ファイルを編集する際、ユーザーにコードを決して出力してはならない。代わりに、コード編集ツールを1ターンに多くても1回使用すること」という指示がありました。攻撃者はこの指示を逆手に取り、まさに開発者が望まない行動を取るようにエージェントを誘導しました。

さらに、このエージェントを運用する企業は、以下の保護策を講じていました。

Pythonコードのみを許可。
eval()、exec()、__import__などの危険なPython関数を禁止。
実行可能な.pyファイルを制限。

しかし、Cascoはこれらの防御策を回避しました。彼らは、コードサンドボックス内で実行されるメインのPythonファイル（app.py）を発見し、そのセキュリティチェックを行う部分を空文字列で上書きしました。これにより、全てのセキュリティチェックが無効化され、任意のコード実行が可能になりました。

結果: 任意のコード実行を達成したCascoは、コンテナ内からクラウド環境のメタデータサービスにアクセスし、GCPプロジェクトの発見やサービスアカウントトークンの取得に成功しました。このトークンを利用して、BigQueryなどのクラウドサービスに保存されていた顧客データにアクセスすることが可能になったのです。これは、コードサンドボックスの不備が、企業の最も機密性の高い情報へのアクセスを許してしまうという、最悪のシナリオを示しています。

対策: この脆弱性に対する最も重要な教訓は、**「独自のコードサンドボックスを構築しないこと」**です。コードサンドボックスのセキュリティを確保することは極めて難しく、コンテナのような技術だけでは十分な隔離層を提供できません。セキュリティの専門家によって設計・管理されたマネージドサービス（Rene氏は可観測性が組み込まれ、高速起動し、MCPサーバーを持つBlaxelのようなソリューションを推奨）を利用するべきです。適切な分離、徹底した可観測性、そして迅速な起動が、安全なコード実行環境には不可欠です。

問題3: 見落とされがちな連携の隙間 - Server-Side Request Forgery (SSRF) による情報漏洩

最後の問題は「Tool call leading to server-side request forgery (SSRF)」、つまりツール呼び出しがサーバーサイドリクエストフォージェリ（SSRF）につながるというものです。これは、システム内の信頼されたコンポーネントが、攻撃者の制御下にある外部リソースに意図せず情報を送信してしまう脆弱性です。

具体的な脆弱性: Cascoは、あるエージェントがバックグラウンドで「データベース作成」ツールを使用していることを発見しました。このツールは、データベーススキーマをプライベートなGitHubリポジトリからプルする機能を持ち、その際にGit認証情報を渡していることが判明しました。ここで問題なのは、リポジトリのURLが単純な文字列として入力可能であり、その文字列に対する入力検証が不十分である点です。

悪用シナリオ: 攻撃者は、git_repoパラメータに、自らが管理する悪意のあるサーバー（例：https://bad-actor.com/test.git）のURLを設定して「データベース作成」ツールを呼び出します。すると、エージェントシステムは、この悪意あるサーバーにGit認証情報（プライベートリポジトリにアクセスするためのトークンなど）を送信してしまいます。攻撃者はこの認証情報を傍受することで、企業のプライベートなソースコードリポジトリにアクセスし、その内容をダウンロードすることが可能になります。これは、信頼された内部システムが、外部の悪意あるエンティティに情報を漏洩させてしまう典型的なSSRF攻撃です。

本質的な問題: SSRFは、システムの内部ネットワークリソースや、外部リソースへのアクセスにおいて、入力が適切に検証・サニタイズされていない場合に発生します。内部からのリクエストは信頼できるという前提が、攻撃者に悪用される隙を与えてしまうのです。

結果: CascoのSlackグループでの報告に対し、バッチメイトからは「心配ない、もう修正済みだ」という返信がありました。これは、彼らがこの脆弱性を認識し、迅速に対応したことを示唆していますが、同様の脆弱性が多くのAIエージェントシステムに存在する可能性を浮き彫りにしています。

対策: この脅威に対処するためには、**「入力と出力を常にサニタイズすること」**が絶対条件です。特に、エージェントが外部リソースを呼び出すツールを使用する場合、そのURLやパラメータに対する厳格な入力検証が必要です。信頼できないソースからの入力がシステム内部のリソースや、企業の許可しない外部リソースにアクセスできないよう、ホワイトリスト方式を採用するなど、厳重なチェックを導入することが求められます。これはWeb開発の基本原則ですが、AIエージェントの文脈ではその重要性が再認識されます。

結論: AI時代のセキュリティを再考する

Cascoのプレゼンテーションは、AIエージェントのセキュリティが、LLMモデル単体の問題に留まらない、より広範で複合的な課題であることを明確に示しました。私たちがこの新しい技術パラダイムを安全に活用するためには、以下の主要なポイントを深く理解し、実践する必要があります。

Agent Security > LLM Security: LLMモデル自体のセキュリティも重要ですが、エージェントがLLM、APIサーバー、データベース、ツール、外部データソースといった複数のコンポーネントとどのように連携し、データをやり取りするのか、システム全体のセキュリティポスチャーを理解することが不可欠です。
エージェントをユーザーとして扱う (認証とサニタイズ): エージェントには人間と同じように、適切な認証（Authentication）と認可（Authorization）の仕組みを適用し、過剰な権限を与えないようにすべきです。また、ユーザーからの入力と同様に、エージェントが生成する入力や出力も常にサニタイズし、潜在的な悪用を防ぐ必要があります。
独自のコード実行エンジンを構築しない: コードを実行するサンドボックス環境のセキュリティを完全に確保することは極めて困難です。独自のコード実行エンジンを構築するのではなく、FirecrackerのようなマイクロVM技術や、Cascoが推奨するBlaxelのような、セキュリティ専門家によって設計・管理されたマネージドサービスを利用すべきです。

これらの教訓は、従来のWebアプリケーションセキュリティのベストプラクティスと共通する部分が多いですが、AIエージェントという新しい技術パラダイムにおいては、より深く、包括的な視点での適用が求められます。AIエージェントは自律的に行動し、複雑な推論を行うため、セキュリティの盲点は予期せぬ形で露呈し、従来のシステムよりも深刻な影響をもたらす可能性があります。

未来のAIシステムを安全に構築するためには、AI開発者、セキュリティ専門家、そして運用チームが密接に協力し、従来のセキュリティ原則をAI固有の課題に合わせて進化させていく必要があります。これにより、AIエージェントが真に信頼できる存在となり、その計り知れない可能性を最大限に引き出すことができるでしょう。

Cascoからの提案: エージェントセキュリティ診断

自社のAIエージェントのセキュリティについて懸念がある場合、Cascoのような専門家に相談することを検討してみてはいかがでしょうか。Cascoは、他のAIエージェントを積極的に攻撃し、どこに脆弱性が存在するのかを特定するAIエージェントを構築しています。彼らの専門知識と革新的なアプローチは、あなたのAIシステムを安全に保つための強力な味方となるでしょう。

詳細については、casco.comを訪問するか、Rene Brandel氏のLinkedInまたはX/Twitterで最新情報を確認してみてください。