Neural Network Computing Cluster · v2.3.0

Meet EmilyAI.
Your autonomous SOC analyst.

Eight years in production — not in beta. EmilyAI is a purpose-built neural network computing cluster that processes over 2.25 million security events per second, eliminates 92% of alert noise, and produces structured, contextualised incident escalations for human analysts. Not a chatbot. Not an LLM. A deterministic security analysis engine.

Platform Architecture Analytical Engine Book a Call
2.25M+ Signals processed per second
99.6% Signal noise eliminated
99.73% Alert Accuracy - no false positives
100% Autonomous Threat Hunting
8 yrs In production — not in beta
100 Billion Signals processed per quarter
22 Clients Protected
v2.3.0 Current platform release
What EmilyAI Is

An autonomous first-line SOC analyst.

EmilyAI is an autonomous SOC analyst platform developed over eight years of continuous research and engineering. She operates as a digital security analyst — continuously ingesting and processing security telemetry, identifying patterns of suspicious behaviour, and producing structured, contextualised incident escalations for human responders.

At her core, EmilyAI is a neural network computing cluster with deeply embedded machine learning and AI structures. This is a fundamentally different architectural basis from contemporary large language model platforms, and that distinction has direct and significant implications for how she operates, what she can do, and how she should be understood by the teams that work alongside her.

Deterministic

EmilyAI produces consistent, repeatable outputs for the same input state. She does not exhibit the probabilistic variability or hallucination characteristics associated with generative AI systems. Every escalation is the product of deterministic analytical logic operating on real telemetry data.

Domain-Specific

EmilyAI has no general knowledge, no language understanding capability, and no ability to reason about subjects outside her training domain. Her entire analytical scope is the structured numerical telemetry produced by security monitoring systems.

Fully Explainable

Every EmilyAI escalation can be traced back through the analytical pipeline to the specific events, thresholds, and weighting values that produced it — structurally different from LLM-based systems where internal reasoning is not fully auditable.

Continuously Improving

EmilyAI improves through structured analyst feedback that adjusts specific weighting parameters within the neural network cluster — a targeted, domain-specific process, not open-ended learning from arbitrary new data sources.

“EmilyAI exists to give our analysts more time, better context, and higher confidence — so that the human judgement applied to each real threat is sharper, not replaced.”
— Cyber Defence Engineering Team
Platform Architecture

A neural network computing cluster.

EmilyAI's computational foundation is a cluster of interconnected neural networks, each specialised for a specific analytical function within the security operations pipeline. These networks do not share weights, do not communicate through natural language, and do not generate probabilistic text outputs. Each network receives structured numerical input — normalised security telemetry — and produces structured numerical output: an anomaly score, a classification, a correlation signal, or a confidence value.

Event flow through the EmilyAI analytical pipeline

Ingestion Telemetry
Normalisation Transform
Neural Cluster EmilyAI
Decision Engine
Human Analyst

Raw telemetry → Normalisation → Parallel neural analysis → Confidence scoring → Human escalation

Telemetry Ingestion

EmilyAI polls the Graylog REST API every 30 seconds for events matching severity thresholds. Events are retrieved with associated MITRE ATT&CK mappings, agent identifiers, customer labels, and timestamp data. Additional telemetry is collected via API from Microsoft 365, Google Workspace, and XDR agents on managed endpoints.

Event Normalisation

Before the neural network cluster processes any event, it is transformed into a standardised numerical representation. This normalisation handles heterogeneous source formats — different vendors, schemas, and timestamp conventions — enabling cross-source correlation. An authentication anomaly from an identity platform and a process execution event from an endpoint agent are correlated after normalisation as related signals on the same host.

Four Databases

EmilyAI uses four purpose-separated MySQL databases, each serving a distinct function: alert data, configuration, threat intelligence, and operational records. This separation ensures that high-volume alert data does not degrade performance on configuration or threat intelligence queries.

Analytical Processing Engine

Four parallel analytical components.

