EdgeGuard: SLM/GraphRAG Edge Intelligence
General
Stories from the Golden Stack
At 02:17, a SOC analyst does not get a story. She gets fragments.
A Wazuh lateral-movement alert lands first. Then a CVE record. Then a MITRE ATT&CK technique. Then an indicator from a threat-intelligence feed. The analyst has to decide whether this is routine noise, credential abuse building toward ransomware, or an attack chain already moving across a healthcare zone.
EdgeGuard starts there: with an analyst who needs a defensible explanation before the alert queue moves on. The project idea is simple to say and hard to build: use a Neo4j knowledge graph, MISP and other open CTI sources, and a small language model to turn alert fragments into an evidence-backed case file.
ResilMesh sets the project context. The EU-funded Innovation Action builds cyber situational awareness and security orchestration for dispersed, heterogeneous cyber systems. EdgeGuard was accepted under ResilMesh Open Call 2, Challenge C2, the track for new analytic algorithms and architectures. In that setting, EdgeGuard has to do more than explain a graph demo. It has to help distributed security teams turn messy alerts into traceable cases.
Ratio1 already announced the collaboration in EdgeGuard: Where Explainable Cybersecurity Meets Edge Reality. The approved proposal gives the project its spine: IICT-BAS leads the GraphRAG, explainability, dataset, and reproducibility work; Ratio1 brings decentralized edge infrastructure, deployment, validation, and the route toward an operational service.
Following Ratio1's initial EdgeGuard announcement, this article marks Sprint 1 finalization. It also opens a short EdgeGuard series: more articles will follow as Sprint 2 moves into SLM/GraphRAG validation, production-baseline work, and ResilMesh integration. The R1 deliverable was submitted on April 29, 2026 and gives the project its first implementation checkpoint: the graph foundation is in place, the ingestion and query substrate works at Sprint 1 scope, and the ResilMesh integration plumbing has started to connect to real workflows. Formal benchmarking, consortium acceptance, SOC-user validation, and the machine-learning layer still sit in later gates.
The short version
EdgeGuard is designed to sit beside the tools a SOC already uses. It listens to the alert stream, pulls threat context from the graph, and hands the analyst a compact answer with evidence attached.
The graph answers the questions analysts already ask under pressure: which CVEs matter here, which techniques fit this behavior, which malware families or campaigns have similar paths, which indicators have source support, and which sector-specific risks change the priority?
The SLM does not have to pretend it knows cybersecurity from memory. Its job is narrower: translate the analyst's question, retrieve the right subgraph, summarize the evidence path, show confidence and caveats, and suggest the next check. Sprint 1 did not try to finish that model layer. It built the graph substrate the model will need in Sprint 2.
The IICT-BAS x Ratio1 split
The public IICT-BAS project page describes EdgeGuard as "Graph-Augmented xAI for Threat Intelligence on Edge Infrastructure" and names Ratio1 as the partner providing specialized edge cloud capabilities and commercial expertise. The accepted proposal says the same thing in project language.
IICT-BAS owns the research-heavy part of the problem: graph schema design, CTI normalization, reasoning-path extraction, SLM evaluation, explanation faithfulness, open-science artifacts, and reproducibility. This work decides whether EdgeGuard can show its evidence trail when it answers.
Ratio1 owns the part that decides whether the method can leave the lab: containerized deployment on edge nodes, node identity and access, distributed storage for larger artifacts, NATS-style messaging, validation on real infrastructure, and service packaging. That is the industry contribution. It turns a promising research method into something a security team can test.
ResilMesh is the operating context
ResilMesh gives EdgeGuard a concrete place to land. The accepted proposal positions EdgeGuard as an extension of the ResilMesh Security Applications / Threat Awareness layer. The core problem starts after alert generation. Security teams already have alerts.
The gap sits after detection. A Wazuh or Suricata alert can tell an analyst that something happened. EdgeGuard is designed to connect that event to CVE and KEV context, MITRE ATT&CK techniques, known IOCs, sector relevance, and graph paths that explain why the alert matters. In the proposal language, EdgeGuard fills the "alert enrichment gap."
The Sprint 1 deliverable makes the ResilMesh link more concrete. EdgeGuard now follows a shared-database integration pattern: ResilMesh topology nodes and EdgeGuard intelligence nodes can sit in the same Neo4j instance, with EdgeGuard-created nodes marked by edgeguard_managed=true. That gives an analyst a practical path from a ResilMesh-observed host to threat actors, CVEs, malware, sectors, and recent indicators without leaving the graph.
The stack: Neo4j x MISP x SLM
The stack reads less like a moonshot and more like SOC plumbing with an explanation layer:
MISP is the source of truth for raw observations, timestamps, and audit trail.
Neo4j stores CTI entities and relationships as the linked intelligence layer.
GraphRAG retrieves the relevant subgraph for a given alert or analyst question.
A quantized SLM turns that subgraph into a short narrative, with citations, confidence, caveats, and next checks.
ResilMesh/NATS-style messaging routes alerts and zone updates.
Ratio1 infrastructure runs the system at the edge and can preserve larger artifacts through R1FS.
The ResilMesh integration drives the workflow. The proposal names NATS topics for threat updates, CVE/KEV enrichment, and Wazuh alert ingestion, including resilmesh.threats.zone.<zone_id>, resilmesh.cve.kev, and resilmesh.alerts.zone.<zone_id>. The Sprint 1 deliverable says the alert processor and zone-based publishing are now implemented at integration-point level, while production-grade subscriber management and multi-zone hardening move into Sprint 2.
The Sprint 1 report also clarifies the ingestion chain: 11 CTI collector modules feed MISP, MISP feeds Neo4j, and Neo4j feeds enrichment jobs plus REST and GraphQL APIs. Six Apache Airflow DAGs orchestrate scheduled ingestion, reconciliation, and the full-window historical load.
Sprint 1: the graph substrate exists now
The February Ratio1 announcement framed EdgeGuard as an active R&D effort. The Sprint 1 deliverable shows what moved from plan into working substrate.
The four Sprint 1 goals from the accepted proposal are marked implemented under internal IICT-BAS and Ratio1 validation: knowledge-graph schema and initial population, automated Airflow-managed ingestion, REST and GraphQL query interfaces at Sprint 1 scope, and ResilMesh integration setup through NATS, shared schema work, and STIX 2.1 export. The report keeps a clear boundary: internal validation remains separate from formal ResilMesh consortium acceptance.
The accepted proposal required at least five key threat sources and a demonstration milestone of at least 50,000 entities. The Sprint 1 codebase integrates 11 collector modules. The 2026-04-23 internal closing run exercised seven sources end to end: NVD, CISA KEV, MITRE ATT&CK, AlienVault OTX, URLhaus, SSL Blacklist, and Feodo Tracker. That run produced 251,203 zone-tagged nodes and 252,105 SOURCED_FROM relationships.
Those counts are not vanity metrics. Indicators give the graph breadth. CVEs and CVSS nodes give it patch context. Malware, actors, techniques, sectors, and sources give Sprint 2 something stricter than a text blob to retrieve from. Healthcare, finance, energy, global, and multi-zone tags are all represented, so the next phase can ask harder questions about retrieval quality, explainability, and model behavior.
Graph paths beat raw scores
SOC reasoning depends on relationships.
An off-hours server access event means little by itself. A known threat-actor IP changes the reading. A related CVE changes patch priority. A MITRE ATT&CK technique changes the incident story. A weak source should lower confidence; two independent feeds should raise it.
The approved proposal uses exactly this kind of chain: unexpected server access outside normal hours, a known threat-actor IP, lateral-movement TTPs, malware families, and related CVEs. EdgeGuard's graph model is designed to keep those links inspectable through paths, provenance, and confidence.
The Sprint 1 report gives concrete query examples. One SOC-style traversal asks which threat actors operate across healthcare, finance, and energy; it returns 78 nodes and 509 relationships and surfaces 68 threat actors plus malware families such as AntSword, ValleyRAT, and Winos4.0. A sector-specific vulnerability query asks which high-severity CVEs affect healthcare infrastructure; it returns 75 CVEs ranked by CVSS v3.1 score.
The appendix narrows the lens further. A cross-sector actor query against the Sprint 1 baseline returns nine actors tagged in all three target sectors in 129 ms. A four-hop trace from Indicator to Malware to ThreatActor to Technique returns 400 paths in 39 ms on the internal-test instance. Those timings are smoke-test signals; formal p50 and p95 measurements are planned for Sprint 2 and Sprint 3.
Small models, close to the data
The project proposal targets 1B to 8B parameter SLM/LLM models, quantized to INT4 or INT8, with an edge baseline of up to 6 logical CPU cores and 16 GB RAM. The performance targets include p95 end-to-end responses of two seconds or less for short analyst queries.
Sprint 1 did the unglamorous work that makes that target plausible later: stable node identifiers across environments, deterministic graph links, MISP-event back-pointers, SOURCED_FROM provenance, preflight checks, smoke tests, and an operator CLI. The model layer arrives in Sprint 2, when the team curates the question-and-answer dataset, fine-tunes a 1-to-8B-parameter model, quantizes it for edge deployment, and starts structured explainability testing.
The model has a bounded job. EdgeGuard needs a smaller model that can:
translate analyst questions into graph queries,
summarize evidence paths,
keep answers within retrieved sources,
surface uncertainty,
run near sensitive data without a mandatory cloud dependency.
The graph carries the knowledge. The model handles interaction, phrasing, and task-specific reasoning over retrieved evidence. In this setup, smaller is not a compromise by default. It is a way to keep the model close to the data and close to the operational constraints.
Where decentralization earns its keep
The blockchain part can get noisy fast, so keep it operational.
EdgeGuard benefits from decentralization in three places. Edge-local analysis reduces the need to push sensitive telemetry into a central cloud. Distributed orchestration can keep services available across multiple nodes and zones, so one control plane does not carry the workflow alone. Tamper-evident records can help show which model version, graph snapshot, deployment, or configuration was active during an investigation.
Ratio1 has been building this argument across several articles. The Decentralized Resilience piece frames Ratio1 around data sovereignty, reduced control-plane concentration, and cryptographic identity. The RedMesh line shows the same cybersecurity instinct from the offensive-testing side: distribute work, keep evidence verifiable, and avoid one brittle scanner. The Sovereign AI article makes the AI-side case for keeping sensitive inference, adapters, and retrieval under the operator's control.
For EdgeGuard, the deployment story has to be as disciplined as the model story. AI answers stay bounded by graph evidence. Cybersecurity data can stay closer to the environment that produced it. The blockchain layer handles concrete operational jobs: auditability, identity, and orchestration.
The analyst-facing answer
A good EdgeGuard answer should read like a short case note:
Wazuh raised a lateral-movement alert in a healthcare zone after unusual access activity. EdgeGuard found a path from the affected asset to related CVEs, MITRE ATT&CK techniques for remote services, and indicators from current CTI feeds. Source support is mixed: the IOC has feed support, but actor attribution remains low-confidence. Check recent authentication attempts, review neighboring hosts for lateral movement, and prioritize exposed services with high CVSS or KEV status.
The wording will change by deployment, but the structure should hold:
what happened,
what graph path supports the interpretation,
which sources support each hop,
what is inferred,
what the analyst should check now.
The Sprint 1 report gives a low-level version of the same idea. A query such as "show me how fox kitten gets in" should compile in Sprint 2 to a deterministic four-hop pattern: Indicator -> Malware -> ThreatActor -> Technique. The analyst should be able to inspect every hop and pivot back to MISP evidence through misp_event_ids.
The road ahead
EdgeGuard remains in active development. Sprint 1 delivered the graph substrate: schema, ingestion, query APIs, enrichment jobs, operator tooling, NATS integration points, STIX 2.1 identifier alignment, and shared-database integration with ResilMesh.
The team now has to run the 730-day production-test baseline on Ratio1 infrastructure, harden production NATS routing, build the Q&A dataset, test graph embeddings, and move natural-language-to-Cypher conversion from demo behavior to measured behavior. The SLM layer also needs a strict contract: answer from graph paths, expose confidence and provenance, and refuse to invent missing context.
A working graph still leaves product work before analysts can depend on the system. EdgeGuard needs source normalization, verified MISP event pivots, confirmed campaign enrichment in the next baseline run, Phase A explainability tests, latency and quality benchmarks, and SOC-user validation. ResilMesh integration also has to move from shared schema and integration points toward workflows that operators can trust under zone-specific alert pressure.
The project also has the normal CTI problem: source quality varies, indicators decay, feeds disagree, and a graph can only explain what the data model preserves.
That constraint is healthy. The proposal already treats source noise, schema drift, hallucination checks, and analyst validation as engineering problems. EdgeGuard earns trust only if it keeps those problems visible.
Why this is a Ratio1 story
EdgeGuard illustrates the role assigned to Ratio1 in the accepted proposal: edge deployment, validation, and commercialization for graph-grounded cybersecurity AI.
The mix is unusual:
decentralization for placement, resilience, identity, and auditability,
SLMs for edge-friendly reasoning and analyst interaction,
Neo4j and MISP for structured threat intelligence,
GraphRAG for evidence-bounded explanations,
cybersecurity as the forcing function that keeps the architecture honest.
Sprint 2 makes the Ratio1 part more visible. The immediate next operator action in the R1 report is a 730-day production-test baseline launch on Ratio1 infrastructure. That run is meant to exercise all 11 collectors across a 24-month historical window and produce the graph state used for Q&A dataset curation, Phase A explainability testing, and the first formal latency and quality benchmarks.
Cybersecurity keeps the architecture honest. If an analyst cannot trace the reasoning, the answer will not survive incident review. If the system cannot run near sensitive environments, the buyer will push it back into another central cloud silo. If the audit trail cannot show what ran, the result will be hard to defend.
That is the Ratio1-specific bet here: do not centralize the data just to explain it, and do not let a model invent context the graph cannot prove. Make the edge node, the graph, the message bus, and the audit trail carry part of the trust story.
Funding acknowledgement
EdgeGuard is developed in the context of the ResilMesh project, funded by the European Union. The article reflects the authors' interpretation of the project work and does not represent the official position of the European Union, the European Commission, or the ResilMesh consortium unless explicitly stated.
Petrica Butusina
