AIの「致命的な三重脅威」を防ぐ方法

• LLMはコードとデータを分離できない構造的問題を抱えており、プロンプトインジェクション攻撃に脆弱である
• 特に外部データへのアクセス・内部機密の閲覧・外部通信権限が同時に与えられると、いわゆる**致命的三位一体（lethal trifecta）**が発生し、深刻な被害につながりうる
• AIエンジニアは機械エンジニアのように考えるべきであり、決定論的アプローチではなく、確率的システムの不確実性を受け入れ、安全余裕を持たせる方式が必要
• ビクトリア時代のエンジニアが材料の不確実性に備えて過剰設計で余裕を持たせたように、AIシステムにも安全限界、リスク許容度、エラー率を導入すべき
• 物理世界の橋に荷重制限があるように、AIシステムにも明示的な限界と安全余裕を設ける規範が必要な時期に来ている

---

LLMの本質的なセキュリティ問題

• 大規模言語モデルはコードとデータを分離できない構造的欠陥を持つ
• そのためプロンプトインジェクション攻撃に脆弱である
  • システムが従うべきでない命令に従うようだます
  • 場合によっては、カスタマーサポートエージェントに海賊のような口調で話させるなど、単に気まずい結果を招く
  • 別の場合には、はるかに破壊的な被害が生じる

致命的三位一体（Lethal Trifecta）

• 最悪の影響は**「致命的な3要素」**がそろったときに発生する
• 3要素の構成
  • 信頼できないデータへのアクセス権限
  • 重要な機密情報を読み取れる能力
  • 外部世界と通信できる能力
• 企業が従業員に強力なAIアシスタントを提供しようとして、この三つを同時に与えると深刻な問題の発生は避けられない
• AIエンジニアだけでなく、一般ユーザーも安全なAIの使い方を学ぶ必要がある
  • 誤ったアプリの組み合わせを導入すると、偶然3要素が成立することがある

AIエンジニアの思考転換が必要

機械エンジニアのように考える

• より良いAIエンジニアリングが最優先の防御線である
• AIエンジニアは橋のような構造物を作るエンジニアのように考えるべきだ
  • 粗雑な仕事が人命を奪いうることを認識する

ビクトリア時代のエンジニアリングの教訓

• ビクトリア時代の英国の偉大な建造物は、材料特性を確信できないエンジニアたちによって建設された
  • 当時の鉄は、無能さや不正のためにしばしば品質が低かった
  • その結果、エンジニアたちは慎重さを選び、過剰設計によって冗長性を組み込んだ
  • その結果、数世紀にわたり持ちこたえた傑作が生まれた

現在のAIセキュリティ業界の問題

• AIセキュリティ提供企業はこのようには考えていない
• 従来のコーディングは決定論的な慣行である
  • セキュリティ脆弱性は修正すべきバグと見なされる
  • 修正すれば消える
• AIエンジニアは学生時代からこうした考え方に慣れている
  • そのため、より多くの学習データとより賢いシステムプロンプトだけで問題を解決できるかのように振る舞う

確率的システムに適したアプローチ

学習データとプロンプトの限界

• 学習データと巧妙なプロンプトはリスクを減らすことはできる
  • 最も賢い最新モデルは、悪意ある要求を検出して拒否する点で、以前のモデルや小型モデルより優れている
• しかしリスクを完全に排除することはできない
  • ほとんどのソフトウェアと異なり、LLMは確率的である
  • 出力は、あり得る応答の中からのランダムな選択によって決まる
  • したがって、決定論的な安全アプローチは不適切である

物理世界のエンジニアリングを模倣する

• より良い方法は、物理世界のエンジニアを模倣することだ
• 予測不可能なシステムとともに働く方法を学ぶ
  • 意図どおりに動くと保証できない気まぐれなシステムに逆らうのではなく、それと付き合いながら働く
• 安全余裕、リスク許容度、エラー率を導入し、予測不可能性をより無理なく扱う

AI時代の過剰設計戦略

