2026年 Hermes Agent Mac版 完全セキュリティ設定ガイド：権限・APIキー・ファイル境界の設定方法

2026年現在、Mac への Hermes 導入でよくある失敗は、初日から「モデルがつながった」「Gateway が起動した」だけで、マシン全体をエージェントに渡してしまうことです。公式ドキュメント（SECURITY.md）も明言していますが、悪意ある LLM 行動に対する唯一のハード境界は OS 側です。コマンド承認、コンテナ分離、Gateway 許可リストは OS 制限の上に載せる深層防御であり、自分で定義するファイル範囲や秘密情報のスコープを置き換えるものではありません。

先に結論： Hermes Agent にホームディレクトリ全体とすべてのシェルコマンドをデフォルトで渡すべきではありません。最小ワークスペース、最小限の API キー、approvals.mode: manual から始め、1 件の実タスクを通してから、意図的に権限を広げてください。以下はインストール後おおよそ30分で終えるべき設定の順序です。

1. 本番タスクの前に決めるセキュリティ baseline

Hermes はデフォルトで terminal.backend: local のため、コマンドは現在の macOS ユーザー権限で実行されます。Gateway に許可リストが未設定だと起動時に外部ユーザーを拒否する——これは健全な fail-closed です。動作確認のために GATEWAY_ALLOW_ALL_USERS=true を入れると、ボットに到達できる誰でもツール呼び出しを起こせます。

現実的なリスクは SF 的な「暴走 AI」ではなく、次の3パターンに集約されます。

• 誤削除・上書き： 再帰 rm、~/.ssh や ~/.hermes/.env の破壊；
• 秘密情報の漏えい： ログ、MCP 子プロセス、コンテナへの環境変数パススルー；
• 不正トリガー： 未承認の Telegram / Discord / Slack ユーザーによるデプロイ・一斉送信・決済スクリプトの実行。

セキュアな設定は「機能を全部オフにする」ことではありません。エージェントが実際に仕事をする範囲だけで動くようにすることです。以降の章の地図として、次の階層表を使ってください。

2. 専用ワークスペースを使う

2.1 メイン macOS ユーザー vs 専用アカウント

避けるべき： 可能なら、日常使いの macOS アカウントで Gateway を常時稼働させないこと。日常アカウントには Photos、Mail、ブラウザパスワードなど TCC 許可が既に広がっており、local ターミナル backend はその表面全体を継承します。

実務的な3段階：

• ローカル試行（低リスク）： メインアカウントのまま CLI のみ、local backend、cwd を専用フォルダに固定；
• 専用 macOS ユーザー（推奨）： システム設定 → ユーザとグループで標準ユーザー hermes を作成、ワークスペースと必要な SSH キーのみマウント；
• 別マシン / VM（本番 Gateway）： terminal.backend: ssh で Mac mini や Linux ワーカーへ接続、Gateway はメッセージルーティングのみ。

Hermes SECURITY.md は、マルチユーザー分離は OS / ホスト層で行う必要があると強調しています。アプリ内セッションキーはトラフィック振り分け用であり、認可境界ではありません。

2.2 ディレクトリ構成と MESSAGING_CWD

専用アカウント上で隔離ワークスペースを作成し、デフォルト cwd を ~ にしないでください。

mkdir -p ~/hermes-workspace/{inbox,outbox,scratch,backups}
chmod 700 ~/hermes-workspace

~/.hermes/.env に：

MESSAGING_CWD=/Users/hermes/hermes-workspace

推奨ゾーン：

• inbox： エージェント向け入力（読み取り専用または準読み取り専用）；
• scratch： 書き込み可能な一時スクリプトとビルド成果物；
• outbox： 外部共有前に人間が確認する出力；
• backups： エージェント書き込み不可——Time Machine や rsync のみ。

リポジトリを紐づける場合は単一プロジェクトのサブディレクトリのみ——~/Projects 全体ではありません。Docker 永続化ではコンテナ /workspace が ~/.hermes/sandboxes/docker/ 配下にマップされます。古いサンドボックスは定期的に削除し、機密ファイルが残らないようにしてください。

3. 秘密情報と API キー

3.1 クレデンシャルの置き場所

Hermes はすべての API キーとトークンを ~/.hermes/.env のみに置く想定です——config.yaml や git には入れません。インストール直後に：

