There is a famous problem in security.
It isn't a lack of data. Modern endpoints generate more telemetry than any team can read. It isn't a lack of tools — most organizations are drowning in dashboards. The problem is the one that has always existed: somewhere in the ocean of normal traffic is the one thing that matters, and finding it requires asking exactly the right question, at exactly the right time, in exactly the right place.
The needle is in the haystack. The haystack is on fire. You have a magnifying glass.
This is the story of a session we ran last week — no scripts, no pre-staged scenarios, no predetermined outcome. Just a natural language interface, a live Threatmatic deployment, and a real organization's telemetry. What follows is what we found, and how we found it.
Start Anywhere
The session began with the simplest possible question: how many organizations are on the platform?
Nineteen. Names returned instantly — from Threatmatic's own research tenant to active customer deployments ranging from a cybersecurity consultancy to a graphics company in Marina.
The follow-up was equally simple: give me an events summary for Gilberts Cyber.
total_devices: 2
connected_devices: 2
total_policies: 2
blocked_events_24h: 117
blocked_events_7d: 1,800
total_events_24h: 33,508Two devices. Two policies. Thirty-three thousand events in a single day. Seventeen hundred blocked connections in a week.
That ratio — 1,800 blocks in seven days against a two-device organization with only two policies — is the first thread worth pulling. Small org. Quiet policy set. Loud block volume. Something doesn't add up.
Pulling the Thread
What's getting blocked?
lhagent.exe (HP Touchpoint Manager) 728 blocks — 7 days
chrome.exe 390 blocks — 7 days
rmm.agent.exe 106 blocks — 7 days
CrossDeviceService.exe 93 blocks — 7 days
svchost.exe 46 blocks — 7 daysThe numbers tell a story before you even interpret them.
HP Touchpoint Manager — an endpoint telemetry and management agent — is being blocked 728 times over seven days. That's not a policy working correctly. That's a policy misconfiguration creating friction: the agent is trying to phone home, getting cut off repeatedly, retrying. Every retry generates another block event. The customer's endpoint management tool is essentially muted.
Chrome being blocked 390 times is the second anomaly. Browsers don't get blocked unless a policy specifically targets either the application or a destination it's trying to reach. This organization only has two policies — and neither of them explicitly targets Chrome.
Then we asked the follow-up question: which policies are applied to these devices?
The answer was unexpected. Both block policies in Gilberts Cyber — "Block LogMeIn" and "Block rmm.agent.exe" — were assigned to only one device: david-hp-zbook-. The second device had no policies assigned at all.
And yet it had 441 blocked events.
The Device That Shouldn't Have Had Blocks
desktop-ejftomv — the second device — showed up in the blocked events data with no direct policy assignment, no tag-based assignment, no explanation for why anything should be getting blocked on it.
This is where inference starts to matter more than queries.
We pulled the device record. One tag: ep:ladera-ranch. We checked whether any tag-based policy assignments existed for that tag within the organization.
One hit.
"Block nytimes.com" — a public policy, visibility: public, assigned via the ep:ladera-ranch tag. Someone had tagged this specific device, assigned a content block policy to that tag, and the policy had been quietly enforcing ever since.
The Chrome blocks weren't random. Chrome was being used to browse nytimes.com.
The Burst That Confirmed It
We pulled the raw blocked events for desktop-ejftomv. Sorted by time, descending.
2026-06-03 16:37:02 chrome.exe → 35.209.233.198 BLOCK
2026-06-03 16:37:02 chrome.exe → 34.54.226.84 BLOCK
2026-06-03 16:37:02 chrome.exe → 34.111.60.239 BLOCK
2026-06-03 16:37:05 chrome.exe → 98.87.215.169 BLOCK
2026-06-03 16:37:05 chrome.exe → 44.214.170.78 BLOCK
2026-06-03 16:37:05 chrome.exe → 100.29.213.41 BLOCK
2026-06-03 16:37:07 chrome.exe → 52.25.18.141 BLOCK
2026-06-03 16:37:07 chrome.exe → 35.167.141.102 BLOCK
...Twenty distinct IP addresses. All egress blocks. All Chrome. All within a thirty-second window on the afternoon of June 3rd.
This is what a modern news site looks like in telemetry. nytimes.com runs on a massively distributed CDN — Akamai, AWS, Fastly — with dozens of IP endpoints across multiple providers. When a browser loads the page, it fans out connection attempts simultaneously. All twenty of those IPs resolved to nytimes.com infrastructure. All twenty got blocked.
We asked the user: were you browsing nytimes.com on June 3rd at 4:37pm?
"Yes, I was."
The needle. Found.
The Meta-Moment
When we pulled the latest permitted traffic for the organization — live, as the session was running — two entries appeared in the feed that stopped us:
08:18:22 claude.exe → 34.149.66.137 PERMIT DESKTOP-EJFTOMV
08:18:16 claude.exe → 160.79.104.10 PERMIT DESKTOP-EJFTOMVThe AI conducting the investigation had appeared in its own evidence.
claude.exe — the Claude Code VS Code extension — was visible in the permitted traffic feed, connecting outbound to Anthropic's infrastructure in real time. The natural language session querying this telemetry was itself being logged by the agent recording it.
The toolbox queries were there too:
08:18:27 toolbox.exe → 172.235.63.113 PERMIT DESKTOP-EJFTOMV
08:18:17 toolbox.exe → 172.235.63.113 PERMIT DESKTOP-EJFTOMVEvery query we ran against the database generated its own entry in the device_access_events hypertable. The investigation was writing itself into the record it was investigating.
This is what real-time telemetry means. Not a dashboard that refreshes every fifteen minutes. Not a nightly batch job. Events, as they happen, from every enrolled agent — including the one running the queries.
What Made This Possible
The session ran in under an hour. It found a misconfigured policy, a content block actively enforcing on a tagged device, and a clear explanation for hundreds of otherwise-mysterious block events. It confirmed the block with a single question to the user. And it caught itself in the act.
None of this required:
- A SIEM rule written in advance
- A scheduled report waiting for the morning
- A threat analyst with a list of queries to run
- Any prior knowledge of which organization or device to start with
It required a natural language interface connected — via MCP — to a live stream of behavioral telemetry from enrolled agents.
The Model Context Protocol is the connective tissue. Threatmatic's toolbox exposes the platform's telemetry, policy engine, and device registry as structured tools. An AI assistant with access to those tools can traverse the data the way a senior analyst would: starting broad, following signals, forming hypotheses, testing them, and arriving at conclusions that a dashboard alone would never surface.
The intelligence isn't added on top. It emerges from the data that's already there.
The Observation That Stays With Us
The blocks on desktop-ejftomv had been accumulating for days before we looked. The tag policy was working silently and correctly. The nytimes.com CDN burst on June 3rd was recorded in full — timestamp, application, remote address, direction, policy match — in a hypertable that had already moved on to the next 33,000 events.
The needle was always in the haystack. It had been there since the first time someone opened a browser and tried to read the news.
The question was just whether anyone was going to ask.
Threatmatic is a Zero Trust Network Access platform with continuous fleet telemetry, real-time policy enforcement, and a natural language interface via MCP. If your endpoints are generating events that nobody is reading, we can help you start asking questions.