---
title: 'OntoLogX: Ontology-Guided CTI from Cyber Logs'
url: https://www.emergentmind.com/topics/ontologx
type: topic
---

# OntoLogX: Ontology-Guided CTI from Cyber Logs

Searching arXiv for the OntoLogX paper and closely related ontology-centric context papers.
Search query: `ti:"OntoLogX" OR 2510.01409`
OntoLogX is an autonomous Artificial Intelligence (AI) agent for transforming raw cybersecurity logs into ontology-grounded Knowledge Graphs (KGs) and then using those graphs to infer higher-level Cyber Threat Intelligence (CTI), specifically MITRE ATT&CK tactics. It is designed for a setting in which system logs are rich in attack evidence but difficult to use directly because they are noisy, heterogeneous across systems and formats, semantically inconsistent, and fragmented across devices and sessions. OntoLogX addresses that problem by combining Large Language Models (LLMs) with a lightweight cybersecurity log ontology, Retrieval Augmented Generation (RAG), SHACL-based validation, and iterative correction, producing validated event-level KGs that can later be aggregated by session for tactic prediction [2510.01409].

## 1. Problem formulation and operational scope

The central motivation for OntoLogX is that logs capture attacker behaviors, exploited vulnerabilities, and traces of malicious activity, but crucial information such as IPs, users, processes, commands, timestamps, or authentication outcomes is rarely expressed in a uniform way. Reconstructing an attack scenario therefore requires reconciling scattered low-level traces into a coherent representation. OntoLogX is explicitly positioned as an attempt to automate that reconciliation directly from raw logs, without requiring heavy preprocessing or user interaction [2510.01409].

Its input is a raw log event plus optional free-form contextual information such as device, operating system, process, or honeypot version. Its primary output is an event-level KG grounded in the paper’s custom ontology. These event-level KGs are then grouped by session, and a second LLM predicts one or more MITRE ATT&CK tactics for each session. The end-to-end workflow is: raw log event arrives; the system retrieves semantically/textually similar previously stored KG examples; an LLM generates a structured candidate graph under ontology guidance; the output is validated syntactically and semantically and checked against ontology constraints; if invalid, the model is iteratively prompted to repair it; the validated event KG is stored in a graph database; later, KGs belonging to the same session are aggregated and fed to a tactic-prediction LLM [2510.01409].

Two claims define the system’s identity. It is “ontology-guided” because extraction is constrained by an explicit ontology and SHACL validation rules, which determine legal entity types, relations, and structure. It is “autonomous” because retrieval, generation, correction, storage, and tactic prediction are all agentic steps within one pipeline with no user intervention. A common misconception is that “autonomous” here implies unconstrained free-form summarization; in fact, the design is centered on constrained structured generation, validation, and repair rather than unconstrained narrative output [2510.01409].

## 2. Ontology architecture and constraint system

OntoLogX introduces a lightweight ontology as a middle ground between minimal log models and very broad cybersecurity ontologies. The paper argues that minimal log models such as SLOGERT’s are too weak for CTI extraction, while broad ontologies like UCO are too complex for reliable direct LLM generation from raw logs. The ontology is therefore compact but expressive, tailored to common concepts that appear in cybersecurity logs [2510.01409].

The class `Event` represents a single log entry. Each event is linked to a `Source`, representing the device or application that emitted the log. `Event` and `Source` are aligned with provenance standards by mapping them respectively to `prov-o`’s `Entity` and `Agent`. Information contained in the logs is modeled through subclasses of `Parameter`, including a dedicated `TimeStamp` aligned with the W3C time ontology. More complex nested structures are also supported: an `Application` parameter may reference other parameters, allowing the ontology to model application-call arguments or chains of calls. User-related information is captured through `UserCredential`, with specialized subclasses for username, email, and password. The ontology emphasizes use of the “most specific type available,” so `UserPassword` is preferred over the more generic `UserCredential` [2510.01409].

