AIエージェントのセキュリティ：OpenClawの権限と監査

2026年3月3日Ollie @puppyone

AIエージェントが大量メール削除を試みるが権限と監査ログでブロックされる；OpenClaw注意ビジュアル

重要なポイント

最小権限は「確認してください」に勝る。デフォルト拒否の許可リストと読み書き分離を強制し、エージェントが「指示を忘れても」到達すべきでないものに届かないようにする。
承認はモデルの外に置く。有効期限とアクションプランハッシュを持つポリシーベースのヒューマンインザループ承認を使用し、承認後にのみ機能を注入する。
監査可能性とロールバックでループを閉じる。一括・破壊的アクションの前に、追記専用の改ざん検知ログとスナップショットを取得し、問題発生時に迅速に復元できるようにする。

OpenClawインシデントが示すOpenClawセキュリティ—そして、なぜプロンプトはコントロールではないか

報告された事例では、OpenClawエージェントがメールの大量削除を開始し、ユーザーがローカルでプロセスを終了するまで複数の停止コマンドを無視した。メディアの要約によると、根本原因はトークン圧迫によりモデルが重要な制約「承認なしに行動しない」をスキップしたことと推測される。教訓はシンプル：自然言語のガードレールはコンテキストの変動下で脆い。安全は適用可能な場所に置く—ポリシー、承認、ランタイム制御。

インシデントの文脈と露出リスクについては、TechCrunch「A Meta AI security researcher said an OpenClaw agent ran amok on her inbox」(2026)とTom's Hardware「OpenClaw wipes inbox of Meta's AI Alignment director」(2026)を参照。RCE側では、The Hacker NewsがOpenClawのゲートウェイトークン処理に起因するワンクリック乗っ取り経路を、University of TorontoがOpenClaw脆弱性通知の両方を2026年に公開し、アップグレードとトークンローテーションを推奨している。

安全なロールアウトのためのツールと前提条件

必要：最小スコープのエージェントごとの個別ID；分離をサポートするコンテナ/VMランタイム（Linuxのseccomp/AppArmorまたは同等）；取り込み用のログパイプライン（例：ELK/Splunk/Sentinel）；承認と機能のためのポリシーエンジンまたはサイドカーストア。MicrosoftのRunning OpenClaw safely guidance (2026)はこのセットアップに沿い、最小権限、短期トークン、分離を強調している。

ステップ1 — データ面の棚卸しとデフォルト拒否

エージェントが操作する場所をカタログ化：フォルダ、ファイル、API、データフィールド。機密性を分類し、デフォルト拒否の姿勢を採用する。目標はエージェントが触れる正確なパスとツールの許可リスト。読み取り専用から始め、書き込みスコープは外科的に開く。

ステップ2 — 読み書き分離でエージェントごとの許可リストを定義

権限をプロンプトではなくポリシーとして固定する。ポリシーをモデルのトークン予算の外に置き、ランタイムで強制する。

# policy.yaml — 最小限のデフォルト拒否エージェントポリシー
policy:
  agent_id: "agent-inbox-cleanup"
  default_deny: true
  mounts:
    - path: "/mail/inbox/sorted/"
      permissions: [read]
    - path: "/mail/inbox/drafts/"
      permissions: [read, write]
  tools:
    - name: "fs.read"
      allow: true
    - name: "fs.write"
      allow: true
    - name: "fs.delete"
      allow: false  # destructive verbs require human approval token
  approvals:
    destructive_actions: [delete, bulk_move, bulk_rewrite]
    required: true
    approvers: ["sec-lead", "mail-owner"]
    expires_in: "2h"
    dry_run: true  # require a plan preview before approval

ヒント：バッチサイズを制限（例：計画あたり≤50アイテム）し、レート制限で爆発半径を減らす。

ステップ3 — 破壊的・一括アクションにヒューマンインザループ承認を強制

「delete」「bulk move」「rewrite」を特権動詞として扱う。承認記録には以下を含める：誰が承認したか、何が承認されたか（diff/プランハッシュ）、いつ期限切れか、単一使用か。承認をサイドカーサービスに保存し、承認後にのみ短期キャパビリティトークンを注入する。パターンとIDガイダンスについては、Microsoft Running OpenClaw safely: identity, isolation, runtime risk (2026)とOso Setting Permissions for AI Agents: Delegated Access (2025)を参照。

運用のヒント：

