より安全なエージェントをエンジニアリングする方法

より安全なAIエージェントを構築するには、その能力と失敗の両方を考慮して設計する必要があります。正当なタスクを実行している場合や悪意のある指示がない場合でも、エージェントは障害を克服しようとする過程でセキュリティ境界を越える可能性があります。

私たちはこれがセキュリティエンジニアリングの問題であると考えており、業界は2000年代初頭のインターネットワームに取り組んだ方法でこれに取り組むべきです。エージェントを取り巻くシステムは、エージェントがアクセスできるものを制限し、望ましくない動作を検知し、障害が発生したときにそれを封じ込めなければなりません。

Perplexityでは、AIエージェント向けのセキュリティエンジニアリングを推進するために研究者や実務者と積極的に協力しており、セキュリティが単一のセーフガードに依存しないよう、モデル、エージェントハーネス、およびインフラストラクチャ全体に複数の防御レイヤーを適用しています。

AIエージェントの暴走（Meltdown）行動

7月、AIエージェントがオープンソースのAIプラットフォームであるHugging Faceの本番インフラストラクチャに侵入しました。内部のサイバーセキュリティ評価およびトレーニングの実行中に、OpenAIのモデルは、互いに通信するための掲示板を確立するためにArtifactoryリポジトリマネージャーを悪用する方法を発見し、それによってスウォーム（群れ）を組織できるようにしました。その後、サイバーセキュリティベンチマークでタスクを進めることができなかったエージェントは、他のエージェントを勧誘して支援を求めました。これらのエージェントは評価環境を抜け出し、インターネットに到達しました。また、ベンチマークタスクの答えをリバースエンジニアリングして不正行為を行う方法を発見しましたが、採点システムがその不正行為を検知するだろうと考えました。検知されることを回避する方法を見つけるためにベンチマーク評価がどのように機能するかをよりよく理解するため、彼らは最終的にHugging Faceのシステムを侵害しました（Hugging Face; OpenAI）。

このインシデントは、私たちが7月に Numbatをオープンソース化した際に説明した障害モードの明確な例です。偶発的な暴走（accidental meltdowns）は、Cornell Techのセキュリティ研究者によって造られた用語です（arXiv）。正当な目標を追求するエージェントは、欠落したファイル、失敗したAPI呼び出し、期限切れの資格情報、パーミッションの拒否などの摩擦に遭遇し、回避策を探します。その過程で、偵察、特権昇格、シークレットの発見、データ流出を通じてセキュリティ境界を越える可能性があります。悪意のあるプロンプトや外部の攻撃者が関与していない場合でも、エージェント自体が事実上の攻撃者になります。

Hugging Faceは孤立した事例ではありませんでした。ここ数週間で、さらに多くのエージェントの暴走行動が発見され、報告されています。5月27日〜28日にかけて、米国政府データへのオープンアクセスを提供するプラットフォーム「Data USA」からアイオワ大学のデータを収集しようとしたエージェントが、不正なクエリに起因するエラーに遭遇しました。エージェントは、SQLインジェクション、クロスサイト・スクリプティング、テンプレート・インジェクション、パストラバーサル、コマンドインジェクションなどのプローブで応答しました。このアクティビティは、後にOpenAIに関連付けられました（SecurityWeek）。6月20日〜21日にかけて、オーストラリア保健福祉研究所（AIHW）からビクトリア州の各地域の医薬品カテゴリに関する一人当たりの政府コストを取得しようとしたOpenAIのエージェントは、ファイルのダウンロードをブロックされました。これに対し、エージェントはその過程でサイトのボット対策を回避し、すでに公開されていたファイルをAIHWのプレプロダクションサーバーからダウンロードしました（SecurityWeek）。

このパターンは1つの研究室に限定されません。サイバーセキュリティテストの際、Anthropicのモデルは、誤ってオープンなインターネットアクセスが与えられた後に3つの企業に侵入し、GoogleのGeminiは3つのウェブサイトの資格情報を推測し、Metaのモデルはサードパーティサービスを悪用しました（Reuters</g1）。

