Legal

Security

Security practices and account protections for FactNot workspaces and service infrastructure.

01

Account and application controls

FactNot uses authenticated sessions, password re-authentication for account export and deletion, authorization checks in context functions, CSRF protection, CSP headers, rate limiting, admin audit logs, and token revocation for sensitive account lifecycle events.

  • LiveViews and controllers call context functions rather than direct data-layer operations.
  • Account erasure revokes stored auth tokens and OAuth records, then anonymizes the user row.
  • Privacy request admin transitions are audit logged with status/outcome metadata.
02

Evidence and reporting

Security and compliance claims must match production configuration and vendor evidence.

  • Published claims about encryption at rest, backup retention, hosting region, and subprocessors depend on current production configuration and vendor evidence.
  • Security reports should be sent to security@factnot.com.
  • This page should be reviewed whenever production infrastructure, vendors, or security controls change.
03

Monitoring and rate limits

FactNot exposes Prometheus-compatible metrics behind HTTP Basic Auth and applies route-level rate limits to authentication, authenticated browser traffic, API sign-in, and MCP requests.

  • Metrics require METRICS_USERNAME and METRICS_PASSWORD and fail closed when not configured.
  • Authentication routes are rate limited more aggressively than ordinary signed-in browser traffic.
  • API and MCP access remain limited and should stay allowlisted or manually enabled during beta.
04

Backups, restore drills, and rollback

Application fault tolerance does not protect against database loss, bad migrations, operator mistakes, blob deletion, or corrupted derived indexes. A beta deployment should have database backups, upload/blob backups, and a tested restore path before users store irreplaceable data.

  • Run and record a restore drill before broad beta expansion, then repeat it after storage, migration, or hosting changes.
  • Keep a rollback plan for deploys: previous release identifier, migration posture, worker pause/resume steps, and a communication note.
  • If restore proof is missing, the beta notice should tell users to keep independent copies of important content.