アーキテクチャ制御がAIセキュリティギャップを埋める方法

このDark Reading News Deskのインタビュー（Blackhat USA 2025より）では、NCC Groupのテクニカルディレクター兼AI/MLセキュリティプラクティスリードであるDavid Brauchler氏が、現在のAIセキュリティアプローチにおける重大な欠陥について語っています。彼は、組織が大規模言語モデルの主なセキュリティ対策としてガードレールに過度に依存していることを指摘し、これは高度な攻撃に対しては不十分であると説明しています。ペネトレーションテストを通じて、彼のチームはセキュリティ境界が不十分なAIシステムが、任意のコード実行、パスワードの流出、さらにはデータベース全体のダンプまで可能になることを実証しました。

Brauchler氏は、AIシステムを導入する際には、オブジェクトベースの権限モデルからデータベースの権限モデルへの根本的な転換を提唱しています。彼の主な推奨事項は、適切なアーキテクチャ制御の確立です。高い権限を持つAIシステムは決して信頼できないデータに晒されるべきではなく、逆に、信頼できないデータを処理するシステムには高い権限を持たせるべきではありません。

組織がAI導入を急ぐ中で、この課題は「津波を止めるようなもの」だと認めつつも、Brauchler氏は、効果的なセキュリティ戦略はすでに存在しており、組織はAIシステムが必要とする独自のセキュリティパラダイムを認識する必要があると強調しています。

NCCのDavid Brauchler氏による「なぜAIガードレールだけでは不十分なのか」全記録

この書き起こしは分かりやすさのために編集されています。

Alexander Culafi: こんにちは、Dark Reading News Deskへようこそ。Black Hat USA 2025からお届けしています。本日はNCC Groupのテクニカルディレクター兼AI/MLセキュリティプラクティスリードであるDavid Brauchler氏にご参加いただいています。彼には新しい研究「ガードレールだけでは不十分なとき：アーキテクチャ制御によるエージェント型AIセキュリティの再発明」についてお話しいただきます。こんにちは、Davidさん。

お話しできてとても嬉しいです。なぜなら、私はDark Readingで毎週のようにプロンプトインジェクション攻撃や、最近では非プロンプトインジェクション型AI攻撃についての記事を書いているからです。今、どんなことに取り組んでいますか？

David Brauchler: ペンテストを通じて顧客全体で観察してきたのは、多くの組織がまだ「ステップ1」にとどまっているということです。つまり、[AIのガードレールに依存している]状態です。

これらのシステムをテストしてきた経験から、設定次第で任意のコードを実行させることができることを確認しています。パスワードを流出させることも可能です。私たちはデータベース全体をダンプすることにも成功しました。そして、世界がよりエージェント型へと進む中で、これらのシステムの攻撃対象領域は指数関数的に拡大しています。だからこそ、ガードレールは第一のセキュリティ対策ではないと伝えに来ました。

とはいえ、テストしたすべての顧客には、プロンプトインジェクションを超えた攻撃を防ぐのに有効なセキュリティコントロールの断片が見られました。

Culafi: どのようなコントロールを考えていますか？

Brauchler: まず、私の講演で最も重要なポイントは、LLMやその他のAIシステムが高度な権限や機密性の高い機能にアクセスできる場合、それを信頼できないデータに晒してはいけないということです。同様に、信頼できない、あるいは悪意のあるデータに晒されるシステムには、高度な権限を与えるべきではありません。

これを実現する方法はいくつかあります。一つは動的に「ケイパビリティシフティング」を使うことです。これは、大規模言語モデル（LLM）のコンテキストウィンドウに入るデータの信頼レベルを追跡し、そのモデルの権限を最も信頼できない入力に合わせて引き下げる技術です。なぜなら、言語モデルは常に受け取る入力のエージェントであることを忘れてはならないからです。

Culafi: セキュリティ分野でAIについて多く語られている中で、LLMがアナリストなどの負担を軽減できるという期待もありますが、その一方で多くの組織がAIをかなり性急に導入しています。AIの脆弱性や弱点を調査していると、すでに走り出した列車を止めようとしているような感覚になりますか？

