管理者による適用範囲

どこに置かれるか
ディレクトリの場所を変える
優先順位
何が管理下にあるのかを見る
管理下の適用範囲を用意する（管理者向け）
セキュリティ上の考え方と制限（v1）

管理者による適用範囲を使うと、管理者が設定と秘密情報の基準となる内容を配り、一般の（root ではない）利用者がそれを上書きできないようにできます。想定しているのは、組織や複数の端末をまとめて運用する場面で、たとえばモデルのプロバイダ、共有の API のベース URL、security.redact_secrets: true などを、その端末を使うすべての利用者に対して固定したいときです。

管理下の適用範囲が存在する場合、そこで指定された値は利用者の ~/.hermes/config.yaml、~/.hermes/.env、さらにはシェルの環境変数よりも優先されます。ただしそれは固定されたキーに限った話です。それ以外はすべて、これまでどおり利用者が自由に決められます。

どこに置かれるか

管理下の適用範囲は、システム全体のディレクトリ（既定では /etc/hermes）から読み込まれます。

/etc/hermes/
├── config.yaml     # managed config layer (wins over ~/.hermes/config.yaml)
└── .env            # managed env layer (wins over ~/.hermes/.env + shell)

このディレクトリとファイルの所有者は root で（ディレクトリのモードは 0755、ファイルは 0644）、誰でも読めますが、書き込めるのは管理者だけです。このファイルの権限そのものが、強制力の正体です。 一般の利用者は管理下のファイルを読めますが、編集はできません。

どちらのファイルも必須ではありません。管理用のディレクトリやファイルが無い場合は、単に「管理下の適用範囲は無い」という意味になり、この機能が無いときとまったく同じように設定が解決されます。

ディレクトリの場所を変える

場所は環境変数 HERMES_MANAGED_DIR で変更できます（コンテナや、/etc 以外に置く構成のためです）。これは HERMES_HOME と同じく、配置や初期設定のための調整項目で、管理下のファイルを所有するのと同じ管理者が設定します。Hermes がこれをどこかの .env に書き残すことはありません。

# Point managed scope at a custom directory (set by IT / the deployment, not the user)
export HERMES_MANAGED_DIR=/opt/org/hermes-policy

優先順位

管理下の層が指定しているキーについては、順位は次のとおりです（上ほど優先されます）。

段	config.yaml	.env
1	`/etc/hermes/config.yaml`（管理下）	`/etc/hermes/.env`（管理下）
2	`~/.hermes/config.yaml`（利用者）	`~/.hermes/.env`（利用者）
3	組み込みの既定値	もともとのシェルの環境変数

統合は末端の値ごとに行われます。model.default を固定しても、model.* の残りが固定されるわけではありません。管理下の config.yaml が次の内容だとします。

model:
  default: org/standard-model

この場合、すべての利用者に対して model.default が強制されますが、model.fallback（およびその他のすべてのキー）は利用者の管理下に残ります。

何が管理下にあるのかを見る

hermes config        # shows a header naming the managed source + the pinned keys
hermes doctor        # reports the resolved managed dir + pinned key counts

管理下の値を変更しようとすると、Hermes は拒否したうえで、その出どころを示します。

$ hermes config set model.default my/model
Cannot set 'model.default': it is managed by your administrator
(/etc/hermes/config.yaml) and cannot be changed.

管理下の秘密情報についても同じです。管理下の .env が固定している環境変数のキーには、hermes config set もセットアップも、利用者側の値を書き込みません。

管理下の適用範囲を用意する（管理者向け）

sudo mkdir -p /etc/hermes

# Pin some config values for every user on this machine
sudo tee /etc/hermes/config.yaml >/dev/null <<'YAML'
model:
  provider: nous
security:
  redact_secrets: true
YAML

# Optionally pin a shared, non-sensitive env value
sudo tee /etc/hermes/.env >/dev/null <<'ENV'
OPENAI_API_BASE=https://inference.example.com/v1
ENV

sudo chmod 0755 /etc/hermes
sudo chmod 0644 /etc/hermes/config.yaml /etc/hermes/.env

変更は、次に Hermes を起動したときに反映されます（管理下のファイルの書式が壊れている場合は、はっきりとログに記録されたうえで無視されます。起動を止めることはありませんが、方針が適用されているかどうかを管理者が hermes doctor で確認すべきです）。

セキュリティ上の考え方と制限（v1）

強制する手段はファイルの権限だけです。 利用者が管理用ディレクトリへ書き込める場合（あるいは

Hermes を root で動かしている場合）、管理下の適用範囲は助言にとどまります。

管理下の .env は誰でも読める状態です（0644）。したがって、そこに置いた秘密情報は

同じ端末の利用者なら誰でも読めます。機微性の高い秘密情報ではなく、共有できて機微でない値（組織の API のベース URL、機能の既定値など）に使ってください。

**エージェント自身のツールは、管理下の*環境変数*の値から完全には遮断されていません。** 管理下の

環境変数は起動時に適用されますが、エージェントが自分のサブプロセスのシェルの中で別の値を設定することは妨げられません。v1 は、通常の利用者に対する運用上の線引きであって、抜け出せないサンドボックスではありません。

次の項目は、v1 では意図的に対象外としていて、今後対応する可能性があります。

エージェント自身にも抜け出せない、厳密な境界。
macOS と Windows のネイティブな管理用の場所（v1 は Linux / POSIX が先です）。
方針を重ねるための、追加ファイルを置くディレクトリ（managed.d/）。
署名や完全性の検証が付いた管理下のファイル。
リモートや端末管理（MDM）による配布。
管理下の秘密情報に対する、より厳しい（グループ単位の）権限。