Most intrusion detection still works the same way it did twenty years ago: match traffic against a list of known bad signatures, and flag anything that hits. It's reliable against threats someone has already catalogued. It's close to useless against anything novel.
In 2013, a group of Cambridge mathematicians and former UK intelligence analysts built a company around a different premise: don't teach the system what an attack looks like. Teach it what normal looks like for this specific network, then flag any meaningful deviation. That company, Darktrace, is now a cybersecurity platform used by close to 10,000 organisations. The engineering idea underneath it is worth picking apart, independent of the business story.
Signature Matching vs. Behavioural Baselining
The distinction that actually matters here isn't "AI vs. no AI" - most modern security tooling uses machine learning somewhere. It's what the model is trained on.
| Aspect | Signature-based detection | Behavioural baselining |
|---|---|---|
| Trained on | Known attack patterns, shared across customers | Each customer's own network traffic |
| Detects | Threats matching a known signature | Deviations from established "normal" |
| Blind spot | Zero-days, novel attack chains, insider misuse | Legitimate new behaviour it hasn't seen yet |
| Update mechanism | Signature database pushes | Continuous, per-deployment retraining |
Signature matching is a lookup table. Behavioural baselining is closer to unsupervised anomaly detection: no labelled "this is an attack" training set, just a continuously updated model of what constitutes routine activity for users, devices, and traffic flows inside one specific environment. Darktrace calls this a network's "pattern of life."
The trade-off is the one you'd expect from any unsupervised approach: it can catch things a signature never could, because it isn't waiting for the attack to be catalogued first. It can also flag legitimate but unusual behaviour - a finance team running an unfamiliar batch job at 3am looks statistically identical to something worth investigating, until a human or a second model says otherwise.
The Architecture: Detection, Response, and Explanation as Separate Layers
What's interesting from a systems-design angle is that Darktrace doesn't treat "detect" and "respond" as one step. It's split into layers that map fairly cleanly onto a pipeline you'd recognise from other ML-ops systems:
The baseline model continuously ingests network telemetry (devices, users, traffic flows) and maintains a probabilistic model of normal behaviour per entity. This is the always-on learning layer - there's no static training/inference split, because the definition of "normal" for a given network shifts over time.
Anomaly scoring compares live activity against the baseline and surfaces deviations, weighted by how unusual they are relative to that entity's own history rather than a fixed global threshold.
Autonomous response(Darktrace's product for this is called Antigena) is the part that makes the anomaly-detection literature interesting in practice: rather than routing every anomaly to a human queue, the system can take a contained action itself - isolating a device, blocking a specific connection - within seconds of the anomaly crossing a confidence threshold.
That's a real latency argument: a human-in-the-loop SOC workflow measured in minutes is a very different risk profile from an automated containment measured in seconds, for the specific case of fast-moving lateral movement or ransomware encryption.
A separate explanation layer (Cyber AI Analyst) takes the raw anomaly signal and correlates it into a written incident narrative - the part of the pipeline aimed less at detection accuracy and more at making the output legible to a human analyst who has to decide whether to trust it.
Splitting detection, autonomous action, and explanation into distinct layers is a reasonable pattern for anyone building an anomaly-detection system with a human-trust problem: you don't have to solve "explainable AI" and "real-time detection" with the same model.
Where This Approach Actually Breaks Down
It's worth being honest about the failure modes, because they're the same ones anyone building anomaly-based detection will hit:
- Cold start. A behavioural baseline is only as good as the history it's built on. A newly deployed sensor, or a network that just went through a major restructuring, has a weak model of "normal" and will produce noisier alerts until it stabilises.
- False positive cost is asymmetric with autonomous response. A missed detection is bad. An autonomous system that wrongly isolates a production database server is also bad, in a very immediate, very visible way. That asymmetry is presumably why response actions are scoped and confidence-gated rather than blanket-applied.
- Adversarial adaptation. An attacker who knows they're inside a behavioural-baselining environment can, in principle, try to move slowly enough to stay inside the model's tolerance for "normal" drift. This is the standard cat-and-mouch problem with any anomaly-based system, not specific to this one.
None of this is a knock on the approach - it's the standard trade-off curve for unsupervised anomaly detection anywhere it's deployed, from fraud detection to industrial monitoring. The interesting engineering decisions are in how tightly you scope autonomous action and how you handle the cold-start problem, not in whether the underlying idea works.
Why It's Worth Knowing About
The company now has a global engineering footprint (offices spanning Cambridge, London, San Francisco, Singapore, and an R&D centre in The Hague) and by mid-2024 was monitoring networks for close to 10,000 organisations. That scale is a reasonable signal that the cold-start and false-positive problems above are solvable in production, not just in a research paper - even if the specifics of how they've tuned it aren't public.
If you're building anything in the anomaly-detection space - fraud systems, observability tooling, intrusion detection for a smaller footprint - the transferable idea isn't "buy this vendor." It's the architectural pattern: separate your baseline model from your response logic, gate autonomous action behind a confidence threshold scoped to blast radius, and don't make your explanation layer do double duty as your detection layer.
This piece looks at the technical approach behind Darktrace's platform. For the business side - the IPO, the $5.3B Thoma Bravo take-private, and how the subscription model works - Entrepreneur Plus Uk covered that in more depth.
Top comments (0)