何のためのものか
permission ベースの設計、prompt injection 対策、MCP・クラウド実行のセキュリティ。これらの保護はリスクを大きく下げるが、いかなるシステムもすべての攻撃に完全に耐えるわけではない。
つまり、仕組みの範囲を知ったうえで運用で埋めるところまでが「使いこなす」に入る。
触る
既定の姿を確認する。
- 既定では厳格な read-only の権限で動く。 ファイル編集・テスト実行・コマンド実行が必要になると明示的に許可を求める
- 書き込めるのは起動したフォルダとそのサブフォルダだけ。 親ディレクトリのファイルは明示的な許可なしに変更できない
/permissionsで今の設定を見る。定期的に監査するのが公式に挙げられているベストプラクティス
入れる
信頼できないコンテンツを扱うときの手順を決める。公式に挙げられているのは次の 5 つ。
- 承認前に提案されたコマンドをレビューする
- 信頼できないコンテンツを Claude に直接パイプしない
- 重要なファイルへの変更案を検証する
- 外部ウェブサービスとやり取りする場合は特に、スクリプト実行やツール呼び出しを VM 内で行う
- 不審な挙動は
/feedbackで報告する
機微なコードでは、プロジェクト固有の permission 設定を使い、追加の分離のために dev container を検討する。
効かせる
保護の中身を知る。ここが分かると「どこまで任せてよいか」が決まる。
- ネットワーク取得系は自動承認されない。
curl/wgetなどは既定でプロンプトが出る。1 回だけ承認するか、Bash(curl *)のような allow ルールを足すか、permissions.denyで完全にブロックするかを選ぶ - web fetch は別のコンテキストウィンドウを使う（取得内容がそのままメイン会話を動かさない）
- 疑わしい bash コマンドは、以前に allowlist されていても手動承認になる。 マッチしないコマンドは fail-closed で手動承認
- MCP サーバーは自分で選ぶ責任がある。 Anthropic は Directory 追加前に listing criteria でレビューするが、セキュリティ監査や管理は行わない
- チームでやるなら managed settings。 承認済みの permission 構成をバージョン管理で共有し、
ConfigChangehook でセッション中の設定変更を監査・ブロックする
落とし穴
-pの非対話実行では trust verification が無効。 対話なら出るはずの確認が出ない- ホームディレクトリで直接起動すると trust がディスクに書かれない。 起動のたびにプロンプトが出る（永続化する設定は無い）。プロジェクトのサブディレクトリから起動する
- Remote Control では接続中トランスクリプトが Anthropic のサーバーに保存される（デバイス間同期のため）。コード実行とファイルアクセスはローカルに留まる
- Windows で WebDAV を有効にすることは推奨されない。 permission system を迂回してリモートホストへのネットワークリクエストを発生させうる
- 脆弱性を見つけたら公開せず、HackerOne プログラム経由で報告する