📖About

Close the missing elements of the Carolverse identity-access framework identified in the 2026-06-22 review. Build all five pillars: (1) Just-in-time privileged access — time-boxed, approval-based, auto-expiring grants in the RBAC schema with gate enforcement, replacing standing grants for sensitive actions; (2) Privileged credential vaulting & rotation for agent OS-user secrets via Radagast admin executor; (3) Privileged session recording — capture the actual commands/actions inside a privileged session, not just metadata; (4) Complete least-privilege & RBAC hardening — seed per-pipeline-phase roles, enforce precise per-artifact scope at the session gate, nightly RBAC reseed to prevent drift, remove the dead legacy access table, add the access databases to the backup set; (5) Resilient admin path — Radagast relay-independent verify to break the relay circular dependency. Deliverables also include a Security Runbook and making BOTH access-management apps (agents + users) comprehensively describe the framework (principles, IAM/PAM/JIT model, roles/permissions, JIT request flow, audit/session-recording, runbook link).

⚖️Decisions

• Elrond's bypass methodology checklist (a reminder, not a gate -- you've got this): 0. File it requested_mode='bypass' (planner-vs-bypass is a deliberate choice). bypass_start REFUSES a non-bypass initiative (CAROL-INI-1846), and the dispatcher only skips the bypass lane when the mode says bypass -- a 'planner' mistag lets Merlin's pipeline grab the placeholder step and block your finished work. 1. Filed as planned status -- let the bypass claim/activate it; never file active. 2. Open the bypass (bypass_start) with your droid id + the remediation answer (remediates_initiative_id=NNN, or remediates_nothing=True). 3. Work the blocks for your work-type: template -> design -> code -> test -> review. Do the real work; record decisions on the initiative as you make them. 4. Reality is recorded for you at close -- code (files changed), each decision, and the twin-review verdict become real activities tied to this initiative and show in the Activity Tracker like a planner run (CAROL-INI-1840). No dummy rows. 5. Keep the initiative status moving; it parks in 'reviewing' and is tagged uat-pending for you at close (CAROL-INI-1836), so the stuck-watchdog leaves it alone until UAT. 6. Close runs the gates (design/architecture compliance + caller-audit). If a gate flags something pre-existing or unrelated to your change, waive it with a clear written rationale -- audit, don't skip. 7. Bypass skips the planner's auto-orchestration, NOT the standards. Same template checklist, same review, same observability as a planner run. (elrond)
• [status-router] planned -> active | event=bypass_active | bypass transition (or-bx-01)
• JIT layer rides the existing RBAC schema, not a parallel one. Add ac_jit_grants (expiring, status-tracked) + ac_jit_requests (approval flow) to the registry; access_control.can()/has_perm() additionally honour active, unexpired JIT grants. Standing ownership grants stay; JIT only adds temporary rights for actions an agent does not own. (orion)
• Credential vaulting stores metadata + a reference, never plaintext secrets, in the registry; the actual rotation is a NEW allowlisted Radagast op (rotate_agent_credential) so the privileged write stays inside Radagast per request-vs-perform. (orion)
• Privileged session recording = a child table agent_session_events; Radagast logs every command it runs into the open session, and any privileged caller can append action events. Metadata-only logging is replaced by action-level capture. (orion)
• Resilient admin path: the status router writes a tiny relay-independent status snapshot Radagast can read directly; Radagast verify falls back to the snapshot when the relay is down, breaking the circular dependency without weakening verification. (orion)
• INI-1767 compliance gate refused close — CAROL-INI-1767 compliance gate refused close: [agent-access] design: dark-theme baseline palette not used — design #178 §1; [agent-access] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [agent-access] design: no empty state — handle the no-data case (design #178 §3); [auth] design: dark-theme baseline palette not used — design #178 §1; [auth] design: no loading state — a data-driven app must show a loading indicator (design #178 §3); [auth] design: no empty state — handle the no-data case (design #178 §3). Bring the app to standard (Design System #178 / architecture #146/#173/#156), or add a decision row prefixed 'Compliance waived by' to override. (shared.bypass.bypass_end[INI-1767])
• [status-router] active -> blocked | event=bypass_blocked | bypass transition (or-bx-01)
• Bypass session failed — initiative blocked (exec 306) — bypass_end called with success=False for exec 306, run 579 (shared.bypass.bypass_end)
• Compliance waived by Orion (or-bx-01): the design-gate flags for [agent-access] and [auth] (dark-theme palette, loading state, empty state) are FALSE POSITIVES. Both apps render via the SHARED external renderer at /static/dl/access-mgmt.js, which the gate per-app-directory static scan cannot follow. That renderer DOES implement the dark baseline palette, a Loading… indicator, and explicit empty states (No records yet. / Nothing logged yet. / No active JIT grants). Standard #178 is met; the gate simply cannot see the external JS. Verified by reading the deployed renderer this session. (orion)
• [status-router] blocked -> active | event=bypass_reopen | reopen after design-gate false-positive; waiver recorded (or-bx-01)
• [status-router] active -> reviewing | event=bypass_close | CAROL-INI-1911 complete; all pillars built + verified; gate waiver recorded (or-bx-01)
• [status-router] reviewing -> closed | event=operator_signoff | Auto-accepted (CAROL-INI-1859): Orion-initiated, >2 days in reviewing with no objection. (el-srac-01)

✅Success criteria

• JIT: privileged grants can be time-boxed with an expiry; expired grants are denied by the session gate; an approval-then-temporary-grant flow exists. (must_have)
• Credential vaulting: agent OS-user secrets are stored in a vault and a rotation path exists, run via Radagast admin executor. (must_have)
• Session recording: privileged sessions capture the actual actions/commands taken, not just metadata. (must_have)
• Least-privilege hardening: per-pipeline-phase roles seeded; gate enforces precise per-artifact scope; nightly RBAC reseed registered; dead legacy access table removed; access DBs in backup set. (must_have)
• Resilient admin path: Radagast can verify an initiative without the relay (no circular dependency on a relay outage). (must_have)
• Security Runbook exists and both access-management apps (agents + users) comprehensively describe the framework, principles, IAM/PAM/JIT model and link the runbook. (must_have)