TTechclick ⚡ XP 0% All lessons
Darktrace · AI NDR · Models & TuningInteractive · L1 / L2 / L3

Darktrace Models, Model Breaches & Tuning Out False Positives

Darktrace doesn't ship signatures — it learns what is normal and scores what isn't. This lesson follows the whole chain: anomaly scores become models, models raise model breaches, Cyber AI Analyst groups those breaches into investigated incidents, and you tune the noise out with tags, groups and custom models — without ever switching detection off.

📅 2026-06-19 · ⏱ 16 min · 5 infographics · live breach demo · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

A clear, interactive guide to Darktrace (2026): how the Self-Learning AI's anomaly scores feed models, how a match raises a model breach with a severity, how you investigate it in the Threat Visualizer, how Cyber AI Analyst groups related breaches into investigated incidents, and how to tune out false positives without disabling detection.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

Anomaly to model

Anomaly scores, models, and the model breach.

 2

Anatomy of a breach

Score, device, evidence — and the Threat Visualizer.

 3

AI Analyst incidents

Grouping breaches so you work incidents, not alerts.

 4

Tuning the noise

Suppress, tag, group, custom models — never disable.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. Does Darktrace detect threats using a list of known signatures?

Answered in Anomaly to model.

2. What does a model breach contain besides the alert?

Answered in Anatomy of a breach.

3. How should you stop a legitimate-but-noisy behaviour from alerting?

Answered in Tuning the noise.

Most engineers think…

Most people assume Darktrace is 'an AI box that flags weird traffic', and that every alert it raises is a threat to chase down. Both halves of that picture get you into trouble.

Darktrace is a layered pipeline: the Self-Learning AI scores how anomalous behaviour is, models add conditions to turn that raw anomaly into a meaningful, explainable alert, and a match raises a model breach with a severity. Cyber AI Analyst then groups related breaches into investigated incidents so you triage incidents, not thousands of raw alerts. The real skill isn't reading alerts — it's tuning the models (tags, groups, custom models, exceptions) so normal behaviour stops shouting while genuine anomalies still breach.

① From anomaly scores to models to model breaches

Darktrace ships no signatures. Its Self-Learning AI watches every device and user, builds a picture of what is normal for each of them, and produces an anomaly score when behaviour deviates. That anomaly detection is the foundation, but a raw score on its own is noisy and hard to act on.

On top of it sit models. A model is logic that combines the AI's anomaly scores with conditions and criteria to describe a behaviour actually worth alerting on — for example, 'a device making an unusual external connection and transferring an unusually large amount of data'. Darktrace ships many built-in models, and you can build custom models for your own environment.

When a device's behaviour matches a model, Darktrace raises a model breach — the alert. So the pipeline is simple to say and important to get right: anomaly scores → models → model breaches. Models are what turn raw anomaly into prioritised, explainable alerts.

Figure 1 — The alerting pipeline — anomaly to breach
The Self-Learning AI scores anomalies; models add conditions; a match raises a model breach; AI Analyst groups breaches into incidents.The alerting pipeline — anomaly to breachLearnbaseline normalScoreanomaly scoreModelscore + conditionsBreachalert + severityIncidentAI Analyst groups
The Self-Learning AI scores anomalies; models add conditions; a match raises a model breach; AI Analyst groups breaches into incidents.
Say the pipeline out loud

In an interview, separate the layers cleanly: the Self-Learning AI produces anomaly scores; models add conditions to turn raw anomaly into a meaningful, explainable alert; a match raises a model breach with a severity. Anomaly detection is the foundation, models are the judgement layer.

Quick check · Q1 of 10 · Understand

In Darktrace, what is a 'model'?

Correct: b. A model sits on top of the anomaly engine: it combines anomaly scores with conditions/criteria (e.g. unusual external connection AND large transfer) to define an alert-worthy behaviour. A match raises a model breach. Darktrace ships many built-in models and you can build custom ones.
👉 So far: Pipeline: the Self-Learning AI scores anomalies, models add conditions to describe alert-worthy behaviour, and a match raises a model breach. Models turn raw anomaly into prioritised, explainable alerts.

