Fosniedocsv0.1

Super-admin & break-glass

The ephemeral emergency super-admin – how to mint a grant, what it can do, and how it is audited.

The super-admin is deliberately not a standing account. It is an ephemeral break-glass session: you mint a short-lived grant on the server's command line and use it for one emergency task, and it expires on its own. Because it talks directly to the database and cache – outside the normal login and any identity provider – it keeps working even when the IdP or the web layer is down, which is one of the reasons it exists (repairing a broken platform). It is for emergencies and recovery, not day-to-day administration, which belongs in the admin console.

Mint a grant

From a shell on the server:

fosnie-backend breakglass issue --ttl 900 --label "on-call" --reason "restore provider config"

This prints a grant id to present to the panel. The lifetime is capped (default 1800 seconds); a grant lives only in the cache with that TTL and auto-revokes on expiry. Two companion commands:

fosnie-backend breakglass list      # active grants and their remaining TTL
fosnie-backend breakglass revoke <grant-id>   # end a grant before its TTL

All three connect to Redis and Postgres directly – no HTTP, no login – so they work even if the server is unhealthy.

Use the panel

Open /superadmin, paste the grant id, and unlock. The grant is held in memory only (never in browser storage) and sent as an X-Break-Glass header on every call; when the TTL runs out the panel re-locks. Wrong grant ids are rate-limited per source IP, so a fat-fingered attempt locks out a prober without throttling a legitimate operator.

The panel has four sections:

  • Settings – live ML tuning knobs fed to the ML service per request (retrieval/RAG, chat, ingestion, groundedness, workflows, voice, Deep Research). Changes apply immediately; ingestion knobs apply to new documents. Each knob can be reset to its default.
  • Integrations – activate or deactivate external connectors. Connectors ship dormant for zero egress; enabling one lifts the egress gate for that connector only.
  • All chats – read any user's chats, by design bypassing the owner check for incident review. Every view is risk-audited.
  • Accounts – deactivate an account, or erase all data tied to it (GDPR). Erasure permanently purges every chat, message, prompt, agent, memory, automation, file, and grant for that user and anonymises the account; the audit trail is kept. It is irreversible, requires typing the account's email plus an audited reason, and is refused while the data is under a legal hold (Fosnie Enterprise).

Audit and safety

Break-glass is a notable event by design. Every issue, revoke, use, and denied attempt is written to the audit log with a risk flag, so the whole lifecycle of an emergency session is on record. Combined with the capped TTL and in-memory-only grant, this keeps a powerful capability accountable.

Treat break-glass as a fire alarm, not a door. Prefer the standing admin console for routine work, mint the shortest TTL that fits the task, and always give a real reason – it lands in the audit trail.

Was this page helpful?

On this page