Security & Architecture

This section is the technical reference for how Unphish v2 is built and what controls protect it. It is intended for security reviewers, architects, platform engineers, and customers under NDA who need to understand the system in depth.

Read in this order

1. Architecture — the runtime: hosts, services, data flow, environments, and how they fit together.
2. Auth and RBAC — identity (Authentik), the role and capability model, route guards, and tenant isolation.
3. Data handling — how evidence, secrets, PII, and audit are stored, transmitted, and retained.
4. Threat model — the adversaries we model, the attack surfaces we protect, and the controls in place.
5. Operations — runbooks, observability, backups, incident response, and rollback.

Headline summary

Unphish v2 is a multi-tenant Next.js application hosted on Vercel with workers on Render and Authentik as the identity provider. State lives in a managed Postgres (Neon). Long-running workflows execute on Temporal (Cloud) via a Render worker. Object storage (S3 / Vercel Blob) holds evidence files. Email goes through Postmark.

The security posture is built around four principles:

1. Authentik owns identity. The application owns authorization. No password hashes in the app database; no fallback auth path.
2. Tenant isolation is structural. Every tenant-scoped record carries organization_id; every client-scoped record carries client_id. Cross-tenant access is impossible without explicit, audited staff capability.
3. Sensitive secrets never live in the app database. The Hub stores credential metadata (provider, target environment, masked fingerprint, last-check status). Actual secrets live in Vercel and Render environment configuration.
4. Source labelling is a security control. Every production-facing surface that could show non-production data labels its source. There is no "silent fixture fallback" in production.

The remaining pages walk through each principle in detail.