技術ブログ

Hermes Agentの設定を管理者側で固定する｜Managed Scopeの優先順位を試す

約16分で読めます
#Hermes Agent#AIエージェント#設定管理#セキュリティ
Hermes Agentの設定を管理者側で固定する｜Managed Scopeの優先順位を試す

執筆用 profile では秘密の伏せ字が有効なのに、レビュー用 profile では無効になっていました。利用者ごとの設定に任せると、同じ端末でも安全策に差が生まれます。

Hermes Agent の Managed Scope は、管理者が選んだ設定だけを利用者設定より上に置きます。すべてを固定する仕組みではありません。security.redact_secretsだけを固定し、model の fallback は利用者へ任せる、といった分担ができます。

2026 年 9 月 13 日、Hermes Agent v0.21.0 で優先順位を試しました。検証用のHERMES_HOMEとHERMES_MANAGED_DIRは/tmpに作成しています。本番の profile や/etc/hermesは変更していません。

profileの分離から、共通ポリシーの固定へ進む

前回の「Hermes Agentの人格を仕事別に分ける」では、profile ごとにHERMES_HOMEを分けました。人格、Memory、Skill、cron を混ぜないための境界です。

今回は、その境界を残したまま、組織で共通にしたい設定を上位から固定します。

時点状態
前回完了時profileごとに人格と状態を分離できます
今回開始時共通にしたい安全設定も各user configへ任せています
今回完了後managed keyを固定し、未管理のkeyはuser側へ残せます

すでに Managed Scope の優先順位を理解している場合は、「変更を拒否するところまで確認する」へ進めます。本番配置だけ確認したい場合は、「本番ではファイル所有者が境界になる」まで飛ばせます。

なぜprofileだけでは足りないのか

profile は、Hermes の状態を役割ごとに分ける機能です。それぞれが独立したconfig.yamlを持つため、設定値も別々に変えられます。

この自由度は、個人の作業には便利です。しかし、複数の profile や利用者で必ず守りたい値には向きません。誰かがsecurity.redact_secretsを無効にすると、その profile だけ tool output や log の保護方針が変わります。

すべての user config を同じ内容にしても、固定にはなりません。後からhermes config setを実行すれば変更できます。配布と強制は別の仕事です。

Managed Scope は、指定した key だけに上位の設定層を加えます。公式資料では、標準の配置先は/etc/hermesです。検証では root 権限を使わず、HERMES_MANAGED_DIRで一時ディレクトリへ向けます。

用語を揃える

用語この回での意味
Managed Scope管理者が選んだ設定をuser設定より優先する層です
managed config標準では/etc/hermes/config.yamlに置く管理設定です
user config各HERMES_HOMEにある利用者側のconfig.yamlです
leafmodel.defaultのような設定ツリー末端の値です
HERMES_HOMEprofileごとの設定や状態を置く場所です
HERMES_MANAGED_DIRmanaged directoryを標準位置から変える起動時の指定です
resolved valuemanaged、user、defaultを重ねた後にHermesが採用する値です

優先順位を図で確認する

今回の検証では、managed と user で同じ leaf へ違う値を書きます。一方、model.fallbackは user 側だけに置きます。

managed config
/tmp/hibanas-managed-scope-lab/managed/config.yaml
├── security.redact_secrets = true      採用
└── model.default = org/standard-model  採用
                 │
                 ▼ leaf単位で優先
user config
/tmp/hibanas-managed-scope-lab/user/config.yaml
├── security.redact_secrets = false     managedにより不採用
├── model.default = user/local-model    managedにより不採用
└── model.fallback = user/fallback-model 採用
                 │
                 ▼
resolved values
├── security.redact_secrets = true
├── model.default = org/standard-model
└── model.fallback = user/fallback-model

親のmodel全体が固定されるわけではありません。managed 側がmodel.defaultを指定しても、指定していないmodel.fallbackは user 側に残ります。これが leaf-level merge です。

検証用ディレクトリを作る

ここからの操作は、専用パス/tmp/hibanas-managed-scope-labだけを使います。既存の同名パスがある場合は実行せず、別の専用名へ置き換えます。

