AIハーネスが新たな攻撃対象領域になっている

AIエージェントが侵害される際、その原因はモデル自体にはないことが新たな調査で明らかになりました。問題はモデルを包み込むコードにあります。しかも、そこに十分な監視の目が向けられている組織はほとんどありません。

AIエージェントの何が危険なのかをセキュリティ研究者に尋ねると、多くはモデルそのものの話をしたがります。何を拒否し、何を拒否しないのか、どれほど簡単にジェイルブレイクされてしまうのか、その重みは信頼できるのか、といった具合です。

しかし、そうした発想はすでに時代遅れになりつつあります。エクスプロイトの実証、独立系レッドチームによる検証、セキュリティ研究者による評価など、増え続ける調査結果が指し示すのは、モデルと外界との間に存在するコードの方です。

このコードは「ハーネス」と呼ばれることが増えており、モデルを包み込んでツールを与え、モデルがトークン単位で生成する出力をシェルコマンドやファイル書き込み、API呼び出しへと変換します。そして、このハーネスこそが、目録の整備も、テストも、そして責任の所在も不十分なまま、企業内に存在しているのです。

Novee Securityの創業エンジニアでセキュリティ研究者のElad Meged氏は、GitHub issueだけを使って、Anthropic、Google、OpenAIそれぞれの公式自動化リポジトリに侵入することに成功しました

Lasso Securityの研究者たちは、中立的とされるエージェントの配管部分を一つ差し替えるだけで、モデルの攻撃成功率が1%から24%へと跳ね上がることを突き止めました。しかも、モデル・プロンプト・ツールはすべて同一のままです。

そして、AIセキュリティ企業ZenityでCTO兼共同創業者を務めるMichael Bargury氏は、AIの「スキル」の中に、認証情報を盗み取るマルウェアが隠されているのを発見しました。この「スキル」は、Anthropicやシスコの公式スキャナーを含め、市場に出回るあらゆるスキャナーをすでにすり抜けていました。

これらの事例はそれぞれ異なる失敗のパターンですが、共通する重要な特徴があります。いずれも、モデルが悪意を持つ必要はおろか、予期しない挙動をする必要すらないという点です。攻撃者が悪用しているのは、モデルを取り巻くソフトウェアの層、すなわちモデルが何を見て、何に触れ、行動した結果として何が起きるかを決定する層なのです。

だからこそ、AIセキュリティ研究者の間では、ハーネスをモデルに付随して自動的にやってくる目に見えない足場としてではなく、それ自体が独立した攻撃対象領域として扱うべきだという声が高まっています。

「ハーネス」とは実際には何なのか

実務者にハーネスの定義を尋ねると、それぞれ異なる角度から同じような比喩が出てきます。

Bargury氏はCSOの取材に対し、ハーネスをモデルの「手であり、足であり、目である」と表現しました。モデル自体はトークンを入力として受け取り、トークンを出力するだけであり、そのトークンをシェルコマンドやファイル書き込み、API呼び出しへと変換するのがハーネスだというのです。

SANS InstituteのチーフAIオフィサー兼リサーチ責任者を務めるRob T. Lee氏は、モデルをエンジンに、ハーネスをシャーシに例えています。Lasso Securityのシニアml エンジニア、Michael Sromin氏は、これをエージェントのオペレーティングシステムになぞらえ、エージェントのループを回しながらモデル、ツール、ユーザーを結びつける存在だとしています。同氏はCSOに対し、「これは……このエージェント型アプリケーション全体の……無限ループを動かすオペレーティングシステムのようなものだと捉えています」と語りました。

シスコのディスティングイッシュト・エンジニアであるOmar Santos氏は、より形式的な定義を示しています。

「AIハーネスとは、モデルを取り囲み、それを実用的なものにする層のことです」とSantos氏はCSOに語りました。「これにはオーケストレーション、ツールの利用、プロンプト、コンテキスト、ロール、評価、ガードレール、そしてモデルの生の出力を範囲の定まった再現可能なアクションへと変換する運用ワークフローが含まれます」。

これらの説明はいずれも同じセキュリティ上の問題を指し示しています。つまり、ハーネスこそがエージェントの権限が行使される場所だということです。ハーネスは、モデルの推論と、実際のファイルシステム、APIキー、あるいは本番データベースとの間に位置しています。

「セキュリティチームはハーネスを攻撃対象領域として扱うべきです。なぜなら、そこがエージェントが権限、コンテキスト、そして行動へと至る経路を得る場所だからです」とSantos氏は述べています。

そして、ハーネスのコードにも、他のあらゆるソフトウェアと同様に脆弱性が存在します。