chmod 600 ~/.hermes/.env
chmod 700 ~/.hermes

保存方法と境界：

3.2 プロバイダーキーをコンテナに渡さない

terminal.docker_forward_env と terminal.env_passthrough は Docker やローカル子プロセスへ変数を注入します。OpenAI / Anthropic の主キーを passthrough しないでください——コンテナ内コードが読み取り、持ち出せます。タスクスコープ付きトークン（例：スコープ限定 GITHUB_TOKEN）のみ転送します。

MCP 子プロセスは、MCP env: ブロックで明示しない限り PATH、HOME など安全なデフォルトのみ受け取ります——意図的な設計です。

3.3 キーローテーション checklist

漏えい疑いまたは定期メンテナンス時、次の順で実行：

1. Gateway 停止：launchctl unload または gateway プロセス終了；
2. クラウドコンソールで失効・再発行（LLM プロバイダー、Telegram bot、GitHub PAT など露出の可能性があるものすべて）；
3. ~/.hermes/.env を更新し、旧値が残っていないか確認；
4. ~/.hermes/logs/ とシェル履歴を平文 secret でスキャン；
5. Gateway トークン漏えい時はペアリング再設定：hermes pairing list / revoke；
6. Gateway 再起動；最小タスクで検証してから自動化を再有効化。

4. コマンドとファイル権限

Hermes には危険コマンド検知（tools/approval.py）が組み込まれています。~/.hermes/config.yaml では：

approvals:
  mode: manual    # manual | smart | off
  timeout: 60     # タイムアウト時は拒否（fail-closed）

smart はヘルパーモデルでリスク評価——経験者向け。off や /yolo は承認無効——使えるのは使い捨てコンテナか CI のみ。ハードブロックリスト（rm -rf /、fork bomb など）は YOLO でも拒否されます。

4.1 許可 / 確認 / 禁止テンプレート

CLI 承認選択肢：once / session / always / deny。本番では rm や systemctl に always を使わないでください——command_allowlist に永久書き込みされます。hermes config edit で定期的に監査してください。

4.2 本番では Docker 分離を優先

terminal.backend: docker（または modal / daytona / vercel_sandbox）では危険コマンドチェックをスキップ——コンテナが境界です。Docker デフォルトは capability 削除、PID 上限、/tmp の tmpfs 分離。例：

terminal:
  backend: docker
  docker_image: "nikolaik/python-nodejs:python3.11-nodejs20"
  docker_forward_env: []          # 空 = ホスト secret をコンテナに入れない
  container_cpu: 1
  container_memory: 5120
  container_disk: 51200
  container_persistent: true

コンテナはデフォルトでパブリックインターネットに到達可能です。Skill がネットワーク不要なら Docker 層で egress 制限、または --network=none を検討してください。

5. macOS プライバシー許可ダイアログ

Hermes CLI / Gateway はファイル、ブラウザ操作、スクリーンショットで TCC ダイアログを出すことがあります。メニュー路径は macOS バージョンで変わりますが、原則は同じ：必要最小限を、できれば専用ユーザーアカウントで付与。

• ファイルとフォルダ： hermes-workspace のみ追加。「ディスク全体」や書類フォルダは不可；
• 自動化（Apple Events）： Mail / Notes を Hermes で操作しないなら拒否；
• アクセシビリティ / 画面収録： ブラウザツールが必要なときだけ有効化；
• フルディスクアクセス： 明確な理由がない限り避ける——TCC を迂回します。

システム設定 → プライバシーとセキュリティ → 該当カテゴリ；いつでも取り消し可能。macOS メジャーアップグレード後はリストを再監査してください。

6. Gateway 認可と監査ログ

6.1 誰がボットと話せるか

~/.hermes/.env で許可リストを設定。本番で GATEWAY_ALLOW_ALL_USERS=true は使わない：

TELEGRAM_ALLOWED_USERS=your_numeric_id
GATEWAY_ALLOWED_USERS=your_numeric_id
# または DM ペアリング：未知ユーザーに8桁コード → hermes pairing approve で承認

判定順：プラットフォーム allow-all フラグ → 承認済みペアリング → プラットフォーム whitelist → グローバル whitelist → デフォルト拒否。ペアリングコードは1時間で失効、10分レート制限、5回失敗で1時間ロック——ID 固定だけより柔軟です。

