Anomaly detected. Coordinated voltage drop pattern across 8 sensors in distinct zones. Classification: possible security event, high severity. Consistent with external interference. Detail in attached report.
AGENT · SCADA ANOMALY WATCHER
SCADA anomalies surface before the fault or the attack.
SCADA Anomaly Watcher monitors the customer's SCADA systems in real time. It identifies patterns consistent with incoming technical faults (sensor drift, parameters outside forecast range) or with security intrusions (anomalous communication patterns, unexpected commands). Immediate alert to the security team or operations.
SCADA Anomaly Watcher at work.
Checking now. Were IT stress tests scheduled this afternoon?
Separately: sensor drift on substation X over the past 7 days — medium severity, calibration required. Alert to operations team on a separate channel.
Confirmed: authorised IT test, false positive. Closing with reason. Substation X is for operations to handle.
Why it exists.
SCADA systems are the nerve centre of utility network monitoring and control. Data volumes are massive: thousands of sensors sending real-time readings, commands to remote devices, logs of every operation. Continuous human monitoring is not viable at that scale; early anomalies — a sensor drifting, a communication pattern consistent with an intrusion attempt — pass unnoticed.
How it streams the data.
SCADA Anomaly Watcher reads the customer's SCADA stream continuously. For each data stream it compares against expected patterns based on the configured baselines, identifies technical anomalies (sensor drift beyond threshold, event sequences consistent with an incoming fault) and security anomalies (anomalous communication patterns, unexpected commands, out-of-hours access or access from unrecognised addresses).
Intervention stays with the team.
The alert goes to the operations team (technical anomalies) or the security team (security anomalies) on the configured work channel. The decision to act — isolating a zone, blocking a command, activating the cybersecurity emergency plan — stays with the operations team or the CISO.
The functions that monitor the network and the utility's security posture.
Network operations manager
Recovers continuous monitoring capacity — not viable manually at real-world data volumes. Technical anomalies arrive early, before the fault, leaving room for preventive action: calibration or maintenance.
SCADA · live 2 anomalies
Substation SE-104 voltage out of range
Line LV-22 current spike
NIS2 classify material · 24h timer
Alert to CISO · ticket opened
CISO or head of cybersecurity
Gets continuous monitoring of security patterns across SCADA systems. NIS2 classifies most utilities as operators of essential services, with specific detection and incident response requirements.
Ongoing outage ETA 35'
Zone Northeast cluster B
Field team 3 crews · in transit
Customer SLA reset · 20'
Regulator report in preparation · 4h
Compliance officer
Has the inspectable trace of identified anomalies, team decisions, and outcomes for NIS2 audit. Every alert, every classification, every outcome is in the registry, readable with a standard SQL client.
14-day forecast 48 sections
MV-North section high
MV-East section medium
Assets > 25 years 12 replacements
Weekly maintenance plan
Two anomalies detected simultaneously, two teams alerted in parallel.
Two anomalies in parallel.
For an energy utility with a regional distribution network, the agent is integrated with the SCADA system via a dedicated adapter. At 14:00 the agent identifies two anomalies in parallel. The first: a voltage reading sequence across eight sensors in different zones shows a coordinated drop consistent with external interference. The second: readings from a single sensor at substation X show constant drift over the past seven days.
Distinct channels for security and operations.
The agent activates two separate alerts on distinct channels. To the security team: classification 'possible security event, high severity' with a summary of the affected sensors and historical series. To the operations team: classification 'calibration required, medium severity' with the sensor's reading history.
False positive closed, maintenance scheduled.
The security team checks the network logs, recognises an IT-team-authorised stress test as the cause of the anomalous pattern, and closes the alert as a false positive with documented reason. The operations team schedules calibration maintenance for substation X. The full event — anomalies, decisions, outcomes — stays in the audit registry for NIS2 inspection.
Declarative technical and security baselines, versioned by the operations team and CISO.
SCADA Anomaly Watcher's rules are declarative. The utility's operations team and CISO define in readable format the technical baselines for sensors and systems, recognised security patterns (based on NIS2 and sector frameworks), and alert thresholds by severity. Rules live in the customer's repository, versioned, and validated at agent startup. Integration with the utility's SCADA systems is built during delivery via a dedicated adapter (OPC UA, Modbus, or equivalent), subject to security policy validation with the CISO and the Delivery team. SCADA systems are often isolated for security reasons (air gap or strict segmentation): the integration pattern compliant with NIS2 policy is defined during commercial discovery.
- Language
- TypeScript (Node.js)
- LLM model
- customer's choice: Anthropic, OpenAI, Mistral, open source models hosted internally, AWS Bedrock for a private model
- Built-in controls used
- pii-detector, credential-detector, prompt-injection, tool-rate-limit
- Native notification channels
- Slack, Telegram, OpenAI-compatible HTTP
- SCADA system integration
- dedicated adapter built during delivery (OPC UA, Modbus, or equivalent); subject to security policy validation with utility CISO and Delivery team (air gap or strict segmentation possible)
- Technical and security baselines
- declarative, versioned, written by the operations team and CISO
- Memory
- persistent per instance, pgvector + PostgreSQL FTS on historical SCADA patterns
- Registry
- append-only, queryable with a standard SQL client (NIS2 audit-ready)
Frequently asked questions about the agent.
No. The agent identifies anomalies and sends alerts to the customer's team. The decision to act on SCADA systems — isolating a zone, blocking a command, activating the cybersecurity emergency plan — stays with the operations team or the utility's CISO, following established procedures.
For utilities with an external or separately managed Security Operations Centre, security alerts can be routed to the SOC as part of the existing security pipeline. Integration is built during delivery with the Exelab team, coordinated with the utility's CISO for NIS2 compliance.
The typical pattern is 14-22 weeks — longer than average because of the complexity of the SCADA integration and the security policy assessment. Discovery 3-4 weeks, baseline construction with the customer's historical data 4-6 weeks, SCADA integration with security assessment 5-8 weeks, hand-off to the team 2-4 weeks. Actual duration is defined in discovery after mapping the network topology and the utility's NIS2 policies.
From a 30-minute conversation to the squad in production.
A 30-45 minute conversation to understand how SCADA Anomaly Watcher would configure to the customer's network. Which SCADA system, which technical baselines, which NIS2 perimeter.