Security operations and recovery

Owner access and alerts

Owners use password login and action-bound recent authentication for sensitive operations. Team members see only authorized resources; organization-wide alert/usage/lifecycle controls are owner-only. Optional MFA is operator-provisioned. Production MFA is currently OFF; do not imply configured enrollment or recovery. The public security/v3 protocol is ON. Capabilities do not replace current owner model approval, enrollment, recovery, authority or quota checks; verified CI additionally requires an exact matching trusted binding and accepted OIDC proof. Source uploads remain self-reported. See current proof limits before treating a report as production readiness evidence.

Dashboard alerts and webhook delivery are separate channels. The external webhook is Not configured, with no tenant destination editor. Operators configure a reviewed destination and signing secret out of band. Never infer a URL. Dashboard acknowledgement records owner review, not external delivery. Auth/access thresholds use 20 events in 15 minutes; quota thresholds are 80/100%, with a 15-minute notification cooldown. Catalog events are a baseline audit, not an immutable SIEM or a guarantee during database failure.

Webhook delivery uses HMAC-SHA256 over timestamp and exact body, a stable event ID and at most 5 claimed attempts. Retry delays are 60/120/240/480 seconds. Only a 2xx response marks delivered; a provider receipt may remain null. Receivers deduplicate the event ID. Delivery is at least once, and HTTP acknowledgement does not prove durable provider processing. Invalid configuration stays explicit; fixture TLS delivery is not production destination evidence.

Quotas and storage uncertainty

The server meters accepted reports, physical ingress and storage through atomic new-attempt ledgers and an observed legacy metadata baseline. Rejected/failed physical writes can consume ingress; deleting a report does not refund daily ingress or accepted-report counters. Read the owner usage values and configured limits; do not infer unlimited storage or guarantee a plan from a fixture.

Discovery lists/heads scoped metadata, not report bodies. Generation fences and persisted cursors bind each pass; current accepted reports need exact observed/owned ledger coverage. Known inconsistency, overage, discovery errors or completed discovery older than 24 hours block new reservation and acceptance. Reads/export remain available. A fresh namespace has a 24-hour initial discovery deadline from creation. Recurring scheduling is every 60 seconds with a default total budget of 25 units (cap 100), shared among cleanup, attempt reconciliation, discovery and delivery/retention lanes.

Owner usage distinguishes baseline incomplete, new namespace atomic ledger, and observed baseline plus atomic ledger. Show audit time, generation, in-progress/error state and legacy observed bytes. This is an audit-time observed baseline plus exact new accounting, not an instant globally exact physical-byte total. Unknown old bursts and old-request lifetime are not bounded by a quiet wait. Unassociated legacy objects remain nondeletable quarantine; late report association requires exact key/project/organization identity. No customer report is deleted merely to meet quota.

Retention, holds and offboarding

Report retention is an explicit reviewed operation, not an automatic tenant purge. Reports older than 180 days by received time can be eligible, while preserving the latest report and latest two mainline CI reports. Each dry-run page has at most 25 exact targets, a manifest hash and a separate 30-minute approval. Apply reauthenticates and executes only that page; changed/expired unstarted targets need fresh approval. Results distinguish completed, deferred and remaining. Retrying resumes the original exact operation; it cannot expand scope silently.

Organization/project/report holds have no automatic expiry. Any active scoped hold conservatively defers organization destruction. Ambiguous hold responses retain their operation ID and uncertainty: retry the original scope and ID with current authorization; do not create a duplicate or clear it by timeout.

Offboarding first records full-organization intent and revokes sessions/credentials before report deletion. The owner loses access. Subsequent pages, hold release and final erasure need explicit operator action tied to the original parent intent. Live replay windows, unsettled puts, holds and legacy quarantine can defer finalization. Ordinary active-organization audit retention is 365 days with foreign-key, recovery and hold exclusions. Completed offboarding removes customer audits while retaining minimized operator recovery/lifecycle proofs. Eligible old audit rows can be removed by scheduled retention; the cleaner does not promise to retain every authority audit forever.

Backup and isolated restore

Recovery uses a separate RECOVERY binding and operator-provisioned epoch with create-only external authority events and SQL fencing. Missing activated control/epoch/schema/binding fails closed. External events preserve conservative deny intent; restoring D1 does not revive revoked sessions/tokens, waivers, model/binding authority or denied runs. Permanent deny rows and the operator journal have no automatic purge. Keep the journal/correlation proof at least 365 days and through all usable backups.

Close external admission and the SQL barrier before a recovery snapshot. settled:false means actual registered operations remain; elapsed time, an empty HEAD or restored active flags cannot unlock it. Restore only to fresh isolated resources while retaining the original recovery journal. Replay verifies coverage and authority before explicit reopen; missing or older-than-coverage backups stay locked. There is no destructive customer-production restore exercise in this evidence.

RPO 24 hours and RTO 4 hours are targets, not a measured provider SLA. Isolated drill receipts record actual time and snapshot gap, and provider backup-window verification remains separate. Operators must verify usable provider backups, resource isolation, production bindings/cron/migrations and safe canaries for the deployment and recovery scope in use. Physical backups expire only under actual provider policy; do not promise immediate deletion from every copy. See report trust for release and authority limits.