6.2 ログに残すべき内容

デフォルトログディレクトリ：~/.hermes/logs/。保持・ローテーション対象：

• Gateway 起動警告（許可リスト未設定など）；
• 危険コマンド承認結果（承認 / 拒否 / タイムアウト）；
• 不正アクセス試行；
• Skill インストールと lazy-install イベント；
• hermes doctor のサプライチェーン勧告。

ログにはパス、コマンド引数、プロンプト断片が含まれることがあり——機密として扱い、公開クラウドフォルダへ同期しないでください。MCP エラーは ghp_ や sk- などをマスクしますが、最初から secret を少なくログに書くことが前提です。

security.website_blocklist で内部管理 URL をブロック。SSRF 保護は RFC1918 とメタデータ IP をデフォルトブロック——LAN 上の Ollama など本当に必要な場合以外 allow_private_urls: false のままにしてください。

7. 段階的に権限を広げる

local + yolo + allow all users から始めないでください。現実的な段階：

1. 1週目： CLI＋手動承認＋専用ディレクトリ＋プロバイダーキー1つ；
2. 2週目： Gateway 追加、DM ペアリング、自分の ID のみ；
3. 3週目： docker backend に切替、リポジトリ1つをバインド；
4. 本番： 専用 Mac mini / VM＋ssh backend＋リソース上限＋ログアラート。

各段階で15分、意図的な承認テスト：一時ファイル削除、内部 IP への curl、push 試行——ブロックが効いているか確認してください。

8. インシデント対応

誤削除： ワークスペース内 backups または Time Machine から復元；バージョン管理されていれば git checkout。エージェントを一時停止し、ログでトリガープロンプトを追跡。

キー漏えい： セクション 3.3 のローテーション checklist に従う；Telegram 露出時は @BotFather で bot トークン再設定。

不正呼び出し： hermes pairing revoke <platform> <user_id>；Gateway webhook URL 漏えいの有無を確認；ファイアウォールや Tailscale でアクセス制限。

API 課金異常： 先にプロバイダー側の支出上限を設定し、ログで暴走ツールループや cron を調査。

注：Hermes は「データがマシンから一切出ない」ことを保証しません——モデル API、ブラウザツール、Web 検索はすべて egress します。完全ローカル運用ならオンデバイスモデルにルーティングし、該当ツールを自分で無効化してください。

9. インストール後30分セキュリティ checklist

• ☐ ~/hermes-workspace を作成し MESSAGING_CWD を設定
• ☐ chmod 600 ~/.hermes/.env；config.yaml に secret がないか確認
• ☐ approvals.mode: manual；YOLO 無効
• ☐ command_allowlist を監査——空または最小限
• ☐ Gateway 許可リストまたは DM ペアリング；GATEWAY_ALLOW_ALL_USERS オフ
• ☐ 本番 Gateway は docker または ssh backend、local ではない
• ☐ docker_forward_env: []；プロバイダーキー未転送
• ☐ macOS プライバシー許可はワークスペースに限定
• ☐ hermes doctor 実行；サプライチェーン勧告に対処
• ☐ ~/.hermes/logs/ が書き込み可能で、同期クラウドフォルダ内でない

Mac mini で Hermes を動かすと境界がきれいになる

Hermes Gateway を専用 Mac mini上でホストするのは、「日常 MacBook にフル権限を渡す」より合理的です。メインマシンは開発とメッセージングに専念し、mini がエージェント、Docker サンドボックス、ログを担当——個人写真やブラウザ Cookie と物理的に分離できます。Apple Silicon のユニファイドメモリはローカルヘルパーモデル（Ollama など）にも有利で、Gatekeeper、SIP、FileVault がシステム整合性を補強、専用アカウントでは TCC を最小化しやすくなります。

Mac mini M4 はアイドル時約4W、ファンレスで静音、24時間 Gateway 運用に向きます。terminal.backend: ssh と組み合わせれば、コマンド実行はワーカー側、Gateway ノードはメッセージと承認に集中できます。長期稼働のエージェントホストを組むなら、Mac mini M4 は最もコスパの良い起点のひとつ——今すぐ導入し、Hermes を自分が定義した境界の内側に留めてください。