The Question Nobody Can Answer Fast Enough

Sponsored by Scanner. They paid for this placement. The reporting, the opinions, and the parts where I go off on a tangent are mine.

Every security team I have been on has had one question that arrives at the worst possible moment. Some vuln drops, some report gets written up, somebody senior reads a headline on their phone, and then my phone rings.

Do we run this? Are we exposed? Is it exploitable? Is it on the internet?

At one of the big banks I worked at, the head of cyber defense had a standing rule for the whole department. If he called and asked, he wanted an answer in 30 minutes. Seems like a totally reasonable ask. We could not do it. Our honest best case was about a week, because getting there meant network scans that took days to crawl the environment, a CMDB that nobody fully trusted, and a lot of very expensive people running very manual queries.

That was around 2015. The question has not changed since. The time it takes you to answer it is still the thing your program actually gets graded on, and most teams still measure it in days.

Post-AI, the attacker side of that clock is heading toward zero. Ours mostly is not.

The reason your answer is slow

Here is the part that annoys me, because it has almost nothing to do with talent. Every team I have worked with could answer these questions if they had the data in front of them. They do not have the data in front of them, because at some point somebody did the math on per-gigabyte ingest pricing and started cutting.

It is common to see only a small slice of an org's log data actually searchable, with the rest sprawled across object storage, a warehouse, and whatever SaaS tool happened to generate it. The stuff that gets cut first is not because it lacks value, it’s because it is just enormous in volume: VPC flow logs, DNS, low-level EDR telemetry.

Those are also the exact sources that let you stitch a timeline together instead of staring at a wall of disconnected alerts.

Cliff Crosland, Scanner's CEO, told me the version of this that happened at his previous startup. They hit about a terabyte a day, and the Splunk renewal came in higher than their entire engineering budget. So they dropped VPC flow. Everybody drops VPC flow.

As your company grows, there is more to defend, more logs to defend it with, and a shrinking percentage of them you can afford to look at. Sequoia's Bogomil Balkansky wrote up his research on this when they led Scanner's $22M Series A. One of the security leaders he interviewed put it about as bluntly as it can be put: they "drown in logs we can't afford to keep," and then go blind on the ones they cannot afford to search.

I lived my own version of this at Reddit. When I got there, genuinely talented security engineers were spending their days as sysadmins keeping Elk alive. We tried a few things, including getting Chronicle basically free because we were a big GCP customer, and it was not ready for prime time back then. We went Splunk as the easy button, and then spent a couple of years clawing our way back off it onto BigQuery. The team wrote the whole thing up publicly after I left.

What I remember most is what I kept asking for and kept not getting. VPC flow and DNS.

What changed is who is asking the questions now

For twenty years the consumer of your security data was a person with a keyboard and a finite number of hours. That person rationed their threat hunts, because each one cost real time and sometimes real money. Athena queries at petabyte scale ran for hours and could cost several hundred dollars a pop, so you learned to be precious about which hunt you kicked off.

The consumer now is increasingly an agent, and agents do not ration anything. They iterate. They follow a thread, get a partial answer, and ask four more questions. An agent that has to wait six hours for a result is a batch job with a chat interface.

This is where query speed becomes the ceiling on everything you can build on top. Scanner says most of their usage now comes from agents rather than humans clicking around the UI, arriving over MCP, Claude Code, and their own set of skills. Agents drive about 80% of queries on the platform, and roughly a third of their customers had the MCP integration in production within weeks of release.

That number tracks with what I have watched happen in my own workflow this year. Hunts I would have scoped, scheduled, and probably skipped are now things I just ask for.

What Scanner’s demo actually did

I sat through a live one, and I have sat through a lot of these, so take the enthusiasm accordingly.

Cliff ran a search for a single IP address across petabytes of CloudTrail data spanning six months, sitting in S3. No field name specified, no schema defined ahead of time, just the IP. The index narrowed a petabyte down to a bit over a terabyte of files that could possibly contain hits, and returned results in tens of seconds. He then pivoted into aggregations across a roughly 300 terabyte slice and got those back in seconds too.

The mechanism is the interesting part, and it is why I think this is more than a pricing story. Scanner indexes data as it lands, schema agnostic, including deeply nested JSON straight out of S3 with every field searchable. Those index files live in cheap object storage in your own AWS account. At query time it spins up serverless compute, hits only the index files that matter, and spins back down. Cliff's team came out of distributed systems and Rust, and the obsession with performance and speed shows.