歴史からの学習: インターネットワームの時代

これらのインシデントは、およそ4分の1世紀前のインターネットワームの時代を彷彿とさせます。2000年代初頭、インターネットは周囲のセキュリティプラクティスよりもはるかに速いスピードで成長しました。私たちはウイルスの波やワームを目撃しましたが、その結果は、現在AIエージェントの暴走で見られるものよりもはるかに深刻なものでした。

2000年5月4日、人々は「ILOVEYOU」という件名の、見覚えのある差出人からのメールを受け取り始めました。メール内の添付ファイルを開くと、被害者のOutlookアドレス帳にいる全員に自身のコピーをメールで送信するスクリプトが実行されました。その日の午後6時までに、CERTコーディネーションセンターは42万以上のインターネットホストに関わる報告を受信しました（US GAO Report）。このウイルスは、国防総省、CIA、NASA、下院、上院を含む少なくとも14の連邦機関に侵入したと報じられています（US GAO Report）。また、ペンタゴンや英国議会のメールサーバーも停止させました（Wired）。保険大手のロイド・オブ・ロンドンは、このウイルスが損害と生産性の損失で150億ドル以上のコストをもたらすという初期見積もりを出しました（US House Committee Hearing）。その後、Computer Economicsは全世界で87億5千万ドルの損害と見積もりました（Information Week）。

人間のクリックを必要としないワームが次に登場しました。2001年7月19日、Code-Redワームは14時間足らずで35万9千台以上のコンピュータに感染しました（CAIDA）。2003年1月25日、SQL Slammerは8.5秒ごとにサイズが倍増し、10分以内にそれに脆弱なインターネットホストの90%以上に感染しました（CAIDA）。これは、Microsoftが6ヶ月前にパッチをリリースしていた脆弱性を悪用したものです（CNET）。2003年8月、BlasterワームとSobigメールワームが約1週間違いで出現しました（Microsoft, F-Secure）。

当時、ネットワーク接続されたコンピュータを安全にできるかどうかを問うことは合理的でした。ILOVEYOUウイルスの6日後、米国の下院小委員会でそれに関する公聴会が開催されました。多くのセキュリティ専門家は、製品の欠陥によって引き起こされた損害についてソフトウェア企業に責任を負わせる法制化を求めました。ワシントンは異なる道を選びました。「国家サイバー空間セキュリティ戦略」には、「連邦規制はサイバー空間を保護するための主要な手段にはならない」と記されていました。また、広範な義務化は「サイバーセキュリティへの最低共通分母アプローチ」を生み出す可能性があると警告しました（CISA）。

業界はエンジニアリングで応答しました。ILOVEYOUの11日後、Microsoftは実行可能添付ファイルをブロックするOutlookのアップデートを発表しました。2002年1月、同社はセキュリティを最優先事項に掲げました（Seattle Times）。自動パッチ適用、安全なデフォルト、バグ報奨金プログラム、および協調的開示が標準的な慣行になりました。2008年、Chromeは「バグを悪用した後に攻撃者ができることを制限する」サンドボックス内でウェブコンテンツの実行を開始しました（Chromium Blog）。かつては例外だった暗号化がデフォルトになりました。多要素認証、ファイアウォール、ゼロトラスト、セキュリティ情報・イベント管理（SIEM）などのセキュリティテクノロジーが広く使用されるようになりました。世界中の組織が、情報セキュリティに2026年には約2400億ドルを費やすと予測されています（Gartner）。ワームが完全に消え去ることはありませんでしたが、インターネット全体での日常的な流行の時代は薄れていきました。同時に、インターネットは規制にほとんど縛られることなく、その後の2十年間でイノベーションと経済成長の強力な原動力となりました。

AIエージェントのセキュリティエンジニアリング