Brauchler: まさに「津波を止める」ようなものです。なぜなら、すべての組織が経営陣や株主から「AIをやらなければならない」というトップダウンの指示を受けているからです。開発者は「LLMを入れてみよう」と気軽に考えますが、それがアプリケーションの攻撃対象領域を大きく拡張することに気づいていません。

私たちはオブジェクトベースの権限モデルに慣れています。たとえば、ユーザーやシステムなどのオブジェクトを初期化します。人間のユーザーは、ある日システム管理者として寝て、翌日脅威アクターとして目覚めることはありません（大金の入ったブリーフケースでも持ってこない限り）。しかし、LLMは、その機能が晒されるデータに依存しているため、簡単に立場を変えてしまうかもしれません。

したがって、セキュリティモデルをオブジェクトベースの権限からデータベースの権限へと変更する必要があります。開発者は、AIを新しいアプリケーションや既存のものに統合する際に従うべき新しいセキュリティプラクティスや教訓について「知らないことを知らない」状態です。セキュリティ企業でさえ、「あなたのAIをレッドチームしました」、つまり「悪いことを言わせました」という段階にとどまっており、「AIエージェントを使ってアプリケーション内でどの資産（機密性、完全性、可用性）を侵害できたか」という次のステップに進んでいません。

Culafi: つまり、最初の段階で適切な判断をして、被害範囲を限定する必要があるということですね。

Brauchler: そうです。重要なのは、守りたい資産の周りに適切なセキュリティ境界を設けることです。そして今や、単にエージェントやユーザーが信頼境界を越えることだけに注目するのではなく、データ自体がアプリケーション環境内を移動する際に、どれだけ信頼を置くかを一段深く考える必要があります。アプリケーション環境内で。

つまり、古い原則と新しい原則の混合です。セキュリティの基本は変わっていませんが、クラウド、[IoT]、ブロックチェーンなど、他のパラダイムシフトで見られたように、既存システムへの基本原則の適用方法が完全に変革されつつあります。

Culafi: 先ほど、プロンプトインジェクションを防ぐためにガードレールを使うのは、永久に追いつけないイタチごっこだとおっしゃっていましたが、これは多くの人が現在フィッシングについて考えていることと似ているように思います。つまり、多要素認証は良いですが、最初から適切な判断をして、物理キーなどのフィッシング耐性のある認証を導入することで、従業員がソーシャルエンジニアリングに引っかからないようにする必要があります。

Brauchler: まさにその通りです。私はLLMを「インターン・イン・ザ・ミドル」シナリオと呼んでおり、組織内の権限の低いインターンを管理するのと同じように管理すべきだと考えています。優秀なインターンの皆さんには申し訳ありませんが、最終的には、脅威アクターに操作される可能性がある人には、追加のセキュリティ境界を設けて、信頼できないデータに触れさせないか、攻撃が発生した場合の被害範囲を制限する適切なコントロールを設ける必要があります。

私はこれをWebアプリケーションファイアウォール（WAF）と比較しています。ガードレールについて話すとき、それは攻撃の成功確率を下げるヒューリスティックです。しかし、それは第一のセキュリティ対策ではありません。開発者がアプリケーションの唯一の防御策としてWAFだけを使わないのであれば、LLMの唯一の防御策としてガードレールだけに頼るべきではありません。

Culafi: あなたの研究を見た人に、特に伝えたいことが1つか2つあるとしたら何ですか？

Brauchler: そうですね、一番大きいのは先ほども述べた通り、信頼できるLLMを信頼できないデータに晒さないことです。しかしそれだけでなく、LLMの分析を脅威モデリングの実践に組み込む必要があります。つまり、データソース（大規模言語モデルのコンテキストに入力できるシステム）やデータシンク（大規模言語モデルの出力を受け取るシステム）を特定することです。

そして、脅威アクターが信頼できないデータをこれらのソースの1つに投入でき、それが彼らがまだアクセスできないシンクに到達できる場合、重大な攻撃チェーンが成立する可能性があります。したがって、これらの攻撃チェーンを断ち切る必要があります。

実際にこれらの異なるアクセス制御層を管理し、メッセージをやり取りするための戦略は数多くありますが、今回は時間の都合で詳しくは触れられません。

決して手遅れではありません。大切なのは「知らないことを知る」ことです。

Culafi: 素晴らしいお話でした。ありがとうございました、Davidさん。

Brauchler: ありがとうございました、Alexさん。