How Waxell Endpoints Works

This page explains what the desktop agent actually does on a machine and how the pieces fit together. For a component-by-component reference (file locations, service names), see What gets installed.

The shape of it

 ┌─────────────────────────── managed device ───────────────────────────┐
 │                                                                       │
 │   AI apps (Claude Desktop, Cursor, Claude Code, Copilot, browsers…)   │
 │            │                                                          │
 │            ▼                                                          │
 │   Network monitor  ──────────►  metadata flows  ─┐                    │
 │   (observe / optionally block)                   │                    │
 │            │ (only if capture enabled for host)  │                    │
 │            ▼                                      │                    │
 │   On-device DLP redaction  ──►  redacted payload ─┤                    │
 │                                                   │                    │
 │   Policy daemon  ◄── guard policy (long-poll) ────┼───┐                │
 │   Cowork watcher / Claude Code hook  ─────────────┘   │                │
 │                                                       │                │
 └───────────────────────────────────────────────────────┼──────────────┘
                                                          ▼
                                            Waxell control plane
                                   (AI Endpoints: Apps · Devices · Guard ·
                                    Captures · Flow stream)

The components

The agent is a few cooperating pieces. On macOS they ship as system extensions plus helper processes inside Waxell Setup.app; on Windows they ship as LocalSystem services plus a hook executable.

• Network monitor — watches outbound connections from AI apps. On macOS it's a Network Extension content filter (flowmonitor); on Windows it's an ETW-based LocalSystem service. By default it records metadata only (which process, which AI host, when). It can optionally block a process/app when policy says so.
• Proxy / capture layer — when (and only when) an admin enables capture for a specific host, this terminates TLS for that host, reads the request/response, hands it to DLP, and uploads the redacted result. On macOS this is the proxymonitor transparent-proxy extension; on Windows it rides the WinDivert driver (see the HVCI caveat).
• Policy daemon — long-polls the control plane for the effective guard policy and writes it locally, so the monitor knows what to observe, block, or capture. Policy changes reach the device within minutes.
• Cowork watcher + Claude Code hook — bring Claude Cowork and Claude Code activity under the same governance umbrella as raw network flows.
• Setup app — the GUI users see: browser sign-in, status, and a Network Monitor view.

Enrollment and the tenant CA

To attribute traffic to a device and (optionally) terminate TLS without breaking trust, each tenant has its own root certificate authority.

1. The MDM profile (or the local installer) trusts the tenant root CA on the device.
2. On first run the device enrolls: it generates a key, sends a CSR, and receives a per-device intermediate certificate.
3. From then on, the device can mint short-lived leaf certs that chain to the tenant CA the OS already trusts — which is what lets the proxy layer terminate TLS for catalog AI hosts only without a certificate error.

Because the CA is per tenant, one customer's CA never touches another's, and the CA-trust payload is the single universal primitive every MDM supports — which is why deployment is MDM-agnostic.

Observe vs. capture

This distinction is the heart of the product:

	Metadata flows (default)	Payload capture (opt-in)
What	Process, AI host, timestamp, bytes	The actual request/response content
TLS	Not terminated	Terminated for that host only
Scope	All discovered AI apps	Only hosts you enable on Guard
Privacy	Nothing sensitive leaves the device	DLP-redacted on-device before upload
Surfaces in	Flow stream, AI Apps, Devices	Captures tab

On-device DLP

When capture is on, redaction happens on the device, before upload. Secrets and PII are stripped locally; the raw payload never leaves the machine. The control plane only ever receives the redacted form. This is what makes capture safe to turn on for genuine AI hosts. Details in Privacy & DLP.

What you see in the control plane

Everything lands in Governance → Connect → AI Endpoints, a tabbed surface:

• AI Apps — every AI agent the scanner found, per device, with its capture ceiling and recommended stance.
• Devices — each device's apps mapped to a governed agent.
• Guard — the layered policy cascade.
• Captures — redacted, attributed payloads (once capture is on).
• Flow stream / AI Activity — the live metadata feed.
• Setup — per-tenant profile/installer downloads.

Next: Key concepts.