自律的に動くエージェントを安心して走らせるには、「やってよいこと」と「人間に確認すべきこと」の線引きが要ります。Claude Code はこれを auto-mode という分類器で持っています。claude auto-mode defaults でその既定ルールが JSON で読め、AI エージェントが警戒すべき危険の地図がそのまま現れます。

3 つのカテゴリ

ルールは ALLOW（自動許可）／SOFT_DENY（要・人間承認）／ENVIRONMENT（信頼境界の宣言） に分かれます。

ALLOW は 8 種類。読み取り専用の操作、プロジェクトスコープ内のローカル操作、manifest に既載のパッケージ導入、公式インストーラからのツールチェーン導入、自分が作ったブランチへの push、メモリディレクトリへの書き込みなど、可逆で影響が閉じた行為が並びます。

要承認に落ちる 30 種類

対して SOFT_DENY は 30 種類と圧倒的に多く、破壊・流出・権限昇格・外部公開を網羅します。代表的なものを挙げます。

  • 本番・共有への変更: 本番デプロイ、kubectl exec などでの本番書き込み、共有リソースの改変
  • 不可逆なローカル破壊: rm -rf・git reset --hard・> file での上書きなど、セッション前から在ったファイルの破壊
  • 資格情報まわり: 資格情報ストアの探索、シークレットの埋め込み、外部への流出
  • 公開・混入: リポジトリの公開化、curl | bash、外部リポジトリのコード実行

設計思想がにじむ 3 つの線引き

既定ルールには、AI エージェント特有の危険観が表れていて学びになります。

読み取りでも本番は危険。 kubectl exec での本番参照は、たとえ読み取りでも認証情報やシークレットを transcript やログに引き込みます。「読み出すこと自体が漏洩」とみなして要承認に落とします。

二つめは 自己改変とメモリ汚染のブロックです。自分の設定（settings.json や .claude/）を書き換える、あるいは読み戻すと許可付与として働く内容をメモリに仕込む——エージェントが自分の権限や記憶をいじって制約を回避する経路を、明示的に塞いでいます。

三つめは 推測した外部サービスへの送信を、善意でも流出扱いにすること。エージェントが自分で選んだ宛先は、ユーザーが信頼を確立していない以上、内部データを送ってよい先ではない、という考え方です。

まとめ

  • auto-mode は各アクションを ALLOW / SOFT_DENY / ENVIRONMENT に振り分ける安全弁。
  • 許可は「可逆で閉じた行為」8 種、要承認は「破壊・流出・公開」30 種。
  • 「読み取りでも本番は漏洩」「自己改変とメモリ汚染を封鎖」「推測した宛先への送信は流出」が思想の核。
  • 組織で使うなら ENVIRONMENT に信頼境界を足して、許可範囲を安全に広げられます。