Administrator Guide

This chapter is for tenant administrators and platform owners responsible for keeping Regurai running cleanly inside the firm.

Administrator roles

Roles are stored in public.user_roles and never on the profile/users table. See the security chapter for why.

User management

Today, users self-register via Supabase Auth on /auth (where enabled) or are invited by an owner / admin. After first sign-in they are forced through MFA enrolment.

To grant a user a role:

1. Open Access Governance v2.
2. Find the user (or invite them).
3. Issue an access_grant with the appropriate role and expiry.
4. The grant is recorded in access_grants and a corresponding entry appears in access_audit_log.

Role management

The role switcher in the top navigation is intentionally only visible on Access Governance pages (/app/access-governance and /app/access-governance-v2). Switching roles outside this surface is not possible — every role change opens a confirmation modal (RoleChangeConfirmModal) and writes an audit entry.

Access reviews

Periodic access reviews are run from Access Governance v2 → Reviews:

1. Start a review cycle (quarterly recommended).
2. The system lists every active grant in scope.
3. Reviewers attest or revoke each grant.
4. Attestations land in access_reviews; revocations also write to access_audit_log.
5. At cycle close, generate the evidence pack from /app/evidence.

Delegating approval authority during leave

Both AI-model approvals (ai_approvals) and access-request approvals (access_request_approvals) enforce strict self-approval at the database layer (Phase 5.4, Option A+ — chapter 14 §9). Concretely, the RLS WITH CHECK predicate (approver_id IS NULL OR approver_id = auth.uid()) ensures that the approver_id recorded on every row is either empty (pending state) or matches the currently signed-in user. An admin cannot record an approval "on behalf of" another named approver by writing that person's id into the field — the database rejects the row with new row violates row-level security policy.

When a named approver (e.g. the Head of Compliance) is on annual leave and an approval must be actioned during that period, do not attempt to record the approval under their identity. Instead, use the existing time-bounded role grant mechanism in Access Governance:

1. An owner/admin/risk_manager opens Access Governance → Grant access for the delegate (e.g. the Deputy Compliance Officer).
2. Issue a grant of the same role the absent approver holds (e.g. compliance_officer), with:
   • expires_at set to the end of the leave period (the grant is automatically revoked at that timestamp by the existing access_grants mechanism — covered by the Phase 2.1 isolation harness);
   • justification set to e.g. "Delegated approval authority — covering [absent approver name] [leave dates] — see ticket REF-1234";
   • regulatory_basis set to ISO 27001 A.5.18 (Access rights — provisioning, review, removal).
3. The delegate signs in and records approvals under their own identity — the audit trail then shows: (a) the delegate as approver_id on each approval row, (b) the temporary grant in access_grants (with its justification and expiry), and (c) the corresponding access_audit_log entries for grant issuance and auto-revocation.

The audit story is therefore complete and accurate: every approval is attributed to the person who actually clicked, the temporary authority is bounded and traceable, and no row in any approval table carries a falsified attribution. This is the supported delegation pattern; no separate "delegate-on-behalf-of" attribution field exists, and none is planned (chapter 14 §9 records Option B as a documented fallback should a customer specifically contract for in-row delegated attribution).

Why this matters for audit: the alternative — a free-text approver_id not bound to the caller — produces approval rows whose attribution can be forged by any role-bearing member of the tenant, which fails the segregation-of-duties (SoD) expectation under ISO/IEC 27001 A.5.3 and the human-oversight expectation under EU AI Act Art.14. The access_grants route satisfies both standards because the delegation event itself is the audit artefact, not an implicit claim inside the approval row.

Configuration

Monitoring and maintenance

GDPR / DSAR handling

Data Subject Access Requests are recorded in public.gdpr_requests. Workflow:

1. Subject submits request (via support channel).
2. DPO records the request in gdpr_requests with status received.
3. Investigation → export / deletion as required.
4. Response delivered; status moves to closed; evidence retained for the regulatory retention period.

Operational hygiene

• Rotate the Lovable Cloud service-role key on staff turnover.
• Re-run the security scan after every release; aim for zero critical findings.
• Review the Change Management chapter monthly; close out open ADRs and tech-debt entries.