Threatmatic · Mohan's Vision

Clearing Customs

The companion question to The Front Door: once a device is allowed to talk to something, what happens to its traffic on the way out? Same mesh, same nodes, opposite direction — zone policy, NetQoS, and π Inspection answer it, with QSChannel and Cloudiffusion carrying it everywhere the ingress page already covered.

ZONE POLICYbagGATEallowed:api.acme.com ✓slack.com ✓everything else ✗"where does this ticket say you're going?" the destination has to be on the list, firstNETQOS🐘1 lane per passenger"that's not one bag,that's a whole flood" you get your lane — not the whole pipeπ INSPECTION🔍same engine that watches ingress — now watching what you're takingTHE INTERNETEXIT"congratulations —you're someone else'sproblem now"once it's out, it's out — everything above is the only chance to be sure

what a device's own traffic goes through before it's allowed to leave — checked once, not felt at all if it's legitimate

The stack, layer by layer

Same rhythm as ingress — three different questions, none of them each other's job.

Zone Policy

Built

"Are you even allowed where you're going?"— WireGuard-level reachability plus the ZTNA policy engine. A device only ever sees the destinations its zone permits — the rest doesn't exist to it, not just "is blocked."

NetQoS

Built

"Are you taking more than your share?"— per-flow rate shaping at the source, before traffic ever reaches a firewall. Enforces at the device itself, same "kernel-level, sub-200ms" model as SynGuard and EdgeGuard.

π Inspection

Built (endpoint)

"What's actually in the bag?" — decrypt, classify, re-encrypt, today running endpoint-local on the device. The exact same engine EdgePi relocates to the edge for ingress — same classifier, different place to stand.

Cloudiffusion™

Built

"Does this apply to cloud workloads too?"— app-level bandwidth governance against runaway cloud costs is already part of what Cloudiffusion ships — NetQoS's own egress-shaping idea, already extended into the cloud.

Still the same fabric underneath

Egress doesn't get a separate mesh. It's the same QSChannel tunnel, same nodes, traffic just flowing the other way.

SAME MESH — TRAFFIC JUST FLOWS OUTWARD THIS TIMEdevice💬Slack🌐the API you need🚫not on the list✗☁️a cloud workload

the device only sees a path to what its zone actually allows — everything else is invisible, not merely refused

Same node. Same hats. Just facing the other way.

What's actually true today

Egress is further along than ingress, honestly — most of this already runs in production.

LayerTodayThe vision
Zone PolicyReal, running — WireGuard reachability + full ZTNA policy engine, live for every device.Already matches the vision at this layer.
NetQoSReal, kernel-level, sub-200ms, per-flow — enforcement-verified.Already matches the vision; console-side policy wiring still catching up.
π InspectionReal, endpoint-local, shipped classifier with 20+ categories.Same engine relocated to the edge (EdgePi) for fleet-scale egress — design-stage.
CloudiffusionShipped and marketed — bandwidth governance already extends into cloud VPCs.Already real; the anchor both this page and the ingress one build toward matching.
QSChannelReal, mature, production — same mesh as the ingress page, no separate egress network.Multi-region routing — same open item noted on the ingress page.
Companion piece — Threatmatic's ingress visionThe Front Door →
← Back to The Wire