When nothing looks wrong, but something is

A workstation in the finance department runs a command that looks like routine administration. A few minutes later, the same machine connects to a server it rarely talks to, a user account quietly gains new privileges, and an outbound connection carries slightly more data than usual. Each event on its own is unremarkable, and each one appears in a different security tool. Taken together, they may describe an attack in progress.

This is the core challenge of anomaly detection in a financial institution. The signals exist, but they are scattered across heterogeneous systems, buried among millions of legitimate events and rarely labelled. Rules catch what has been seen before, while everything else depends on an analyst connecting the dots in time.

What we are developing

Within CyberAId, the University of Piraeus Research Center (UPRC) leads the work on data protection and anomaly detection and, in collaboration with CaixaBank, is developing an AI agent for anomaly detection in banking environments. The agent is designed to work on the security telemetry that financial institutions already collect (e.g. endpoint, network, web, email and access logs) and to learn what normal looks like for the users, hosts and services of an organisation, so that meaningful deviations can be surfaced early and explained.

Since such telemetry is sensitive, the approach is designed with privacy in mind: it operates on anonymised data, it can run within the boundaries of each institution, and it does not depend on large volumes of labelled attacks, which are rarely available in practice.

An ensemble of models and agents

Rather than relying on a single model, we are building an ensemble in which machine learning models and LLM agents each do what they are good at (Figure 1).

• Machine learning detectors learn behavioural baselines for users, hosts and services and score deviations from them, such as unusual connection patterns, rare process activity or atypical access behaviour. Unsupervised and semi-supervised methods keep the approach usable where labels are scarce.
• LLM agents read what numbers alone cannot capture, such as commands, alert descriptions and messages. They recognise intent (e.g. obfuscated scripts, credential access or the staging of data for exfiltration) and map it to MITRE ATT&CK techniques, producing structured, evidence-backed signals rather than free text.
• An ensemble layer fuses these signals across sources and over time, linking activity that belongs to the same user or device, so that a weak signal in one place becomes meaningful when it is corroborated elsewhere.

On top of the ensemble sits an LLM analyst agent that turns scores into findings. It assembles the correlated evidence into an incident narrative along the attack chain, explains why the behaviour is anomalous, attaches the supporting events and the ATT&CK mapping, and recommends next steps. In line with the CyberAId design, the agent operates within strict access and audit boundaries and never acts on its own: its findings feed the platform’s log correlation and are reviewed by security analysts through the human-in-the-loop conversational interface.

How it connects with email threat detection

The same philosophy drives EMTD, the email threat detection agent presented in our previous post. Since then, EMTD has grown into a catalogue of 69 detection components, including a dedicated family of financial process checks such as changed IBANs and wire instructions. It is now integrated into the CyberAId platform and produces explainable findings, in which quarantine and block recommendations require an analyst’s approval. Email is one of the channels the anomaly detection agent observes, which makes the two agents natural companions: a suspicious message and unusual activity on a workstation can be read as parts of the same story.

Where we are and what’s next

We are currently building the detectors and the ensemble layer, and, together with CaixaBank, designing an evaluation based on realistic attack scenarios that measures how early an attack is detected and how many alerts an analyst would actually need to review. Next, the LLM analyst agent will be connected to the CyberAId platform. Looking further ahead, we plan to explore privacy-preserving and federated learning, so that financial institutions can benefit from each other’s detection models without sharing their data.

 

An email arrives at a financial institution asking an employee to change a supplier’s payment details. The message looks familiar, but a security tool flags it as suspicious. Is it a genuine request, an attempted fraud, or an early sign that an account has been compromised? A related challenge is explored in CyberAId’s post on client impersonation in wealth management.

This illustrative example shows why an alert is only the beginning of an investigation. A security team may need to examine the message, check related activity and understand the consequences for the business before deciding what to do.

CyberAId is developing an approach to help bring those pieces together. Its design for coordinating AI agents sets out how specialised assistants should work with security tools and present evidence-based recommendations to people. The aim is to give analysts a clearer picture of an incident while keeping consequential decisions subject to appropriate review.

Bringing the right expertise together

An AI agent is a software assistant that can use tools and follow up on what it finds. In cybersecurity, one agent might examine suspicious emails, while another looks for unusual activity in system records. Each has a defined role.

CyberAId’s design includes a coordinator that directs work to the relevant specialists and brings their findings together. The coordinator manages the investigation; detailed analysis belongs to the specialists.

In our email example, an email specialist could examine signs of impersonation or a malicious link. A specialist reviewing system activity could look for related events, such as an unusual login. These are different questions about the same potential incident. Connecting their findings gives an analyst more context than an isolated warning.

The design also allows one investigation to lead to another. If an initial check raises a new question, the relevant specialist can be asked to follow it up. This reflects how security teams already work: each piece of evidence helps determine what to examine next.

Showing the evidence behind the recommendation

A nicely written explanation can sound convincing even when it is wrong. For this reason, CyberAId’s design asks agents to return findings that connect their conclusions to the evidence they examined.

For the suspicious email, a useful finding should explain what raised concern and point to the supporting records. It should also identify which agent produced the assessment and how confident it is. An analyst needs enough information to check the recommendation, challenge it and decide whether further investigation is necessary.

Sensitive information also needs boundaries. The proposed design limits which information an agent may access and uses references to evidence rather than copying the underlying material into every finding. This is intended to help keep an investigation traceable while limiting unnecessary duplication of confidential data.

Disagreement remains visible. If one specialist finds little cause for concern while another identifies a serious warning sign, the design calls for both assessments to reach a human reviewer with their evidence. That disagreement may be exactly what deserves closer attention.

Helping people decide what happens next

Different actions carry different consequences. Looking up a threat indicator is a routine investigative step. Restricting access to a business system can disrupt legitimate work.

CyberAId’s proposed review approach takes that difference into account. Routine, reversible checks can proceed automatically, while actions with greater impact require human approval. The review level also considers the seriousness of the finding and the agent’s confidence. High-impact actions require approval regardless of how confident an agent claims to be.

Analysts can reject or correct recommendations, and the design records those decisions alongside the findings. The same evidence can then support reporting. A reporting agent is intended to turn validated findings into an incident account or management summary, with conclusions that remain connected to their sources.

Turning research into a testable design

This work draws on CyberAId-supported research into large language model agents for cybersecurity. Our systematic review examined 59 studies and found promising examples of coordinated agents, alongside limited evidence for financial-sector use. None of the reviewed studies reported evaluation in a live production environment under the review’s highest evaluation category.

Those findings help explain the project’s emphasis on evidence and review. They also underline the need to test the proposed workflows carefully. An architecture can specify how an investigation should proceed; practical evaluation must establish whether it helps analysts, how it handles errors and whether its recommendations are useful.

CyberAId’s ongoing work is moving towards implementation and evaluation of this shared approach. For a security team handling an uncertain alert, the intended benefit is concrete: understand what was found, see why it matters and make an informed decision about the next step.

Related publication: LLM-Based Agents for Cybersecurity (open-access paper)