プロンプトインジェクションはSQLインジェクションではない：NCSCの設計上の教訓

NCSCブログは、プロンプトインジェクションはSQLインジェクションではない、としています。現在の大規模言語モデルは指示とデータを分けず、そのリスクは、パラメータ化されたクエリがSQLインジェクションを除くのと同じやり方では完全には取り除けないかもしれない、としています（https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection）。NCSCニュースは、その比較は危険であり、この問題を止められるという主張に異議を唱えています（https://www.ncsc.gov.uk/news/mistaking-ai-vulnerability-could-lead-to-large-scale-breaches）。設計上の教訓だけです。攻撃の手引きではなく、法律助言でもありません。

2026-10-09。これはエンジニア向けの設計上の教訓で、根拠はNCSCの2ページだけです。攻撃の手引きではなく、回復の約束でもなく、法律助言でもありません。2025年12月8日公開のNCSCブログは https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection です。2025年12月10日公開のNCSCニュースは https://www.ncsc.gov.uk/news/mistaking-ai-vulnerability-could-lead-to-large-scale-breaches です。これらのページには、件数、損失額、率はありません。この記事も加えません。

NCSCブログは、プロンプトインジェクションを、開発者が自分の指示と信頼できない内容を一つのプロンプトに連結し、モデルの応答を、アプリケーションが求めたことと信頼できない内容とのあいだに堅い境界があるかのように扱う場合、と説明しています。現在の大規模言語モデルは、プロンプトの内部で指示とデータのあいだのセキュリティ境界を強制しない、としています。

## SQLとの比較がなぜ誤解を招くか

NCSCブログは、プロンプトインジェクションをSQLインジェクションと比較するのは危険だとしています。SQLでは、パラメータ化されたクエリによって、渡された入力を指示として扱わせないことができます。LLMのもとでは、データと指示の本質的な区別はなく、モデルはそこまでのテキストから次のトークンを予測している、とブログは述べています。そのため、プロンプトインジェクションは、SQLインジェクションと同じやり方では完全には緩和されないかもしれない、としています。

同じブログは、注入の試みを検知する、アプリケーションの指示を優先するようモデルを訓練する、どの範囲がデータかを強調する、という研究を挙げています。それらは、指示とデータを自ら分けない仕組みの上に重ねるものだ、と位置づけています。この記事は、それらの重ね方を作り方としては書きません。

## 本質的に取り違えやすい代理

NCSCブログは、これを単一のコード注入の修正としてではなく、本質的に取り違えやすい代理（inherently confusable deputy）の悪用として扱うよう求めています。古典的な confused deputy は緩和できるが、大規模言語モデルのリスクは同じようには取り除けない、としています。目指すのは、起こりやすさと影響を減らすことです。残るリスクを許容できないなら、その仕事はLLMの良い用途ではないかもしれない、とブログは述べています。

システムがモデルの出力からツールやAPIを呼ぶとき、NCSCブログは、影響が、信頼できない当事者にそれらのツールやAPIへの直接のアクセスを与えた場合の最悪にまで上がる、としています。この記事は、その呼び出しを起こす方法は書きません。

ブログは、間接のパターンも、高い水準だけで名づけています。システムに直接アクセスできない誰かが何かを書き、それが後から処理され、指示として扱われる、というものです。モデルに渡す文書やメッセージが、そのパターンを運び得ます。この記事は、写して使う文言は出しません。

## NCSCがETSI TS 104 223に揃える設計の手順

NCSCブログは、次の手順をETSI TS 104 223に揃えています。ブログはそれを、AIモデルとシステムのためのベースラインのサイバーセキュリティ要件として引用しています。この記事は規格を再述せず、条項番号や試験方法も加えません。

認識。ブログは、開発者、セキュリティチーム、リスクを持つ人が、プロンプトインジェクションは残存リスクのままであることを知る必要がある、としています。製品やアプライアンスでは完全には取り除けません。設計、構築、運用のなかでリスクとして扱う必要があります。

セキュアな設計。ブログは、重要な制御は、それ自体が別のLLMではない決定的な保護であり、システムが許される動作を制約するものだ、としています。権限の規則も述べています。モデルがある当事者からの情報を処理するとき、その処理に使える権限は、その当事者の権限まで下がる、というものです。ブログのメールの例は同じ考えです。任意の外部送信者からのメールを読むモデルに、特権のあるツールを与えない、ということです。

取り違えを起こりにくくする。ただしフィルタを修正とは扱わない。ブログは、データの区間を指示とは別だと印づけると、データの中に入った指示にモデルが従う頻度を下げ得る、としています。既知の句の一覧を止めるやり方は失敗する、とも警告しています。同じ依頼は多くの言い換えができるからです。プロンプトインジェクションを止められると主張する製品には注意し、代わりに、制御が起こりやすさや影響をどう減らすかを見る、とも述べています。

監視。ブログは、疑わしい活動が見えるだけの記録を残す、としています。モデルの入出力や、ツールまたはAPIの呼び出しを含み得ます。失敗したツール呼び出しやAPI呼び出しを、早い合図として扱います。この記事は、その失敗を起こす方法は書きません。

## NCSCニュースが加えること

2025年12月10日のNCSCニュースは、その警告を要約しています。SQLインジェクションとの比較は危険な誤解であり、プロンプトインジェクションはSQLインジェクションと同じやり方では完全には緩和されないかもしれず、大規模言語モデルは指示とデータを区別しない、としています。プロンプトインジェクションを止められるという主張に異議を唱え、設計者、構築者、運用者に、リスクと影響を減らすことと、AIサプライチェーンのレジリエンスを向ける、としています。この誤解に対処しなければ、ウェブサイトは2010年代のSQLインジェクションによる侵害を上回る侵害のリスクを負う、と警告しています。その文はNCSCの警告です。ニュースページは件数も損失も率も述べておらず、この記事も加えません。

## Mithrilがすること、しないこと

Mithrilはエンジニアに公開された境界を示し、プロンプトインジェクションを止めるとは主張しません。ガードレールとファイアウォールのページ https://docs.mithril.fund/reference/guardrails-firewall は、以前の名前付きファイアウォールの版、保証の段、コンテンツ審査のレシート、GET /v1/secure が実装されていない、と記録しています。現在のWorkerは、従量の推論の前に、リクエストのオリジン、プリンシパル、トークンのスコープ、inference以外のトークンスコープを出すときのパスキー保証、モデルチーム、ルート設定、クレジットを確認します。これらのゲートは、プロンプトの審査や、完全な利用許容の制御を証明しません。コンテンツのモデレーション、拒否の監査、プロバイダの扱いは、推論を守られていると宣伝する前に、測定され日付のある検証を必要とします。この記事は、その検証を記録していません。

System One Coding https://docs.mithril.fund/system-one-coding は、段階的なコーディングハーネスと、https://code.mithril.fund/ の登録制の無料パイロットについての公開説明です。そのページは、ハーネスがプロンプトインジェクションを検知するとも、モデルのまわりで権限を下げるとも述べていません。この記事は、そこから性能の数値を写しません。

ホスト型のDASTとSASTはPlannedです。セキュリティサービスのページは、それらをgatedであり、まだ使えない、と掲載しています。Mithrilはインシデントを調査せず、金銭を回復せず、法律助言をしません。エンジニア向けの他のノートは https://blog.mithril.fund/for/engineers にあります。