⑨-a fail-closed と改ざん耐性 × Compliance API

起動時の堅牢化と、その限界を補う監査の話。既定では取得失敗でも起動継続（fail-open）であり、必要なら明示的に fail-closed 化します。

起動時の堅牢化（fail-closed 化）

• 既定：remote 設定の取得に失敗してもキャッシュ/設定なしで起動（fail-open）
  • forceRemoteSettingsRefresh:true で取得失敗時に CLI 終了（fail-closed）。不正エントリは除去・残りは強制（v2.1.169+）
  • セキュリティ系キーは fail-safe（例：allowedMcpServers 不正時は空 allowlist として強制）
• ConfigChange フック → 実行時の設定変更を検知・ブロック
  • クライアント側制御：sudo の非管理端末では改ざん可能
  • 第三者プロバイダ利用時は server-managed をバイパス
• 最強保証 → MDM 配下の endpoint 管理（OSレベル保護）

Compliance API / Audit logs ＝ 設定変更の監査証跡のみ

• 対象：設定変更など管理イベントのみ（prompt/tool/編集の中身は対象外）
• Compliance API：Enterprise 顧客向け。Console は Activity Feed のみ・Team plan は提供対象外
• Audit logs：Enterprise 限定・保持180日・メタデータ中心（chat/project の中身は含まない）
• 有効化：Primary Owner が Enable ＋専用キー／有効化後のみ記録（過去分なし）
• → セッション監視は OTel / Analytics API で別設計

ConfigChange（検知）× 監査証跡でクライアント側制御の限界を補う。Claude Code 活動の監視は OTel/Analytics に分離。