② Anatomy of a model breach — and the Threat Visualizer

A model breach is not just 'something happened'. Each breach carries a score / priority (its severity), the triggering device, the time, and — crucially — the underlying anomalies and evidence that caused it. That evidence is why Darktrace alerts are explainable rather than a black box.

Investigating in the Threat Visualizer

Analysts open and investigate breaches in the Threat Visualizer. From a single breach you can see the device, its connections, the exact behaviour that breached the model, and you can pivot across the network to related activity. The severity score tells you where to look first; the evidence tells you whether it is a real threat or simply unusual-but-legitimate behaviour.

Figure 2 — What a model breach carries
Every model breach is explainable — it records its severity, the device, the time and the evidence behind it.What a model breach carriesScore / priorityseverity — where to look firstTriggering devicewhich device breachedTimewhen the behaviour happenedEvidencethe underlying anomalies
Every model breach is explainable — it records its severity, the device, the time and the evidence behind it.
📈
Anomaly score
tap to flip

How unusual a behaviour is versus the device's learned baseline — produced by the Self-Learning AI and the raw input to every model.

🧩
Model
tap to flip

Logic combining anomaly scores with conditions to describe a meaningful behaviour worth alerting on. Many are built-in; you can build custom ones.

🚨
Model breach
tap to flip

The alert raised when a device matches a model — carries a severity score, the device, the time and the underlying evidence.

🤖
Cyber AI Analyst
tap to flip

Automatically investigates breaches and groups related ones into investigated incidents, so analysts work incidents, not thousands of raw alerts.

Quick check · Q2 of 10 · Remember

Which of these does a model breach record?

Correct: a. Every model breach is explainable: it carries a score/priority (severity), the device that triggered it, the time, and the underlying anomalies/evidence — which is exactly what you read in the Threat Visualizer.
👉 So far: A model breach carries a score/priority (severity), the triggering device, the time and the underlying evidence — investigated in the Threat Visualizer, where the severity says where to look and the evidence says whether it's real.

③ Cyber AI Analyst — incidents, not raw alerts

A busy network can raise a lot of model breaches. If a human had to read each one, the SOC would drown. Cyber AI Analyst solves this: it automatically investigates breaches and groups related ones into investigated incidents, complete with a written narrative of what it believes happened and why.

The practical effect is a change of unit of work. Instead of triaging thousands of raw breaches, analysts triage a handful of incidents, each prioritised by severity and already investigated. The interview line: you work incidents, not alerts. Cyber AI Analyst does the first-pass investigation so the human starts from a story, not a stack of disconnected pings.

Figure 3 — Cyber AI Analyst groups the noise
Related model breaches are investigated and grouped into one incident, so analysts work incidents instead of raw alerts.Cyber AI Analyst groups the noiseAI Analystone incidentBreach: scanBreach: C2 beaconBreach: lateral moveBreach: large transferBreach: unusual conn
Related model breaches are investigated and grouped into one incident, so analysts work incidents instead of raw alerts.
Triaging raw breaches one by one

Working every model breach individually burns the SOC out and misses the wood for the trees. Let Cyber AI Analyst group related breaches into incidents, then prioritise incidents by severity. You work incidents, not thousands of raw alerts.

Quick check · Q3 of 10 · Understand

What is the main job of Cyber AI Analyst?

Correct: c. Cyber AI Analyst does the first-pass investigation and groups related model breaches into incidents with a narrative, so analysts triage a handful of investigated incidents instead of thousands of raw breaches.
👉 So far: Cyber AI Analyst investigates breaches and groups related ones into investigated incidents with a narrative, so analysts triage a handful of prioritised incidents instead of thousands of raw breaches.

④ Tuning out false positives — without losing detection

Most day-to-day Darktrace work is tuning, not chasing alerts. When a breach is legitimate-but-noisy you can acknowledge or suppress it, adjust a noisy model, build a tuned custom model, use device tags and groups to express what is normal for a set of devices, and whitelist known-good patterns. All the while, the AI keeps learning as the environment changes.

Best practice, and the traps