The analytical processing engine is where EmilyAI's neural network cluster operates. The cluster is composed of distinct neural networks running in parallel, each specialised for a specific analytical function. Their outputs are fed into the decision engine as a combined analytical signal.

01

Behavioural Modelling Networks

These networks maintain continuously updated numerical representations of normal activity patterns for each monitored entity — users, devices, service accounts, applications, and network segments. Each event is evaluated against these baseline representations and assigned a numerical anomaly score reflecting its deviation from established norms. The baselines are learned numerical structures that update incrementally as new observations arrive — not static thresholds.

02

Rule-Based Detection Engine

A deterministic rule-based detection engine covering known-bad indicators, published threat actor techniques, and specific attack patterns. Rules are maintained and updated incorporating intelligence from published CVEs, MITRE ATT&CK framework updates, and production incident investigations. Rule matches combine with behavioural anomaly scores to produce higher combined confidence values.

03

Neural Pattern Recognition

Trained on historical security event sequences from production deployments, these networks identify structural patterns characteristic of specific classes of adversary behaviour. Particularly effective at identifying obfuscated or fragmented attack chains — intrusions that deliberately decompose malicious activity into individually unremarkable steps — because the network evaluates the shape of the sequence rather than the content of individual events.

04

Threat Intelligence Correlation

Enriches event analysis by matching observable attributes — IP addresses, domain names, file hashes, user agent strings, certificate fingerprints — against continuously updated threat intelligence feeds. Implements advanced IOC reputation scoring: each match is weighted by source reliability, observation age, false positive history, and independent source count. Reputation scores decay over time as older intelligence loses relevance.

Advanced Correlation

Multi-stage attack detection.

The Advanced Signal Correlation Engine is a multi-dimensional signal correlation system that identifies complex attack patterns across multiple data sources, time windows, and entities. It surfaces attack chains that single-event analysis would miss.

Attack Chain Detection

Correlation patterns define multi-stage attack chains by specifying required signals, entity bindings, and time windows. The system validates signal ordering even when events arrive out of sequence, enabling detection of attacks that unfold over hours or days.

Partial Sequence Alerting

When an incomplete but significant attack sequence is detected — for example, three of five expected stages of a ransomware kill chain — EmilyAI generates an early warning escalation rather than waiting for the full sequence to complete. This enables proactive intervention before an attack reaches its most damaging stage.

Campaign Tracking

Related multi-stage attacks are grouped by threat actor patterns. If multiple alerts share the same C2 domain, ransomware family, or other campaign indicator, they receive a shared campaign identifier — enabling analysts to understand the scope of a single adversary campaign across multiple affected hosts or time periods.

Baseline Deviation Detection

Uses Exponentially Weighted Moving Average (EWMA) models to identify entities producing anomalously high signal volumes. When a host or user generates significantly more signals than its historical norm, this generates a derived signal contributing to correlation scoring.

Dynamic Threshold Adjustment

A self-tuning threshold mechanism automatically adjusts alert sensitivity based on contextual factors. Threshold changes are applied gradually (default: 2% per 15-minute interval), preventing sudden alert volume spikes when conditions change.

ML Alert Scoring

A machine learning component extracts 14 features from each alert and predicts priority classification. Supporting Random Forest, Gradient Boosting, and Logistic Regression models, it is trained on each deployment's own analyst decisions and improves progressively as labelled data accumulates.

Decision Engine

From confidence score to disposition.

The decision engine receives the combined output of all analytical components and applies a weighting model to aggregate them into a single confidence score. Based on the result, each event receives one of three dispositions.

99.6%

Dismiss

Low confidence score, no corroborating signals. The event is suppressed from the active alert queue but retained in the data store for retrospective query. This accounts for approximately 92% of total event volume in a typical deployment.

71%

Monitor

Score exceeds a lower observation threshold but does not meet the escalation threshold. The event enters an active observation state; EmilyAI continues to evaluate corroborating signals within a defined time window and will escalate automatically if accumulated evidence crosses the threshold.

