Security
Aggregated view of security data, plus per-node data export. Backed by real ops endpoints (security/grants/list, security/signing-keys/list, backup/export). Security v1 is auth_failures-complete (§55); a direct row-level read/list surface over individual auth_failures rows is still a real, undecided open item -- unlike that, aggregate access (burst detection, the retention-prune count) is real and built, since neither exposes an individual row.
The unified audit trail, anomaly detection, and retention-prune preview live on their own dedicated pages -- Audit timeline and Retention / pruning, both reachable from this section's own sidebar.
Cross-tenant, platform-wide visibility lives at its own separate route, not a toggle here -- Super Admin (also reachable from this section's own "Cross-tenant view" sidebar entry).
Other security actions
Grant history
Calls POST /security/grants/list. node_id is the authorization anchor (any real role there authorizes the read) and the actual query target -- every grant issued on that node, newest first.
Signing key lifecycle
Calls POST /security/signing-keys/list. node_id is the authorization anchor (any real role there authorizes the read). Read-only -- key material itself is never returned.
Export subtree data
Calls POST /backup/export (§62). Owner-only -- a per-node data export, not the whole-database DR backup concern (§27.2, separate and still unresolved). signing_keys is metadata-only, raw key material never included.
Retention prune
Deletes auth_failures rows older than the retention window below and records the run permanently (auth_failures_pruning_log) -- shows up in the audit trail above as "Auth-failures retention prune." Owner at your root node only. Preview first to see the real row count and oldest row before anything is deleted -- a genuine dry run (preview_auth_failures_prune, sql/179), not an estimate.
Signing key management
Provisional placement -- Siddharth named Security as the LIKELY home for signing-key issue/revoke when retiring them from the old combined provisioning page, not a confirmed decision ("likely Security, flagging not deciding"). Functionality is real and unchanged; only the page it lives on is still open.
Record a signing key
Calls POST /signing-keys/issue. Pubkey/cert are base64 -- already certified externally (e.g. `ewuscloudd sign`), this just records them. No cryptographic verification happens here.
Revoke a signing key
Calls POST /signing-keys/revoke. Owner-only; an already-revoked key is a real refusal, not idempotent.
Household viewer roles
Temporary placement, no confirmed home -- Siddharth explicitly said this has no decided page and to flag it to the auditor rather than guess. Kept visible here (rather than unrendered) so the working functionality isn't lost from the app while a real home is decided; treat this section's presence on Security as unconfirmed, not as the answer.
Household viewer roles
Calls POST /viewer-roles/list. node_id is the authorization anchor (any real role there authorizes the read) and the actual query target.