AgentHarm・AgentHazardで読むAIエージェントの危険な失敗：ツール権限と禁止事項をどう設計するか
AgentHarm、AgentHazardとOWASPの2026年セキュリティガイドをもとに、AIエージェントの権限、runtime controls、承認と停止条件を整理します。
公開 2026.06.27 / 更新 2026.09.26
この記事のポイント
- AgentHarmとAgentHazardは、単発の返答ではなく、有害な依頼・状態・複数stepの連鎖を評価する材料
- 現行Codexの安全運用は、sandbox、approval、network、credential、rules、telemetryを別の境界として設計する
- OWASPの2026 Top 10はリスク分類、Agent Control Standardはruntime制御の標準化資料で、個別agentの安全確率や認証ではない
- full access、本番、secret、DB、billing、削除、外部送信は、ベンチマークのスコアではなく人間承認とrollbackで管理する
結論：安全性は、拒否率だけでなく行動の連鎖と停止点で見る
AIエージェントの危険性は、単発の返答だけでは判断できません。ファイル、ブラウザ、外部通信、認証情報、繰り返し実行がつながると、個別には正当に見える操作が全体として危険になることがあります。AgentHarmとAgentHazardは、その評価を考えるための研究であり、実システムへ攻撃を試す手順ではありません。
| 評価・資料 | 主に見ていること | 個人開発への翻訳 |
|---|---|---|
| AgentHarm | 有害なagent requestへの拒否と、複数stepでの安全性 | 有害な依頼・秘密情報・本番操作を明示的に拒否し、人間確認へ止める |
| AgentHazard | computer-useで状態、反復、文脈、依存が積み上がる危険 | 1操作ごとでなく、作業全体の目的、状態、累積影響、停止条件を見る |
| OpenAI Codex安全運用 | sandbox、approval、network、credential、rules、telemetry | 低リスク作業を限定環境で進め、高リスク操作は承認・記録・rollbackつきにする |
| OWASP LLM / Agentic Top 10 2026 | LLMアプリ全般のリスクと、agent固有のリスク分類。LLM Top 10ではExcessive Agencyが3位 | 順位を発生確率と見なさず、機能、権限、入力、結果の境界へ対応づける |
| OWASP Agent Control Standard | agent platformのmiddleware hookとruntime policy enforcementを標準化する提案 | 対応表明だけで安全と見なさず、実際のhook、制御、ログ、例外処理を確認する |
ベンチマークは特定条件の評価、Top 10はリスクを整理する枠組み、Agent Control Standardはruntime controlsを実装するための標準化作業です。役割は異なります。個人開発では、どの情報を読めるか、どのtoolを実行できるか、誰が確認するか、実行をどう記録して止めるかを具体的に確かめます。
個別の操作が安全そうでも、連鎖すると別のリスクになる
「ファイルを読む」「設定を変える」「テストを実行する」「外部サービスへ接続する」は、単独なら通常の開発作業に見える場合があります。しかし、対象範囲が広い、秘密情報へ届く、networkが開いている、承認なしで繰り返せる、結果を人間が確認しない、という条件が重なると、許可の意味が変わります。安全チェックは操作名ではなく、対象・権限・順序・累積影響で行います。
| 確認軸 | 先に決めること | 止める条件 |
|---|---|---|
| scope | 対象repo、directory、branch、変更可能なfile | 対象外のfile、未知のrepo、広すぎるpath |
| execution | sandbox mode、approval policy、実行できるtool | danger-full-access、無制限の自動承認、破壊的操作 |
| network | 必要なdestination、allowlist、送信内容 | 未知のdomain、外部送信、secretを含むrequest |
| credential | keyring、OAuth、環境変数、credentialのscopeと期限 | 実値の表示、広い権限、期限不明のtoken |
| evidence | prompt、tool action、結果、差分、test、reviewの記録 | 完了文だけ、失敗ログの欠落、未確認事項の不明 |
| final action | deploy、DB、billing、公開、削除のownerとrollback | 人間承認なしの不可逆・本番・課金操作 |
現行Codexを使う時の防御寄りチェック
- 最初はread-onlyまたは限定workspaceから始め、対象pathと変更上限を作業前に書く
- sandboxとapprovalを別の境界として確認し、承認を省略する設定を安全保証と扱わない
- networkは必要なdestinationだけに絞り、外部送信するデータとdomainを確認する
- APIキー、Cookie、token、private key、.envの実値を入力・表示・コミット・送信しない
- 自動化する前にfixture、test、git diff、生成物、ログを確認し、失敗時の停止とrollbackを決める
- deploy、DB変更、billing、公開、削除、権限拡大は、agentの自己評価ではなく人間が最後に承認する
AgentHarm・AgentHazardと権限設計のFAQ
AgentHarmとAgentHazardは何が違いますか？
AgentHarmは有害なagent requestへの拒否や複数stepの安全性を読むベンチマーク、AgentHazardはcomputer-use agentで状態・反復・依存が積み上がる危険を読むベンチマークです。どちらも自分の環境の安全保証ではありません。
sandboxを使えばAIエージェントは安全ですか？
安全保証ではありません。sandboxは実行範囲の一部を制限しますが、approval、network、credential、対象repo、入力の信頼性、最終確認、rollbackも別に設計します。
ベンチマークのスコアが高いagentへfull accessを許可してよいですか？
スコアだけでは許可できません。作業範囲を狭くし、低リスクのfixtureで確認し、差分・ログ・testを見てから必要な権限だけを段階的に与えます。本番、secret、DB、billing、削除は人間承認を残します。
OWASP Agent Control Standardに対応していれば安全ですか？
対応表明だけでは安全を保証しません。利用するagent platformで必要なruntime hookが実行経路に適用され、policy違反や例外が記録され、人間の承認・停止経路が機能するかを確認します。