mkdir -p \
  /tmp/hibanas-managed-scope-lab/managed \
  /tmp/hibanas-managed-scope-lab/user

managed config を作ります。

printf '%s\n' \
  'security:' \
  '  redact_secrets: true' \
  'model:' \
  '  default: org/standard-model' \
  > /tmp/hibanas-managed-scope-lab/managed/config.yaml

次に user config を作ります。同じ 2 項目へ、意図的に違う値を入れます。

printf '%s\n' \
  'security:' \
  '  redact_secrets: false' \
  'model:' \
  '  default: user/local-model' \
  '  fallback: user/fallback-model' \
  > /tmp/hibanas-managed-scope-lab/user/config.yaml

この例の model 名は、優先順位を見分けるための文字列です。model へ接続せず、API key も使いません。

2つの設定場所を環境変数で指定する

現在の shell だけで、検証用の設定場所へ向けます。

export HERMES_HOME=/tmp/hibanas-managed-scope-lab/user
export HERMES_MANAGED_DIR=/tmp/hibanas-managed-scope-lab/managed

HERMES_HOMEは user config の場所です。HERMES_MANAGED_DIRは managed config の場所です。

この 2 行を shell の起動設定へ追加しません。検証を終えたら shell を閉じるか、値を解除します。

resolved valueを3件読む

hermes config getで、衝突する 2 件と、user 側だけにある 1 件を読みます。

hermes config get security.redact_secrets
hermes config get model.default
hermes config get model.fallback

期待する出力です。

true
org/standard-model
user/fallback-model

今回の実出力も同じでした。

true
org/standard-model
user/fallback-model

security.redact_secretsとmodel.defaultは managed 値です。model.fallbackは managed 側にないため、user 値が採用されました。

ここで確認できたのは、設定解決時の優先順位です。/tmpのファイルを一般利用者が編集できないことは確認していません。検証用ファイルは同じ利用者が作成しているためです。

変更を拒否するところまで確認する

次に、managed key を user 側から変更します。

hermes config set security.redact_secrets false

期待する動作は、変更を拒否して終了コード 1 を返すことです。今回の実出力は次の通りでした。

Cannot set 'security.redact_secrets': it is managed by your administrator (/tmp/hibanas-managed-scope-lab/managed/config.yaml) and cannot be changed. Contact your administrator to modify it.

終了コードも確認しました。

set_exit=1

拒否後に 3 件を読み直すと、値は変わっていませんでした。

true
org/standard-model
user/fallback-model

この結果から、managed key に対するhermes config setが拒否されたと分かります。未管理のmodel.fallbackまで固定されたわけではありません。

検証用ファイルを片付ける

値の確認が終わったら、環境変数を解除します。

unset HERMES_HOME
unset HERMES_MANAGED_DIR

検証専用パスであることを再確認してから削除します。

rm -rf -- /tmp/hibanas-managed-scope-lab

本番の~/.hermesや/etc/hermesを削除対象へ含めません。専用パスが一致しない場合は、削除せず止めます。

本番ではファイル所有者が境界になる

公式資料の標準配置は次の形です。

/etc/hermes/
├── config.yaml
└── .env

directory mode は0755、files は0644が例示されています。root が所有し、標準利用者は読めても書けない状態を作ります。Managed Scope の強制力は、この filesystem permission に依存します。

本番でHERMES_MANAGED_DIRを別の場所へ向ける場合、その値も管理者が service unit や container image で固定します。利用者が自由に変更できると、自分が管理する空の directory へ向けられます。これでは管理層を回避できます。

配置後は、次の read-only command で確認します。

hermes config
hermes doctor

hermes configは managed source と固定された key を表示します。hermes doctorは解決済みの managed directory と固定 key 数を報告します。設定ファイルを置いただけで運用開始と判断せず、Hermes を新しく起動して表示を読みます。

managed .envへ高機密secretを置かない

Managed Scope には.envもあります。ただし、v1 の公式例では file mode が0644です。同じ端末の利用者が読めるため、高機密の API key や token の保管場所には向きません。

