Introduction

Securing the digital backbone of the UK’s critical services

The battle between cybersecurity attackers and defenders is a constantly evolving arms race. At Reliance Cyber we always try to offer the latest protective technologies to our clients, allowing rapid responses to new attacks, whatever their form.

In 2026 the battleground is AI. The past few years have seen a proliferation of AI-enabled cyber attacks, starting with personalised mass phishing, progressing into deepfake enabled and Business Email Compromise, and recently full stack attack chains carried out by autonomous agents ^[1][2]. These attacks are fast and ruthless, and to adequately protect against them we need to stay one step ahead.

We have spent the last year building AI and LLM reasoning into our Managed Detection and Response service. We have rolled it out responsibly, introducing one feature at a time to allow us to assess their efficacy and ensure we’re not putting our clients at risk.

Our core principle is to use AI to augment, rather than replace, our human cybersecurity experts. We’re proud of our team, and we have designed our platform to aid them. Things move quickly in a SOC, with analysts sometimes only getting a few minutes to make decisions and disrupt real time cyber attacks. In the critical minutes that our clients are under attack, our goal is to use those minutes as impactfully as possible. We have designed these tools to allow our analysts to process more data and execute actions at scale, freeing them to apply their human expertise where it is most effective.

You can read our full AI Mission Statement here

Case Enrichment

Core to our MDR service is how we manage cases. Each case is raised based on data from our clients’ environments, such as EDR alerts, operating system logs, or DNS records. To accurately review cases and determine if an event is a genuine cyber attack, we also need to draw on other data such as threat intelligence, historic reputation scores, and live detonation of potentially malicious code. This means that for each case there are tens of thousands of lines of useful information, far more than analysts can reasonably assess given the short timeframes they have to respond to a potential attack in progress.

We have built an AI model into our case assessment to review this vast quantity of data and highlight areas of interest for our analysts. It can draw on and process all of these, using both public sources and private threat feeds. This means that our analysts have more information than ever before when making real time decisions crucial to the security of our clients.

We have engineered this to ensure that a human is in the loop and makes the final decision. Our approach is to use human and AI together to ensure each case is reviewed far more thoroughly than previously possible.

Detection Rules

Our detection rules are our initial point of discovery for suspicious activity. We deploy hundreds or potentially thousands of detection rules for each client environment, listening for events that require further investigation. As we operate a technology agnostic SOC, our rules need to deal with a wide range of technologies, covering both off-the-shelf platforms and bespoke technology stacks. It also means we support different SIEM and EDR platforms, meaning the same rules need to be deployed in multiple languages for different client technology stacks (e.g. YARA-L for Google SecOps and KQL for Microsoft Sentinel).

To address this we have created RADAR: Reliance Autonomous Detection Analytics Repository. This centralised detection logic management platform uses LLMs to assist with reviewing, updating, standardising, and deploying rules at scale. Previously rules management was a painstaking manual human process, and updates we made for one client would need to be hand written for different clients. RADAR allows us to manage detection logic orders of magnitude faster than was previously possible.

As always, we believe in the principle of keeping a human in control and we ensure that no changes are rolled out without human oversight. RADAR provides a thorough review and sign off process, highlighting opportunities for improvement but requiring authorisation from our specialised detection engineers before being deployed.

Speed

The speed of cyber attacks can be measured in minutes and seconds. This is especially true as we enter the age of AI, and we believe that as defenders we need to operate at the same speeds.

One of the dangers of LLMs and other neural networks is their non-determinism: there is always the risk of getting back unpredictable results, and this is a significant risk for automated decision making. To mitigate this we rely primarily on symbolic AI (or GOFAI – “Good Old-Fashioned AI”) for decision making, which is not neural network based and allows us to have confidence in deterministic responses.

Our integrated AI platforms allow us to operate at a faster pace in three key ways:

1. Firstly, they provide our analysts with analysis of vast data sets that they would not previously have been able to absorb during real time attacks. Our automation playbooks automatically carry out searches of threat intelligence feeds, internet management organisations such as domain registrars and address registries, and public sources, to provide our analysts with this data at the beginning of their investigations.
2. Secondly, some low risk actions can be taken prior to a human looking at the case. This is only used in cases where we can be certain what is going on and ensure that any actions we do take are straightforward to roll back once reviewed by our cybersecurity experts. In some situations acting immediately and then reviewing those actions leaves our clients more secure than taking no action until after the human review. This allows the immediate blocking of some parts of the kill chain, stopping rapid cyber attacks in their tracks.
3. Thirdly, our AI SOC allows us to carry out actions simultaneously over the full range of our clients. This is critical to our regular threat hunts, as well as allowing us to be confident when we know there is a new zero-day vulnerability being exploited in the wild.

Investigation Depth

Each investigation we carry out is a trade-off between speed versus depth. More thorough investigations allow us to be more certain of making the right response, but may give an adversary longer to carry out an attack before we intervene.