完璧にアラインメントされたモデルであっても、ワイルドカードのシェルパターンを無条件に信頼したり、信頼できないコンテンツを扱う2回のパスの間でワークスペースを使い回したりするハーネスの中に置かれれば、そのモデルのアラインメントの良し悪しはほとんど意味を持たなくなります。脆弱性はモデルの中にあるのではないのです。

3つの失敗パターン、1つの攻撃対象領域

今年発表された調査の中でも特に詳細なものは、ハーネスが失敗する3つの異なる経路を明らかにしています。すなわち、アーキテクチャ上の信頼境界、実装上の選択、そしてサプライチェーンの侵害です。

Meged氏はBlack Hatにおいて、GitHub issueだけを使ってAnthropic、Google、OpenAIの公式自動化に侵入した結果を基に、1つ目のパターン(アーキテクチャ上の信頼境界)を実演しました

繰り返し見られたパターンは、「ある場所で決定が下され、それがより強い権限を持つ別の場所で消費される」というものだったと同氏は述べています。

各ベンダーの脆弱性はそれぞれ異なるものでした。あるものではコード実行が可能になり、あるものではハーネスが除去したはずの認証情報が漏洩し、また別のものでは、より後段のより強い権限を持つ段階が再検証なしに信頼してしまう指示を埋め込むことができました。

しかし、その根底にあるアーキテクチャ上の誤りは驚くほど一貫していました。あるコンポーネントがセキュリティ上の判断を下し、それより下流にあるより強力なコンポーネントが、その判断を再検証することなくそのまま信頼してしまうという構図です。

これはモデルの失敗ではありません。信頼境界の失敗なのです。

Lasso Securityの調査は、2つ目の問題を明らかにしています。悪用可能な実装上の不備がなくても、ハーネス自体の設計がエージェントのセキュリティを根本から左右してしまうというものです。

「LLMやツールなど諸々を選び、そしてハーネスを選ぶと、そこで1つのエージェントが出来上がります」とSromin氏は言います。「そして別のハーネスを選べば、まったく別のエージェントが出来上がるのです」。

これは、多くの組織が認識している以上に大きな違いです。一部のセキュリティ専門家は、いまだにハーネスを、モデルとツールの間を取り持つ単なる交換可能な配管、パススルーのループ程度にしか捉えていません。

しかし、Lasso Securityが示した数字はそれとは異なる実態を物語っています。同一のオープンウェイトモデルの下でハーネスを差し替えただけで、攻撃成功率は1%から24%へと変化し、モデルとタスクの組み合わせ100件のうち43件で結果が完全に逆転しました。

「これは単なる恣意的な選択ではありません」とSromin氏は言います。「慎重に検討すべき選択です。取り組んでいる内容次第では、大きく状況を左右し得るのです」。

同氏の提言は、モデルと同様にハーネスもベンチマークすべきだというものです。テストもせずに既製のハーネスを選ぶということは、重大なセキュリティ上の選択を、自らそれと気づかぬまま下していることになります。

ZenityにおけるBargury氏の調査によれば、ハーネスのサプライチェーンは急速に拡大しており、すでに悪用が始まっています。

同氏のチームは、エージェントに新しいタスクの実行方法を教える「スキル」ファイルを調査し、古くからあるセキュリティ問題が新しい形で再び現れていることを発見しました。

「これは単なるサプライチェーンの問題であり、それがスキルという形で再び表面化しているに過ぎません」とBargury氏はBlack Hatで語りました

しかし、エージェントのスキルは、エージェントが繰り返し信頼する環境そのものを書き換えてしまう可能性があるという点で、この問題に独特の変化形をもたらします。

例えば、エージェントは起動するたびに、自分が何をすべきかについての指示が書かれたメモリファイルを再読み込みすることがあります。Zenityは、悪意のあるスキルがこのメモリファイルに自らを書き込めることを発見しました。スキル自体を削除しても、それを再インストールせよという指示は残り続けるため、エージェントが次に実行された際にマルウェアが再び戻ってくることになります。

Zenityが調査したもう1つの悪意あるスキルは、正規のAnthropic製ツールになりすましていました。実行されると、本物のツールを削除し、攻撃者版のツールに置き換えます。その結果、ユーザーの目に明らかな変化がないまま、エージェントは悪意あるコードを実行し続けることになります。

最も顕著な例は、人気のオープンソースツールを密かに改変して複製し、ログイン認証情報を盗み出すよう仕組んだキャンペーンでした。この悪意あるスキルは、skills.sh上でコピー元となった正規のツールを上回る人気を獲得し、キャンペーンが摘発されるまでにおよそ170万件のダウンロードを積み重ねていました

