railiance-platform/openbao/policies/workload-kv-read-approval-engine-operator-client.hcl

path "platform/data/workloads/approval-engine/operator-client" {
  capabilities = ["read"]
}

path "platform/metadata/workloads/approval-engine/operator-client" {
  capabilities = ["read"]
}
Prepare the two approval client-side reader admissions RPF-WP-0035-T06. Adds CCR-2026-0019 (secrets-engine) and CCR-2026-0020 (approval-engine-operator) with their exact-path read policies, reusing the existing version-1 custody from the verifier activation. No reseed, rotation, shared reader or verifier Secret reuse; both requests are in_flight and nothing is applied. The two shapes were decided by read-only survey rather than assumed. secrets-engine consumes its client secret through an operator-run CLI reading a protected file, and its namespace holds no workload, so reader 1 is an attended operator-workstation OIDC lane rather than an ESO lane; its one missing input is the operator group claim, which NetKingdom and KeyCape own. approval-engine is not deployed and no owner source names who presents the operator client, so reader 2 records the undetermined actor instead of guessing one for the widest approval scope in the pair. Both declare openbao.auth missing rather than carrying a placeholder binding. T06 moves to wait on those two owner inputs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WLUjpv3ssxNRAEPPgLFnEB Assistant: claude-code Assistant-Model: opus Assistant-Process: 1275505@bnt-lap001 Assistant-Session: 97265baa-f08f-4032-b290-a1e2965a69c5 2026-09-09 14:41:01 +02:00			`path "platform/data/workloads/approval-engine/operator-client" {`
			`capabilities = ["read"]`
			`}`

			`path "platform/metadata/workloads/approval-engine/operator-client" {`
			`capabilities = ["read"]`
			`}`