Use when designing the internal admin / back-office console of a multi-tenant SaaS — tenant impersonation (audited, time-boxed), tenant lifecycle controls (suspend/restore/archive/hard-delete), billing operations (refunds, credits, plan overrides), feature-flag overrides per tenant, bulk actions (mass invite, plan migration, region migration), and the audit-log spine that backs all of it. Distinct from the customer-facing super-admin panel in `multi-tenant-saas-architecture`.
Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.
Quelldateien prüfen
Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Ein direkter Befehl überspringt den Prüf-Prompt. Prüfen Sie die Quelle, bevor Sie ihn ausführen.
Use when designing the internal admin / back-office console of a multi-tenant SaaS — tenant impersonation (audited, time-boxed), tenant lifecycle controls (suspend/restore/archive/hard-delete), billing operations (refunds, credits, plan overrides), feature-flag overrides per tenant, bulk actions (mass invite, plan migration, region migration), and the audit-log spine that backs all of it. Distinct from the customer-facing super-admin panel in `multi-tenant-saas-architecture`.
AI incident console: when the platform ships AI features, the back-office must include an AI incident console with: feature kill-switch, agent task kill-switch, model-pin, prompt-pin, retrieval index-pin, tool-pin / tool-disable, gateway routing pin, per-tenant feature pause, quota cap, and the evidence-bundle exporter. Each control writes to ai_incident_mitigation_log with (actor, ts, primitive, scope, reason, ticket_id). The reason field is mandatory. See ai-incident-response-runbook §3 for the primitive contract and ai-incident-recovery-and-rollback/references/rollback-patterns.md for the un-pin path.
§1 Why the Back-Office Console Matters
Trio book: between $1M and $10M ARR, the manual-SSH-and-Stripe-Dashboard model collapses. Staff make mistakes; nothing is audited; customer trust erodes. The back-office console is how operations becomes a discipline rather than a hero activity.
For SOC2 and similar: every privileged access must be logged, justified, time-boxed, and traceable to a human. A console enforces this; a shell does not.
Bulk operations are blast-radius nightmares. Pattern:
1. Staff selects cohort (SQL query, CSV upload, saved segment).
2. Dry-run runs the operation in a transaction-marked-readonly; produces a report (what would change, on how many tenants).
3. Staff reviews report; submits production-run with a second-approver MFA confirmation.
4. Production-run executes in batched chunks (e.g., 50 tenants per batch); pauseable; with progress reporting.
5. Per-tenant audit log entries.
6. Rollback snapshot — pre-state captured so undo is possible within N hours.
7. Slack broadcast at start, midpoint, completion.
Examples of safe bulk ops:
Plan migration: "Move all legacy_pro to pro_v2 with same price-locked Stripe Subscription."
Region migration: "Move tenants in EU pod from eu-west-1 to eu-central-1."
Feature-flag rollout: "Enable new_dashboard for 10% of pro tenants."
Examples of dangerous bulk ops that need extra scrutiny:
Co-sign mechanism: second staff user approves in the back-office UI within a time window; otherwise the action expires.
§8 Anti-Patterns
admin.html page on the same app behind a JWT claim — same auth surface, same code path, same risk; back-office should be a separate auth domain, separate deploy, separate network segment.
Impersonation invisible to tenant — discovered later; trust catastrophe.
No co-sign on high-risk actions — one bad day, one compromised laptop, platform compromised.
Justifications optional — left blank by everyone; audit log is useless.
No internal Slack mirror of audit events — team has no informal accountability layer.
Bulk ops without dry-run — one bad SELECT kills 500 tenants.
Same role for support and billing — supports cancellation of others' accounts; supports cross-team mistakes.
§9 Build Stack Suggestions
Depending on the SaaS stack:
Retool / Internal / Tooljet / Forest Admin / Appsmith — fast to build, audit-friendly, role-based; great for $1M-$10M ARR stage.
Custom React/Vue app talking to control-plane APIs — once team scales, custom gives the best UX and integration.
Django admin + customization — works for Django stacks; needs extension for audit/impersonation/co-sign.
Laravel Nova / Filament — same for Laravel/PHP stacks.
Regardless of UI tool, the API surface is the contract — UI is just one client; CLI / Slack-bot / scripts are equally valid clients of the back-office API.
§10 Agent Ops Console
When agentic features ship, the back-office gains a new surface: the Agent Ops Console. Without it, operating live agents in a multi-tenant SaaS is impossible — a runaway task or a tenant-specific safety incident has no fast remediation.
Required views
View
Purpose
Live agent tasks (per-tenant + global)
All in-flight tasks: tenant, feature, state, age, cost so far, last activity
Pending approvals (per-tenant + global)
All awaiting-approval tasks; staff can override on behalf of tenant admin
Task viewer (drill-down)
Per-task trace + step list + tool I/O (redacted) + replay link — see ai-agent-observability-and-replay
Transitions to AWAITING_APPROVAL (paused-by-staff); resumes when staff or tenant resumes
Reason required; tenant notified
Tenant-wide agent kill-switch
Sets agent_enabled=false; in-flight tasks complete current step and stop
Reason; tenant notified; expires unless made permanent
Feature-specific kill-switch
Pauses one agent feature for one tenant
Reason; auto-expire default 24h
Approval override
Approve / reject an approval on behalf of a tenant admin
Co-sign required for irreversible; visible to tenant
Resume abandoned task
Restart from last persisted step
Audit
Re-run with new config
Replay task with candidate prompt/model/tools
Sandbox only — never re-execute side effects in prod
Memory inspection / forget
Surface per-tenant or per-user agent memories; force-forget on legal request
GDPR audit row written
Tool registry view
See which tools each tenant has, which versions pinned, deprecations
Read-only here; mutations via control-plane API
Kill-Switch Speed Requirement
Per-tenant agent kill-switch must flip in < 5 seconds wall-time from staff click to runtime enforcement. Implementation: write to a Redis key the runtime checks before each step; DB updated asynchronously for audit.
# Runtime check before each stepdefcheck_kill_switch(tenant_id):
if redis.get(f"agent:killed:{tenant_id}") == "1":
return KillSwitch("tenant_kill_switch")
returnNone
The kill-with-rollback runbook (ai-agent-reversibility-and-blast-radius §4) describes the compensation cascade. The console wires the button.
Required co-signs
Tenant-wide agent kill-switch on Enterprise: 2 staff (support engineer + tenant CSM or higher).
Approval override of irreversible: 2 staff.
Bulk kill of > 10 tasks: 2 staff + dry-run.
Memory force-forget: 1 staff + legal ticket reference.
Cross-references
ai-agent-runtime-architecture — provides the task list + state machine the console drives.
ai-agent-observability-and-replay — provides the task viewer + replay link.
ai-agent-action-approval-and-hitl — approval objects the staff override.
For agent products, the back-office needs two purpose-built surfaces beyond the standard tenant/billing views: an SLA-credit override console and a dispute-resolution console. Both share the principle that every keystroke is dual-authed, audit-logged, and links to the verdict / evidence pack.
SLA-credit override console
Reads from the credit-case ledger produced by ai-agent-sla-credit-automation. For each open case the operator sees:
The breach event (incident link or detection signal).
The eligibility decision (auto-approved, auto-denied, needs-review).
The proposed credit amount (formula + inputs).
The trace bundle + verdict + evidence pack.
The per-tenant credit cap remaining for the period.
Every action emits to the credit-case audit log; the customer-facing dashboard reflects the outcome in < 60 seconds.
Dispute-resolution console
Reads from the dispute queue produced by ai-agent-task-success-tracking/references/dispute-resolution.md. For each open dispute the operator sees:
Customer-asserted outcome (success or failure).
System verdict (task.success.verdict) and evidence pack.
The judge rationale.
Per-tenant dispute volume in the rolling window (abuse signal).
The proposed resolution from the rebuttal pipeline.
Actions:
Action
Effect
Uphold system verdict
dispute closed; no commercial action
Overturn (success → failed)
refund triggered (ai-agent-abandonment-and-refund-policy), revenue de-recognized in current period
Overturn (failed → success)
rebill at resolution price; customer notified
Escalate
dual-auth review queue for the head of CS
Rate-limit safeguard: if a tenant's overturn-in-customer-favor rate in the rolling 90-day window exceeds the configured chargeback ceiling, the console refuses single-auth overturns and forces escalation.
Cross-links
ai-agent-sla-credit-automation — case data source.
ai-agent-task-success-tracking — dispute data source.
ai-agent-abandonment-and-refund-policy — refund execution invoked from overturns.
dual-auth-rbac — auth model for the override actions.
Compliance Console (Enhancement)
The back-office adds a Compliance Console surface for control owners and (read-only) for auditors.
Screen
Purpose
Backing service
Control Status
One row per SOC 2 / ISO 27001 / HIPAA control; latest evidence pack, cadence health, owner, open exceptions
All open compliance exceptions sortable by control / severity / target-close
ai-agent-soc2-controls
Auditor Portal
Read-only auditor sub-surface (separate auth realm, scoped to packs)
ai-agent-evidence-automation
All Compliance Console actions are themselves logged onto the action audit log with event_class=compliance_console. Auditor-portal access is logged separately into auditor_access_log (evidence for CC6.1).