これら3つの調査すべてに共通する教訓は同じです。モデルを保護することと、エージェントを保護することは、決して同じではないということです。

CISOが知っておくべきこと

CISOにとって、これらの調査が突きつける課題は3つあります。組織内ですでに稼働しているハーネスを洗い出すこと、それらが触れられる範囲を制御すること、そして自社のセキュリティ管理策が実際に機能しているかを独自に検証することです。

1つ目は、見た目以上に難しい課題かもしれません。というのも、ほとんどの組織は「AIハーネス」という区分自体を管理台帳に持っていないからです。

「チームはアプリ、サービス、パイプライン、ボットといった単位で物事を考えがちです」とSantos氏は言います。ハーネスは、セキュリティ管理台帳上の独立した資産として現れるのではなく、コードリポジトリやSaaS製品、ベンダーの設定画面の中に紛れ込んでしまいます。

用語そのものすら統一されていません。

「あるチームはそれをエージェントと呼び、別のチームはコパイロット、また別のチームはワークフローアシスタント、さらに別のチームはプラグイン型の自動化と呼びます」とSantos氏は言います。「しかし、実質的にはそのすべてがハーネスなのです」。

同氏の提言は、本番稼働中のすべてのエージェントについて生きた目録を作成し、それぞれのハーネスを特定した上で、アクセス可能なすべてのツールとリソースをマッピングすることです。そのうえで、それらの権限を必要最小限まで削減するべきだとしています。

組織は、完璧な可視性が得られるまで待つ必要はありません。Santos氏の見立てでは、プロトタイプやシャドーAIを後回しにして本番システムから着手すれば、比較的早い段階で60%から70%程度の可視性を確保できるとのことです。

2つ目の問題は、ハーネスが信頼するあらゆるものを制御することです。

エージェントは単独で動作しているわけではありません。ツール、プラグイン、スキル、MCPサーバー、ウェブサイト、その他のシステムから指示やコンテンツを取り込みますが、その際にはしばしば、ユーザーに代わって行動するための認証情報や権限を保持したままです。

したがって、攻撃者はモデル自体を侵害する必要はありません。ハーネスが信頼を寄せている何かを侵害すればよいのです。

「あなたは自分のノートパソコンをエージェントと共有しているのです。そのノートパソコンには、あなたのIDも、ファイルも、秘密の情報も、すべてが詰まっています」とBargury氏は言います。

AIセキュリティに専用の予算を割けない組織に対して、同氏は少なくともオープンソースのコンテインメントツール(隔離実行環境)の中でエージェントを動かすことを推奨しています。「これは根本的な解決策ではありません」と同氏は釘を刺しつつも、「それでも役には立ちます」と述べています。

潜在的なサプライチェーンの規模の大きさは、この問題を従来型のソフトウェア依存関係管理とは質的に異なるものにしています。

「ソフトウェアのサプライチェーンといえば、せいぜい10か15程度のパッケージレジストリの話です」とBargury氏は言います。「一方、エージェントのサプライチェーンとなれば、あらゆるコンテンツ、あらゆる画像、あらゆるテキスト、あらゆるウェブサイト、あらゆるCRMオブジェクト、あらゆるスキル、あらゆるMCPサーバー、インターネット上のあらゆるコンテンツが対象になり得るのです」。

3つ目の問題は、ベンダーが掲げるセキュリティ上の主張が、エージェントが実際に稼働する環境にもそのまま当てはまると思い込んでしまうことです。

あるベンダーがプロンプトインジェクションの99%をブロックできると謳っていたとしても、それは「現場の実態とは結びついていないベンチマーク」を引き合いに出しているだけかもしれない、とBargury氏は言います。

Lasso Securityの調査結果は、これがなぜ重要なのかを示しています。モデル、プロンプト、ツールを固定したままハーネスだけを変えると、セキュリティ上の結果は劇的に変わり得るのです。

つまり、エージェントを評価する組織は、そもそも問いの立て方を間違えている可能性があります。問うべきは単に「どのモデルが最も安全か」ではありません。「組織が実際にそれを展開する条件下で、モデル・ハーネス・ツール・権限・外部入力のどの組み合わせが安全であり続けるか」なのです。

Meged氏は、3社のベンダーの公式自動化に侵入した経験から得た教訓を、こう凝縮しています。「ドキュメントではなく、デフォルト設定を読め」。

「その製品は安全だと謳っていました」と同氏は語ります。「私たちはまさにそこから調査を始めたのです」。

翻訳元: https://www.csoonline.com/article/4208236/the-ai-harness-is-the-new-attack-surface.html

ソース: csoonline.com