The construction plan proposed an AppRole from a survey written with no
OpenBao session. The phase-4 live survey found kubernetes/ auth already
enabled on this cluster with four external-secrets-* roles using it, and
the founder ruled for it on 2026-08-27.
The pod authenticates with its own projected ServiceAccount token, so the
lane has no role_id/secret_id to deliver, store, or rotate. Bound to
state-hub/state-hub and deliberately not to default, which would grant
the lane to every pod in the namespace.
Policy and role are built and capability-verified. Entry stays draft: the
KV path holds no token until paste_once_provision delivers one, and the
ServiceAccount does not exist yet (STATE-WP-0084-T02).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3377672@bnt-lap001
Assistant-Session: 15463ccf-238f-4e13-b163-93aa25c6d166
warden route find "state hub read private repository" returned nothing,
which is why the need had to be reasoned out from first principles
instead of looked up.
Pointer-only (warden_executes: false): ops-mason builds the AppRole,
policy, and KV path under MASON-WP-0003; the forge owner mints the
value; paste_once_provision delivers it. ops-warden routes and executes
nothing.
Graded high on breadth, not on write authority — the token is read-only
but organisation-wide, so a leak reads every private repository.
Approved at that breadth 2026-08-26 (ops-mason plan §6).
status: draft until MASON-WP-0003-T02 has created the structure and the
negative capability check passes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3377672@bnt-lap001
Assistant-Session: 15463ccf-238f-4e13-b163-93aa25c6d166