~18%

Escalate

Score meets or exceeds the escalation threshold. A structured incident report is generated containing: a plain-language summary, the contributing event sequence, involved entities, MITRE ATT&CK mappings, confidence score with contributing factors, full enrichment context, and recommended initial response actions. These reports are templated and structured — not generated through language model inference.

Context-Aware Enrichment

Before an escalation reaches a human analyst, EmilyAI automatically enriches each alert with contextual information from five sources: asset context, user context, historical context, threat intelligence, and network topology. Enrichment adds approximately 50–150ms per alert. If any source is unavailable, the alert is still processed and the missing context is noted.

False Positive Memory

If the same rule ID and agent name combination has been marked as a false positive within the past eight weeks, the event is suppressed and an engineering notification is sent rather than generating a new alert. This prevents recurring known-benign events from consuming analyst attention whilst ensuring the engineering team is informed.

Intelligent Grouping

Alert grouping logic clusters related alerts — those sharing the same root rule, affected asset, MITRE tactic, and time proximity — into summary notifications. This reduces notification volume by approximately 80% in high-volume environments without suppressing material security findings.

Detection Capabilities

What Emily detects.

EmilyAI's detection coverage encompasses the adversary technique categories most commonly encountered in production deployments. Because the primary detection mechanism is behavioural pattern recognition rather than static signature matching, the platform is not limited to techniques that have been explicitly catalogued.

Behavioural Anomaly Detection

Continuously updated baseline models for every monitored entity. Deviations from normal behaviour are scored proportionally — unusual is not the same as malicious, and EmilyAI understands the difference through learned behavioural context.

User & Entity Behaviour Analytics

UEBA capabilities include geographic anomalies, impossible travel detection, and off-hours access profiling — particularly relevant to insider threat and account compromise scenarios where legitimate credentials produce no signature-detectable malicious activity.

Attack Surface Monitoring

Weekly scans of client external-facing assets using AbuseIPDB, VirusTotal, AlienVault OTX, and IPInfo to identify newly exposed services, credential exposure on dark web marketplaces, and infrastructure changes that may have increased the attack surface.

Threat Intelligence Correlation

Every alert is enriched against live threat intelligence feeds with advanced IOC reputation scoring. IP reputation, domain categorisation, malware hash lookups, and CVE cross-referencing — all with weighted confidence based on source reliability and observation age.

Alert Deduplication

Noisy devices, misconfigured applications, and log storms are collapsed into single enriched cases. One thousand identical alerts become one case with a count — not one thousand queue items.

Data Loss Prevention

Sensitive data classification, exfiltration monitoring, and insider threat detection — integrated into Emily's triage pipeline and monitored by your named analyst.

Automated Threat Hunting

Ten automated threat hunting searches executed weekly against full telemetry: suspicious PowerShell execution, LOLBin spawning, LSASS access, credential dumping, persistence mechanisms, lateral movement, security log clearing, and Defender tampering.

SOC365 Integration

Fully integrated with the SOC365 detection engine — thousands of correlation rules, signature matching, anomaly detection, and behavioural analytics feed directly into Emily's analytical cluster.

Knowledge Management

Playbooks and runbooks.

EmilyAI maintains two distinct categories of operational knowledge document that together constitute her institutional memory. Understanding the distinction between them is essential to understanding how EmilyAI accumulates and applies operational knowledge over the lifetime of a deployment.

Playbooks

Human-Authored

Structured analytical frameworks created by the human analyst team. Each playbook defines the proposed approach to a specific class of security event — what telemetry sources should be prioritised, what correlation logic applies, what escalation criteria are appropriate, and what initial response actions are recommended.

  • Signal-Based Playbooks — Rule-scoped analytical workflows that define how a specific event class should be scored and dispositioned, with sequential evidence steps applying score adjustments.
  • Client-Based Playbooks — Higher-priority scoring adjustments for specific client organisations, accommodating client-specific risk tolerance, SLA requirements, and known environmental characteristics.
  • Auto-Generation — When a previously unseen rule ID is encountered and no playbook exists, EmilyAI generates a suggested initial playbook for the analyst team to review and refine.

