安全に設定するための確認事項

確認済み実機・内容確認: 2026-07-22 対象バージョン: v0.19.0 対象コミット: 967e078a #hermes#guide#security#checklist

承認の既定は smart で、ファイル書き込みの保護層がある。このチェックリストはその前提で書いている。

初期設定

承認モードは smart のままか、manual へ戻すか

承認の既定は manual ではなく smart。危険パターンに一致したコマンドは LLM レビュアーが独立に審査し、低リスクならそのコマンド 1 回限りで自動承認、明確に危険なら自動拒否、判断がつかない場合は従来どおり人への確認プロンプトへエスカレーションする。承認プロンプトの頻度が下がるのは正常な動作で、設定ミスではない。

次のいずれかに当てはまる間は manual へ戻すことを推奨する。

エージェントが実行するシェルコマンドをまだ読み慣れておらず、何が危険かを自分で判断できない
本番環境や顧客データに触れるワークスペースで使う
導入直後で、どんなコマンドがどんな頻度で実行されるかをまず把握したい

切り替えは設定 → 安全性 → 承認モード（ステータスバーの承認モードメニューからも可能）。動作の詳細は安全性を参照。

絶対に実行させたくないコマンド（approvals.deny）

ユーザー定義の拒否ルール。~/.hermes/config.yaml の approvals.deny に fnmatch グロブ（* ? [...]）で書いたパターンは、--yolo や /yolo、承認モード: off よりも先に評価され、一致したコマンドは無条件でブロックされる。「承認は smart で自動化しつつ、force push のような一線だけは越えさせない」構成に向く。書き方と注意点は安全性を参照。

API キーの保管（SecretSource）

プロバイダーの API キーを平文の ~/.hermes/.env に置く代わりに、SecretSource 経由で Bitwarden Secrets Manager または 1Password（op:// 参照）から起動時に取得できる。.env に残すのはシークレットマネージャーへ接続するためのブートストラップトークンだけで、残りのキーはマネージャー側で集中管理・ローテーションできるため、ディスク上の漏えい面が減る。複数ボールトを同時に有効化でき、優先順位は決定的（.env / シェルの既存値が原則勝ち、競合は起動時に警告）。注入されたキーには変数ごとに出所ラベルが付き、セットアップフローや hermes model の表示で「(from Bitwarden)」のように確認できる。設定方法はツールとキーを参照。

ファイル書き込みの保護

公式セキュリティドキュメントの防御モデルは 8 層で構成され、「File write safety（ファイル書き込みの安全性）」が独立した層として含まれる。write_file と patch によるファイル書き込みは、実行前に保護パスの拒否リストと、任意の書き込みサンドボックスで検査される。ブロックされた書き込みは承認プロンプトを経ずに即座にエラーとしてエージェントへ返り、チャット UI から上書きする手段はない。

常時拒否される保護パス

次のカテゴリは HERMES_WRITE_SAFE_ROOT の設定有無に関係なく常に書き込み拒否される。

カテゴリ	例
OS の資格情報	`~/.ssh/`、`~/.aws/`、`~/.kube/`、`/etc/sudoers`、`~/.netrc`
Hermes の資格情報	`~/.hermes/.env`、`~/.hermes/.anthropic_oauth.json`、`mcp-tokens/`、`pairing/`

サンドボックスのルートを $HOME に向けても、~/.ssh/id_rsa などの保護パスは書き込めない。

HERMES_WRITE_SAFE_ROOT で書き込み先を限定する

前提: ターミナルから Hermes の起動環境に環境変数を設定できる。~/.hermes/ 配下へも書かせたい場合はそのパスもルートに含める（プロジェクトディレクトリだけを指定すると、cron ジョブ定義などの Hermes 状態ファイルへ書けなくなる）。
操作: HERMES_WRITE_SAFE_ROOT=/path/to/project:/home/you/.hermes のように、許可する書き込み先を : 区切り（Windows は ; 区切り）で設定して起動する。
期待結果: write_file と patch は指定ディレクトリ配下のみ書き込める。範囲外は承認へ回らずハードブロックされ、エージェントには Write denied: '…' is outside HERMES_WRITE_SAFE_ROOT (…) が返る。
失敗時: 意図しないブロックが続く場合は指定パスの綴りとプレフィックスを確認し、環境変数を外せば通常状態（保護パス拒否のみ）へ戻る。

file-mutation verifier フッターの読み方

display.file_mutation_verifier は既定でオン。ターン内に write_file / patch の失敗が残ったまま応答が終わると、最終応答の末尾に「File-mutation verifier: N file(s) were NOT modified this turn …」という警告フッターが付き、書き込まれなかったファイルと理由が列挙される。モデルは書き込みがブロックされても「編集が完了した」と要約することがあるため、本文の完了報告よりこのフッターを信頼する。フッターに載ったファイルはディスク上では変更されていない。

なお、この保護層が対象とするのは write_file と patch のみで、terminal ツールは同じ OS ユーザーとして動くため対象外。事故防止の一層であり、悪意あるプロセスを封じるサンドボックスではない。

自動的に働く安全機構

次の項目は自動的に有効になっており、ユーザー側の設定変更は不要。

Vertex AI の資格情報（GOOGLE_APPLICATION_CREDENTIALS / VERTEX_CREDENTIALS_PATH）はサブプロセスの環境変数から取り除かれ、プロファイルのシークレットスコープ経由で解決される。
メディア・ビジョン・画像生成ツールのローカルファイル読み取りは、資格情報ファイルの読み取りを拒否する共有ガードを通る。
webhook を受け付けるすべての aiohttp サーバーに、受信ボディサイズの上限が設定されている。
Telegram の接続・送信エラーの表示とログから bot トークンが墨消しされる。
ブラウザーガードや .env 読み取り制限を含む複数の P1 セキュリティ修正が組み込まれている。

リモート・外部サービス

ゲートウェイ URL の運営者と TLS を確認した
フォールバック先のデータ処理方針を確認した
クラウドブラウザーへ内部 URL を送らない
Langfuse などの観測基盤へ送るデータを確認した
メモリプロバイダーの保存場所と削除方法を確認した

MCP

配布元と実行コマンドを確認した
stdio サーバーへ渡すパスと環境変数を限定した
HTTP サーバーは HTTPS を使用する
tools.include で必要なツールだけ公開した
書き込みツールの並列実行を許可していない
再読み込み時の確認をオンにした

更新前

設定 JSON を書き出した
バージョンとコミットを記録した
Hermes ソースのローカル変更を確認した
stash / discard の選択を確認した
更新後に全設定項目の追加・削除を確認する予定を立てた

問題発生時

実行中の操作を停止する。
リモートゲートウェイならローカルへ戻す。
直前に追加した MCP、キー、プライベート URL 許可を無効化する。
desktop.log とエラー表示を確認する。
設定書き出しと現在値を比較する。

関連: 安全性 / ツールとキー / ゲートウェイ / MCP