Prioritise with severity plus Cyber AI Analyst incidents, and tune iteratively — never try to action every raw breach. The classic pitfalls: disabling a model wholesale to kill noise (you lose the detection and miss the real thing later); ignoring AI Analyst's incident prioritisation and drowning in raw breaches; and not using tags/groups, so behaviour that is perfectly normal for a group keeps alerting forever. Tune the model — don't switch it off.

Figure 4 — Tune the model vs disable the model
Tuning silences the noise but keeps detection; disabling wholesale stops the noise and the real threat with it.Tune the model vs disable the modelTune (do this)Suppress / acknowledge noisyTag & group devices to scopeBuild a tuned custom modelDetection stays — real threatsDisable (avoid)Switch the whole model offNoise stops instantlyNo tags, no exceptions, no nuanceYou miss the real attack later
Tuning silences the noise but keeps detection; disabling wholesale stops the noise and the real threat with it.
Figure 5 — Tuning a noisy breach the right way
A legitimate-but-noisy breach is scoped out with tags and a tuned model — not silenced by disabling detection.Tuning a noisy breach the right wayBreachnoisy but legitConfirmevidence in VisualizerTaggroup the deviceTunescope / custom modelKeep AIdetection stays on
A legitimate-but-noisy breach is scoped out with tags and a tuned model — not silenced by disabling detection.

Sneha at a Hyderabad logistics firm faces this

Every night around 1 a.m. the backup server BKP-SRV-01 raises a flood of high-scoring breaches on an 'unusual large data transfer' model, and the SOC is exhausted triaging them.

Likely cause

A legitimate nightly backup is genuinely unusual against that device's baseline, so the model breaches every night — true behaviour, not a true threat.

Diagnosis

In the Threat Visualizer the evidence shows the same destination, same time window, same backup pattern nightly; Cyber AI Analyst has already grouped them into one recurring incident, confirming expected backup activity.

Threat Visualizer ▸ open breach for BKP-SRV-01 ▸ review evidence + AI Analyst incident
Fix

Tag BKP-SRV-01 into a 'Backup Servers' group and tune the model (scope/exception for the nightly pattern) instead of acting on each breach; let the AI keep learning the device.

Verify

Next night the expected backup raises no breaches, while a genuinely anomalous large transfer from a workstation still breaches and is escalated by AI Analyst as a high-severity incident.

Prove the tune, don't assume it

After tuning, confirm two things on the next cycle: the legitimate behaviour no longer breaches, AND a genuinely anomalous version of it still does. If only the first is true you may have disabled detection by accident rather than scoping it.

▶ Watch a noisy backup breach get tuned the right way

How a legitimate nightly transfer breaches, gets confirmed and tuned — while a real exfiltration still gets caught. Press Play for the healthy path, then Break it to see the classic failure.

① Breach raisedAt 1 a.m. the backup server BKP-SRV-01 breaches the 'unusual large data transfer' model with a high score.
▼
② Confirm in VisualizerAn analyst opens the breach in the Threat Visualizer; the evidence shows the same backup destination and window every night — legitimate, not a threat.
▼
③ Tag & tuneThe server is tagged into a 'Backup Servers' group and the model is scoped so this normal nightly pattern no longer breaches.
▼
④ Detection stays onA genuinely anomalous large transfer from a workstation still breaches and AI Analyst escalates it as a high-severity incident.
Press Play to step through the healthy tuning path. Then press Break it.
Quick check · Q4 of 10 · Analyze

A backup server legitimately breaches an 'unusual large transfer' model every night. What is the right fix?

Correct: d. Tune, don't switch off. Tagging the server into a group and scoping its normal nightly pattern stops the noise while a genuinely anomalous transfer from another device still breaches. Disabling the model wholesale would lose detection and miss a real exfiltration later.
👉 So far: Tune, don't disable: suppress/adjust models, build custom models, tag and group devices, whitelist known-good, and let the AI keep learning. Prioritise by severity + incidents; never switch a whole model off to kill noise.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Remember

What produces the anomaly scores that models reason over?

