OntoLogX: Ontology-Guided CTI from Cyber Logs

• OntoLogX is an autonomous AI agent that converts messy cybersecurity logs into ontology-grounded knowledge graphs for extracting CTI based on MITRE ATT&CK tactics.
• It integrates large language models with a lightweight cybersecurity log ontology, retrieval augmented generation, and SHACL validation to ensure precise data extraction.
• The system uses an iterative correction loop and session-level aggregation to produce semantically validated and actionable knowledge from heterogeneous log data.

Searching arXiv for the OntoLogX paper and closely related ontology-centric context papers. Search query: ti:"OntoLogX" OR ([2510.01409](/papers/2510.01409)) OntoLogX is an autonomous 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 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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 $q$0, Precision $q$1, Recall $q$2, F1 $q$3, Entity $q$4, Relationship $q$5, G-Eval $q$6	Best overall reported result
Claude Sonnet 4, starter set retrieval	Precision $q$7, Recall $q$8, F1 $q$9, Entity $D$0, Relationship $D$1, G-Eval $D$2	Nearly identical to full retrieval
Qwen3 Coder 32B, full retrieval	Success $D$3, SHACL $D$4, Precision $D$5, Recall $D$6, F1 $D$7, Entity $D$8, Relationship $D$9, G-Eval $S \subset D$0	Strongest open-weights model
Llama 3.3, full retrieval	Precision $S \subset D$1, Recall $S \subset D$2, F1 $S \subset D$3	Competitive precision, lower recall
Mistral Large, full retrieval	Precision $S \subset D$4, Recall $S \subset D$5, F1 $S \subset D$6	Balanced but lower overall
gpt-oss 120B, full retrieval	Success $S \subset D$7, Precision $S \subset D$8, Recall $S \subset D$9, F1 $\lambda \in [0,1]$0, Entity $\lambda \in [0,1]$1, Relationship $\lambda \in [0,1]$2, G-Eval $\lambda \in [0,1]$3	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 (Cotti et al., 1 Oct 2025).

The G-Eval analysis highlights a notable failure mode. For Qwen3 Coder 32B, structured-output-only achieved a very high G-Eval of $\lambda \in [0,1]$4, but poor F1 ($\lambda \in [0,1]$5). 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 $\lambda \in [0,1]$6, suggesting a trade-off between broad semantic capture and ontological exactness (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Cotti et al., 1 Oct 2025).

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 (Damodaran et al., 2016). “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 (Szilagyi et al., 2024). “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 (Yang et al., 2024). 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.