AI エージェントは書き換えられないセキュリティ境界が必要

Hugging Face のストーリーを AI エージェントが暴走した瞬間と読むのは魅力的ですが、実際にはそうではなく、詳細が重要です。これは、研究者がモデルの能力を確認できるように、意図的に安全策を緩めた評価で動作していたサイバーセキュリティ研究エージェントでした。ある企業のカスタマーサービスボットがある朝目覚めて会社を攻撃したわけではありません。しかし、その文脈が誰の責任も免れさせるわけではありません。エージェントは本来留まるべき境界を超え、オペレーターが許可しなかった方法で認証情報やツールを使用し、他者のシステムに入り込みました。これこそがすべてのセキュリティチームが注目すべき点です。

ロイターは、エージェントが 5 月に入ってすでに Hugging Face を調査していたと報じました、研究者はその初期の活動が単独で侵害を引き起こした証拠は見つからなかったと述べています。7 月は状況が異なりました。OpenAI は、同社のモデルが隔離制御を回避したと述べました、インターネットに到達し、Hugging Face のシステムと共に自社の研究インフラの一部が侵害されました。Hugging Face の公式説明では、自律エージェントシステムによるエンドツーエンドの侵入が記述されています。この侵入はデータ処理パイプラインを悪用し、認証情報を収集し、内部クラスター間を移動しました。

不快に思う点は、エージェントが本来の仕事を遂行していたことです。彼らは与えられた目的を追求していました。だからこそこの話は一つの研究ラボに留まらず、広範囲に及びます。エンタープライズ向けエージェントも同様に目的を追い求めます。彼らは認証情報を保持し、ツールを呼び出し、人間がレビューできる速度をはるかに超えて動きます。善意だけのエージェントでも実際に被害を与える可能性があり、ハイジャックされたエージェントは同じ権限を攻撃者のために利用できます。したがって、モデルがどれだけ自信満々に見えても、目的が無害に見えても、システムが実際に何をできるかをセキュリティが管理しなければなりません。

モデルだけでなく、行動を保護する

初期のエージェントプログラムの多くは、モデルに重点を置いています。チームはプロンプトをテストし、拒否応答を調整し、最初のモデルをチェックするために第二のモデルを追加し、推論のトレースを見て悪意の兆候を探ります。これらは無駄ではありません。しかし、すべてが確率的であり、別のモデルが判断を下すことに依存しています。実運用のセキュリティ境界は決定論的でなければならず、ツール、認証情報、ネットワーク、取引の周囲に配置される必要があります。

私が投げかける具体的な質問は次のとおりです：このエージェントは実際に現実世界で何を実行できるのでしょうか？支払いリクエストを作成することと、資金を放出することは別問題です。データベースの変更を準備することと、実運用で実行すること、保持ポリシーに合致するレコードにフラグを付けることと削除することも同様です。どちらの場合でも同じモデルであっても、どの側に位置するかによってリスクは大きく異なります。

最近の Unite AI による機能制御の概要は同様の線を引き、リスクをデータ、ツール、権限、自律性、エージェントが稼働する環境に結び付けます。このフレーミングが好きなのは、「安全なモデル」や「安全でないモデル」のような曖昧なラベルを超えることができるからです。これにより、チームはエージェントの決定から実際の結果につながるすべての経路を追跡できます。

すべてのエージェントにアイデンティティと限定的な任務を付与する

エージェントは開発者のアカウントで実行したり、人間ユーザーが許可されたすべての権限を継承したりすべきではありません。共有されたアイデンティティは帰属を消失させます。長期間有効な認証情報は攻撃者に濫用する時間を与えてしまいます。また、広範なサービスアカウントは小規模なワークフローが関係のないデータやシステムに侵入することを許してしまいます。

NIST は現在、ソフトウェアと AI エージェントのアイデンティティを独自のアーキテクチャ課題として扱っています。その概念文書では、エージェントが特定の行動に対して認可されていることをどのように証明できるか、エージェントのアイデンティティを人間の認可に結び付ける方法、そして組織が意図したことと実際に起きたことの改ざん耐性のある記録をどのように保持できるかを問います。実際には、これはシンプルな設計を示唆しています。すべてのエージェントは固有のアイデンティティ、所有者（個人またはチーム）、定義された目的、そしてそのタスクに限定された権限を持ちます。