This ontology is coupled with SHACL constraints. Validation checks cardinalities, type consistency, and required fields. The graph-level semantic constraints described in the paper are strict: there must be exactly one `Event` node; there must not be multiple `Event` nodes; relations cannot point to undefined entities; duplicate node definitions are invalid; and the graph must remain connected from the `Event` node. The prompting layer reinforces the same discipline by instructing the model to use only available ontology types, preserve case, use the proper property prefixes such as `userUID` rather than `uid`, omit empty properties, and ensure every node is reachable from the `Event` [2510.01409].

The structured output schema is defined around placeholders for `NodeType`, `PropertyType`, and `RelationshipType`, corresponding respectively to valid ontology classes, valid data properties, and valid object properties. This suggests a deliberately bounded generation target: the ontology is not merely a post hoc annotation layer but the generative schema itself [2510.01409].

## 3. Retrieval-augmented generation and backend realization

The extraction methodology begins with hybrid retrieval over a store containing previously generated KGs and manually crafted ontology-aligned examples. For each incoming log plus context, OntoLogX runs both vector search and full-text search. The vector index stores embeddings of the raw log event and context used to generate graphs, while the full-text index stores the individual words of the log and context. The rationale is that full-text search catches near-identical lexical matches, while vector search captures semantic similarity that can surface conceptually related logs. Results from the two are normalized to a common scale, merged, and reranked [2510.01409].

To improve diversity, the system uses maximal marginal relevance (MMR):

$$
\text{MMR}(d) = \lambda \cdot \text{Sim}(d, q) - (1 - \lambda) \cdot \max_{s \in S} \text{Sim}(d, s)
$$

where \(q\) is the query, \(D\) the candidate set, \(S \subset D\) the already selected results, and \(\lambda \in [0,1]\) balances relevance against diversity. This means OntoLogX does not simply pick the top-\(k\) nearest examples; it prefers examples that are both similar to the input and diverse relative to each other [2510.01409].

Generation is then performed by an LLM using the raw log, optional context, the ontology, and the retrieved examples as few-shot guidance. The prompting is model-agnostic. The main generation prompt defines the model as a “top-tier cybersecurity expert” extracting structured information into a KG according to the `olx` ontology. The prompt enforces several hard rules: the graph must contain exactly one `Event` node; only ontology-defined types may be used; the most specific available types and relationships must be used; type casing must be respected; the appropriate prefixed property names must be used; empty values must be omitted; only structurally allowed properties and relations may be inferred; and the graph must be connected from the `Event` node [2510.01409].

Structured output is enforced through function-calling interfaces rather than by asking models to emit free-form RDF/Turtle. The baseline prompt injects the exact expected JSON graph schema, allowed properties by node type, allowed relationships in \((\text{source type}, \text{relationship type}, \text{target type})\) form, and structural relationships among node types. The validated KGs are stored in Neo4j, with extensions for vector and full-text indexing. This backend choice is operationally important because retrieval and persistence are built into the same graph infrastructure [2510.01409].

## 4. Validation loop, repair strategy, and session-level ATT&CK inference

A major part of OntoLogX is the iterative correction loop. Because LLM outputs may be malformed or semantically inconsistent, the system validates and repairs them in three stages. First, syntax validation checks whether nodes and relationships are properly defined and whether the graph matches the required structured format. Second, ontology compliance is checked using SHACL: correct class and property use, consistent data typing, and required schema conditions. Third, semantic validation checks higher-level invariants such as exactly one `Event`, no undefined relationship targets, no duplicate nodes, and overall graph coherence [2510.01409].

If violations are found, OntoLogX creates a targeted correction prompt that identifies the errors and asks the model to revise the output. In experiments, correction is capped at three refinement prompts per event. If no valid graph is produced within the allowed attempts, the system outputs an empty graph. This design is explicitly framed as a safety and backend-compatibility mechanism: only validated ontology-compliant graphs are persisted, ensuring that downstream retrieval and graph querying operate on clean data [2510.01409].

Once valid event-level KGs are available, OntoLogX performs session-level aggregation. It does not try to merge all event graphs into one globally unified graph; instead, graphs are stored independently and then grouped by session when higher-level analysis is needed. For tactics prediction, all event KGs from a session are presented together to another LLM. This second prompt positions the model as a cybersecurity analyst AI and instructs it to inspect the set of KGs, identify suspicious behavior, and map it to MITRE ATT&CK tactics such as Execution, Persistence, or Discovery. The prompt explicitly allows multiple tactics, allows the possibility of a benign session, and forbids inventing tactics outside MITRE ATT&CK [2510.01409].

