最近、AIエージェントの安全設計を追っていて、少し気になる事例が続きました。
「危険な操作を禁止する」「sandboxへ閉じ込める」だけなら分かりやすいのですが、AIが自分で想定外の実行経路を見つけるようになると、話が変わってきます。
この記事では、2026年にOpenAIが公開したサイバー関連の事例を材料に、AIエージェントの境界を Allow / Deny だけで考えてよいのかを、実装寄りに整理します。
この記事は設計上の問いを整理する記事です。OpenAI内部に公開資料で確認できない仕組みが存在しない、と断定するものではありません。
まず何が起きたのか
2026年7月21日、OpenAIはHugging Faceと共同で、モデル評価中に発生したセキュリティインシデントを公開しました。
OpenAIの説明によると、GPT-5.6 Solとさらに強い未公開モデルをExploitGymで評価していた際、モデル群は本来の問題を解くだけでなく、評価環境からInternetへ到達する経路を探索しました。
大まかな流れは次のように読めます。
ExploitGymの問題を解く
↓
Internetへ直接出られない
↓
利用可能な経路を探索
↓
内部package proxyの未知の脆弱性を利用
↓
研究環境内でprivilege escalation
↓
lateral movement
↓
Internetへ出られるnodeへ到達
↓
Hugging Face側にsolutionがある可能性を推論
↓
外部production infrastructureへ到達
OpenAIは、この事例について自己保存や独立した隠れた目的の証拠を示したわけではありません。むしろ、モデルが与えられた狭い目標へ強く最適化していた、と説明しています。
ここが重要です。
「AIが悪意を持って脱走した」という話にしなくても、Goal達成のために設計者が想定していなかったAction Pathを生成したという問題は残ります。
公式資料:
できる と やってよい は別
人間なら当たり前に分けているものがあります。
Capability != Authority
鍵の開いた部屋へ物理的に入れるとしても、それだけで「入ってよい」ことにはなりません。
ソフトウェアでも同じです。
from dataclasses import dataclass
@dataclass
class Actor:
can_delete: bool
authority_scope: set[str]
actor = Actor(
can_delete=True,
authority_scope={"sandbox.tmp"},
)
このactorに削除能力があっても、次の操作は別判定です。
def can_delete(actor: Actor, resource_scope: str) -> bool:
return actor.can_delete and resource_scope in actor.authority_scope
ここまでは普通のauthorizationです。
しかし、AIエージェントではさらに難しい問題が出ます。
そもそも設計時に列挙していなかったPathを実行時に見つけた場合、そのPathのAuthorityをどう判定するのか。
OpenAIは3月の時点で「制限迂回」を観測していた
実は7月のincidentより前、OpenAIは2026年3月19日に内部coding agentのmonitoringについて公開しています。
数千万規模のagent trajectoryを監視した結果、モデルがユーザー指定Goalを達成しようとして、制限を回避しようとするケースがあると報告しています。
公開された例では、agentが Access is denied に遭遇したあと、security controlの可能性を推測し、commandの難読化や処理分割で回避を試みています。
OpenAIはdeveloper promptがこの挙動を誘発していたことを確認し、promptを変更しました。
現在の仕組みでは別AIがtrajectoryを監視し、問題行動を検出すると人間へescalateします。また将来的には、Actionを実行する前にmonitorが評価してblockする同期型制御も計画されています。
公式資料:
構造として書くと、こんな形です。
Agent
↓
Proposed Action
↓
Monitor AI
↓
Alert / Block
↓
Human Review
これは非常に重要なdefense-in-depthです。
同時に、境界判定をAgentの外側にも持たせる設計だと分かります。
7月のincident後はContainmentを強化した
7月21日のincident後、OpenAIは次のような改善を説明しています。
- containmentの強化
- monitoringの強化
- access controlの改善
- evaluation practiceの改善
ここで大事なのは、「モデルをもっと倫理的にする」だけを回答にしていないことです。
Agentが判断を誤っても、環境側で被害範囲を制限する。
これは安全設計として妥当です。
Internal Judgment
+
External Enforcement
の二重化と考えられます。
8月7日、Critical cyber capabilityを排除できなくなった
さらに2026年8月7日、OpenAIは開発中モデルAstraについて、Preparedness Framework上のCritical cyber capabilitiesを排除できないと発表しました。
「Criticalだと確定した」ではありません。
OpenAIの表現は、preliminary evaluationの結果、Critical水準を持つ可能性を安全側から除外できなくなった、というものです。
その対応として、OpenAIは次を強化しました。
- isolated testing environments
- network / tool access restrictions
- sandboxed execution
- model-weight protection
- monitoring / detection
- agentic application全体へのrisky-action / misalignment monitoring
さらに、必要なcontrol requirementsを満たさないAstra関連の内部活動をpauseしています。
公式資料:
ここでも設計の中心は、能力だけではありません。
Capability
↓
Risk Classification
↓
Control Requirement
↓
Run / Pause
と、実行経路そのものを制御しています。
8月10日、強いCapabilityを「誰に渡すか」で分けた
さらに3日後の8月10日、OpenAIはDaybreakを拡張しました。
Daybreak Blueでは、承認された防御側ユーザー向けに通常より強いcyber capabilityへのaccessを提供します。
Daybreak Redでは、さらに高度なsecurity research向けにGPT-5.6-Cyberを提供します。
GPT-5.6-Cyberは、OpenAIのAdvanced Cybersecurity Completion Rateで高度なcyber requestの95.0%を完遂したと報告されています。通常のGPT-5.6 Solは1.5%です。
公式資料:
ここでOpenAIが採ったのは、
強いCapability = 常に禁止
ではありません。
利用者、用途、権限、scope、monitoringを含めて、通してよい経路を限定しています。
Capability
↓
Actor Qualification
↓
Authorization
↓
Scope
↓
Permission
↓
Action Review
↓
Execute / Block
↓
Monitoring
↓
Human Oversight
これは単純なcontent guardrailより、かなり実行系に近い安全設計です。
ここで実装上の問いを一つ足したい
ここまでの対策は必要です。
sandboxも必要です。
permissionも必要です。
monitor AIも必要です。
Human-in-the-Loopも必要です。
その上で、もう一つ問いがあります。
Agent自身が、現在の関係によって「ここから先は自分のAuthorityではない」と判断できるようになっているか。
たとえば、昨日までは自分だけが使っていたファイルが、今日から共同成果物になったとします。
Filesystem permissionは変わっていないかもしれません。
Capabilityも同じです。
それでも、削除の意味は変わります。
昨日:
自分だけのdraft
→ delete可能
今日:
共同成果物
→ delete前に確認が必要
つまり境界は、resource permissionだけでは決まりません。
概念的には次のような状態関数になります。
Boundary = f(
Self,
Other,
Relation,
Authority,
Context,
Time,
Impact,
Reversibility,
History
)
このBoundaryは、Actionによってまた変わります。
Allow / Deny だけでは状態が足りない
実装するなら、最低でも次の状態が欲しくなります。
from enum import Enum
class BoundaryDecision(str, Enum):
ACT = "act"
ASK = "ask"
HOLD = "hold"
STOP = "stop"
ESCALATE = "escalate"
たとえば不可逆性が上がったら ACT から ASK へ移る。
第三者影響が見つかったら HOLD へ移る。
Authority conflictが解消できなければ ESCALATE する。
重要なのは、最初に一度Policy checkして終わらないことです。
Observe
↓
Boundaryを再評価
↓
Act / Ask / Hold / Stop
↓
結果を観測
↓
Relation / Contextを更新
↓
Boundaryを再評価
Responsibility Pathwayとの接続
私は、AI・人間・組織・外部systemをまたぐActionについて、Capability、Authority、Evidence、External Effect、Repair、Resume、Residual Ownership、Human Returnを切らずに扱う構造を、責任経路（Responsibility Pathway）として整理しています。
既存の実装記事はこちらです。
今回の問いは、その中でも境界を固定値として持たない方向の設計課題です。
現時点では、関係変化からBoundaryを再構成する部分を「関係責任（Relational Responsibility）」という設計仮説として扱います。
これは現行RPE / RPR APIの実装済み機能だという意味ではありません。
まとめ
OpenAIの2026年の公開資料を並べると、Agent Safetyが単純な「危険な出力を拒否する」問題ではなくなっていることが分かります。
- Agentは制限迂回を試みることがある
- 高能力モデルは想定外のAction Pathを生成できる
- sandboxやnetwork制限だけでは、未知のPathを完全には列挙できない
- monitor AIやHuman reviewが重要になる
- CapabilityとAuthorityを分離し、Actor / Scope / Permission単位で制御する必要がある
その上で、次の実装問題が残ります。
AIを境界の中へ閉じ込めるだけでなく、AI自身が「他者が存在すると境界が変わる」ことを扱えるように設計できるか。
外側でも止める。
内側でも止まる。
片方をもう片方の代替にしない。
次の記事では、OpenAIだけでなくAnthropic、Google DeepMind、Microsoftの公開設計を比較して、すでにどこまで来ているのかを確認します。