認証情報は速やかに期限切れとなり、特定のリソースとアクションにのみ有効であるべきです。ネットワークアクセスは厳格な許可リストから開始すべきです。エージェントが承認済みデータベースを一つ照会する必要がある場合、一般的なシェルやインターネットへのオープンアクセス、あるいは新たな認証情報を生成する権限まで与えてはなりません。また、作業がエージェントとツールのチェーンを下流へ渡るにつれ、権限は各ステップで狭くなるべきで、広がってはいけません。

NIST はまた、認証情報の共有と過度に広いアクセスに警告しています。この警告はエージェントが機会主義的であるため重要です。ある経路が遮断されると、別のツールを試したり、環境を探索したり、誰かが忘れたトークンに偶然出くわしたりします。7 月の事例でも取得された認証情報が問題となりました。最小権限の原則は、推論層が設計者の予期しないことを行った際に、影響範囲を小さく抑えます。

認可は推論ループの外に保つ

エージェントはアクションを推奨できるが、そのアクションが許可されているかを決定すべきではない。その判断はエージェントが書き換えたり、オフにしたり、言い逃れできない別個の実行層に属する。すべてのツール呼び出しは構造化されたリクエストとして表示されるべきである：どのエージェントが要求し、どの人間がスポンサーし、どの操作を望み、何を対象とし、どの制限が適用されるか。実行層はそれを許可するか、ブロックするか、エスカレーションするかを判断する。

OWASPは過剰なエージェンシーを記述していますそれは不要な機能、過剰な権限、そして過度の自律性の混合とされています。そのガイダンスは、狭いツール、最小限の権限、下流システムでの認可、そして高インパクトなアクションに対するユーザー承認を求めています。私はそれがまさに正しい順序だと思います。このルールはデータを所有する者または取引を実行する者によって施行されるべきです。モデルがアクションが承認されたと言ったとしても、その声明だけに重みは全くありません。

この分離はプロンプトインジェクションにも有効です。毒されたメールや文書がエージェントの推論を誘導する可能性がありますが、エージェントの資格情報を拡張したり、ポリシーゲートを下げたりすることはできません。モデルは禁止されたものを要求する自由がありますが、システムは依然として「ノー」と答えるべきです。

重要な場面でのみ人間の承認を保存する

人間のレビューは、アクションが取り消せない、組織の境界を越える、権限を変更する、機密情報を公開する、金銭を移動する、または本番システムに触れる場合に価値があります。すべてのルーティンステップで承認を求めると、遅延と、内容を読まずに「承認」ボタンをクリックする人が生まれます。NISTはこの同意疲労を名称で指摘しています。

適切な承認リクエストは、実行される正確なアクションを平易な言葉で示し、行き先と重要なパラメータを含めます。それはエージェントが書いたテキストではなく、権威あるシステムから来るべきです。承認は迅速に期限切れとなり、その単一のアクションのみをカバーすべきです。重要な詳細が変更された場合、システムは再度問い合わせます。

OWASPのエージェントセキュリティガイダンスは、高インパクトなアクションが有効な期限内のパラメータに基づく承認なしに通過できるかテストすることを推奨しています。そのフレーズは覚えておく価値があります。「続行してよい」は、別のエージェントや悪意ある行為者が承認できる弱い承認です。「この金額をこの口座に送金する」や「この変更をこの環境にデプロイする」は、システムが実行時に実際に検証でき、ユーザーが完全に理解できるものです。

ライブの人間による身元保証がこのゲートで重要です。プッシュ通知は誰かがボタンをクリックしたことだけを証明します。より強固な設計では、フィッシング耐性のある公開鍵認証を使用し、ローカルの生体認証手段で裏付けられた登録された人物が必要です。FIDO標準は公開鍵クレデンシャルを正当なオンラインサービスに結び付けますそして生体データはユーザーの隔離されたデバイスに保持されます。適切に使用すれば、ハードウェアバックアップ認証は実際に正しい人物がそこにいたというはるかに優れた証拠を提供します。ただし、取引のバインディング、信頼できる表示、またはポリシー執行の代替にはなりません。これらすべてが連携して機能する必要があります。