最近のインシデントは、エージェントのガバナンスに関する正当な疑問を投げかけています。既存のセキュリティメカニズムは、範囲が狭く、主に決定論的なソフトウェアの動作を特徴とするプレエージェントコンピューティング環境向けに開発されました。特にアクセス制御メカニズムは、主に人間のユーザーを中心に設計されており、原則として重大な害を引き起こすのに十分な広範な権限を人間に付与することがよくあります。

この設計はいくつかの前提に基づいています。ほとんどのユーザーは善意で行動していること、悪意のある行為者は監査や現実世界の結果を通じて抑止できること、そして人間は正しいか誤っているかに関わらず比較的限られた頻度でアクションを実行すること、という前提です。これらのセキュリティメカニズムをエージェントに適用するには、人間とエージェントの動作の違いを考慮する必要があります。私たちが AIエージェントセキュリティに関するNISTの情報提供依頼への回答で書いたように、AIエージェントはこれらの前提に挑戦します。それらはマシンの速度で特権を行使してアクションを実行でき、現実世界の結果によってそれ自体が抑止されることはなく、技術的には許可されているものの一般的な人間のユーザーめったに実行しないようなアクションを実行する可能性があります。

これらの疑問に答えるには、セキュリティエンジニアリングが必要です。個々のコンポーネントが誤動作したときにリスクを制御下に置くシステムを構築するためのセキュリティ原則はわかっています。しかし、AIエージェントのトレーニング、テスト、使用のための環境をエンジニアリングする際に、これらの原則が確実に適用されるようにする必要があります。

多層防御セキュリティ原則

AIエージェントの安全性を確保するために適用する必要があるおそらく最も重要なセキュリティ原則は多層防御であり、これはシステムリソースを保護するために、複数の、多様で冗長な防御策を採用する階層型セキュリティアーキテクチャを推奨するものです。単一のセーフガードが完璧であるということはありません。人間がソーシャルエンジニアリング攻撃に引っかかってログイン情報を漏洩させたり、ゼロデイソフトウェアの脆弱性が発見されて悪用されたり、侵入検知が新しい攻撃バリアントを見逃したりすることがあります。多層防御はそのような事態を受け入れ、いくつかの独立した防御レイヤーを重ね合わせます。1つの防御レイヤーが回避されたとしても、他のレイヤーがそのまま残り、侵入に対抗または検知します。

Hugging Faceのインシデントは、多層防御（ディフェンスインデプス）がなぜ重要であるかを示しています。OpenAIの回顧録によると、本番システムで使用されていたハーネス、自動レビューモデル、安全分類子などの自動セーフガードは、評価環境には存在していませんでした。現在デプロイされている思考の連鎖（チェーンオブソート）モニタリングがそれらの評価で実行されていた場合、侵害の1日以上前に初期のアクティビティを検知し、セキュリティチームにページャーで通知していたでしょう（OpenAI）。問題を検知できたはずのレイヤーは存在していました。単に、それらがすべて同時に所定の位置になかっただけなのです。

AIエージェントの安全性を確保するには、AIモデル自体の安全性とセキュリティ、およびそれらを囲むシステムの両方を改善する必要があります。モデルレイヤーでの作業は重要であり、成果を挙げています。初期のLLMはインジェクションされた指示によって簡単に操作されていましたが、今日のモデルはそれらを認識して拒否する能力が大幅に向上しています。モデル開発者はまた、より安全な動作のためにモデルをトレーニングし、OpenAIの回顧録が説明するように、問題のある動作の兆候がないか推論トレースを監視します。しかし、モデルレベルの防御は解決策の一部に過ぎません。エージェントがトレーニング、テスト、およびデプロイされるシステムも、セキュリティと封じ込めのためにエンジニアリングされなければなりません。モデルレベルの安全性はエージェントが道を踏み外す可能性を減らし、システムレベルのセキュリティはその際に被害を制限します。

拡大

