This conversation was recorded in 2025 for our Beyond The Signal podcast. The examples below come from Magnaflux's IT director at the time, in his own words.
It's the hardest question in this category to answer, and a customer of five years asked it on a recorded call: what have you actually stopped for us?
He wasn't being hostile. He was pointing at something real. When detection and response works, it interrupts an attack early enough that there's no story to tell afterward. No outage, no ransom note, no board update. The evidence of a job well done is a quiet month, which looks identical to a quiet month where nobody was looking.
So here are two specific examples from that customer, in his words. One of them turned out to be nothing at all, and that's the more useful of the two.
Magnaflux makes non-destructive testing products and is part of ITW. In the episode, their IT director at the time described a monthly review where something odd came up.
"Here's a simple example. Why are our servers reaching out to Japan for time? Like, we found that. And that sounds like a really simple example, kind of silly in some cases, but we didn't set the service to do that, so we had to go in and troubleshoot why."
Then the part most vendors would cut:
"It ended up being some software that we had put on there that just needed to be configured in the right way. So luckily we didn't have any kind of thing. But I would never see that without having someone that has my back looking out for me."
It wasn't an attack. A piece of software had been installed with a default time server on the other side of the world, and nobody noticed because nobody was looking at outbound connections at that level of detail.
We could have written this up as a thwarted intrusion. It wasn't one, and being clear about that is the point.
Because it tells you what the service actually does in a normal week.
There's a reason you rarely see this kind of content anywhere in the category, and it isn't that nothing gets caught. It's that almost no organization will authorize a vendor to publish what happened inside their environment. Nobody wants their name attached to an incident, even one that ended well. So the examples that do circulate tend to be anonymized past the point where you can check them.
A lot of what a detection service surfaces is not an attack. It's drift. Misconfigurations, forgotten software, a service account doing something nobody authorized, a device phoning somewhere it has no business phoning.
Those are worth finding for two reasons. The mundane one is hygiene: a server syncing time from an unexpected country is a small operational defect worth fixing. The other reason is that the same signal, coming from a different source at a different moment, is exactly what early-stage compromise looks like. Unexpected outbound connections to infrastructure you didn't configure is one of the more reliable indicators there is.
You can't tell the difference by guessing. You tell the difference by investigating, which requires somebody to have noticed in the first place.
His own summary:
"Small things like that can really become bigger things in the future. Even though it looks like it's nothing, it ends up being something huge."
The second one moved faster and ended differently.
"There was a high alert on something, so I'm assuming maybe another client may have seen some activities, and we got contacted by Gradient Cyber and they said hey, there's some activity coming out of Kenya, we need to get a block in place. We got the block in place, approved it, and went forward. We have no reason to be doing business in Kenya. We're the North America location for what we do, so there was no reason to not block it."
Three things worth pulling out of that.
He was contacted, not alerted. Somebody reached out with a specific finding and a specific recommended action. He didn't have to notice a row in a console.
We made the change, not him. The firewall block was executed on our side. That's active response, and it's the difference between a provider that tells you what to do and one that does it. What his policy determined was the gate in front of it. He wanted notification and approval before a rule went in, so that's how it ran. A different customer with a different policy would have had the block in place first and the notification after.
He guessed at the mechanism, correctly. "Maybe another client may have seen some activities." Detection patterns learned in one customer environment apply to every other customer environment, because an attacker's technique doesn't necessarily change based on who they're targeting. That's the compounding benefit of a service model, and it's the one thing an in-house team genuinely cannot replicate.
One caveat, since it cuts both ways. As attackers lean harder on agentic AI, more of what they do gets generated per target rather than reused across targets. Pattern reuse in the signature sense gets less useful in that world. Cross-environment visibility gets more useful, because what you're matching on stops being the payload and starts being the behavior. That's the bet we're making. It's a fair question to put to any provider you're evaluating.
His answer was not about features.
"I don't have 24 hours a day to be watching screens and every system out there. We have a job to do, we have customers to serve, we have more efficiencies to gain. And that's where the real value of it is. But you're not going to have any of that unless you have a stable, secure environment."
That's the mid-market case for MXDR in one paragraph, from someone who isn't selling it. The IT function has a business to support, and watching consoles competes directly with that work.
Don't ask what they've stopped. You'll get a war story, and war stories are selected.
Ask for the last ninety days, in writing:
That last one matters the most, and it's the one providers will volunteer the least. Sensors go quiet. Agents fall off during hardware refreshes. A log source breaks after a firewall upgrade and nobody notices for six weeks.
We wrote the longer version of that test in how to tell whether your MXDR service is actually working. It applies to us as much as to anyone else.
No, and the distinction matters. A false positive is a detection that fired on nothing. The Japan example was a real, unexpected behavior that was correctly identified, investigated, and explained. The outcome was benign. The detection was accurate.
It varies by environment, and any provider quoting you a universal number is guessing. The more useful question is what share of validated findings get dispositioned each month and whether you can see that breakdown.
You set the rules, we execute within them. Where active response is authorized, Gradient Cyber makes the change through your enforcement systems rather than handing you a task. Whether we notify and get approval first, or act and tell you after, is your policy decision, agreed per action type before anything is live. In the Kenya example the customer's policy called for notification and approval ahead of the change, so that's how it ran.
By reviewing outbound connection destinations against expected behavior, continuously, across every server. That's technically possible in house. In practice it competes with every other thing the IT team is responsible for, which is the whole argument.
The episode is embedded above and runs about twenty minutes. It was recorded in 2025.
Quiet months are the goal. The problem is that you can't tell a quiet month from a blind one without asking for the records, and most buyers never ask.
Ask. It takes one email, and the time it takes to get an answer tells you nearly as much as the answer does.