A LogLM is a Log Language Model, a foundation model trained on operational telemetry (logs, flow records, identity events, cloud activity) instead of natural language. It learns the behavioral grammar of an environment the way a large language model learns the grammar of human text. DeepTempo's LogLM is the detection model at the core of the Intelligent Defense Platform. This page is the canonical reference.
Read the video transcript
As AI-powered attacks proliferate, DeepTempo's LogLM, which was purpose-built to find hard-to-find attacks, is coming to the fore. In this video, let's take a look at the LogLM and explain how it is built, what it does, and how it compares to LLMs.
What if a security model could begin finding attacks before a customer-specific training project? DeepTempo's LogLM is pre-trained on telemetry, so it can work zero-shot: no labels, and no months of tuning before the first assessment. In external evaluations, it achieved 99.3% malicious recall with Deutsche Telekom and a 99 F1 score at 0.08% false positives with a very large internet service provider. That matters as attacks change, including AI-powered attacks designed to move faster than handwritten defenses.
How can it recognize activity it has not seen in that exact form? It learns the language inside the logs. Why does that work? First, sequence. Logs happen in order, and order carries meaning. A login followed by a privilege escalation followed by an outbound connection can tell a story. Put those same events in a different order and they may be harmless. A LogLM is built to learn the pattern across the sequence, not judge each line in isolation.
Second, context. A connection on port 443 from a workstation to a software service is ordinary. The same connection from a domain controller right after a credential dump is not. And most telemetry is uneventful. The meaningful events are rare, like the important sentences hidden in a very long book. Transformer architectures are good at learning sequence and context from that sparse signal.
Here is how it works. A LogLM is pre-trained on operational telemetry, not human text. It preserves the structure of fields, IP addresses, ports, paths, and identifiers. The transformer learns how events relate across sequence, context, and sparse signal, then turns activity into embeddings: compact mathematical representations of behavior. Similar activity ends up near similar activity on that behavioral map, even when the raw log lines are not identical. Classifiers read those representations to identify attacker intent and map detections to MITRE ATT&CK. Because the model arrives with that telemetry knowledge, it can detect zero-shot, before customer-specific adaptation. It is not a chatbot pointed at a pile of logs.
Traditional tools often ask a narrower question. Does this match a known rule or signature? Is this one behavior statistically unusual? Those approaches still have value. But attackers can change a known pattern, and unusual does not always mean malicious. A LogLM asks a broader question across this pattern of activity: what is the actor trying to accomplish? It can recognize behavior across activity it has not seen in exactly the same form before. The goal is not to replace every existing control. It is to add a learned view of the full pattern, where several individually ordinary events can form a meaningful attack story. That is intent-level detection.
Consider command and control beaconing. A traditional network detection tool may look for a known beacon signature or perfectly regular timing. An attacker can evade both by beaconing every 47 seconds, adding jitter, and using HTTPS through a content delivery network. No single property has to look abnormal. A LogLM places that flow in the context of the workstation's other activity over the previous week: DNS lookups, certificate fingerprints, differences between bytes sent and received, and timing relative to user activity. Together, that pattern lands in a region of embedding space the classifier associates with T1071.001, web protocols. DeepTempo can then surface a command and control detection.
Notice what changed. The model did not declare one packet, domain, or interval bad. It combined several weak clues, plus their order and surroundings, into one stronger judgment about what the actor was doing.
DeepTempo runs the LogLM and its classifiers against telemetry your environment already produces. The output is a set of MITRE-mapped detections as structured JSON findings, ready to flow into your SIEM and your existing security operations workflow. From there, a finding can be investigated further with Vigil or another AI SOC. And the same model supports threat hunting: because activity is represented across very rich behavioral dimensions, hunters can search semantically across those dimensions to surface the patterns worth a closer look.
Logs are not just records. In sequence and context, they describe behavior. A LogLM learns that language so defenders can see the intent behind the activity. Learn more about DeepTempo's Intelligent Defense Platform at deeptempo.ai.
The short answer
Foundation models learn rich, transferable representations of a domain by training on large volumes of data from that domain. ChatGPT learns from human text. A vision foundation model learns from images. A LogLM learns from logs.
Because it learns the structure and meaning of operational telemetry, not just statistical norms, a LogLM can recognize patterns of attacker behavior across activity it has never seen before. That makes it qualitatively different from rules, signatures, baselines, or anomaly detectors.
Why language models work for logs
Logs share three properties with natural language that make them well-suited to language-model architectures.
Sequence. Logs occur in order, and order carries meaning. A login followed by a privilege escalation followed by an outbound connection is a story; the same three events in a different sequence may be benign.
Context. Each log line means different things depending on what surrounds it. A 443 connection from a workstation to a SaaS endpoint is mundane; the same connection from a domain controller after a credential dump is not.
Sparseness of meaningful events. Most logs are uneventful. Like the meaningful sentences in a book, the meaningful sequences in a telemetry stream are rare and depend on context to be recognized.
Transformer architectures are very good at learning sequence and context from sparse signal. Applying them to logs is the core insight behind LogLM.
How a LogLM differs from a general-purpose LLM
A general-purpose LLM is trained on human text. Its vocabulary is words and tokens from natural language. Its output is generated text. Its optimal use is reasoning, generation, and summarization. It is large, expensive, and limited in accuracy on security telemetry because logs are out-of-distribution for it.
A LogLM is trained on operational telemetry. Its vocabulary preserves the structure of fields, IPs, ports, and identifiers. Its output is embeddings consumed by classifiers and mapped to MITRE ATT&CK. Its optimal use is detection and classification in security telemetry. It is significantly smaller, faster, cheaper, and more accurate within the domain it was built for.
Retrofitting a general-purpose LLM to security telemetry is the equivalent of asking a generalist who has read every book to suddenly debug a network. They can guess. They do not speak the language.
What it took to build LogLM
Building a foundation model for operational telemetry was not a quick exercise. The work spanned several specific engineering investments worth describing.
Training corpus curation. Most of the engineering effort went into collecting, cleaning, and aligning a substantial corpus of operational telemetry across cloud, data center, and OT environments. Generic log datasets do not carry the diversity needed to learn the difference between legitimate administration and attacker behavior. The corpus had to include both, with enough volume in each category to learn distinguishing structure.
Domain-specific tokenization. Natural-language tokenizers shred IP addresses, GUIDs, command-line arguments, and file paths into nonsense subwords. We built a tokenization scheme that preserves the structure of operational telemetry so the model can learn meaningful tokens rather than fragments of identifiers.
Self-supervised pretraining at scale. The base LogLM was trained with self-supervised objectives appropriate for sequence data. This step alone consumed significant compute and required careful ablation work to land on training objectives that produced stable embeddings for downstream classification.
Classifier head training against MITRE ATT&CK. On top of the foundation model, we trained classifiers on labeled examples of activity mapped to MITRE techniques. This labeling work is ongoing and is where domain expertise compounds. Each round of labels improves the classifier and surfaces edge cases that inform the next round of training.
Continuous evaluation against held-out data. False-positive rate above 5 percent is not viable in a SOC. Getting far below that threshold required dozens of evaluation rounds against held-out telemetry, with explicit attention to high-noise categories like routine administration, automated CI/CD activity, and security tooling itself.
None of this is a wrap-around-an-LLM exercise. A vertical foundation model takes domain data, domain expertise, and substantial engineering work to build.
How LogLM detects an attack in practice
Consider C2 beaconing. A traditional NDR looks for known beacon signatures or unusual periodicity. An attacker who beacons every 47 seconds, jitters the interval, and uses HTTPS to a CDN evades both checks.
A LogLM does not look at any single property of the beacon. It produces an embedding of the flow in the context of every other flow that workstation has produced over the last week, including DNS lookups, certificate fingerprints, byte-pattern asymmetry, and timing relative to user activity. Even when no individual property is abnormal, the combination sits in a region of embedding space the classifier has learned corresponds to T1071.001. DeepTempo surfaces it as a Command and Control detection.
This is intent-level detection. The system is not asking whether a packet is bad. It is asking what an actor is trying to accomplish across an entire pattern of activity.
How DeepTempo applies this
The Intelligent Defense Platform runs the LogLM in production. The platform deploys against operational telemetry your environment already produces, runs the LogLM and its classifiers in real time, and outputs MITRE-mapped detections that flow into your existing SOC workflow. Measured results reflect the engineering tracks described above. In Deutsche Telekom's Phase II evaluation, LogLM achieved 99.3 percent malicious recall. In a Phase 1 evaluation with a very large internet service provider, LogLM reached a 99 F1 score zero shot at 0.08 percent false positives, with sub-second latency. SOCBench, the open benchmark DeepTempo established, exists so results like these can be reproduced against a common yardstick.