Cost lands around 30 cents per terabyte actually scanned, and the whole point of the index is that it scans a fraction of what you store. That petabyte query cost a couple of dollars.

Turning your security logs into something that responds at roughly search engine speed is a good outcome on its own, because nobody enjoys watching a spinner at one in the morning during an incident.

What I cannot stop thinking about is what it lets you build on top.

The part I got genuinely nerd sniped by

Right now the sequence is: a question forms in somebody's head, a human opens a tool, an investigation begins.

If a six month sweep costs about a dollar of query compute and a dollar of tokens and comes back in seconds, you can flip that sequence entirely. Threat intel lands. An agent with context on your actual environment decides whether it is even applicable, skipping the Microsoft-flavored intel if you are all AWS. It runs the sweep across six months of history. Then it posts to Slack before your CISO has finished reading the headline that would have generated the question.

Nobody ever opens an investigation. The answer just shows up.

Cliff showed me a beta of this running in their own Slack, and it is the shape of the thing. Today's KEV batch, IOCs extracted from each entry, swept against about ten months of log data, came back clean, with the reasoning attached for why it believed that.

Extend it one more step and the trigger does not have to be threat intel at all. It can be the anomaly itself. Cliff's example was the Hugging Face and OpenAI mess I covered in the newsletter and on a bunch of videos/podcasts a few weeks back, where the weird activity was sitting in a package manager for months with nobody watching that corner. Base64 blobs in absurdly long directory names, megabyte-scale paths, the kind of thing that is obviously wrong the moment a human looks at it. Nobody looked, because that log source was never going to survive a per-gigabyte ingest budget.

Cheap storage plus fast search plus an agent that never gets bored is a real answer to that class of problem, and it's the same logic behind what it takes to stop an AI swarm. The bottleneck stops being the query and starts being agent speed. If your whole data stack is faster than Claude, you’re winning.

Where they sit in a very crowded room

I made a joke at Black Hat this year that AI SOC vendors are undergoing carcinisation. Evolution keeps independently arriving at the crab body plan, and our industry keeps independently arriving at the same company. Two years ago the floor was full of differentiated products. This year it was forty variations of the same agent triaging the same alerts.

Scanner is deliberately standing somewhere else, and I asked Cliff about it directly. He does not want to build agents that plug into your entire environment and run response. His words: he wants to be an unbelievably fast data layer that AI SOC and MDR companies build on top of. Several of them already resell Scanner underneath their own offerings, because their customers want the agent without paying twenty years of SIEM feature accretion for the storage.

I think that is the right call, and selfishly it is the version I want as a builder. Give me the fast data layer and I will build my own harness on top. I never would have attempted this on BigQuery. Every time I hit run on a BigQuery query I was nervous I had just spent real money on a broken query I would find out about in twenty minutes.

Before you go eval them

A few things worth knowing, because a sponsored post that only lists strengths is worthless to you and to me.

Deployment is AWS-only today. Scanner will index data from anywhere, GCS buckets, Azure blob storage, Kafka, Snowflake, Okta, CrowdStrike, Google Workspace. The compute deploys into your AWS account, or into their managed environment if you are fine with the index files living in their bucket. GCP and Azure deployment are on the roadmap without a firm date. If you are a regulated Azure shop with low SaaS tolerance, that conversation is worth having early, and Cliff was upfront that customer demand is what decides which cloud comes next.

It is more of a practitioner's tool right now. Cliff volunteered this before I could ask. Engineers get it immediately. CISOs who want a visual posture overview are less served today. Dashboards are the known gap and the thing they are working on. (I actually tried to talk him out of building dashboards at all. Practitioners begging for a performant tool is what’s driven adoption everywhere I’ve worked, though I’ll admit that’s shaped by the kind of shops I’ve worked at, mostly high tech places.)

Per-terabyte-scanned pricing means your agents can spend money. A few dollars per hunt is nothing until an unsupervised loop runs a thousand of them overnight. Teams are handling this by batching medium and low severity work on a schedule and letting only high-severity alerts trigger immediately. Budget for it like compute, not like a license.

Where this leaves us

Ten years ago my honest answer to "are we exposed to this" was "give me a week, and I will be guessing on day seven anyway."

A dollar fifty and thirty seconds would have been a hell of a trade.

Scanner