• 必要以上に高性能なモデルを使う
  • 不適切な行動をするようだまされるリスクを下げる
• 外部ソースからLLMが受け取れるクエリ数の制限を課す
  • 悪意あるクエリによる被害リスクに応じて調整する
• 安全に失敗することを重視する
  • AIシステムが機密にアクセスする必要があるとしても、王国の鍵を丸ごと渡すことは避けるべきだ

安全限界設定の必要性

• 物理世界では橋には荷重制限がある
  • ドライバーに常に明示されているとは限らなくても存在する
  • 重要なのは、こうした制限が、計算上その橋が耐えられるとされる実際の許容範囲の中に十分な余裕を持たせていることだ
• 今やAIシステムの仮想世界も同様の仕組みを備えるべき時期に来ている
• 明確な安全限界と余裕を持つシステム設計が不可欠

[GN⁺]

Hacker News の意見

• アーカイブ記事リンク
• 今週 lethal trifecta に言及した Economist の記事としては2本目。1本目は AIシステムは決して完全に安全にならない ― 対処すべき「致命的な三重脅威」 で、メディアの中では prompt injection が何で、なぜ危険なのかを最も明快に説明していたと思う。自分が引用されている部分もあるので少しひいき目かもしれないが、経営層にはぜひ勧めたい記事。今回の新しい記事はあまり好みではない。LLM は非決定的だからセキュリティ脆弱性の修正が難しいと述べ、そのため橋のように「オーバーエンジニアリング」して許容誤差に備えるべきだという比喩を使っている。橋なら当てはまるかもしれないが、セキュリティ脆弱性に対する根本的な解決策ではないと思う。もしシステムが100回に1回でも prompt injection にやられるなら、攻撃者は成功するまで派生攻撃を試し続けるはずだ。lethal trifecta（非公開データへのアクセス、信頼できない命令への露出、外部流出経路）のうちどれか1つでも遮断できれば攻撃は成立しない
  • 橋を作る技術者の大半は敵対的攻撃を前提に設計しない。仮に備えるとしても、頑丈にすることより、移設しやすく素早く再配置できることに重きを置く。爆撃に耐える頑丈な橋より、一時的な橋をもう1本架けるほうが速くて安い。具体例 参照
  • LLM は人間と同じく非決定的だ。だからセキュリティ管理も人間に対するのと同じように考えればよい。必要なロールベースアクセス制御で最小権限だけを与え、危険または高コストな作業は承認プロセスを通すべきだ。技術、インフラ、防衛、金融などの主要組織なら、ロシア、中国、イスラエル、北朝鮮など外国政府の工作員がチームに紛れ込んでいる前提で脅威モデルを立てるのが基本だ
  • 実は両方の記事は同じ号の記事だ。Economist では毎号の冒頭に "Leaders" という記事シリーズを載せ、同じ号に掲載された深掘り記事を短く一般化して要約する。つまり新聞全体に逆ピラミッド型の構成（逆ピラミッドの説明）を適用しているようなものだ。今回もリンク先の記事が、その問題を扱った本編全体の要約版の役割を果たしている
  • LLM のセキュリティ問題は「もし自分のコードがソーシャルエンジニアリング攻撃に突破されうるとしたら？」と考えている。LLM は人間と似ていて、どれだけ訓練しても騙されうる。コンピュータに root 権限を与えたうえで、世界中の誰でも LLM と会話できるようにすれば、結局脆弱になるしかない。人間に無制限の権限を委任しないのと同じで、LLM にも依頼者と無関係なデータへのアクセスや、ユーザーデータの変更などは許可しないのが妥当だ
  • lethal trifecta のどれか1つを断てばよいというのが問題だ。実際にはこの3要素は互いに絡み合っている。たとえばメールのように外部コンテンツ自体が個人情報でもありうるし、メールを送れば自分の受信箱の内容が攻撃者に渡る可能性もある。そしてメールや GitHub などは送受信の両方ができてこそ最も有用だが、機能ごとに専用サーバーを分けるのは非効率だ
