安全性
コマンド承認、内部ネットワークアクセス、シークレット保護、編集前スナップショットを設定する。承認モードの既定は smart、承認タイムアウトの既定は 300 秒で、設定ファイル側には無条件拒否ルール approvals.deny がある。

| 画面表示(主) | 内部キー(サブ) | 製品既定値 | 推奨 |
|---|---|---|---|
| 承認モード | approvals.mode | smart | smart。全件を自分で確認するなら manual |
| 承認タイムアウト | approvals.timeout | 300 秒 | 300秒(既定のまま) |
| MCP 再読み込みの確認 | approvals.mcp_reload_confirm | オン | オン |
| コマンド許可リスト | command_allowlist | 空 | 頻用する低リスク操作のみ |
| シークレットを伏せる | security.redact_secrets | オン | オン |
| プライベート URL を許可 | security.allow_private_urls | オフ | オフ |
| ブラウザーのプライベート URL | browser.allow_private_urls | オフ | オフ |
| プライベート URL にはローカルブラウザーを使用 | browser.auto_local_for_private_urls | オン | オン |
| ファイルチェックポイント | checkpoints.enabled | オフ | コード編集ではオン |
このほか、設定画面には表示されない設定ファイル専用のキーとして approvals.deny がある。
| 画面表示(主) | 保存値(内部) | 既定 | 動作 |
|---|---|---|---|
| Manual | manual | いいえ | 承認対象コマンドを毎回人が確認する。全件を自分で確認したい場合 |
| Smart | smart | はい | フラグ付きコマンドを LLM レビュアーが審査し、低リスクのみ自動承認する |
| Off | off | いいえ | 承認プロンプトを省略する。隔離された使い捨て環境以外では非推奨 |
製品既定値は smart。off でも、致命的な破壊操作のハードブロック、後述の approvals.deny、sudo の標準入力保護など一部の防御は残る。ただし人による確認を失うため、安全と同義ではない。
Smart の仕組み
Section titled “Smart の仕組み”危険パターンに一致(フラグ付き)したコマンドは、会話本体とは別の LLM レビュアーが独立に審査する。判定は 3 通りに分かれる。
- 低リスク ─ 自動承認して実行する。
- 明確に危険 ─ 自動拒否する。拒否は「再試行・言い換え禁止」としてエージェントへ返る。対話中の画面では、この拒否をその 1 回に限り人が上書き承認できる。
- 不明・審査への干渉が疑われる ─ 自動判断せず、従来どおり人への手動プロンプトへエスカレーションする。
判定はそのコマンド 1 回限りで有効になる。自動承認がパターン単位で保存されることはなく、同じ危険パターンに一致する後続コマンドも毎回個別に審査される。またコマンド文字列は信頼できない入力として扱われ、シェルコメントを除去したうえで区切り記号に包んで渡し、コマンド内に埋め込まれた指示を無視するようレビュアーへ明示する。レビュアーの呼び出しに失敗した場合は手動プロンプトへフォールバックする。
すべて確認したい場合(manual へ戻す)
Section titled “すべて確認したい場合(manual へ戻す)”- 前提: Hermes Desktop の設定画面を開ける。
- 操作: 設定 → 安全性 → 承認モード で
manualを選ぶ。ステータスバーの承認モードメニュー(手動 / スマート / オフ)からも切り替えられる。 - 期待結果: 以後、承認対象コマンドごとに毎回確認プロンプトが表示される。
- 失敗時: 切り替えたのに自動承認が続く場合は、操作したプロファイルと会話中のプロファイルが一致しているかを確認する(次項)。
プロファイル別の承認モード
Section titled “プロファイル別の承認モード”デスクトップの承認モードは、プロファイル単位で保持・同期される。ステータスバーの承認モードメニューで、いま使っているプロファイルのモードだけを切り替えられるため、たとえば作業用プロファイルは smart、検証用プロファイルは manual のような使い分けができる。プロファイルの概念は プロファイル管理 を参照。
承認タイムアウトと許可リスト
Section titled “承認タイムアウトと許可リスト”承認タイムアウトは確認待ちの秒数。時間内に応答がなければ拒否される(フェイルクローズ)。既定は 300 秒。メッセージング経由の承認はプッシュ通知で届き、すぐに気づけないことがあるため、通常は既定のままでよい。
コマンド許可リストはカンマ区切りのパターン一覧。たとえば systemctl を登録すると、その語に一致する危険コマンドが将来のセッションでも自動承認される可能性がある。rm, sudo, パッケージ公開、クラウド変更など範囲の広いパターンを登録しない。
無条件拒否ルール(approvals.deny)
Section titled “無条件拒否ルール(approvals.deny)”ユーザー定義の拒否ルール。許可リストの逆で「エージェントに絶対実行させないコマンド」を明示する。設定画面には項目がなく、~/.hermes/config.yaml に直接書く。
approvals: deny: - "git push --force*" - "*curl*|*sh*"- パターンは fnmatch グロブ(
*?[...])で、大文字小文字を区別せずコマンド全体と照合される。 - 照合は危険パターン検出と同じ正規化・難読化解除済みのコマンド変形に対して行われるため、クォート分割(
git pu""shなど)でルールをすり抜けることは難しい。 - 一致したコマンドは
--yoloや/yolo、承認モード: offよりも先に評価され、無条件でブロックされる。製品同梱のハードラインブロックリストの、ユーザーが編集できる対応物にあたる。 - ブロック結果は「再試行・言い換え禁止」としてエージェントへ返り、何も実行されない。
- YAML の都合上、パターンは必ずクォートする。先頭の
*は裸で書くと YAML として解釈に失敗する。
推奨の使い方は「承認は smart で自動化しつつ、絶対に実行させたくないコマンドをここで明示する」構成。承認疲れを減らしながら、force push やパイプ経由のスクリプト実行のような一線だけは越えさせない運用ができる。なお、このルールが守るのはホストに到達する実行バックエンドで、もともとホストに触れない隔離コンテナ実行はこのガードの対象外。
拒否理由を伝える(/deny)
Section titled “拒否理由を伝える(/deny)”承認待ちのコマンドを拒否するとき、/deny <理由>(複数まとめてなら /deny all <理由>)で一言の理由を添えられる。理由はそのままエージェントへ伝わるため、単に「拒否された」ではなく「なぜ拒否されたか」に基づいて別の進め方へ軌道修正させられる。コマンドの一覧と使える場所は スラッシュコマンド一覧 を参照。
プラグインによる承認ゲート
Section titled “プラグインによる承認ゲート”プラグインの pre_tool_call フックが approve アクションを返すと、そのツール呼び出しは危険コマンドと同じ人間の承認ゲートへエスカレーションされる。プラグインが独自の判断でブロックするのではなく「この操作は人に確認させる」と宣言できる仕組みで、エージェント側から承認をスキップする手段はない。承認の記憶粒度はプラグインが指定するルールキー単位(未指定ならツール名と理由の組み合わせ)で管理され、人が応答できない非対話コンテキストではフェイルクローズする。
MCP 再読み込みの確認
Section titled “MCP 再読み込みの確認”- オン: MCP ツールセットを再構築する前に確認する。
- オフ: 確認せず再読み込みする。
MCP のツール定義が変わると、モデルが利用できる外部操作も変わる。また、ツールスキーマがシステムプロンプトに含まれるため、再読み込み後のターンではプロンプトキャッシュが作り直される。オンのままにし、サーバー名、実行コマンド、URL、公開ツールを確認する。
シークレットを伏せる
Section titled “シークレットを伏せる”- オン: API キー、トークン、パスワードに見えるパターンを、ツール出力が会話コンテキストやログへ入る前に可能な限り伏せる。
- オフ: 検出文字列をそのまま扱う。レダクター自体の診断以外では非推奨。
完全な漏えい防止を保証する機能ではないため、ログやファイルに平文シークレットを置かない運用も必要。実行中プロセスが値を保持する場合があるため、変更後は新しいセッションで確認する。
プライベート URL
Section titled “プライベート URL”localhost、ループバック、LAN、社内ネットワーク、クラウドメタデータなどへのアクセスに関係する。
| 設定 | オフ | オン |
|---|---|---|
| プライベート URL を許可 | 一般的な URL 取得処理で内部アドレスを拒否 | 一般ツールが内部 URL へ到達可能 |
| ブラウザーのプライベート URL | ブラウザープロバイダーによる内部 URL 操作を拒否 | ブラウザーで内部 URL を開くことを許可 |
| プライベート URL にはローカルブラウザーを使用 | 選択済みのブラウザー経路を維持 | 内部 URL をクラウドへ送らずローカルブラウザーへ自動切替 |
ローカル開発サーバーを操作するときだけ必要範囲で有効化する。内部管理画面やメタデータエンドポイントへの意図しないアクセスに注意する。
ファイルチェックポイント
Section titled “ファイルチェックポイント”- オン: ファイル変更前に、実プロジェクトの
.gitとは別の共有シャドウ Git ストアへスナップショットを作る。 - オフ: チェックポイント処理を行わない。
変更が多いコーディング作業ではオンを推奨する。保持数は 詳細 で設定する。Git コミットやバックアップの代替ではない。
ファイル書き込みの保護(概要)
Section titled “ファイル書き込みの保護(概要)”write_file と patch によるファイル書き込みは、実行前に保護パスの拒否リストと、環境変数 HERMES_WRITE_SAFE_ROOT による任意の書き込みサンドボックスで検査される。~/.ssh/ などの OS 資格情報ディレクトリや、auth.json・.env などの資格情報ファイルは設定に関係なく常時拒否され、承認プロンプトを経ずに即ブロックされる。公式セキュリティドキュメントは、この層を含む 8 層の防御モデルを説明している。設定変更時の安全確認の進め方は 安全に設定するための確認事項 を参照。
© 2026 Hermes Desktop ガイド(非公式)。引用・部分転載は、出典として本ページへのリンクを添えていただければ歓迎します。記事全文の無断複製・転載はご遠慮ください。