Edge Architecture

Everything that runs on the user’s machine — proxy, extensions, daemon, and how they share a unified session model

Edge Architecture

Quint’s “edge” is the software running on the machine where an AI agent executes — a developer’s laptop, a CI runner, a server. Five components work together:

Component	Role	Language
Forward Proxy	HTTP CONNECT + MITM TLS for explicit opt-in	Go
Network Extension (NE)	macOS transparent interception, zero-config	Swift
Endpoint Security (ES)	Kernel-level ground truth (procs + files)	Swift
Edge Daemon	Unifies proxy + ES into one session model, forwards to cloud	Go
QuintAgent.app	Container app, holds NE/ES system extensions	Swift

How traffic reaches the daemon

Two interception paths, one MITM pipeline. Any flow captured via HTTP_PROXY or the NE extension ends up in the same serveMITMImpl function — so request parsing, tool-call extraction, audit stamping, and session attribution are identical regardless of how the bytes arrived.

The ES extension runs in parallel and feeds process/file events directly to the daemon over a separate socket. The daemon merges both streams into unisession.Tracker, keyed by root PID, to produce one session per AI agent invocation.

What stays on the machine

Stays local	Goes to cloud
Source code content	Structured action metadata
Credentials, API keys, secrets	Agent identity + platform
Full LLM conversation bodies	Session lifecycle events
Tool input arguments (raw)	Tool name + capability + risk score
CA private key + Ed25519 audit signing key	Timestamps + session IDs

The edge daemon enforces this split. Raw bodies persist to the local signed audit log (quint.db) for forensic replay. Only normalized events flow to api.quintai.dev.

Where to read next

• Understanding the interception paths: Forward Proxy then Network Extension
• Understanding audit + sessions: Edge Daemon → Audit Log & Session Attribution section
• Installing on a new machine: Operations → Installation
• When things break: Operations → Troubleshooting