• 機械工学のバックグラウンドから見ると、この記事は不十分に感じる。「強度を足せばよい」という言い方はよくあるが、実際には多様な故障モードを細かく理解して初めて適用できる。lethal trifecta も1つの故障モードにすぎず、それを防ぐために「強度」を持たせる。「この橋は揺れすぎる → 揺れる橋を安全に渡る方法を考えよう」ではなく、橋そのものが過度に揺れないように変えるのが正しい
  • 世界が狂っているように感じる。その橋の比喩で言えば、昔から橋を作る技術はあるのに、ごくまれに床が突然消えて人が川に落ちる現象が起き、それでも「別の方法を考えよう」ではなく「下に網を張って、全員落ちたら捕まえよう」と言っているようなものだ。私たちは本質的に予測不能な技術に何十億も投じ、そのうえでガードレールを少し追加する程度の対応しかしていない。本当におかしい
  • 記事に coders need to という文句が出てきた時点で興味を失った。比喩そのものが間違っている感じがするし、実務分野の経験者にも不自然に聞こえる。記者が例として挙げた「会社で LLM が信頼できないデータ、重要情報、外部との通信のすべてに同時にアクセスできる」という条件自体が問題だ。企業がセキュリティより機能を優先して、こうしたリスクを自ら作り出していることが多い。「LLM は確率的であり、決定論的アプローチは不適切だ」という主張は論理の飛躍だ。非決定的であってもサンドボックスの考え方は依然として有効で、言い換えれば比喩を引っ張りすぎるとむしろその分野の理解に役立たない。関連用語やドメイン知識を使うほうがよいが、そうすると記事としての魅力は薄れるだろう
• まさか記事では、単に速度制限とより良いモデルの利用だけが解決策だと言っていたのか？ ソフトウェアエンジニアはこうしたことを何十年も前から研究してきた。この業界はセキュリティについて答えを知っているのに、AI 製品を急いで出す今の姿勢と噛み合っていないのが問題だ
  • AI も今や同じ IT 分野なのだから、結局のところ「私たちはセキュリティを理解していなかった」ということだ。AI が careless なのは事実ではない。データと命令トークンを完全に分離する方法がないのは根本的な限界であって、不注意のせいではない。「何十年も前に全部わかっていた」というのは傲慢だ
  • 「何十年も前にセキュリティは解決済みだ」という発言は、新しい産業が既存の悪い標準を再生産して「AI 製品」を出すことに躍起になっているときに起こる現象だ。MCP 標準のように最初から穴だらけだった例を見るだけでも、「プロンプトをうまく書く」といったアプローチは滑稽に思える。最大の問題は、AI 業界のほぼ全員が MCP サーバーが DB に直接アクセスする設計を特に疑いもなく受け入れていたことだ。できるからといって、必ずそうすべきではない。こうした杜撰なセキュリティのせいで、多くの AI 製品が実際に侵害されている
  • 「私たちはすでにセキュリティを知っている」という主張は、実際には事実ではない。人間の問題に話を移すと、なおさらそうだ。何十億もかけて繰り返し教育しても、効果は次第に薄れていく構造になっている。最近でも、優れたセキュリティ専門家ですら YouTube 上の単純なフィッシングに引っかかった事例があった
• 元の @simonw の投稿: The lethal trifecta for AI agents, 関連する追加投稿 も参照可能。HN 内の関連議論 のリンクも残しておく
• lethal trifecta とは、LLM が信頼できないデータへのアクセス、重要情報の閲覧、外部通信の3つを同時に持つときに発生する問題だ。解決策は境界（権限）管理によってリスクを下げることで、ごく基本的な Security 101 の話だ
  • そうだが、実際にはセキュリティと機能の間に大きな緊張関係が生じる。個人データで有用な仕事をさせようとすると prompt injection の脆弱性が開いてしまう。また、こうした関連コンテキストをできるだけ統合することはエージェントの効率には有効だが、だからといって信頼できない入力を読むエージェントを完全に分離・隔離すると、かえって有用性が落ちる。関連ブログ 参照
  • これも厳密に言えば基本的なアクセス制御（Access Control）にすぎない。インターネットに接続された瞬間にリスクは急増する。優れたセキュリティ研究者がいれば、たった1つの prompt injection だけでシステム全体を掌握でき、条件の少なくとも1つは即座に満たされてしまう
