rm -rf をブロックしても、AIの本番事故は防げない ── hookに『環境』を判定させる

• URL: https://zenn.dev/sprix_it/articles/4c44e56ba6f28a
• 日付: 2026-06-24
• Tier: Tier 3
• 要旨: rm -rf や破壊的コマンドのフックは本番とステージング を区別しないため、本番環境での accidental リスクは残る。実装例として環境変数・ホスト名から本番判定するロジックを hook に組み込み、deny/ask/allow を振り分ける設計を提示。read は自由に、非本番は高速に、本番の変更は ask で承認、戻せない本番操作は deny に収束させることで、構造的にうっかりを減らす運用を実現できる。ガードレール設計であり完全な壁ではないが、実務的には有効。

詳細

本番環境での AI エージェント運用リスク

基本的な rm -rf・sudo ブロックだけでは不十分。本番環境を特定できなければ、環境に適応した destroy・delete など戻せない操作が素通りする。

環境判別の戦略：環境変数（AWS_PROFILE）・接続先ホスト・踏み台経路・命名規則から本番性を判定し、hook の PreToolUse で read/write/destroy を3層に分類。

実装の核：hook 内で bash 条件分岐で本番判定し、JSON 出力で deny/ask/allow を返す。複数の hook を走らせても出力契約が統一されるため予測可能。

運用上の配分：deny は「戻せない本番操作」だけに絞り、大部分の本番変更は ask で人間が見て承認する。非本番は allow で AI の高速化を活かす。

フック単体の限界：文字列パターンマッチなので、エイリアス・変数展開・環境変数一時変更で回避可能。セキュリティ境界ではなく構造的うっかり軽減装置。本番権限分離・監査ログと多層で守るべき。

実装は permit シェル・settings.json の PreToolUse で登録し、–dangerously-skip-permissions モードでも有効。