セキュリティを「検知」だけに頼らない
図: fail-closed 監査（EU AI Act 向けの考え方）
攻撃が検知をすり抜けても、権限を小さくしておけば被害は限定されます（特権分離）。
セキュリティ担当者の役割
セキュリティ部門は LLM ゲートウェイ導入の Risk Owner として、脅威モデル・DLP・インシデント対応を定義する。KEEL では社内データと顧客データが混在しうるため、fail-closed（疑わしきはブロック） を既定とする。
脅威モデル（STRIDE 要約）
| 脅威 | LLM 文脈の例 | 主な対策 |
|---|---|---|
| Spoofing | 盗まれた仮想キーでの不正利用 | キー短 TTL、IdP 連携、mTLS（Phase 2） |
| Tampering | プロンプトインジェクションでツール操作 | 出力ガードレール、MCP スコープ制限 |
| Repudiation | 誰が機密を送信したか不明 | 監査ログ、仮想キーと個人の紐づけ |
| Information Disclosure | 学習データへの混入、ログ漏洩 | DLP、プロンプト非保存、契約上のオプトアウト |
| Denial of Service | 大量リクエストでコスト爆発 | RPM/TPM、予算キャップ、自動キー停止 |
| Elevation of Privilege | エージェントが本来の権限外 API を呼ぶ | ツール許可リスト、ネットワーク segmentation |
DLP（Data Loss Prevention）設計
レイヤー構成
| レイヤー | 検査タイミング | 手法 |
|---|---|---|
| L1 クライアント教育 | 送信前 | ポリシー、IDE 注意表示 |
| L2 ゲートウェイ入力 | リクエスト受信時 | 正規表現、辞書、エントロピー |
| L3 ゲートウェイ出力 | レスポンス返却前 | PII マスキング、機密パターン |
| L4 ネットワーク | egress | 許可 FQDN のみ |
| L5 事後分析 | バッチ | ログ異常検知、サンプリングレビュー |
検知パターン（最低限）
| カテゴリ | 例 | アクション |
|---|---|---|
| 認証情報 | API キー、パスワード、接続文字列 | ブロック + アラート |
| 個人情報 | マイナンバー、クレジットカード | ブロックまたはマスク |
| 顧客識別子 | 契約で禁止された顧客名・案件コード | ブロック |
| ソースコード | 顧客リポジトリのフルファイル（閾値超） | 警告 → Phase 2 でブロック検討 |
正規表現のみの DLP は誤検知・見逃しがある。Phase 2 で ML ベース分類器（Azure AI Content Safety 等）の追加を計画する。
ガードレール
| 種別 | 目的 | 実装例 |
|---|---|---|
| 入力ガード | ジェイルブレイク、指示上書き | 既知攻撃パターン、システムプロンプト保護 |
| 出力ガード | 有害コンテンツ、機密の再出力 | コンテンツフィルタ、長さ制限 |
| ツールガード | 危険な MCP ツール呼び出し | 許可ツールリスト、人間承認（HITL） |
| 予算ガード | コスト暴走 | キー単位の日次/月次上限 |
5 層プロキシ防御モデル
KEEL 推奨の論理防御層（物理は統合可）:
- WAF / CDN — DDoS、基本ボット対策
- API ゲートウェイ（LiteLLM / APIM） — 認証、レート制限、ルーティング
- DLP / コンテンツ検査 — 入力出力スキャン
- プロバイダ契約層 — エンタープライズ契約、学習オプトアウト、地域制限
- 監視・応答 — SIEM、SOAR、キー失効
Internet/社内LAN → [1.WAF] → [2.Gateway] → [3.DLP] → [4.Provider API]
↓
[5.SIEM/Alert]Fail-Closed 原則
| 状況 | 動作 |
|---|---|
| DLP エンジン障害 | 全リクエスト拒否（503 + 内部アラート） |
| プロバイダキー取得失敗 | 拒否（フォールバック別プロバイダは事前定義時のみ） |
| ログ基盤ダウン | リクエストは許可しつつ 別途アラート（Phase 1 妥協点）→ Phase 2 で拒否検討 |
| 認証不明 | 拒否 |
「使えなくなるより漏れる方がまし」は LLM 文脈では成立しない。セキュリティ担当は 停止を既定 で経営と合意する。
インシデント対応チェックリスト
検知〜封じ込め（0〜2 時間）
- [ ] アラート内容の確認（DLP ヒット / 異常コスト / 外部通報）
- [ ] 該当仮想キーの 即時失効
- [ ] 影響プロジェクト・担当者の特定（ログ
key_id） - [ ] セキュリティ責任者へのエスカレーション
- [ ] 必要に応じプロバイダ側キーのローテーション
調査（2〜24 時間）
- [ ] 送信データの分類評価（個人データ・顧客機密の有無）
- [ ] プロンプトサンプリングモードが ON だったか確認
- [ ] 同様パターンの横展開検索（同一チーム・同一ツール）
- [ ] 法的報告要件の判断（個人情報保護法、顧客契約）
復旧・再発防止（1〜2 週間）
- [ ] ポストモーテム作成（第 15 章テンプレ）
- [ ] DLP ルール・教育資料の更新
- [ ] 経営・顧客への報告（契約に従う）
- [ ] 四半期レビュー議題への追加
セキュリティレビューゲート
| ゲート | タイミング | 承認者 |
|---|---|---|
| SR-1 | Phase 1 設計完了 | セキュリティ部長 |
| SR-2 | 新モデル追加 | セキュリティ + 法務 |
| SR-3 | RAG/MCP 本番許可 | セキュリティ + データオーナー |
| SR-4 | 四半期見直し | セキュリティ + 経営 |
顧客案件向けセキュリティパッケージ
KEEL が顧客に提示できる統制の「売り物」:
- 仮想キーによるプロジェクト分離
- 監査ログのエクスポート手順
- DLP ヒットレポート（月次）
- インシデント通知 SLA（社内定義に基づく）
詳細テンプレ → 第 15 章。コンプライアンス対応 → 第 14 章。
プロンプトインジェクション防御（2026 更新）
2026 年の最大 AI セキュリティリスクは プロンプトインジェクション（意味論層への攻撃）。従来 DLP・ファイアウォールは構文パターン中心のため、ゲートウェイでのセマンティック検査 + 権限分離 が必須。
攻撃分類とゲートウェイ対応
| 種別 | 説明 | 主な防御フック |
|---|---|---|
| 直接インジェクション | ユーザー入力に指示を埋め込む | llm_input |
| 間接インジェクション | メール・Web・RAG 文書経由 | mcp_post_tool / llm_output |
| ツール悪用 | 許可過多ツールでのデータ流出 | mcp_pre_tool + Runtime AuthZ |
特権分離（検知に依存しない層）
「致死的三要素」を同時に満たすエージェントを作らない。
- 機密データへの読み取りアクセス
- 信頼できない外部コンテンツの取り込み
- 無制限の外部送信または副作用のあるツール
高リスク操作（クレジット付与、一括削除、外部メール送信）は 人間承認（HITL） をゲートウェイまたはワークフローで強制する。
Content GW ↔ Runtime AuthZ の連携
異常プロンプトパターンを検知した場合、Runtime Authorization 側のリスクスコアを上げ、通常自動承認される操作を HITL にエスカレーションする 双方向シグナル を Phase 2 で設計する。
規制産業・金融系顧客案件では fail-closed（ガードレール失敗時はブロック）をデフォルトとする。fail-open は PoC のみ。
第 7 章へ — 本番品質の深掘り
本章はゲートウェイ上の DLP・ガードレールの骨格です。社内 RAG の本番投入や監査対応では、第 7 章の PII ハイブリッド・監査 5 要素・出力検証 をあわせて設計してください。
v1.7 補強 — 研究知見から見た防御優先順位
OWASP LLM Top 10、NIST AI 100-2、MCP tool poisoning 研究、EchoLeak 型の事例を横断すると、防御の優先順位は「検知精度の高さ」よりも 権限境界・出力経路・証跡相関に置くべきである。
| 優先 | 防御 | 理由 | KEEL 実装 |
|---|---|---|---|
| 1 | 最小権限 | 検知はすり抜ける前提。権限が小さければ被害が限定される | 仮想キー scope、モデル許可、MCP tool ACL |
| 2 | 出力・外部送信の検査 | 間接インジェクションは回答内リンクや外部 fetch で漏洩しやすい | URL/HTML/Markdown/コード片の llm_output 検査 |
| 3 | RAG 検索前 ACL | LLM へ渡った後では秘密情報を完全に回収できない | chunk ACL、検索クエリログ、文書分類 |
| 4 | ツール定義の審査 | MCP は tool metadata 自体が攻撃面になる | tool schema 差分レビュー、署名、承認フロー |
| 5 | 統一 trace_id | 事故時にプロンプト・検索・ツール・認可をつなげる必要がある | Gateway、RAG、MCP、SIEM の共通 ID |
プロンプトインジェクション検知器は有効だが、単独の合否判定にしない。検知、最小権限、出力サンドボックス、実行時認可を重ねる。
セキュリティレビューで追加する質問
| 質問 | 合格ライン |
|---|---|
| RAG 文書は、検索前に利用者権限で絞られているか | LLM 投入前に ACL 適用済み |
| 外部 URL・画像・Markdown リンクを出力する用途か | 用途別に allowlist / blocklist を定義 |
| MCP tool の説明文・schema は誰が承認するか | 所有者・承認者・差分履歴がある |
| Agent が write/delete/export を実行できるか | 人間承認または Runtime AuthZ が必須 |
| 事故時に同一 trace_id で追えるか | プロンプト、検索、ツール、認可、応答が相関可能 |
統制責任の境界表 — 何をどこでやるか
ゲートウェイ万能論を避けるため、実装場所を分けて理解する。
| 統制 | ゲートウェイ（社内 GW / CF AIG 等） | IdP / SaaS 管理画面 | アプリ実装 |
|---|---|---|---|
| 認証・RBAC | 仮想キー・テナント分離 | Entra ID · ChatGPT Enterprise ロール | アプリ側ロールチェック |
| DLP（秘密・PII） | 入力/出力スキャン・ブロック | SaaS 保持期間・学習オプトアウト | 送信前マスキング |
| Guardrails（有害コンテンツ） | CF Guardrails 等で flag/block | プロバイダ Content Safety | 出力の再検証 |
| プロンプトインジェクション | 部分検知 + 権限分離 | — | RAG 取込制御・ツール ACL |
| レート / コスト上限 | GW で集中 | SaaS シート管理 | リトライ制御 |
| 監査ログ | リクエストメタ・DLP 判定 | SaaS 利用ログ（契約範囲） | 業務アプリ監査 |
| MCP / Agent ツール | MCP GW・ツール台帳 | コネクタ権限 | 最小権限・HITL |
| Action control（外部送信） | ポリシーで禁止ツール | ChatGPT アプリ権限 | 人間承認フロー |
Cloudflare Guardrails は有害コンテンツ評価に強いが、プロンプトインジェクション専用防御ではない（Cloudflare Guardrails 公式）。インジェクションは権限分離 + 間接入力の再検査（第 7 章）で補う。
OpenAI Enterprise 側にも保持期間・RBAC・アプリ権限がある（Business data privacy）。「GW だけ見ればよい」は誤り。
研修 — セキュリティコース D（確認 5 問）
| # | 問題 | 正解 |
|---|---|---|
| 1 | DLP が検知をすり抜けた場合の最後の砦は？ | 権限分離（特権最小化） |
| 2 | 間接プロンプトインジェクションの主な経路は？ | RAG / メール / Web 文書 |
| 3 | Guardrails だけで Agent の DB 削除を防げる？ | いいえ — ツール ACL + HITL |
| 4 | 監査ログが書けないときの金融系方針は？ | fail-closed（推論も止める） |
| 5 | シャドー MCP の対策は？ | ツール台帳 + ネットワーク遮断 |
演習 — DLP アラート初動（15 分）
状況: 深夜、SIEM に「顧客名パターン検知・ブロック」が 50 件/10 分。
| ステップ | あなたの対応 |
|---|---|
| 1. 15 分以内 | 該当仮想キー特定・一時停止要否判断 |
| 2. 1 時間以内 | PM・データオーナーへ連絡 |
| 3. 24 時間以内 | インシデントチケット起票（第 15 章） |
模範: キー停止 → ログ保全 → 横展開検索 → 第 13 章 Runbook 参照。
v1.10 — 4 カテゴリ・2026 チェックリスト
現場の AI セキュリティ論点は、次の 4 カテゴリに整理できます（Zenn 記事 より KEEL 向けに適用）。
*出典: 開発現場のAIセキュリティを見直す（nenene01 / Zenn）*
| カテゴリ | 代表対策 | 本パック |
|---|---|---|
| ガバナンス・契約 | 学習オプトアウト、Shadow AI 禁止、保持期間 | 第 3 章 |
| データ保護 | マスキング、本番データ持ち込み禁止、DB 権限 | 第 7 章 |
| アクセス統制 | 専用ロール、短命認証、監査可能な接続経路 | 第 8 章 |
| 外部汚染への防御 | Lethal Trifecta 回避、MCP 審査、パッケージ確認 | 第 6・9・13 章 |
露出 vs 悪用可能 — インフラメタデータの捉え方
| 情報 | 露出してよいか | 悪用に必要なもの |
|---|---|---|
| ARN・アカウント ID・リソース名 | リコン材料にはなるが、単体ではアクセス不可 | 有効な認証情報 |
| シークレットのキー名（Key Vault / Secrets Manager 参照） | チーム内「目次」相当。値は別 | GetSecretValue 権限 |
| 個人情報・接続文字列の値 | 不可 | — |
構成情報の露出はゼロが理想だが、エージェントに describe 系を任せるとコンテキストに載る。短命 SSO + 読み取り専用ロールで「知っていても鍵はかかっている」状態に留める（第 8 章付録）。
研修 — 確認テスト追補（コース D）
| # | 問題 | 正解 |
|---|---|---|
| 6 | 学習不使用プランなら個人情報をプロンプトに入れてよい？ | いいえ — 保持期間の問題が残る |
| 7 | SELECT * で本番 DB を調査させたとき最大のリスクは？ | ツール出力が事業者へ再送信される |
v1.11 — 破壊的コマンドとリスト防御（iwaken71 教訓）
Zenn: Dドライブ消失事例 では「ブランチ整理」が git clean -fdx 等に化けうる。DLP やモデル allowlist では止まらない。
| 防御層 | 具体策 | 限界 |
|---|---|---|
| deny 加速弾 | git clean, git reset --hard, rm -rf, Remove-Item -Recurse | パス・cwd 次第で爆心地が変わる |
| allowlist | 日常は git status, npm test 等のみ無承認 | best-effort（Cursor 公式） |
| サンドボックス | シェルをワークスペース内に閉じる | .cursorignore は端末に効かない |
| セマンティック hook | destructive_command_guard | 導入・更新の運用コスト |
| スコープ | リポジトリ単位で開く（ドライブ直下禁止） | 組織文化 |
研修 — セキュリティコース D 追補（リスト）
| # | 問題 | 正解 |
|---|---|---|
| 6 | git clean を deny リストに入れれば D ドライブ事故は防げる？ | いいえ — cwd・.git 位置・allowlist/サンドボックス併用が必要 |
| 7 | allowlist はセキュリティ境界か | いいえ — 便利な加速。承認・hook と併用 |
| 8 | リストの正本は GW だけか | いいえ — 端末・Registry・IdP も正本。台帳で RACI |
インシデント時に見るリスト
- 直前に変更された KEEL-LST-xxx（第 15 章）
- 仮想キー / チームの MCP 権限（LiteLLM Admin）
- 端末 permissions.json / Run Mode 設定
- 監査ログ（GW + SIEM — チャット履歴に依存しない）