Runbooks

EmilyAI-Maintained

Permanent operational records maintained by EmilyAI herself. Where a playbook defines intent, a runbook records what has actually happened: how processes have evolved in practice, what adjustments have been made and why, and what the cluster has learned from operational experience.

  • False Positive Records — Full context of every miscategorisation: triggering event sequence, analytical pathway, analyst determination, and the specific adjustment made to prevent recurrence.
  • Zero-Day Observations — When the cluster observes activity exhibiting structural characteristics of a potential zero-day, a runbook entry is preserved regardless of whether it crosses the escalation threshold.
  • Audit Trail — The accumulation of runbook entries over a deployment's lifetime creates a traceable history of analytical refinement — invaluable for regulatory audit and analyst onboarding.
“Neither document type can fulfil the other's function. A playbook without a runbook is an untested specification. A runbook without a playbook would be a record of ad hoc decisions without a principled framework. Together, they form a knowledge management system in which human expertise and machine operational experience reinforce each other continuously.”
— EmilyAI Platform Overview, v1.2
Operational Engagement

Human-AI symbiosis.

EmilyAI is explicitly designed for a symbiotic relationship with human security expertise. The cluster handles volume, consistency, and speed of first-line analytical processing; human analysts provide contextual judgement, proactive investigation, client knowledge, playbook authorship, and continuous feedback that the cluster cannot generate independently.

Ten Mandatory Analyst Interactions

Within deployments that pair EmilyAI with a named human analyst, ten mandatory analyst tasks are defined for every operational shift. These tasks codify the specific ways in which human analysts engage with, validate, and improve EmilyAI's output — and they illustrate the operational dependency between the neural cluster's analytical capability and the human expertise that contextualises it.

Continuous Feedback Loop

The cluster improves across four channels: miscategorisation feedback with runbook updates, suspected zero-day observation and runbook updates, threat hunting to rule and playbook development, and threat intelligence and watchlist updates. Every false positive escalation triggers both an analytical weighting adjustment and a permanent runbook record.

Automated Reporting

EmilyAI includes a comprehensive suite of automated reporting: end-of-shift handover reports, weekly summaries with threat hunting results, and client-facing documentation. All reports are generated programmatically from operational data — they do not require additional manual data collection.

SMB Deployment

Enterprise-grade security. SMB-ready.

In smaller business environments — organisations with between 10 and 100 endpoints — EmilyAI is deployed via a dedicated appliance positioned inline on the organisation's network. The appliance handles DHCP, provides centralised log aggregation, and connects the site's telemetry stream to the backend analytical cluster.

Zero Overhead

The organisation does not need to operate or maintain a SIEM, a separate log management platform, or any of the ancillary tooling that enterprise security operations typically requires. An optional Concierge Service provides on-site deployment in two to three days.

Baseline Maturation

In a 25-endpoint environment, behavioural baselines typically reach production-quality precision in four to six weeks. The ML alert scoring component requires a minimum of 50 classified alerts before its first model can be trained, with meaningful quality at 100–200 classifications.

Human Oversight

In smaller environments, each individual analytical judgement carries proportionately greater weight. The analyst's privileged account activity review is a critical compensating control — contextual knowledge that only a human can provide.

“Eight years later, it's the single best operational decision I've made as CEO. We spend less on SOC in a Box than we previously spent on the collection of tools it replaced — and we get immeasurably more.”
— Richard Magnus, CEO, Northcott Global Solutions
Development History

Eight years of continuous engineering.

EmilyAI's development began in 2018 with the creation of an initial neural analysis prototype, exploring whether a purpose-built neural network could replicate the contextual pattern recognition that experienced human security analysts apply when reviewing security telemetry. Every generation of the platform has been informed by production operational experience from its predecessor.

