Files
curriculum-project-hub/.scratch/saas-production-readiness/issues/42-decide-platform-admin-identity-audit.md
T

3.0 KiB

Decide the platform-administrator identity and audit boundary

Type: grilling Status: resolved

Question

Which identity issuer, bootstrap and recovery procedure, invite/allowlist model, session claims, role lifecycle, separation from Organization membership, and append-only audit contract will authenticate Platform Administrators for the initial service? The decision must keep /admin/platform private, make every Organization/connection/workload-control mutation attributable, and define a reviewable break-glass path without treating platform staff as customer members.

Answer

Platform Administrators authenticate only through a dedicated Platform-owned Feishu Application and a separate, server-side Platform Session. Platform Identity, standing grant, invitation, session, audit and emergency grant are independent of customer User, OrganizationMembership, Project permission and Project/Run audit. The initial control plane has one peer role only.

The first administrator is created by a versioned, idempotent, transactional database bootstrap procedure that runs only when no standing administrator is active and atomically records the Platform Audit Entry. Later administrators receive short-lived, single-use invitations bound to a specific platform Feishu account. The last active standing administrator cannot be revoked; revocation immediately invalidates that identity's sessions and invitations.

Every platform request reloads the revocable session and current standing or unexpired emergency grant. Administrator, connection/credential, Organization-lifecycle, workload-brake and emergency-grant actions require recent Feishu OAuth step-up.

Every successful platform mutation commits with a separate append-only Platform Audit Entry or fails. Organization Administrators receive a redacted projection of platform actions affecting their own Organization. No standing break-glass account exists: offline recovery requires controlled host access, an off-host recovery key, an incident and reason, and issues only an expiring Emergency Platform Grant.

The complete accepted decision and implementation divergences are in ADR-0023. The pinned semantic invariants are in Spec.System.PlatformAdministration, and the canonical terms are in CONTEXT.md.

Exact numeric session/invitation/step-up limits and browser mechanics remain with Design the production browser and session boundary. Customer Project/Run audit retention remains with Reconcile the audit and run-history contract, without reopening Platform Audit's separate fail-closed boundary. Implementation is owned by Build the private platform-administrator control plane, and recovery rehearsal by Write and drill production incident recovery runbooks.