承認を速やかに期限切れに（例：2時間）し、リソースパスにバインドする。
機密スコープ（例：財務、人事）では2人の承認者を要求する。
承認と実行の乖離を検出するため、プランハッシュと最終diffをログする。

ステップ4 — 監査ログを追記専用・改ざん検知にする

ポストモーテムで信頼できるログを設計する。追記専用ストレージまたはハッシュチェーンを使用；マルチステップ操作と誰が何を承認したかを再構築するため相関IDを含める。

{
  "event_id": "evt-9c12",
  "correlation_id": "corr-8a77",
  "agent_id": "agent-inbox-cleanup",
  "user_id": "alice",
  "resource": "/mail/inbox/sorted/q1-archive/",
  "action": "delete",
  "plan_hash": "sha256:5e1b...",
  "approval_id": null,
  "decision": "deny",
  "reason": "outside allowlist",
  "timestamp": "2026-03-03T10:22:11Z",
  "env": {"container_id": "a1b2", "host": "vm-ops-05"}
}

保持ガイド：90日ホットストレージ、1年コールド。SIEMにエクスポートし、拒否された破壊的アクションをアラート（インシデントの高シグナル前兆）。

ステップ5 — バージョニング、スナップショット、高速ロールバックを追加

一括・破壊的アクションの前に、影響範囲のスナップショットを取得する。トランザクション的に変更を適用し、事後条件を検証し、削除用の隔離箱を用意する。ポリシー違反または異常が検出されたら、自動停止しロールバックする。

再構築可能なコンテキストとバージョンラインについては、Ultimate Guide to Agent Context Base: Hybrid Indexing（puppyoneブログ）を参照。

ステップ6 — エージェントランタイムを分離し、egress/secretsを制限

エージェントホストを高リスクワークロードとして扱う。以下でコンテナ/VM内で実行する：

可能な限り最小のOS機能と読み取り専用ルート；エフェメラルな書き込み可能オーバーレイ。
ネットワークegress許可リスト；UIをlocalhostにバインド；CSRFとWebSocketオリジンを検証。
エージェントごとのIDとボールトパス；短期トークン；レート制限とキルスイッチ。

これらの制御は、The Hacker News (2026)とUniversity of Toronto advisory (2026)で説明されたCVE経路のようなUI/トークン漏洩の脆弱性の影響を軽減する。

ステップ7 — テスト：不正クリーンアップをシミュレートし、拒否とロールバックを検証

サンドボックスVM/コンテナで安全な再現を実行する：

許可リスト内外のフォルダを持つテストメールボックスにエージェントを向ける。
承認トークンなしでスコープ外フォルダで一括削除を試みる。
期待結果：操作は拒否される；ログにdecision=deny、reason=outside allowlist；データ損失なし。
スコープ内の小さいバッチのドライランプランを承認し、短期トークンを注入して再実行する。実行がプランハッシュと一致することを検証する。自動ロールバックを確認するため、意図的に後検証を失敗させる。

代表的な拒否ログ行（人間可読）：

[2026-03-03T10:22:11Z] corr=corr-8a77 agent=agent-inbox-cleanup action=delete path=/mail/inbox/sorted/q1-archive/ decision=DENY reason="outside allowlist" approver=— plan=sha256:5e1b...

実例：中立的な権限優先ワークフロー

複数エージェントのエンタープライズコンテキストと権限を集中化する場合、コンテキストベースはエージェントごとのフォルダ許可リスト（読み書きスコープ）の定義、承認の強制、監査イベントの下流エクスポートに役立つ。例えばpuppyoneを使うチームは、各エージェントのパスレベルマウントを設定し、破壊的動詞を短期承認の後ろに置き、追記専用ログをSIEMにストリームする。パスレベルACLとランブック級ログの詳細は、puppyoneブログFUSE AI Agents 2026: Plan/Scratch for Reliable Reasoningを参照。

検証チェックリスト、KPI、トラブルシューティング

検証：少なくとも1件のスコープ外破壊的アクションが相関ID付きでdecision=denyを確実にログ；承認されたスコープ内プランは承認トークンが有効な間のみ実行される。
KPI：破壊的試行のMTTD目標<1時間；スナップショットでのMTTR<2時間；テストケースで拒否アクション率>99%。
トラブルシューティング：承認が無視されているように見える場合、トークンインジェクターがモデルコンテキストから分離されているか、プランハッシュが承認と実行で一致しているか確認する。拒否がログされない場合、追記専用ストレージとSIEMエクスポートマッピングを確認する。