2018

Neural Analysis Prototype

Initial neural analysis prototype created — exploring purpose-built neural networks for contextual pattern recognition in security telemetry. Basic deduplication and IP reputation enrichment become operational.

2019–2020

Behavioural Modelling Networks

Behavioural analytics engine developed. Emily begins learning baseline activity patterns per entity — users, devices, service accounts, and network segments. False positive rates drop significantly as baselines mature.

2021–2022

Neural Pattern Recognition & Feedback Loops

Pattern recognition networks trained on historical attack sequences. Analyst feedback mechanisms integrated — creating closed-loop learning. Multi-dimensional priority scoring deployed across enterprise clients.

2023

SOC in a Box Integration

EmilyAI becomes a core component of SOC in a Box — the managed SOC product designed for UK SMBs. Named analyst plus autonomous AI triage becomes the standard operating model.

2024

ML Scoring & Correlation Engine

Machine learning alert scoring component introduced (v2.1.1). Advanced Signal Correlation Engine added with multi-stage attack detection, campaign tracking, and partial sequence alerting.

2025

DLP, UEBA & Attack Surface Monitoring

Data Loss Prevention, User and Entity Behaviour Analytics, and external attack surface monitoring introduced. 92% noise elimination rate achieved and sustained across all deployments.

2026

v2.3.0 — Current Release

Comprehensive exception handling, UEBA with impossible travel detection, advanced IOC reputation scoring, and signal catalogue-driven correlation. Processing 2.25M+ events/sec with full analytical depth.

Important Distinction

What EmilyAI is not.

Not an LLM or Generative AI

She does not understand or generate natural language, does not hold knowledge beyond her security telemetry domain, and does not reason in the way that conversational AI systems do. Her outputs are structured analytical products — confidence scores, event classifications, and incident reports assembled from templated structured fields.

Not a Replacement for Analysts

EmilyAI's design explicitly acknowledges categories of analytical judgement that require human intelligence — contextual knowledge of a specific client environment, business-hour awareness, hypothesis generation for proactive threat hunting, and the advisory relationship between a security team and the organisation it protects.

Not a Decision-Making System

EmilyAI produces structured escalations and recommended response actions, but does not autonomously execute containment or remediation without human authorisation. Every escalation that leaves the SOC is a human decision, made by a named analyst.

Not a Static Rule Engine

EmilyAI's neural behavioural models enable detection of adversary techniques that have not been explicitly encoded into any rule — including novel attack methods and living-off-the-land techniques that produce no signature match but generate measurable behavioural anomalies.

Transparency

Known limitations and boundaries.

EmilyAI's design documentation is explicit about the boundaries of the cluster's capability. These are not deficiencies to be engineered out — they reflect deliberate architectural decisions about which analytical functions require human intelligence and should not be automated.

Contextual Business Knowledge

The neural cluster has no representation of an organisation's business context. An escalation that represents a genuine incident in one context may be entirely expected business activity in another. Only the human analyst can make that distinction.

Genuinely Novel Attack Techniques

A sufficiently novel attack that produces no behavioural anomaly, matches no known structural patterns, and generates no threat intelligence correlation may not be detected until measurable signals accumulate. Proactive human threat hunting is the primary compensating control.

Residual Miscategorisation Rate

Escalation quality is high but not perfect. A small proportion of false positives and missed detections are expected and accommodated. Every reported false positive triggers both a weighting adjustment and a runbook update — the miscategorisation rate declines progressively over a deployment's lifetime.

Log Source Dependency

The cluster can only analyse telemetry that reaches it. A log source that stops feeding data creates a blind spot. The log source health check is a mandatory analyst task precisely because a gap in data inputs is functionally equivalent to a gap in the security perimeter.

Future Direction

What comes next.

EmilyAI's development roadmap describes principal capability areas under active development, building on the substantial capability base established in the v2.3.0 release.

Autonomous Threat Hunting

