A multi-agent SOC.
Every job that used to be yours.

Puts a user under active observation after an incident where the evidence was not conclusive enough to close and not serious enough to escalate. It builds targeted queries over sign-in activity, directory changes and alerts for that user, checks them on a cycle, and records the result of every check including the clean ones.

Worth knowingThe judgement is deliberately fail safe. If the assessment of a tripwire hit cannot be completed for any reason, the hit is treated as an anomaly and escalated. An outage never silently swallows a detection.

Takes the incident out of Sentinel, resolves which triage procedure applies, establishes who and what is actually involved, enriches it with your own history and business context, and works it to a verdict. Where the evidence does not settle it, the agent opens an Advanced Investigation: it forms hypotheses about what happened, tests each against the estate, and resolves what the first pass could not. It then audits its own work for gaps before producing a verdict with a blast radius assessment, a recommendation and the report attached.

Worth knowingTwo gears, not two agents. Advanced Investigation is the hypothesis work that used to sit behind a handover, and it now happens inside the same agent on the same incident. Where there is still no configured rule for a procedure, it escalates to a human and flags it for review rather than guessing.

Stops incidents being treated as unrelated events. When an incident reaches investigation, Fusion pulls every incident from the last 30 days sharing an entity with it, every standalone alert from the last 14 days touching the same entities, and how each of those was resolved. It then classifies what it is looking at: a recurring pattern, an active campaign, or a one off.

Worth knowingIt also checks whether an alert type is firing abnormally for you specifically, by comparing the last 24 hours against your own seven-day baseline rather than against a generic threshold.

Ingests threat intelligence continuously from vendor feeds, research publications and Microsoft Defender Threat Intelligence, extracts the actors, techniques and indicators, and works out which of it is actually relevant to your estate. It then does the step most intelligence programmes skip: it checks whether a reported technique is something your detections would actually see, and raises the gap to Detection Engineering.

Hunts on a schedule, on demand, and in response to new intelligence. It reads your environment and your coverage gaps, then writes its own hunts and its own queries, constrained to the data you actually ingest, so it never proposes a hunt against a table you do not have.

Worth knowingIt also ingests penetration test and red team reports, extracts the engagement window and the activities performed, and hunts each activity against that exact window. That answers the question a pen test rarely does: would we have caught it. Hunting ships requiring approval before it runs.

Owns the detection rules as a living estate rather than a deployment. It reviews rules on a cycle, rewrites logic that is underperforming, backtests the proposed change against real historical data before anything is deployed, and grounds its tuning in how incidents from that rule were actually dispositioned by analysts.

Worth knowingA new or rewritten rule is a draft; deploying it to Sentinel is a separate, gated step. It also detects rule changes made outside CYBERSHIELD AI, directly in the Sentinel portal, and records what changed and when.

Pulls vulnerability findings, asset context, installed and end-of-life software, misconfigurations, browser extensions, certificates and hardware inventory from Defender, prioritises against exploitation data and against which of your assets actually matter, and produces the remediation plan.

Worth knowingPrioritisation is deterministic, using CISA KEV, EPSS exploitation probability and CVSS, and the AI layer writes the narrative on top of it. That separation is deliberate, and it is the answer to "how do I know the AI is not just making this up".

Builds a per-user risk picture from the signals your estate already emits, scores it, and surfaces the people whose behaviour has actually changed against their own established baseline rather than against a generic rule. It discounts activity with known third parties, decays older activity, and shows the arithmetic behind every score.

Worth knowingThe scoring is deliberately not done by a language model, and every score decomposes into the signals that produced it. It is the strongest explainability story in the platform.

Executes the containment and response plan once an investigation calls for one. Plans are built from steps, each step declares the exact tools it may use, and the agent is given only those tools. It proposes each action, holds it for approval where approval is required, executes on approval, and records the outcome with the reason.

Worth knowingEvery step defaults to requiring approval. Auto-run requires both the step and the owning agent to allow it, and then a stated condition to hold. An unrecognised condition falls back to manual approval. It never fails open.

Owns what you are told and when. It drafts the notification from the investigation, routes it to the right recipients for you and for that incident type, sends it from the SOC mailbox, records every send against the investigation, and tracks replies.

Worth knowingRecipients are resolved once, when the run starts, so an edit made mid-run cannot change the audience of an email already waiting for approval. "Why did this go to them" is always answerable.

• Produces scheduled service and executive reporting
• Tracks incident trends, SLA performance and detection coverage over time
• Builds board-ready summaries from the underlying case data

Keeps the platform’s own machinery honest: the health of every connection into your estate, the state of the tool catalogue, stalled or stuck work, and the reconciliation checks that confirm the platform’s own records match reality.

Runs the service rather than the incident. It watches queue health, service level standing against target, workload distribution and throughput, and surfaces the incidents at risk of breaching before they breach rather than after.

Worth knowingWork is not dispatched first in, first out. Every incident carries a service level deadline set at ingestion and never moved, and as it approaches that deadline it moves through priority zones. In the two most urgent zones severity is deliberately set aside, so a near-breach low-severity ticket outranks a comfortable high-severity one.