Correct: b. Anomaly detection is the foundation: the Self-Learning AI learns what is normal for each device and user and scores deviations. Models then add conditions to turn that raw anomaly into alert-worthy behaviour.
Q6 · Understand

Which statement best captures the role of models?

Correct: a. Models sit on top of the anomaly engine and combine anomaly scores with conditions to describe a meaningful behaviour worth alerting on, so the raw anomaly becomes a prioritised, explainable model breach.
Q7 · Apply

An analyst needs to read the device, connections and evidence behind a specific breach. Where do they go?

Correct: c. The Threat Visualizer is the investigation console — from a breach you see the triggering device, its connections, the evidence and you can pivot across the network.
Q8 · Analyze

Why do analysts work 'incidents, not raw alerts' in Darktrace?

Correct: b. Cyber AI Analyst does the first-pass investigation and groups related model breaches into incidents with a narrative, so a busy network's thousands of breaches collapse into a handful of prioritised, investigated incidents.
Q9 · Evaluate

A model is noisy but the behaviour is legitimate. What is the best response?

Correct: b. Tuning silences the noise while preserving detection: suppress/adjust the model, scope it with device tags/groups, or build a tuned custom model. Disabling wholesale stops the noise and the real threat with it.
Q10 · Evaluate

Which is a genuine pitfall when managing Darktrace alerts?

Correct: c. Disabling models wholesale is the classic trap — you stop the noise but lose the detection and may miss a real attack. The other options are all good practice; the right move is to tune iteratively, not switch detection off.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: why is 'tune the model' better than 'disable the model' when a breach is noisy? Then compare with the expert version.

Expert version: Because a noisy breach often comes from behaviour that is unusual-but-legitimate for that device, not a fault in detection. Tuning — suppressing/adjusting the model, tagging and grouping the device, or building a custom model — scopes out that specific normal pattern so it stops alerting, while the underlying detection stays live. Disable the whole model and the noise vanishes, but so does your ability to catch the genuinely anomalous version of that behaviour later; the backup server goes quiet and the compromised workstation's large exfiltration sails through unseen. Tuning is iterative and surgical; disabling is blunt and dangerous.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

Self-Learning AI
Darktrace's engine that baselines normal behaviour per device and user and scores anomalies, without static signatures.
Anomaly score
A measure of how unusual a behaviour is versus the learned baseline — the raw input that models reason over.
Model
Logic combining anomaly scores with conditions/criteria to define an alert-worthy behaviour; many are built-in, and you can create custom models.
Model breach
The alert raised when a device matches a model — carries a score/priority (severity), the triggering device, the time and the underlying evidence.
Threat Visualizer
Darktrace's console for investigating breaches — the device, its connections, the evidence and network pivoting.
Cyber AI Analyst
The layer that automatically investigates breaches and groups related ones into investigated incidents with a written narrative.
Incident
A set of related breaches grouped and investigated by Cyber AI Analyst, prioritised by severity — the analyst's real unit of work.
Tuning
Reducing false positives by suppressing/adjusting models, building custom models, tagging/grouping devices and whitelisting known-good patterns.
Device tag / group
A label that scopes behaviour so what is normal for a group of devices does not keep alerting.
Custom model
A model you build or adapt for your environment to detect — or to stop alerting on — a specific behaviour precisely.

📚 Sources

  1. Darktrace — How Darktrace works: Self-Learning AI and anomaly detection. darktrace.com
  2. Darktrace — Darktrace / NETWORK (NDR) product page. darktrace.com
  3. Darktrace — Cyber AI Analyst: investigating and grouping alerts into incidents. darktrace.com
  4. Darktrace Customer Portal — Models and model breaches; creating and tuning custom models. customerportal.darktrace.com
  5. Darktrace Customer Portal — Threat Visualizer: investigating model breaches and evidence. customerportal.darktrace.com
  6. Darktrace — Reducing false positives: tagging, grouping and tuning models. darktrace.com

What's next?

Got models and tuning? Next, go proactive with Darktrace / Proactive Exposure Management (formerly PREVENT) — finding and shrinking the attack paths to your crown jewels before anyone breaches anything.

Next · All interview lessons → Practice on exam.techclick.in →