Background

What Unphish v2 is

Unphish v2 is the production platform for autonomous brand-protection enforcement. It detects, classifies, and takes action against brand impersonation, phishing, malware distribution, fakeshops, counterfeit, copyright violations, fraudulent mobile apps, account takeover infrastructure, and other online abuse targeting the brands of our clients.

The platform is operated by Unphish staff and Unphish partners on behalf of rights-owner clients. Threats are detected through a mix of provider integrations, scheduled scans, watchlist monitoring, client API submissions, and manual entry. They are enriched with screenshots and infrastructure metadata, classified by a multi-signal scoring engine, and routed through configurable enforcement channels — registrar abuse, hosting providers, browser blocklists, social platforms, DNS-blocking partners, and direct provider APIs.

Every sensitive action is permissioned, audited, and explainable.

Why v2 exists

Unphish v1 (the legacy Django/React platform) is the system of record we are migrating from. It worked, but it grew organically over years and accumulated three problems:

1. Workflow surfaces fragmented. "Threat Feed", "Cases", "Approvals", "Verification", and "Watchlist" felt like separate products even though they are stages of one lifecycle.
2. Operator and customer surfaces blurred. There was no clean separation between the platform control plane (Hub) and the per-tenant operator app.
3. AI-readiness was bolted on. Classification, evidence synthesis, and feedback loops were retrofitted rather than designed in.

V2 is a ground-up rebuild that keeps every piece of legacy functionality unless explicitly retired, while restructuring the system around the autonomous enforcement engine described in the Unphish v2 proposal.

The first delivery milestone is pilot-ready: a customer can be onboarded, threats can move end-to-end through the platform, and every action is auditable.

The four product layers

Think of v2 as four concentric layers, each with a different audience:

1. Hub — the platform control center

The Hub is the operating console for Unphish itself. It exposes:

• Environment tiles for demo, staging, production, and the development workbench.
• Team management with invitations, roles, expiry, and revocation.
• Tenant and environment readiness, including deployment blockers.
• Secrets and integration configuration for external providers.
• Security controls for SSO, MFA, API keys, and session policy.
• Activity log of user, invitation, configuration, and deployment events.

Hub access requires staff or admin system role. This is where Unphish operates the platform; it is not a customer surface.

2. Admin — staff and platform operators

The Admin layer is the global-visibility layer for Unphish staff. It exists inside the same app as the analyst workspace and is gated by capability rather than living in a separate deployment. Admins manage:

• Organizations, partners, clients, and the tenant hierarchy.
• Users, memberships, invitations, roles, and access status.
• Environment activation and data-source readiness.
• Service plans, quotas, usage, and entitlements.
• Provider integrations and platform-wide default policies.
• Global audit log and operational activity.

3. Agent / Partner — the multi-tenant operator workspace

Each agent or partner manages their own branded Unphish instance: their client portfolio, their analysts, their enforcement queues. Partners are not a separate codebase; they are a tenant scope with white-label branding and portfolio filtering applied to the same routes that internal analysts use. This is what makes Unphish a viable channel-partner business.

Partner capabilities include partner branding, client setup, analyst queues, cross-client dashboards, and client-approval workflows where required by policy.

4. Client portal — rights owners and customer users

The client layer is a scoped, quiet portal for the rights owner. Clients see only their authorized data: active cases, threat feed, enforcement history, watchlists, reports, and metrics. When their policy requires, they approve or reject enforcement actions. They can also submit threats, evidence, and notes through secure forms.

And the development workbench

A fifth surface, the Workbench, sits alongside the four production layers. It is the production-parity sandbox for pipeline development — ingestion, classification, workflow, enforcement, verification, and integration testing. Crucially, the workbench uses the same data contracts as production; it switches only the provider transport to fixture/sandbox mode. This is what makes regression testing and model evaluation tractable.

How the lifecycle works (in one diagram)

A threat moves through this canonical lifecycle:

Intake (provider feed, scan, API, manual, watchlist update)
   ↓
Enrichment (screenshots, DNS, WHOIS/RDAP, SSL, redirects, HTML, language, email)
   ↓
Classification (visual + NLP + domain + evidence → confidence + label + route)
   ↓
Triage gate
   ├── Auto-route (high confidence + policy permits)
   ├── Analyst review (low confidence or ambiguous)
   └── Client approval (policy requires customer authorization)
   ↓
Enforcement (XARF, CleanDNS, registrar, host, Meta, X, Cloudflare, GSB, SmartScreen, manual)
   ↓
Verification (DNS, HTTP, visual, blocklist checks every 4 hours)
   ↓
Closure (resolved / dismissed / escalated)
   ↓
Resurrection monitoring (30 days post-closure; reopens on reappearance)

Continue to Concepts for the data model, Personas for who uses the system, Goals for what we are and are not building, and the Glossary for definitions.