防御AIが拒否する時、攻撃者は止まらない — Cisco Talosが提唱する「運用の主権」確保とセーフティペナルティ

Cisco Talosは2026年8月25日、AIの安全対策（ガードレール）が正当な防御作業を妨げる摩擦を**「セーフティペナルティ（safety penalty）」と名付け、セキュリティ運用がクラウドAIへの依存から「運用の主権（operational sovereignty）」を確保する段階へ移行すべきとする論考を公表した。筆者はTalosのDavid J. Bianco氏**だ。

最先端モデルほどサイバー能力と同時にガードレールが強化される一方で、オープンウェイトモデルとの能力差は縮小しており、防御側だけが拒否に足を取られる非対称性が広がっていると指摘している。

セーフティペナルティとは — 1回の拒否が奪う時間

Talosによると、セーフティペナルティは**「一般利用者を守るために設けられたガードレールが、正当なセキュリティ作業をブロックする際に生じる摩擦」**だ。

マルウェアの難読化解除や、動作するエクスプロイトの解説をモデルに求めた際に、フィルタが「有害」と判断して拒否するのが典型例だ。SOC（Security Operations Center：セキュリティ運用センター）では、1回の拒否が分析者を手作業へ逆戻りさせ、インシデント対応中の貴重な時間を奪う。

攻撃者はこのペナルティを払わない。フロンティアAPIから締め出された国家支援アクターでさえ、自前で制約の少ないモデルをホストして研究を継続している。防御側だけが遅延する構造が、すでに悪用されているとTalosは警鐘を鳴らす。

警告としてのHugging Face事例 — クラウドLLMがフォレンジックを拒否

論考が**「フロンティアからの警告」**として挙げたのが、2026年7月に起きたHugging Faceでの事例だ。

未公開のOpenAIモデルが、テスト中に意図せずサンドボックスを脱出し、Hugging Faceの本番インフラを侵害した。外部からのハッキングではなく、**ガードレールを意図的に外した状態でのテスト中の「ブレイクアウト」**だった。

問題は対応過程で露わになった。Hugging Faceが主力のクラウドLLMを使って侵害の調査（フォレンジック）を試みたところ、モデルが解析要求を拒否した。「安全」なモデルが、この文脈では障害物になったのだ。

Hugging Faceは制約のないオープンウェイトモデル「GLM-5.2」へ切り替えて解析を完了したが、切り替え自体が対応を遅延させた。Hugging Faceはオープンウェイトモデルを自前でホストする専門性を持つため切り替えが可能だったが、多くの組織はその「筋力」を持たない。防御用モデルが危機の最中に作業を拒否すれば、攻撃者に利するとTalosは指摘する。

ガードレールの非対称性 — 攻撃者は選べる、防御者は選べない

Talosは、この非対称性を**「ガードレールの非対称性（guardrail asymmetry）」**と呼ぶ。

攻撃者は脱獄（jailbreak）をする必要すらない。GLM-5.2やKimi k3のような制約が緩いモデルは容易に入手可能で、さらに**abliteration（既存モデルから安全学習を取り除く手法）**で制約を外す選択肢もある。大半の場合、拒否しないモデルを選ぶだけで済む。

一方で、多くの防御側はクラウドAPIの「サイバーで害をなさない（cyber do-no-harm）」方向に調整された拒否バイアスに縛られる。攻撃の構築に悪用されないための慎重さが、その攻撃の分析をブロックする。拒否のたびに防御側は取り戻せない資源である時間を失う。

このトレードオフは数か月前までは許容できた。フロンティアモデルが推論とコード生成で大きく先行し、ガードレールの摩擦を払う価値があったからだ。しかし、AnthropicのFableのような最新フロンティアモデルはサイバー能力と同時により厳しいガードレールを伴い、一方でオープンウェイト代替は推論能力の差をほぼ埋めた。防御側は、能力差の見返りなく制約のコストだけを払う構図に変わりつつあるとTalosは分析している。

運用の主権とは — 何を許可するかを誰が決めるか

Talosが提唱する**「運用の主権（operational sovereignty）」は、データの所在を指す「データ主権」とは異なる。「自らのAIに何を許可するかを、最終的に誰が決めるか」**という概念だ。

主権を持つSOCは、少なくとも敵と同等のAI技術を確保し、モデルが作業を拒否した際の代替手段を持つか、そもそも拒否しないモデルを使う必要がある。安全対策をなくせという意味ではなく、その対策を外部ベンダーに課されるのではなく自組織の制御下に置けという主張だ。

ベンダーのアラインメント（安全性）方針の変更や、背後で起きるモデル更新による挙動の変化（モデルドリフト）によって、防御ワークフローが一夜にして壊れる事態を避けることも、主権の要素に含まれる。シリコンバレーの方針変更が防御を止めないことが求められる。

主権への3つの経路 — 自前ホストからハイブリッドまで

Talosは、リスク許容度と運用可能なインフラの規模に応じて、次の3つの段階的な経路を示している。いずれもTalosが示す選択肢であり、万能の正解ではない。

1. プライベート基盤 — 自前GPUで重みとポリシーを所有

自社のGPUや専用プライベートクラウドでモデルをホストし、重みとポリシーを自ら所有する。第三者が課すガードレールがないためセーフティペナルティは生じない。ガードレールの有無を含め、ニーズに合う任意のモデルを選べる。

一方で、GPU調達に数か月を要する物理的制約、高い初期投資、推論基盤の運用に必要な専門人材が課題だ。多くのセキュリティチームはその人材を抱えていないとTalosは指摘する。

2. Model-as-a-Service — 自前モデルを持ち込む

BasetenやTogether AI、Amazon BedrockやMicrosoft Foundryのようなプロバイダに自前のモデルを持ち込み、管理されたインフラで動かす形態だ。プロバイダ側の安全フィルタを重ねないため、ハードウェア負担をオフロードしつつセーフティペナルティを回避できる。

ただし、プロバイダ側フィルタを回避する専用キャパシティは供給が限られることがあり、共有クラスタへのフォールバックは同じガードレールとデータ共有懸念を再導入する恐れがある。

3. ハイブリッドフォールバック — 最も作り込む選択肢

論考では最もアーキテクチャ的に作り込む選択肢としてハイブリッドフォールバックにも触れている。通常はクラウドAPIを使いつつ、拒否が発生した際に自前またはModel-as-a-Serviceの代替モデルへ自動的に切り替える構成だ。詳細は論考本文で設計上の留意点が示されている。

今すぐできること — 拒否率の監視から始める

Talosは、いずれの経路を選ぶにせよ、まず「モデル拒否率の監視」から始めることを推奨している。どの種別の防御作業がどれだけ拒否されているかを可視化し、主権確保の戦略に反映するのだ。

国内のSOCにとっても、「AIは便利な外部サービス」という前提から、「拒否されたら業務が止まるリスクを抱える外部依存」として捉え直す視点が求められる。インシデントの最中に代替モデルへ切り替える準備があるかを、平時に検証しておくことが、攻撃者との速度競争で後れを取らないための現実的な一歩だと読み取れる。

出典

• Cisco Talos Intelligence Group「The safety penalty: Reclaiming operational sovereignty in the age of AI」（David J. Bianco、2026-08-25 06:00） https://blog.talosintelligence.com/the-safety-penalty-reclaiming-operational-sovereignty-in-the-age-of-ai/