A second common misconception is that the tactic layer is a symbolic ATT&CK reasoner. It is not described that way. The paper does not describe any confidence score, explicit ATT&CK ontology, or symbolic reasoning engine for tactic prediction; it is a multi-label classification-style LLM judgment over session-level KG evidence. The ontology-guided aspect is indirect at this stage, because the model consumes normalized KG inputs rather than raw logs [2510.01409].

## 5. Experimental setup and empirical findings

The empirical study has two parts: KG generation and ATT&CK tactic prediction. For KG generation, the paper uses the AIT-LDS corpus as a public benchmark, specifically logs sampled from the RussellMitchell testbed. From each log file, the first 100 events were collected. Then 70 diverse events were selected using embedding-based dissimilarity: embeddings came from `nomic-embed-text-v1.5`, and any candidate with cosine distance below 0.7 from a previously selected sample was discarded. These 70 events were manually annotated with gold-standard KGs and split into 10 examples for few-shot prompting, 10 for validation during prompt refinement, and 50 for testing [2510.01409].

The KG-generation implementation was intentionally model-agnostic. The compared LLMs were Llama 3.3 (80B), Llama 3.1 (8B), Claude Sonnet 4, Claude 3.5 Haiku, Mistral Large (123B), gpt-oss 20B, gpt-oss 120B, and Qwen3 Coder 32B. All except Qwen3 Coder were accessed through AWS Bedrock; Qwen3 Coder ran locally via vLLM on four NVIDIA L4 GPUs. Temperature was set to 0.7 for all models, and each experiment was repeated 10 times. Embeddings for retrieval were generated using `gte-multilingual-base`, graphs were stored in Neo4j with vector and full-text support, and experimental results were organized using the MLSchema ontology [2510.01409].

The ablation tested five configurations: baseline; retrieval only; structured output only; structured output + correction; and the full OntoLogX pipeline, i.e. retrieval + structured output + correction. The metrics were Generation Success Ratio, SHACL Violation Ratio, Precision, Recall, F1 score, Entity Linking Accuracy, Relationship Linking Accuracy, and G-Eval Score. The paper gives a nuanced reading of G-Eval: because logs are noisy, a very high semantic overlap score is not always ideal, and roughly \(0.7\)–\(0.8\) is interpreted as high information retention without reproducing noise [2510.01409].

The strongest reported KG-generation results are summarized below.

| Model and setting | Key reported results | Interpretation |
|---|---|---|
| Claude Sonnet 4, full retrieval | Success \(1.000\), SHACL \(0.008\), Precision \(0.817\), Recall \(0.776\), F1 \(0.786\), Entity \(0.731\), Relationship \(0.786\), G-Eval \(0.764\) | Best overall reported result |
| Claude Sonnet 4, starter set retrieval | Precision \(0.809\), Recall \(0.762\), F1 \(0.775\), Entity \(0.727\), Relationship \(0.844\), G-Eval \(0.761\) | Nearly identical to full retrieval |
| Qwen3 Coder 32B, full retrieval | Success \(1.000\), SHACL \(0.004\), Precision \(0.758\), Recall \(0.702\), F1 \(0.717\), Entity \(0.598\), Relationship \(0.539\), G-Eval \(0.787\) | Strongest open-weights model |
| Llama 3.3, full retrieval | Precision \(0.764\), Recall \(0.568\), F1 \(0.630\) | Competitive precision, lower recall |
| Mistral Large, full retrieval | Precision \(0.661\), Recall \(0.646\), F1 \(0.638\) | Balanced but lower overall |
| gpt-oss 120B, full retrieval | Success \(0.878\), Precision \(0.734\), Recall \(0.731\), F1 \(0.721\), Entity \(0.666\), Relationship \(0.706\), G-Eval \(0.652\) | Improved with strong retrieval scaffolding |

