ガバナンスと承認（human-in-the-loop）
このページは、少なくとも1つのソースを接続し、これから estate を ガバナンス する必要のある 運用者向けです: 誰が・何が行動できるかを決め、プラットフォームが提示するものをレビューし、 それに対処する。ガバナンスは モジュール VI（アイデンティティ、権限、ガバナンス） に存在し、 API の他の部分と同じ認可コアの上に乗っており、完全に監査されます。
あなたがその中でガバナンスする認可モデル
Section titled “あなたがその中でガバナンスする認可モデル”あらゆるガバナンス決定は、control plane の他の部分を保護するのと同じ認可コアによって下されます。 何かを変更する前に、その3つの性質を理解してください。
RBAC は deny-by-default
Section titled “RBAC は deny-by-default”認可は RBAC が最初に 走ります。あるテナントにメンバーシップを持たないプリンシパルは 拒否 されます ── 暗黙の付与はありません。権限はテナントにスコープされ、ハンドラは リクエストが解決した 単一のテナントに対してのみ 作用し、それが再導出するテナントには 決して作用しません。これにより confused-deputy と IDOR のクラスを構造的に封じます。
組み込みロールは能力が増していくはしごを成します:
| ロール | 何ができるか |
|---|---|
viewer | 運用データと監査証跡を読む |
editor | 上記に加え、運用データの書き込み |
admin | 上記に加え、テナント IAM ── ユーザー、メンバーシップ、トークン、設定 |
owner | テナント内のすべての権限 |
モジュールは自身の名前空間付き権限（<namespace>:<resource>:<verb>）を宣言し、ロールには
それらの権限が 動詞層ごとに 付与されます（viewer は read、editor は write、admin と owner は
admin にマッピング）。したがって新しいモジュールは、エンジンのリリースなしにガバナンス画面を
導入します。
ポリシーシーム（ABAC/PDP）は restrict のみ
Section titled “ポリシーシーム（ABAC/PDP）は restrict のみ”RBAC の上に、運用者は属性ベースのルールのために外部の policy decision point（PDP） を配線できます。 エンジンは単一の環境変数で選びます:
# Choose one. Cedar is the embedded, pure-Go primary; OPA is an over-HTTP adapter.OLIVARES_PDP_ENGINE=cedar # or: opa | none両エンジンは1つのシームの背後に位置し、そのシームには、それについてどう推論すべきかを支配する 1つの不変条件があります:
2つのアダプタはその不変条件を異なる方法で保ちます。あなたはそれに応じてポリシーを記述します:
- Cedar（組み込み、主要、pure-Go）。
forbidルールを書きます。マッチするルールは制限であり、 空のルールセットは RBAC の決定がそのまま残ることを意味します。Cedar のpermitが決定を 広げることは決してありません。 - OPA（HTTP 経由）。 あなたの Rego は permit-by-default でなければなりません
（
default allow := trueに、拒否のためのallow := false句を添える）。trueの結果は 制限なしを意味します。false、結果の欠如、またはあらゆるトランスポートや非 2xx エラーは fail closed します ── リクエストは拒否されます。
無効な PDP 設定は外部 PDP のみを無効化 し、その事実をログに記録します ── ネイティブ ABAC と RBAC はガバナンスを続けます。設定ミスのポリシーエンジンが、リクエストをガバナンスされないまま 放置することも、control plane をダウンさせることも決してありません。PDP が適用するあらゆる制限は 監査されます。
画面があなたに対処を促すもの
Section titled “画面があなたに対処を促すもの”human-in-the-loop ガバナンスは、プラットフォームが観測し提示するものによって駆動されます。 2つのストリームが、何が判断に値するかを運用者に伝えます:
| ストリーム | モジュール | 何を提示するか |
|---|---|---|
| least-privilege drift | III（access map） | permitted-vs-observed の差分 ── 誰も意図しなかった形で使われた付与済みケイパビリティ、または到達可能だが一度も行使されていない経路 |
| 検出結果（findings） | IX（セキュリティ、guardrails、フォレンジクス） | guardrail と red-team の検出結果、加えてプラットフォームがルーティングする通知ストリーム |
モジュール III、すなわち access map は read-first です ── ログ、OpenTelemetry、そして
（非協調的なカーネルバックストップとして）eBPF を通じて観測し、エージェントのデータ経路には
決して入りません。したがってコレクタの障害が本番を壊すことはありません。それはまた
minimal-data です: 関係 agent → resource (read/write) を格納するだけで、ペイロード、シークレット、
PII は決して格納しません。それが運ぶシグナルは、自身の確信度（attributed か approximate か）と
自身の到達範囲について正直です。
あるシグナルのクラスは、明示的なガバナンス判断を必要とします。MCP のツールアノテーション
（readOnlyHint / destructiveHint）は有用な read/write のヒントですが、MCP 仕様によって
untrusted です ── クライアントはそれらを untrusted として扱わなければなりません。プラットフォームは
それらを信頼できるシグナルに対して 裏付け（corroborate） し、決して単独では信頼しません。
アノテーションのみに依拠する drift 項目に対して行動するとき、あなたもそうすべきです。
human-in-the-loop の運用形態
Section titled “human-in-the-loop の運用形態”意図されたガバナンスループは次のとおりです: 画面が提示する（モジュール III からの drift、 モジュール IX からの検出結果）→ 権限を持つ運用者が決定する → その決定が監査台帳に記録される。
このループの3つの部分すべてが今日稼働しています。画面は実在します ── モジュール III が permitted-vs-observed の差分を生成し、モジュール IX が検出結果を生成します。承認エンジンは 実在します ── ガバナンス対象の承認リクエストがガバナンスモジュールに対して開かれ （deny-closed、プランハッシュ紐付け、時間制限付き）、権限を持つ運用者が決定エンドポイント経由で 承認または拒否し、職務分掌、重複決定者、有効期限がサーバー側で強制 されるため、リクエスト者が 自身のリクエストを決定することは決してできず、期限切れのものが拘束することも決してできません。 そして 記録は実在し、強固です ── 下記の保証を参照してください。なお設計段階 なのは、 作り込まれた 運用者レビューコンソール です ── リッチな承認キュー UI。エンドポイントとエンジンは 出荷済みで、洗練されたレビュー画面がモジュール VI の今後の道筋です。
このループを信頼に足るものにする依存関係は、エージェントごとのアイデンティティ です。 プラットフォームの監査は、活動を認証情報やロールに帰属させるのであって、本質的にエージェントに 帰属させるわけではありません。コネクションプールを持つ共有サービスアカウントは帰属を崩壊させます。 したがってうまくガバナンスするとは、エージェントごとにアイデンティティを発行し強制する ことを 意味します ── 観測（モジュール III）からガバナンス（モジュール VI）への架け橋です。この アイデンティティ側は、不透明で失効可能なファーストパーティ認証情報と、非人間アイデンティティの 名簿を中心に構築されています。製品中の 唯一の認証情報発行プリミティブ はオプトインで、 attested で、監査され、発行されたトークンを決して永続化しません。アイデンティティ、権限、 ガバナンスが estate 全体でどう合成されるかについては モジュールカタログ を参照してください。
記録をそのまま取り出す
Section titled “記録をそのまま取り出す”外部の不変なコピー ── ネイティブテレメトリが提供しない、エンタープライズ監査人が求めるもの ── のために、台帳は 認証付きのプル方式エクスポート として公開されます:
# Pull the signed, hash-chained ledger for offline re-verification.# Requires a token whose role can read the audit trail (viewer and up).curl -fsS "https://localhost:8443/v1/audit/export?format=cef" \ -H "Authorization: Bearer $OLVK_TOKEN" \ -H "X-Olivares-Tenant: $TENANT" >> /var/log/olivares/audit.cefサポートされる format 値は cef、leef、syslog、otlp、otlp_envelope、otlp_log_record、ocsf です。
otlp は完全で POST 可能なエクスポートリクエストを出力し、otlp_envelope はその厳密なエイリアス、
otlp_log_record は 1 行 1 LogRecord の素の射影です。すべてのレコードは
チェーン整合性フィールドを保持するため、SIEM や WORM ストアが チェーンをオフラインで再検証
できます。分離された署名は、DB のみの侵害（インジェクション、盗まれたバックアップやレプリカ、
RLS をバイパスするロール）とチェックポイント削除に対して防御します。オフボックスのコピー が、
完全に侵害されたホストに対する制御です。完全なファイル追従パイプラインについては
Splunk への監査転送 を参照してください。
これらの決定が対処する least-privilege drift は、access map の permitted-vs-observed の結果です。 zero-to-graph チュートリアル は、デモ estate 上でそこに具体的に 到達する手順を案内します。access-map モジュールの画面は、他のすべてと同じ deny-by-default RBAC、 テナントスコープ、読み取りごとの監査の対象であり、だからこそその読み取りが editor 以上のアクションなのです。