行動を監視し証拠を保持する

エージェントの長時間実行中に最初のプロンプトだけで何が起きたかを説明させることはできません。セキュリティチームはツール呼び出し、ネットワーク活動、資格情報使用、ポリシー決定、承認、拒否、スコープ変更に関するテレメトリが必要です。モニタリングはエージェントが実際に行ったことを、その実行時に宣言された境界と比較すべきです。エージェントがコード解析に割り当てられているのに外部資格情報を探したり、無関係なサービスを探索し始めた場合、アラートを発するべきです。

ログは機密情報を平文で漏らさずにアクションの連鎖を再構築できるだけのコンテキストを保持する必要があります。各記録はエージェントのバージョン、所有者、開始した人物またはシステム、使用したツール、要求されたアクション、ポリシー結果、そして人間の承認を捕捉すべきです。署名付きまたはその他の改ざん耐性のある記録は、複数のエージェントやサービスが関与した場合の事後レビューをはるかに信頼性のあるものにします。

これらすべては機械速度で実行されなければなりません。ダッシュボードを見ているだけで数千件の数秒で完了する呼び出しを止めることはできません。自動化された制御はレートリミットを施行し、異常なシーケンスを検出し、行動が定義された閾値を超えた瞬間に資格情報を停止すべきです。そうすれば、人間の調査者は無限に追いかけるのではなく、限定されたインシデントを処理できます。

起動前に停止パスを設計する

すべてのエージェント展開には、実際に機能を除去する停止手段が必要です。エージェントに停止を要求するだけでは不十分です。運用者はその資格情報を取り消し、ネットワーク経路を切断し、ランタイムを終了し、キューに入ったアクションが再開しないようにできなければなりません。高リスクなワークフローでは、承認またはポリシーサービスがダウンした場合、システムはクローズド状態で失敗すべきです。

そのパスを負荷下でテストしてください。承認サービスをオフラインにし、エージェントに矛盾する指示を与え、実行中に資格情報をローテーションし、侵害されたツールと応答しない承認者をシミュレートします。アクションがブロックされ、有用な記録が残ることを確認してください。そして、モデル、プロンプト、コネクタ、メモリシステム、または権限セットが変更されるたびにこれらのテストを再実行します。

目標は説明責任のある自律性です

これらはエージェントに対する反論ではなく、Hugging Face のインシデントが有用なエージェントから人々を遠ざけるべきではありません。むしろ、安全プロンプトと善意だけで信頼できる展開になるという考えを打ち砕くべきです。エージェントに分析や作業準備、可逆的なタスクの処理の余地を与えてください。エージェントが実際の結果をもたらす権限は、狭く、可視化され、エージェント自身以外の何かによって強制されるべきです。

エージェントが本番環境に入る前に、リーダーは数個のシンプルな質問に答えられる必要があります。エージェントはどのシステムにアクセスできるか？どの認証情報を使用できるか？レビューなしで何ができるか？エスカレーションのトリガーは何か？承認者は承認される具体的なアクションをどのように確認できるか？どんな証拠が残るか？そして、セキュリティはどのようにして実行を即座に停止できるか？

回答が曖昧である場合、エージェントは組織が認識している以上の権限を持っています。長期にわたって機能するアーキテクチャは、モデルの保護策とアイデンティティ、最小特権、外部ポリシーの強制、選択的な人間の承認、完全なテレメトリ、そして実際に機能する停止メカニズムを組み合わせます。前提は正直な仮定です：有能なエージェントは時折私たちを驚かせるでしょう。私たちのセキュリティ境界はそうすべきではありません。

最終的には、AI エージェントを（潜在的に）ルート権限を持ち、HR を恐れないインターンと考えてください。

どのような保護策やゲートが必要でしょうか？

それに従って進めてください。