The platform admin console is the operator surface reserved for platform super-admins — the people responsible for the correctness, security, and health of the entire multi-tenant estate. It covers cross-tenant health rollups, dead-letter queue triage, governance-mode enforcement, tenant signing-key lifecycle, two-person GDPR erasure, audit backfills, retention purges, and budget reconciliation. None of these operations are available to individual tenant administrators; they live on a separate access plane entirely. For the tenant-facing governance controls that sit one level below this surface, see plan gating and feature flags.
What the platform admin console does
The console is not a general-purpose admin dashboard in the sense of "manage users and settings." It is a focused operator surface for the handful of people responsible for the correctness and security of the entire multi-tenant estate — covering tasks that no individual tenant can or should perform.
Who can access it and how access is enforced
Access is restricted to a designated group of platform super-admins whose identity is verified through a dedicated access control layer that is entirely separate from the normal RBAC and role-permission system governing individual organizations. A user who is an org admin within their own tenant has no elevation here; the admin console is an orthogonal plane of access that cannot be reached by privilege escalation from the tenant side.
Every route in the console requires authentication and passes through the super-admin access check. High-risk write operations carry additional rate limiting to prevent bulk automation from a single session.
Because this surface is intentionally cross-tenant — the tenant rollup, for example, is one of the few places in the system designed to read across organization boundaries — access control is enforced at every entry point. Any route that can read across tenant boundaries is protected by the same access check, with no opt-out path.
Tenant and organization management
The console provides a global view of all organizations and users on the platform. An operator can list tenants, inspect their current governance mode, check per-org usage and health data, and identify organizations in anomalous states without needing to impersonate a tenant user or access their data directly.
The tenant rollup surface aggregates usage and health signals across organizations so platform operators can spot capacity outliers, stalled pipelines, or billing anomalies before tenants raise support tickets. This kind of cross-tenant observability is not available inside any individual org; it exists only at the operator layer. For the tenant-facing analytics that sit beneath this view, see advanced analytics for AI operations.
Dead-letter queue inspection and replay
Distributed systems produce failed jobs. Agent task failures, workflow-continuation jobs that could not proceed, and Stripe webhook events that could not be processed all land in dead-letter queues rather than disappearing silently. The admin console gives operators a consistent interface to inspect what is in each queue, replay individual jobs, dismiss jobs that should not be retried, and bulk-clear queues when a systemic issue has been resolved.
The DLQ surface covers the distinct failure categories the platform produces: agent task failures, workflow-continuation failures, and payment webhook failures. This matters because the failure modes and replay semantics differ: a failed agent task might be safe to replay immediately, while a failed payment webhook might need manual investigation before replay. Having a unified but category-aware triage surface means operators can handle each class correctly. For the billing reliability patterns that generate these webhook events, see Reliable Billing: Stripe Webhooks, Reconciliation, and Dunning.
Replaying a job is not a no-op operation, and the console validates replay requests before accepting them. The goal is to prevent accidental bulk-replays of unrelated queues.
Governance modes and tenant signing keys
Each organization on the platform operates under a governance mode that controls what kinds of automated actions are permitted, what requires human approval, and how strictly policy is enforced. Platform operators can view the governance mode triple for any organization and, when necessary, flip it.
Mode changes are high-stakes: loosening governance on a regulated tenant or tightening it unexpectedly can have immediate operational consequences. For this reason, governance-mode changes go through a two-person initiate-and-confirm flow. One super-admin initiates the change and creates an approval ticket; a second super-admin (in a distinct session) confirms it. The approval is single-use and cryptographically bound, so replay and reuse are rejected.
The same two-person pattern applies to tenant signing-key lifecycle operations. Signing keys underpin cryptographic audit log integrity and GDPR-related data subject operations. Rotating a key is routine maintenance; revoking one is a break-glass action that affects every log entry signed with that key going forward. Both operations require a distinct second approver before they execute. For a deeper look at how signing keys protect audit log integrity, see Audit Trails That Hold Up: Cryptographic Integrity.
GDPR Article 17 erasure
The admin console implements data subject erasure in compliance with GDPR Article 17. This is a dedicated erasure cascade that removes personal data across audit events, auth records, and any associated personal information, rather than a soft delete that leaves data in place. For the broader compliance context, see GDPR erasure and EU AI Act readiness.
Erasure can run in two modes depending on platform configuration. A one-shot mode executes immediately when erasure has been explicitly enabled at the platform level; if it has not been activated, the operation fails closed rather than silently proceeding. An initiate-and-confirm mode requires a second approver, the same two-person pattern used for governance and key operations.
This design reflects the seriousness of an irreversible erasure: the subject's data cannot be recovered after the cascade runs. The two-person requirement and the fail-closed activation gate are both safety mechanisms against accidental or unauthorized execution.
Audit backfills, retention, and budget reconciliation
Over the life of a platform, the cryptographic structure of audit logs sometimes needs to be brought up to date: new records may need signatures applied retroactively, or Merkle root anchors may need to be computed for historical batches. The admin console exposes backfill triggers and progress endpoints for both audit-signature and Merkle-root operations. Operators can initiate a backfill and poll its progress without manually querying the database.
Retention purges remove data that has aged past its configured retention window and seal the audit trail at the point of purge. A seal is a cryptographic marker that proves no data was deleted outside the normal retention process; it makes the purge defensible to an auditor. For the underlying cryptographic guarantees, see tamper-evident audit logs with cryptographic proofs.
Log-level overrides let operators temporarily raise the verbosity of platform logging without a full redeploy, which is useful when diagnosing a production issue in a targeted way. This is a scoped debugging tool intended for short-lived use during active investigation.
When billing events and usage records drift out of sync — which can happen across restarts, network interruptions, or edge cases in metered billing — the admin console provides a budget reconciliation trigger. Running reconciliation realigns the recorded spend against actual usage data, corrects any over- or under-counted balances, and can be configured to auto-heal minor discrepancies without manual intervention. The goal is to keep billing state consistent so that per-org budget enforcement remains accurate and invoices reflect actual consumption. For how per-connection attribution feeds into that billing accuracy, see tracking per-connection AI usage and cost.
Common questions
Who qualifies as a super-admin and how are they designated? Super-admins are designated through a platform-level configuration process that is separate from the normal user management UI. This keeps super-admin designation outside the tenant data plane and under infrastructure-level control, so it cannot be modified through the application itself.
What happens if a two-person approval is not confirmed? Approval tickets are single-use and time-limited. If the second approver does not confirm within the validity window, the ticket expires and the operation cannot proceed. The initiating operator must start a new initiate request if the operation is still needed. This prevents stale approvals from being used later in changed circumstances.
Can platform operators read tenant data through the admin console? The admin console exposes cross-tenant observability data such as usage rollups and health signals, but it is not designed to expose the content of tenant records (agent configurations, workflow data, customer information). The cross-org reads that do exist are scoped to operational metadata and are governed by the same access control layer that protects every other admin console route. Praesidia is designed so that the operator and tenant planes remain separate: operators see what they need to run the platform, not what individual tenants are doing inside their own organizations.
How does the two-person approval protect against insider threats? The initiate-and-confirm pattern requires two distinct authenticated sessions to complete a high-stakes operation. Because the approval token is single-use and cryptographically bound to the specific operation, an insider who initiates a governance-mode change or key rotation cannot also confirm it — and cannot reuse an expired approval from a previous session. The full audit trail records both the initiating and confirming identities, timestamps, and the operation approved, giving security reviewers a complete chain of custody for every sensitive administrative action.
The platform admin console is the backstage of a multi-tenant AI control plane. Most users and even most org admins never see it; its entire purpose is to give platform operators the tools they need to keep the system correct, auditable, and recoverable when something goes wrong. For a closer look at how governance and compliance controls are structured across the platform, see audit trails that hold up: cryptographic integrity and how to audit AI agent activity.