Skip to content

Architecture Overview

Max Ivankovsky edited this page Aug 12, 2026 · 1 revision

Architecture Overview

This is a short map, not the full story. For the complete design rationale, including why specific approaches were tried and rejected, see ARCHITECTURE.md in the main repository; the sections on the browser extension and blocking are the most useful starting points.

The pieces

Component What it is Runs as
Console Policy management API + web UI (console-backend, FastAPI + SQLite; console-frontend, Next.js static export) Windows Service, http://127.0.0.1:8123
Agent Endpoint monitor: clipboard*, print, and local network channels (agent/CloakDlp.Agent, C#/.NET) Windows Service
Tray notifier Shows notifications, and runs clipboard detection itself* (agent/CloakDlp.Tray) Per-user process, starts at logon and immediately on install
Browser extension Reads card fields directly out of checkout forms before the browser encrypts them (browser-extension, plain JS, Manifest V3) Runs inside your browser

* Clipboard detection specifically runs in the tray notifier, not the agent service. Windows Services execute in an isolated session (Session 0) that cannot see the interactive desktop's clipboard at all, confirmed directly during development; the tray notifier runs in your actual logged-in session, where it can.

Why a browser extension instead of intercepting HTTPS traffic

Almost every real checkout page is HTTPS. A network proxy that only inspects plain HTTP traffic can't see a card number typed into a payment form; seeing it would require installing a local root CA and intercepting TLS, which is a much bigger trust and security surface for what's meant to be a lightweight personal tool. The extension sidesteps this entirely: a content script reads the field directly, before the browser ever encrypts anything, with no certificate installation and no system proxy changes needed. See the "Browser extension: what was tried, and why it isn't a TLS-intercepting proxy" section of ARCHITECTURE.md for the full reasoning.

Zero-config pairing

The agent and the browser extension each self-register with the console on first run over a loopback-only endpoint (nothing reachable from outside the machine), and persist the credentials they get back. The console auto-creates a default "Credit Card Entry" policy on first startup so detection works immediately, no setup required. Opening the console signs you in automatically too, the same loopback-trust mechanism: since only something running on this exact machine can reach it, there's nothing to authenticate against.

Blocking

Every policy's actual enforcement decision (log, flag, or a real block) is computed once, server-side, on every match, never trusted from whatever channel reported it. See Configuring Policies for how to set this up, and the "Blocking" section of ARCHITECTURE.md for exactly how each channel enforces it.

No CloakDLP-operated backend

Every piece above runs on your own machine. There is no external CloakDLP server anywhere in this picture; the console you talk to at 127.0.0.1:8123 is the only server involved, and it's the one running on your own PC.

Clone this wiki locally