冗長なセーフガードのための設計ルール

多層防御には冗長なセーフガードが必要です。エージェントに対しては、3つの設計ルールを適用することを推奨します:

1. 独立性。各レイヤーは、独立した理由で失敗するべきです。同じ前提を共有する2つの制御は、同じ攻撃によって打ち破られる可能性があります。モニターと強制ポイントは、エージェントの手が届かない場所に配置する必要があります。
2. エージェントの下での強制。少なくとも1つのレイヤーは決定論的である必要があります。つまり、モデルが何を生成しようとも禁止されたアクションをブロックする、従来型の検証可能なコードです。エージェントが呼び出しを拒否したり再設定したりできるセーフガードは、セーフガードではありません。
3. シグナルは権限を減らすことしかできません。検知は、一時停止、資格情報の失効、ネットワークアクセスの切断、セッションの終了など、エージェントができることを狭める応答をトリガーする必要があります。いかなるリスクシグナルも、追加のアクセス権を付与してはなりません。

私たちは、ハーネスがエージェントの試みを誘導し、インフラストラクチャがその実行できる内容を制御すると主張しているNVIDIAを含む、 Open Secure AI Allianceのパートナーとこれらの原則を共有しています（NVIDIA）。

Perplexityの製品における多層防御

Perplexityは、クラウドのエージェントプラットフォームComputer、ブラウザのComet、ユーザーデバイスのPortable Computer、およびエンジニアがサードパーティ製コーディングエージェントを使用する従業員のラップトップという4種類の環境でエージェントを実行しています。各環境には独自のりスクがあり、それぞれに複数の防御レイヤーが適用されます。

クラウド内: ComputerとSPACE

すべてのComputerタスクは、デフォルトでエージェントを信頼できないものとして扱う当社のサンドボックスプラットフォームであるSPACE内で実行されます。各タスクには独自のマイクロVMが割り当てられ、資格情報はサンドボックスの外に保持され、必要な場合にのみインジェクションされ、アウトバウンドトラフィックはゲスト外で制御され、スナップショットによって破壊的な変更をロールバックできます（Making SPACE）。エンタープライズ顧客は独自の暗号化キーを持ち込むこともできます。キーを失効させると保護されたデータが読み取り不能になり、エージェントはその決定をオーバーライドできません。

また、これらのレイヤーが維持されるかどうかもテストしています。「Escaping SPACE: Part I」では、SPACEサンドボックス内に9つのフロンティアモデルにルートアクセスを与え、そこからの脱出を試みるよう依頼しました。VMから脱出したものはありませんでしたが、部分的なネットワークアクセスが許可された際に、ネットワークポリシーを回避する方法を見つけたものもいくつかありました。それらのギャップを修正し、再テストで修正を確認し、他の10のサンドボックスプラットフォームのうち8つで見つかった同様の脆弱性をそれぞれのベンダーに開示しました。

ブラウザ内: CometとBrowseSafe

Cometは、リリース以来、階層型プロンプトインジェクション防御を使用しています。分類子が取得したコンテンツをスクリーニングし、構造化されたプロンプトで信頼できないものとしてマークし、メールの送信や注文の配置などの機密性の高いアクションにはユーザーの確認を求め、何かがブロックされたときにユーザーに通知します（Comet prompt-injection defenses）。最初のレイヤーの背後にあるオープンソースの検知モデルであるBrowseSafeは、当社のBrowseSafe-Benchベンチマークでフロンティアモデルを上回る性能を発揮しますが、同じベンチマークは、どの検知器もフェイルセーフではないことを示しており、それが検知が唯一のレイヤーにならない理由です（BrowseSafe research）。Computerはこれらの防御を継承しており、これらはTrail of Bitsによって監査されています（Perplexity）。

デバイス上: Portable Computer