The cluster itself will generate and evaluate hunting hypotheses — identifying structural gaps in current detection coverage and initiating targeted queries against the telemetry data store. This supplements, not replaces, human-led threat hunting.

Predictive Attack Modelling

Given an observed early-stage indicator, predictive networks will estimate the most probable subsequent stages of an attack chain and recommend pre-emptive defensive actions — evolving from detecting what has happened to anticipating what is likely to happen next.

Automated Response Integration

Deeper integration with response orchestration platforms to trigger specific containment actions — endpoint isolation, credential revocation, network path blocking — subject to policy-defined human approval thresholds.

Infrastructure Maturity

Formal containerisation support (Docker and Kubernetes), Redis-backed distributed coordination for multi-instance horizontal scaling, Prometheus metrics, ELK stack integration, and automated database replication and backup.

FAQ

Frequently asked questions.

EmilyAI is a neural network computing cluster with embedded machine learning structures — fundamentally different from a large language model or generative AI system. She operates exclusively on structured numerical security telemetry, produces deterministic and auditable analytical outputs, and has no capability outside the security event analysis domain. The cluster comprises four parallel analytical components: behavioural modelling networks, a rule-based detection engine, neural pattern recognition networks, and a threat intelligence correlation layer.

Useful triage begins immediately — EmilyAI starts with generic industry baselines for your sector and begins learning from the first telemetry. Within two weeks, false positive rates drop to highly actionable levels. In smaller environments (10–100 endpoints), behavioural baselines typically reach production-quality precision in four to six weeks. The ML scoring component requires a minimum of 50 classified alerts before training its first model, with reliable quality at 100–200 classifications.

No. EmilyAI is an augmentation layer — an autonomous first-line analyst that handles the volume, consistency, and speed of triage so that human analysts can focus on threats requiring judgement, investigation, and contextual business knowledge. Ten mandatory analyst tasks are defined for every operational shift, codifying the specific ways humans engage with, validate, and improve EmilyAI's output. Every escalation is a human decision.

Through four feedback channels: miscategorisation feedback that adjusts neural network weighting parameters, suspected zero-day observations preserved in runbooks, threat hunting findings that generate new detection rules and playbook updates, and threat intelligence updates to the correlation layer's watchlists. Every false positive triggers both an analytical adjustment and a permanent auditable runbook record.

Playbooks are human-authored structured analytical frameworks that define how specific security event classes should be handled. Runbooks are permanent operational records maintained by EmilyAI herself — recording what actually happened, what adjustments were made, and what the cluster learned. Together they form a knowledge management system where human expertise and machine operational experience reinforce each other.

Currently, EmilyAI is exclusively available as part of SOC in a Box and Cyber Defence's managed SOC services. She is not sold as a standalone product — because triage without an analyst to act on the results is only half the solution.

All telemetry is processed within the SOC365 platform. EmilyAI does not send data to third-party AI services. All processing occurs within Cyber Defence's infrastructure, subject to the same data protection controls, certifications, and contractual safeguards that apply to the wider SOC service.

The 92% figure is the median false positive / noise suppression rate measured across all SOC in a Box deployments over a rolling twelve-month period. It represents alerts that would have reached an analyst under a traditional system but are correctly identified by EmilyAI as benign, duplicate, or low-priority — freeing analyst time for genuine threats.

The decision engine aggregates outputs from all four analytical components into a single confidence score per event. Events receive one of three dispositions: Dismiss (~92% of volume), Monitor (active observation with automatic re-evaluation), or Escalate (structured incident report generated for human analyst review). False positive history is checked before thresholds are applied — known-benign events are suppressed with engineering notification.

See EmilyAI in action.

Book a 30-minute scoping call. We'll walk you through how EmilyAI's neural network cluster processes security telemetry, how the analytical pipeline works, and how SOC in a Box replaces your piecemeal security spend with a single, analyst-led service.

Book a Scoping Call Learn about SOC in a Box

No obligation · 30 minutes · We'll name your analyst on the call