managed .envは、共有する API base URL など、機密性の低い値へ限定します。高機密 secret は、Bitwarden Secrets Manager や 1Password などの secret source を使い、閲覧権限と rotation を別に管理します。

また、managed env は agent process を閉じ込めません。agent が起動後の subprocess で別の環境変数を設定することは防げません。Managed Scope は通常利用者向けの設定管理であり、OS sandbox ではありません。

固定するkeyを小さく保つ

組織で使うからといって、modelやsecurityの全項目を同じ値にする必要はありません。先に、変更されると困る leaf を決めます。

今回なら、固定対象は次の 2 件です。

  • security.redact_secrets
  • model.default

利用者へ残す対象はmodel.fallbackです。この分け方なら、安全策と標準 model は揃えつつ、障害時の代替先を profile ごとに選べます。

固定範囲を広げる前に、次の 3 点を確認します。

  1. その key を全 profile で同じにする理由があります
  2. 利用者が変更できないことによる障害対応手順があります
  3. hermes configとhermes doctorで適用を確認できます

設定を配る作業と、例外を扱う作業を同時に設計します。例外の連絡先がない固定設定は、復旧を遅らせます。

よくあるエラー

症状主な原因対応
user値がそのまま表示されますHERMES_MANAGED_DIRが別のdirectoryを指していますhermes doctorで解決済みパスを確認します
Cannot setになりません対象leafがmanaged configにありませんkeyの階層と綴りを確認します
model.fallbackまで固定されたと思いました親keyとleaf-level mergeを混同していますmanaged側が指定したleafを列挙します
本番では利用者がmanaged fileを編集できますownerまたはpermissionが誤っています管理者所有に直し、標準利用者で書けないことを確認します
別directoryへ向けると固定が消えます利用者がHERMES_MANAGED_DIRを変更できますservice unitやcontainer imageで管理者が固定します
managed .envのsecretを他利用者が読めますv1の例は0644です高機密値を置かず、secret managerへ移します
agentが別の環境変数を使えますManaged Scopeをsandboxとして扱っていますcontainer、OS権限、network制限を別に設計します
設定を置いたのに実行中セッションへ反映されません起動時に読む設定が残っています新しいHermes processで確認します
YAMLエラーでもHermesが起動しますmalformed managed fileは無視されますlogとhermes doctorを確認し、管理者が修正します

Managed Scopeが守る範囲を見誤らない

今回の実験で確認した事実は 3 つです。

  • managed で指定した leaf が user config より優先されました
  • managed にない leaf は user config の値が残りました
  • managed key へのhermes config setは終了コード 1 で拒否されました

一方、確認していないこともあります。/tmpの managed file は同じ利用者が作りました。そのため、root 所有の file を一般利用者が変更できないことは実証していません。

Managed Scope v1 は、filesystem permission を土台にした設定管理です。root で動く利用者や managed directory へ書ける利用者には、強制境界になりません。署名検証、MDM 配布、agent 自身を閉じ込める仕組みも v1 の範囲外です。

profile は役割ごとの状態を分けます。Managed Scope は選んだ設定を上から固定します。sandbox は process の権限を制限します。この 3 つを別の層として扱うと、人格の分離と組織ポリシーと実行権限を混同せずに済みます。

一次情報

資料確認した内容
Hermes Agent Managed Scope標準配置、優先順位、leaf-level merge、変更拒否、filesystem permission、v1の限界
Hermes Agent ConfigurationHERMES_HOME、hermes config get、hermes config set、設定の構造
Hermes Agent Profilesprofileごとの状態分離とManaged Scopeの役割差
NousResearch/hermes-agent公式source repository
2026年9月13日の実機検証Hermes Agent v0.21.0で3件のresolved valueとmanaged keyの変更拒否を確認

※2026 年 8 月 16 日から 9 月 12 日までの GSC では、hermes agent cronが 1 impression、hermes agent openclaw 違いが 1 impression、hermes agent 人格が 2 impressions でした。Managed Scope 固有の検索需要は確認できていないため、題材は AI エージェント運用の関心を起点に選んでいます。

この記事をシェア
hibana
この記事を書いた人
hibana

技術ブログを運営しています。日々の学びや発見を発信中。

関連記事