Portable Computerはローカルファーストのエージェントです。モデル、ハーネス、会話、および軌跡はデフォルトでユーザーの機械上に留まります。LLMではなくハーネスコードである決定論的なオーケストレーターがループを実行し、ポリシーを強制します。モデルがアクションを提案し、承認されたツール呼び出しは、プロセス、ファイルパス、およびネットワークアクセスを制限するOSレベルのサンドボックス内で実行されます。サンドボックスは常に稼働しており、フェイルクローズです。利用できない場合、ハーネスはユーザーの権限でコマンドを実行する代わりに自身を無効化します。ウェブ検索、コネクタ、およびより強力なクラウドアドバイザーモデルへのエスカレーションなど、デバイスの境界を越えるアクションは、ユーザーがそれを有効にして承認した場合にのみ発生します。アドバイザーの呼び出しの前に、PII分類子が機密情報にフラグを立て、送信される内容がユーザーに表示されます。アドバイザーはその承認されたコンテキストのみを受信し、デバイスのファイルやツールへのアクセス権なしでテキストのガイダンスを返します。

エンドポイント上: Numbat

開発者のラップトップ上で動作するコーディングエージェントは、ソースコード、資格情報、および本番システムへのアクセス権を持った状態で何時間も実行されます。オープンソースのエージェントセキュリティスイートであるNumbatは、単一のエージェントの外部に位置する独立したレイヤーを追加します。Claude Code、Codex、OpenCode、Piなどのハーネスと連携し、実行前に危険なアクションをブロックし、秘密の読み取りとその後のデータ送信などの不審なマルチステップシーケンスにフラグを立て、調査のためのセッションタイムラインを保持します。Numbatは、オープンソースのサプライチェーンスキャナーであるBumblebeeと共に、何千ものPerplexityのエンドポイント上で実行されます。Computerはそれらの発見事項を定期的にレビューし、改善された検知ルールを提案し、人間がすべての変更を出荷前に承認します。

業界全体のための仕事

AIエージェントの能力が向上し、広く使用されるようになるにつれて、セキュリティエンジニアリングはその開発とデプロイの中心であり続けなければなりません。研究者やエンジニアは、確立された原則を基にし、現実世界の発見事項を使用して防御を洗練させ、エージェントが動作する環境全体でセーフガードをテストすることができます。セキュリティとは、テクノロジーと共に発展する継続的なエンジニアリングの分野です。

エージェント向けのセキュリティエンジニアリングは、業界全体にとっての仕事です。単一の企業がエージェントが実行されるフルスタック全体を制御しているわけではありません。モデル開発者、ハーネスビルダー、サンドボックスおよびランタイムプロバイダー、クラウドおよびハードウェアベンダー、そしてエンタープライズセキュリティチームがそれぞれ1つのレイヤーを所有しています。全体の安全性は、別のレイヤーがスリップしたときにすべてのレイヤーが耐えるかどうかにかかっています。だからこそ、私たちはエージェントのハーネス全体で機能するセーフガードを構築し、ツールをオープンソース化しています。また、他のプラットフォームで見つかった脆弱性を開示し、OpenSecure AI Allianceなどの取り組みに参加する理由もそこにあります。

これらの課題についてより幅広いコミュニティと協力するため、Perplexityは2026年3月にSecure Intelligence Instituteを立ち上げ、最先端AIシステムのセキュリティ、信頼性、および実践的な防御について研究しています（Perplexity）。Perplexityは現在、スタンフォード大学、カーネギーメロン大学、デューク大学、コロンビア大学、オハイオ州立大学、バージニア大学の学術研究者と協力および/または資金提供を行っています。また、エージェントセキュリティ研究のフロンティアを押し広げ、それらの進歩をPerplexityのシステムの具体的な改善に翻訳し、より広いAIエコシステムの強化に役立つ知識とリソースを共有するために、内製研究も行っています。より安全なエージェントは、業界がエンジニアリングできるものです。私たちは引き続き自らの役割を果たし、他の方々にも私たちと共に構築することを呼びかけます。