add

2026-07-03 00:38:05 +09:00
parent 87eacd39b2
commit 86cad348b4
149 changed files with 24450 additions and 105 deletions
@@ -0,0 +1,38 @@
+---
+title: AI Jailbreak Severity Framework
+created: 2026-07-01
+updated: 2026-07-01
+type: concept
+tags: [llm, evaluation, security, reliability]
+sources: [raw/articles/anthropic-redeploying-fable-5-jailbreak-framework-2026.md]
+confidence: medium
+---
+
+# AI Jailbreak Severity Framework
+
+AI jailbreak severity framework は、LLM の安全機構を迂回する手法を「成功した／しなかった」だけでなく、どれほど危険で、どれほど急いで直すべきかを共通尺度で扱うための枠組み。[[ai-evaluation-infrastructure]] がモデル能力や agent workflow を測る基盤を扱うのに対し、この概念は安全評価・脆弱性報告・政府や業界との連絡を同じ triage 言語にそろえることを目指す。
+
+Anthropic は Fable 5 / Mythos 5 の輸出管理解除と再展開の記事で、Amazon 研究者の報告を契機に Fable 5 のサイバーセキュリティ安全分類器を強化し、該当の bypass を 99% 超で遮断するようにしたと説明している。一方で、この強化は日常的な coding / debugging の benign request を誤検知しやすくするため、モデル安全は単純な拒否率ではなく、危険行為の取り逃しと正当利用の阻害を同時に測る必要がある。^[raw/articles/anthropic-redeploying-fable-5-jailbreak-framework-2026.md]
+
+## 評価軸
+
+Anthropic の提案は、jailbreak を少なくとも次の 4 軸で見る。
+
+| 軸 | 見るもの | 実務上の意味 |
+|---|---|---|
+| Capability gain | 既存ツールや弱いモデルをどれだけ超える能力を開くか | 既存手段で同じことができるなら緊急度は下がる |
+| Breadth of capability gain | 同じ手法が何種類の攻撃や対象に効くか | narrow jailbreak と universal jailbreak を分ける |
+| Ease of weaponization | 攻撃へ変えるための人間の手間や再試行回数 | 一発で動くほど対処優先度が上がる |
+| Discoverability | 手法の入手しやすさ | 公開済み・拡散済みなら被害化が早い |
+
+この見方は、ソフトウェア脆弱性に CVSS があるように、AI jailbreak にも報告・修正・公開・政府連絡の共通語が必要だという立場に近い。ただし jailbreak の挙動はモデル更新、classifier、prompt、tool 接続、権限境界で変わるため、単一スコアだけで安定的に扱うのは難しい。
+
+## Agent 運用との接続
+
+Agentic coding や自律 job では、jailbreak は chat の不適切回答だけでなく、tool call、shell command、credential、外部 API、永続状態に波及する。したがってこの枠組みは [[ai-agent-command-safety]] や [[ci-cd-runtime-security]] と接続する。たとえば「危険な command を 1 回で出させる」jailbreak は、会話上の失敗よりも実行環境上の影響が大きい。逆に、sandbox・approval・read-only database・network 制限があれば、同じ model-level jailbreak でも運用上の severity は下がる。
+
+## Open questions
+
+- CVSS のような数値化を、モデル・classifier・tool 権限・実行 sandbox が絡む agent system にどう拡張するか。
+- 政府や大手 model provider が作る共通枠組みを、個人や小規模 OSS の red-team / disclosure workflow へどう軽量化するか。
+- Benign coding/debugging の false positive を増やさずに、危険な capability gain だけを抑える評価データをどう作るか。