Full L7 visibility on first contact. Near-zero overhead on every request after.
There is a tension at the heart of application-layer inspection: to see everything, you have to touch everything. And touching everything adds latency. For a fleet spread across 30 countries, routing every HTTPS request through a central inspection cluster is a non-starter. But letting traffic flow uninspected is exactly the problem inspection is supposed to solve.
The answer is not to choose between the two. It's to recognize that the expensive part of inspection is the first contact with an unknown host — not the hundredth request to one you've already cleared.
Threatmatic's Catch, Check, Release architecture does exactly that: full L7 inspection on first contact, local fast-path on every request after.
CATCH: The Local Intercept
Every enrolled device runs a Threatmatic's payload inspector — a transparent Threatmatic π™ TLS interceptor operating at the QSChannel layer. No per-application proxy configuration. No changes to app settings. From the browser's perspective, nothing is different. From the security team's perspective, every outbound HTTPS session passes through a controlled chokepoint before it leaves the device.
This is the CATCH phase. Threatmatic π maintains a local verdict cache — a table of hosts whose traffic has already been inspected and classified. When a request arrives for a host in the cache, Threatmatic π handles it locally: pass it through, block it with a 204, or apply a stored modification rule. No network hop. No added latency.
When a request arrives for a host not in the cache — a new destination the device has never talked to — Threatmatic π forwards the first request to the nearest Payload Inspector node via the QSChannel mesh. That triggers the second phase.
CHECK: The Fleet Does the Work
The Payload Inspector fleet is geo-distributed across Threatmatic's global infrastructure. Threatmatic π™ routes the first-contact request to the closest node — typically adding 3–8ms of round-trip latency for a regional connection. At that node, the request goes through the full inspection pipeline:
- Decrypt — SSL terminated using the Threatmatic-managed CA certificate distributed to enrolled devices at enrollment
- Classify — application, domain, path, method, content type, response code, and entropy all evaluated at L7
- Policy check — the same policy engine that governs network access and zone segmentation, now applied at the application layer
- Telemetry — the event logged to the fleet's time-series store, visible immediately in the Threatmatic console
The inspector returns a verdict. Three outcomes are possible:
- RELEASE — traffic is clean, policy permits it, pass it through and cache the result locally
- BLOCK — traffic matches a block policy; return
204 No Contentto the client immediately - MODIFY — traffic is permitted with a patch (strip a tracking header, rewrite a path, inject a policy tag); the modification rule is cached locally for future application
The verdict travels back to the Threatmatic π™ over the same QSChannel connection. The full round-trip — first request forwarded, inspector pipeline, verdict returned — completes in milliseconds.
RELEASE: The Local Fast Path
Once a verdict is cached, the remote inspector is out of the loop for that host.
A RELEASE verdict means subsequent requests to that destination flow through the Threatmatic π without touching the fleet. Threatmatic π applies any stored modification rule locally, logs the event to the local telemetry buffer, and passes the traffic through. The overhead is unmeasurable from the user's perspective — there is no network hop, no TLS handshake to a remote node, no queue to wait in.
A BLOCK verdict is equally fast on subsequent attempts. Threatmatic π returns a local 204 No Content in 2–8 milliseconds — before the request has had a chance to leave the device. The remote C2 server never receives a connection. The ad exchange never loads. The exfiltration endpoint never sees the first byte.
The result: the inspection overhead for any given host is paid exactly once. On the second request, and every request after, the decision is local.
The Re-Inspect Problem
Caching verdicts raises an obvious question: what happens when a previously clean host goes bad?
Verdict cache entries are not permanent. Three conditions invalidate a cached RELEASE and trigger re-inspection through the fleet:
TTL expiry. Every cache entry carries a time-to-live. The default is 24 hours for standard traffic, configurable per policy tag. A host that was clean yesterday gets re-checked today. For high-risk categories — newly registered domains, hosting providers known for abuse, anything matching a threat intelligence indicator — the TTL can be set to minutes.
Behavioral anomaly. The Threatmatic π watches for response-level signals that indicate a host has changed behavior: entropy spikes in response bodies, unexpected content-type shifts, new path patterns inconsistent with the classified application. Any of these triggers immediate re-inspection, regardless of TTL state.
Control-plane invalidation. When Threatmatic's threat intelligence pipeline updates — a domain joins a known-bad list, a /24 gets flagged, a newly observed C2 indicator arrives — the control plane pushes a targeted cache-clear to every enrolled device whose verdict cache contains a matching entry. The device doesn't need to wait for TTL expiry. Within seconds of the intelligence update, the affected host is back in the CHECK queue on every device in the fleet.
This is, in practice, more robust than always-inspecting. A traditional always-inspect architecture protects against unknown threats by checking every request. Catch, Check, Release protects against both unknown threats (first contact always inspected) and newly-known threats (control-plane invalidation clears cached verdicts instantly, fleet-wide).
What This Looks Like at Scale
Consider the traffic profile of a typical enterprise endpoint. Over the course of a day, a device contacts hundreds of distinct hosts — but the vast majority of its requests go to a small set of destinations it visits repeatedly. Microsoft 365, Google Workspace, GitHub, Slack, AWS endpoints, a handful of SaaS tools. After the first working day, the verdict cache for most devices is warm. The inspection fleet is invoked only for genuinely new destinations.
For a fleet of 5,000 devices, the practical effect is dramatic. The remote inspector handles first-contact traffic — a small fraction of total request volume. Everything else resolves locally. The fleet's capacity is concentrated where it matters: on traffic that has never been seen before, and on traffic where a control-plane invalidation has forced a re-check.
Blocked traffic — ad exchanges, tracker infrastructure, known C2 endpoints — is blocked locally at every subsequent request, with no load generated on the inspection fleet at all. Once a domain is blocked, it stays blocked locally until the verdict TTL expires or policy changes. The fleet never sees it again.
The Design Principle
Security tools are usually built around the assumption that more inspection is always better. Catch, Check, Release is built around a different assumption: that the most expensive inspection is the redundant one.
An adversary doesn't get a second first impression. If a connection to a new host is inspected — fully, at L7, by a policy-aware fleet node — before the first byte of application data reaches the remote server, the window for undetected initial access is closed. Everything after that is either covered by the verdict cache or handled by a control-plane invalidation the moment new intelligence arrives.
The fleet inspects deeply when it matters. The Threatmatic π handles everything it already knows. The overhead is paid once.
That's the point of Catch, Check, Release: not to do less inspection, but to never do the same inspection twice.
Catch, Check, Release is part of the Threatmatic π™ Payload Inspectors platform, available to enterprise customers. Contact us to discuss deployment options for your fleet.