How it works
Four components, and one rule: a flow is tunnelled only if an allow rule matches it. Everything else is closed without a byte being copied.
| Component | Runs on | Responsibility |
|---|---|---|
| Agent | the device (macOS, Windows) | captures network flows at the OS layer and steers them to the Edge; enforces per-flow allow/deny locally |
| Edge | your infrastructure | decides every flow against policy, routes allowed ones, decrypts and inspects where configured, re-originates what it decrypted, audits the decision |
| Control Plane | alongside the Edge | Admin API, policy engine, identity and NHI registry, audit, OIDC — where configuration, admission and revocation are authored |
| Connector | inside your private network | an outbound-only bridge between the Edge and a private application — and the only way in |
What happens to a request
Two properties are worth stating plainly, because they are the ones people ask about.
- Default-deny is the default, not a mode. There is no configuration in which the absence of a rule means allowed.
- Private applications are never exposed inbound. The Connector dials out to the Edge; nothing dials in. The application has no internet-facing listener to attack.
Is something you run yourself really ZTNA?
Worth answering plainly, because "ZTNA" is frequently used as a synonym for "a large vendor cloud" — under which anything an operator runs would fail the definition by construction, and the word would be a description of a business model rather than of a security property.
ZTNA is a trust model. It is not a topology, and it is not a vendor. Never trust by network location. Verify every access against identity, device, posture and policy. Default-deny. Enforce at a control point. A deployment either has those properties in its decision path or it does not — and here you can read the decision path instead of inferring it from who is hosting it.
Scale and geography are separate questions with real answers. Multi-region delivers availability and data residency, and it is in this release. But it is not what makes the thing zero trust; a single node has that property, and a global cloud without those checks does not.
The Agent, and why it has to be on the device
The Agent runs as a macOS Network Extension, or as a Windows WFP agent with a first-party callout driver, and captures flows at the OS network layer — not as a proxy setting someone has to remember to configure. It carries an mTLS device identity, so the Edge admits a device, not merely a credential. Posture, risk state and revocation are continuous: a device can be admitted, degraded, or cut off while it is running.
This is also what makes same-LAN mediation possible at all. A cloud-only service can never see the traffic between two machines sitting next to each other.
Where TLS is decrypted — and where it deliberately is not
The interception configuration determines which destinations are decrypted and which are forwarded without decryption. Being an approved SaaS service does not by itself mean a destination is excluded from inspection. In our current lab, AI-service traffic remains subject to DLP inspection.
On an intercepted flow, the Edge can inspect the decrypted content and apply DLP rules. On a flow excluded from decryption, it cannot inspect that encrypted content for DLP. Exclusions therefore need to reflect the operator's inspection requirements.
Certificate-pinned hosts are proposed for bypass and never auto-bypassed. The operator decides, and the decision is visible.
How the Edge re-originates what it decrypted
When the Edge decrypts a flow, it opens the upstream connection itself. The standard configuration uses Go's HTTP and TLS implementations for this connection. Policy enforcement, DLP inspection and upstream certificate verification remain in place.
This is the configuration running in our three-region lab and selected for the Experimental release. Web browsing works in that deployment. The upstream connection carries Go's TLS and HTTP fingerprint; it does not claim to match Chrome's. Compatibility with every site's bot protection is not guaranteed.
The source also includes an optional curl-impersonate implementation: libcurl linked against BoringSSL, with browser-oriented TLS and HTTP/2 settings. It can be compiled into the Edge through cgo or hosted as a separate egress service. It requires additional build and configuration steps; the standard build and installer do not enable it. No browser runs inside either implementation.
The egress implementation is an explicit deployment choice. Selecting curl-impersonate does not create an automatic fallback to Go if that engine fails. The standard Go configuration is a configuration of its own, and neither choice authorises an automatic bypass of inspection or certificate verification.
Identity, including the non-human kind
Policy is written against identity, and identity here includes AI agents, non-human identities, MCP and delegated tool execution — in scope from the start rather than retrofitted. Delegated access grants are explicit, persisted and revocable, and out-of-band step-up approval exists for east-west access between internal systems.