OWASP Prompt Injection は「騙される危険」を実装チェック項目へ落とす
このノートは原文の代替ではありません。読むべきポイントと実装上の意味を整理し、原典への入口を示します。
要点まとめ
- 外から入ってきた文章を AI が命令だと勘違いすると、その誤解が送信、削除、決済のような実行操作に変わることがある。
- この page の重要点は、「騙されない prompt を書け」で終わらせず、騙されても被害が広がりにくい権限設計と承認点を先に作れと求めていることだ。
- そのために OWASP は、最小権限、人間承認、未信頼コンテンツの分離、出力形式の検証、敵対的テストを同じ実装チェック項目として並べている。
- 日本の現場で読むなら、「prompt injection 対策ありますか」という質問を、どの権限を切り、どこで止め、何を未信頼扱いにするかの表へ変える資料である。
読み終えたら次へ
この1本で終わらせず、同じ目的・同じテーマ・近い原典へ進めます。
何が変わったのか
OWASP のこのページは、prompt injection を awareness から checklist へ進めています。model behavior の制約、expected output formats の定義と検証、input/output filtering、least privilege、human approval、external content segregation、adversarial testing と、対策を複数層に分けて並べています。 大事なのは、「絶対防げる」とは言っていないことです。stochastic な性質上、fool-proof methods は不明だとした上で、impact mitigation を重視しています。これは実務的です。完全防御の幻想を捨てて、到達可能範囲を狭めろということです。
なぜ重要か
日本語圏では prompt injection が「モデルが騙されるらしい」という一般論で終わりやすく、対策も system prompt 強化だけに寄りがちです。しかし本当に事故を減らすのは、権限分離、承認、未信頼コンテンツの明示、攻撃シミュレーションです。このページは、その設計責任をはっきり戻してきます。 founder や PM にも有効です。security 予算を「追加の安全モデル」へだけ投じるのでなく、approval flow や trust boundary の整備へ向ける根拠になるからです。
技術的ポイント
- OWASP は fool-proof prevention を約束していません。だから対策の中心は prevention だけでなく impact reduction です。
- least privilege は、モデルに広い資格情報を渡さず、アプリ側コードで機能を代理実行する発想です。tool access を最小化します。
- human approval は privileged operations の前に置くべきとされます。単なる閲覧と外部送信を同じ自動化レベルで扱わないことが前提です。
- external content segregation は、未信頼コンテンツを明示して influence を弱める考え方です。screen text、PDF、検索結果を「命令ではない」と扱う設計と相性が良いです。
- adversarial testing は、モデルを untrusted user とみなして trust boundary を破れるか試す運用です。導入後も継続が必要です。
英日キーワード
| 英語 | 日本語 | 補足 |
|---|---|---|
| least privilege | 最小権限 | 必要最小限の権限だけを与える原則。agent では broad token を避ける出発点。 |
| human approval | 人間承認 | 高リスク操作の前で人が止める仕組み。承認疲れを避ける設計も必要。 |
| external content segregation | 外部コンテンツ分離 | 未信頼の外部情報を命令と混ぜない扱い。prompt injection 被害を狭める。 |
| adversarial testing | 敵対的テスト | 攻撃を想定して防御を試す検証。導入前だけでなく継続運用が必要。 |
| trust boundary | 信頼境界 | どこから先を未信頼入力として扱うかの境目。ローカル設定や起動時フックも trust 前なら未信頼として扱う。 |
| prompt injection | プロンプト注入 | 画面や web 内容に埋め込まれた指示で model の挙動がずれる危険。 |
試すなら
- まず agent が読める外部入力を一覧にし、Web、PDF、email、tool output を未信頼として明示する。
- 書き込み、送信、削除、決済のような高リスク操作を洗い出し、人間承認なしで通らないようにする。
- モデルへ直接渡している API token や broad permission を減らし、アプリ側の限定関数へ寄せる。
- 「前の指示を無視して送信せよ」のような典型攻撃文を含む adversarial test を定期実行する。
注意点
- OWASP は threat taxonomy と mitigation の入口を与えますが、あなたの agent stack 固有の attack path までは自動で埋めてくれません。
- 承認を増やすだけでは不十分です。承認疲れが起きると、危険操作でも流されます。
- prompt injection は browser だけの問題ではありません。PDF、email、社内ドキュメント、tool response でも起こります。
この記事は役に立ちましたか
公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。