• LLM は prompt とデータを区別しない。NX bit（実行禁止ビット）のような概念もなく、それに近いものを実装した例もない。もちろん NX bit が導入されてもリモートコード実行を完全には防げなかったように、これだけで完璧に対処できるわけではない。現在もっとも現実的な方法は、既存のセキュリティメカニズムで LLM エージェントのプロセスを管理することだ。たとえば別ユーザーアカウントで実行してファイルアクセスを制限し、ネットワーク、ハードウェア、cgroups による制限も追加する。それでも信頼できないデータに命令が混ざっていれば、LLM が秘密データまで外部に出してしまう危険は残る。そして利用者が LLM の出力内容を認識せずに外部へコピーすれば、流出経路は再び開いてしまう
  • 「それに近いものを作った人がいないと言うけれど、本当に試みた人すらいるのか、関連する訓練データがあるのか気になる。社会的動物は自然に compartmentalization（区画化）を行う。犬でさえ人の様子をうかがって食べ物の存在を隠すことがある。私も子どもを育てながら、社会生活、機密知識、子どもの個人情報、まだ子どもには受け止めづらい情報、自分の本音、信頼できない出所から得た内容などに応じて情報をすべて分けて扱っている。知能も重要だが、知恵（wisdom）こそが、まだ LLM の領域では最重要の考慮事項になっていない。子犬や幼児でさえ区画化能力では先を行っている状況だ
• 関連する深掘り記事で印象的な引用を見た。Google が提案した CaMeL システムは2つの LLM を使って lethal trifecta の一部リスクを回避する。1つは信頼できないデータにのみアクセスし、もう1つはそれ以外のすべてのデータを扱う。高信頼なモデルがユーザーの自然言語命令を制限された範囲のコードへ変換し、信頼できない側のモデルがそのコードの空欄を埋める。この構造によってセキュリティ保証は得られるが、その代わり LLM が実行できる業務範囲に大きな制約が生じる。初めて聞いたが、本当に有効なのか気になる。真に「絶対的」なセキュリティが保証されるのか、どんな制約条件が発生するのか、実用的な代替になりうるのか知りたい。記事出典
  • CaMeL 論文については長く考えたことがある。かなり良いアプローチだが、実際の実装は相当に難しく、システムがこなせる機能もかなり限定される。私の分析記事 にまとめてある
• 「AI エンジニアも、橋の建設など人命被害につながりうる分野の本物のエンジニアのように考えるべきだ」という比喩が出てくる。「AI エンジニアは学生時代から、より多くの訓練データと賢い prompt さえあれば問題は解決すると信じ込むように慣らされている」といった文脈だ
  • ここでいう「AI エンジニアは本物のエンジニアのように考えるべきだ」とは、単なるソフトウェアエンジニアではなく、現実のエンジニアのように、今やソフトウェアは橋や車にも組み込まれているのだから、少なくとも物理を扱う工学者の思考法を身につけるべきだ、という意味だ
  • まるでソフトウェアエンジニアリングの資格や倫理認証まで必要だという提案を示唆しているようだ。しかし、非倫理的だが合法なソフトウェアが非常に高い収益を生み出す以上、こうしたアイデアは実際には適用が難しいと感じる
  • 「より良い訓練データさえあれば解決する」という考えの行き着く先は、結局こうした悲劇的被害そのものが訓練データになるということだ
  • ソフトウェア「エンジニア」だけでなく、「アーキテクト」の役割も忘れてはならない
• LLM アカウントを自動監視し、入力をフィルタリング／パイプライン処理してくれるソフトウェア製品を、一定料金のサブスクリプションサービスとして運営すれば、ビジネス機会があるのではないかと思う