Several empirical conclusions are explicit. First, the best setups reduce SHACL violations by an order of magnitude relative to minimal baselines. Second, retrieval is the biggest contributor to extraction quality; retrieval-only often outperformed structured-output-only. Third, structured output alone was often insufficient, and for several models it failed catastrophically. Fourth, adding correction helps repair malformed outputs but, without retrieval, is still weaker than retrieval-based approaches. Fifth, full retrieval and starter-set retrieval performed nearly the same on the benchmark, which the paper attributes to the deliberately diverse, small dataset; it argues full retrieval should matter more in real deployments such as honeypots, where many events are similar [2510.01409].

The G-Eval analysis highlights a notable failure mode. For Qwen3 Coder 32B, structured-output-only achieved a very high G-Eval of \(0.912\), but poor F1 (\(0.460\)). The paper interprets this as semantic capture of much of the log’s information with enough noise or mismatched detail to reduce exact triple precision and recall. By contrast, stronger F1 configurations stabilized around G-Eval \(\approx 0.8\), suggesting a trade-off between broad semantic capture and ontological exactness [2510.01409].

For ATT&CK tactic prediction, the dataset came from a real-world Cowrie honeypot deployed by Politecnico di Torino. The logs covered a 10-day collection window from August 4, 2025 to August 14, 2025. Logs were grouped into sessions, each containing around ten logs on average. The split was 1 session for training, 2 sessions for validation, and 100 sessions for testing, with all test sessions manually annotated with MITRE ATT&CK tactics. For this stage, the generation backend was Claude Sonnet 4 using the full retrieval configuration, while tactic prediction was performed by Foundation-sec-8b running locally with vLLM. The paper reports that “some tactics” were identified in the “vast majority of cases” and that OntoLogX was effective in extracting CTI from generated graph sessions, but the excerpt does not include the per-tactic numeric values from the figure [2510.01409].

## 6. Significance, limitations, and broader ontology-centric context

The practical significance of OntoLogX lies in its use of ontology-grounded KGs as a structured representation for actionable CTI extraction from logs. A normalized graph abstracts away raw logging idiosyncrasies and exposes meaningful entities and relations—users, credentials, applications, timestamps, sources, parameters, and their interactions—in a form suitable for semantic querying, traceability, and downstream reasoning. Because graphs are ontology-grounded and SHACL-validated, they are more interoperable and auditable than ad hoc parsed fields or unconstrained LLM summaries. Stored in Neo4j with retrieval support, they are also operationally useful for pattern exploration and reuse of prior examples [2510.01409].

The limitations are equally explicit. Running LLMs is computationally expensive in both time and cost, especially for near-real-time settings. The ontology is intentionally lightweight, which improves generation reliability but may leave out rarer log phenomena or broader CTI standards. Because extraction relies on LLM inference, hallucination and over-interpretation remain risks, even with retrieval, structured output, and correction. Generalization beyond the limited benchmark and the Cowrie honeypot setting remains to be tested across other enterprise log families, cloud telemetry, or endpoint logs. The system is also model-dependent: some architectures, especially reasoning-oriented ones under the prompt design used here, perform poorly unless retrieval scaffolding is strong. Finally, it stores KGs independently rather than solving full cross-event graph integration, so longitudinal or cross-device reasoning is only partially addressed through session grouping. Future work suggested in the paper includes optimization for throughput, incremental learning, and ontology extension toward broader CTI interoperability [2510.01409].

Within a wider ontology-centric literature, OntoLogX occupies a distinct position. “Portable Ontological Expressions in NoSQL Queries” addresses portability of queries across diverse physical implementations of large data stores by embedding Address Expressions in KQL, which is an ontology-mediated query abstraction rather than ontology-guided extraction from raw logs [1610.06084]. “OntoForms” generates user-interface structure from a domain ontology using description logic inference services, showing a different use of ontology as an operational driver for system behavior [2408.02130]. “TransBox” proposes EL++-closed ontology embeddings that can represent complex class expressions compositionally, which suggests a separate but compatible line of work for ontology-aware ranking and predictive reasoning over complex axioms [2410.14571]. This suggests that OntoLogX is best understood not as a generic ontology platform, but as a specialized synthesis of ontology guidance, retrieval, constrained generation, and LLM-based CTI inference for cybersecurity logs.

Source: https://www.emergentmind.com/topics/ontologx