Our SOAR playbooks are designed to work as a hybrid between human and AI. We now integrate RAG (Retrieval Augmented Generation) directly into playbook workflows, ensuring that by the time a human analyst looks at the case they have all of the relevant data in front of them. This approach minimises the risk of LLM hallucinations, and allows our analysts to absorb more information than they would otherwise be able to while making rapid decisions. We provide LLM analysis of the data retrieved, pointing out anomalies, risks, or reassuring factors, along with the raw data itself so that analysts can verify any findings. Each LLM analysis reviews tens of thousands of lines of data, primarily log files and threat intelligence feeds, meaning our investigations are now far deeper than is possible with a human alone approach.

This is the foundation we’re building on. Where today’s playbooks pre-fetch a fixed set of data for each case, we are now implementing functionality to give the model the ability to follow up on its own observations: if an EDR alert suggests further evidence would help confirm or rule out malicious activity, the model can pull related records from the client’s SIEM without an analyst needing to ask. Humans still make the decisions; the model just becomes a more capable evidence-gatherer.

Security

One of the key dangers of LLMs is jailbreak and prompt injection attacks, where models are tricked into following commands from input text. Our defences operate at several layers: validation of inputs reaching the model, scoped permissions for any tool the model can call, deterministic checks before any action with real-world impact, and full logging of every prompt, response, and decision. Although we do not believe it is a good idea to publicly disclose all of the controls we have put in place, we regularly penetration test our services to identify whether they are exploitable.

Results so far

This post wouldn’t be complete without putting some numbers on what we’ve built. These are constantly being tuned and re-evaluated, so treat them as a snapshot rather than a final assessment.

Our AI case analysis has been live across 18 client environments since October 2025, and in that time it’s processed over 20,000 cases. Because every case is ultimately reviewed and dispositioned by a human analyst, we have a near-real-time signal on how the model’s judgments line up with our experts’ professional assessments.

One thing to keep in mind as you read the numbers below: the model’s job today isn’t to make the final call on cases, that remains a human decision. Its job is to absorb the data faster than an analyst could, surface the relevant evidence and threat intelligence, and explain its reasoning. The numbers below measure how often the model and the analyst end up in the same place. They don’t directly capture the part we care about most: whether the model is helping the analyst investigate better and faster. We have indirect signals on that and are working on more direct measures.

The model has been deliberately tuned to err on the side of caution. We’d rather it surface something benign for review than miss a real attack, and the numbers below reflect that design choice.

They split into three asymmetric claims:

The impact

Two of these numbers, 99.3% and 87.9%, are the ones we care most about. The third, 13.3%, is a known cost we’ve chosen rather than a problem we’re avoiding. When a client is potentially under attack, a noisy alarm that buys an analyst’s attention is better than a quiet system that lets something slip through. The trade is asymmetric on purpose: the downside of missing a real attack can be a client breach, while the downside of an over-flagged case is a few minutes of analyst review. Given those stakes, we’d far rather over-flag than under-detect. We expect all three numbers to keep shifting as we refine the model, but we don’t intend to chase a higher headline figure at the expense of recall. Even more so, we don’t intend to chase agreement at the expense of the model’s actual job, which is making our analysts better-informed by absorbing larger amounts of data.

A note on methodology: Our reference point in all of this is the disposition each case receives from a human analyst. That’s the strongest signal we have routinely available, but it has limits: analysts see the model’s summary before making their call, so some agreement is anchored on the AI’s judgment rather than independent of it; and the comparison is observational rather than randomised. To check that AI activation hasn’t introduced a hidden cost, we ran a longitudinal comparison across our client base, comparing each client’s outcomes before and after their AI activation date, alongside our never-enabled clients as a control group. Across roughly six months of staggered rollout, the time taken to close cases and the rate of confirmed malicious cases moved in the same small ways for treated and control clients. This was found to be consistent with gradual calendar drift rather than effects of the AI analysis rollout. We’re continuing this work alongside a blind-review study of analyst-AI disagreements, and will publish further results when they’re ready.

What’s to come

We’ve still got a lot of improvements in the pipeline that we think will enable our analysts to make better and faster decisions. Right now we’re looking to increase the amount of client specific context that our model has, primarily so it’s more confident at flagging cases as false positives when there is more information available (our model really doesn’t like penetration tests as it has no way currently of knowing they are simulated attacks).

For the alerts that we are confident are false positives and have very low risk of harm, we want to deprioritise these for our analysts, so they can spent their time looking at the more complicated cases. Those deprioritised cases can then be confirmed during slower hours when our case load is relatively light.

Currently our LLM model isn’t allowed to make decisions on its own (although our deterministic case code can) so that is something we are exploring. We don’t want to be in a situation where our model locks a client out of something critical, so we need to be very confident in our deployment before enabling that functionality. We will test this for low-risk cases with soft containment actions that will be easy to review and, if necessary, roll back once humans have had a chance to assess them.

There are many other improvements and agentic workflows in the pipeline, but we’ll save those for later blogs. We’ve got some very cool functionality coming that we’re excited to talk about, but we want to be sure they’re delivering the desired effects before making them public and enabling them for all clients. All of our functionality is designed to support our human-in-the-loop processes, giving our clients the best of both worlds: agentic speeds and human expertise.

[1] https://www.anthropic.com/news/disrupting-AI-espionage

[2] https://www.microsoft.com/en-us/security/blog/2026/03/06/ai-as-tradecraft-how-threat-actors-operationalize-ai/

---