
Koda IDS Frontier
Koda IDS Frontier is a lightweight open cybersecurity reasoning model built on Liquid AI's LFM2.5-2.6B and specialized for defensive security analysis.
Koda is designed to analyze security telemetry, correlate evidence, evaluate competing explanations, identify missing information, prioritize investigations, and recommend proportionate defensive actions.
Rather than treating every unusual event as an attack, Koda is trained to distinguish what is observed, what is inferred, what is hypothesized, and what remains unknown.
Base model: Liquid AI LFM2.5-2.6B
Parameters: ~2.7B
License: Apache-2.0
Language: English
Domain: Defensive cybersecurity
Status: Frontier research release
Why Koda?
Security telemetry is rarely clean.
A DNS spike might be malicious traffic, but it might also be a deployment. A large number of authentication events might indicate credential abuse, but they might also come from a scheduled job. An unusual process might be suspicious, but without process, network, or file evidence, its intent may remain unknown.
Koda is specifically trained around this distinction:
Context modifies suspicion.
Evidence determines conclusions.
Missing evidence remains unknown.
The model prioritizes:
Evidence > speculation
Calibration > false certainty
Investigation > premature conclusion
Defensive action > offensive action
A correct answer may therefore be:
There is insufficient evidence to determine whether the activity is malicious.
That is an intended behavior, not a failure.
Model Lineage
Liquid AI LFM2.5-2.6B
│
│
▼
Cybersecurity SFT
│
│
▼
Reasoning training
│
│
▼
Koda IDS Frontier
│
├── F16 GGUF
│
└── Q4_K_M GGUF
Koda is not trained from scratch.
It is a fine-tuned derivative of LFM2.5-2.6B, with training focused on defensive cybersecurity reasoning and investigation behavior.
The training data combines the NetGoat VSA dataset with additional cybersecurity reasoning data.
Core Capabilities
Koda IDS Frontier is specialized for:
- Security telemetry interpretation
- Incident triage
- Network and DNS anomalies
- Authentication and identity events
- Endpoint and process telemetry
- Cloud infrastructure events
- CI/CD activity
- Service-account behavior
- Database activity
- Logging and monitoring anomalies
- Backup and recovery events
- Distinguishing legitimate activity from suspicious activity
- Evidence-grounded hypothesis generation
- Uncertainty estimation
- Investigation prioritization
- Defensive response planning
Reasoning Philosophy
Evidence first
Koda should only make claims supported by the available evidence.
It should not turn an assumption into a fact or treat a correlation as proof of causation.
Multiple hypotheses
Security events frequently have multiple plausible explanations.
Koda should consider legitimate operational causes alongside suspicious explanations when the evidence supports doing so.
Examples include:
- Scheduled jobs
- Deployments
- Internal audits
- Monitoring
- Backups
- Configuration changes
- Software failures
- Administrative activity
- Misconfiguration
- Potentially malicious activity
Explicit uncertainty
When important evidence is missing, Koda should identify the missing information rather than filling the gap with speculation.
Calibrated conclusions
Suspicious telemetry does not automatically mean compromise.
Koda should distinguish between:
Observed
↓
Inferred
↓
Hypothesized
↓
Needs verification
Investigation over speculation
When the available evidence is insufficient, Koda should identify the investigation that would provide the greatest reduction in uncertainty.
This makes investigation prioritization an important part of the model's behavior.
Proportionate response
Defensive recommendations should correspond to the evidence available.
Koda should avoid both extremes:
Ignore everything suspicious
↕
Treat everything as compromise
Instead, it should recommend proportionate investigation, containment, monitoring, escalation, or remediation when justified.
Tool-Aware Reasoning
Koda can be integrated into security systems that expose investigation tools.
When tools are available to the model, it is trained to reason about:
- Which tool is appropriate
- What evidence the tool could provide
- Why that evidence matters
- Which investigation should happen first
- How potential results would change the assessment
However, the base model does not inherently have access to your infrastructure, logs, networks, endpoints, databases, or security tools.
A runtime integration must explicitly provide those capabilities.
Koda should never claim that a tool was executed or that a result was obtained unless the runtime actually provided that information.
Example Investigation Flow
A typical Koda investigation follows this pattern:
Security event
│
▼
Observed evidence
│
▼
Known facts
│
▼
Competing explanations
│
▼
Missing evidence
│
▼
Highest-value investigation
│
▼
Updated assessment
│
▼
Severity / confidence
│
▼
Proportionate defensive action
For example, unusually high DNS traffic should not automatically be classified as DNS abuse.
Koda should consider:
- What generated the traffic
- Whether there is an approved operational explanation
- Whether the destination is expected
- Whether the query characteristics are unusual
- Whether process or network evidence supports a malicious hypothesis
- What information is still missing
Training Focus
The training process emphasizes several behaviors that are important for defensive security analysis:
Evidence grounding
Do not invent telemetry, indicators, timestamps, tool results, commands, or investigation outcomes.
Uncertainty handling
Explicitly identify what cannot currently be determined.
Hypothesis comparison
Consider multiple explanations rather than immediately committing to the most alarming interpretation.
Information gain
Prioritize investigations that resolve the most important uncertainty.
Metacognitive checking
Koda is trained to audit its own assumptions, including recognizing when an initial interpretation may have over-weighted a particular piece of evidence.
For example:
Initial interpretation:
The activity coincides with an approved deployment.
Self-check:
The timing supports the deployment hypothesis but does not prove
that the deployment caused the activity.
Updated assessment:
The deployment is relevant context, while causation remains unverified.
The purpose of this behavior is to improve calibration, not simply to produce longer reasoning.
Usage with llama.cpp
The published GGUF files can be used with llama.cpp-compatible runtimes.
Q4_K_M
llama-cli \
-m koda-ids-Q4_K_M.gguf \
-c 8192 \
-n 1024
F16
llama-cli \
-m koda-ids-f16.gguf \
-c 8192 \
-n 1024
Exact context length, generation limits, and runtime parameters should be adjusted according to available hardware and application requirements.
Ollama
Koda IDS Frontier can be loaded into Ollama using the published Q4_K_M GGUF.
Example Modelfile:
FROM ./koda-ids-Q4_K_M.gguf
PARAMETER temperature 0.1
PARAMETER top_k 50
PARAMETER top_p 0.7
PARAMETER repeat_penalty 1.1
PARAMETER num_ctx 8192
PARAMETER stop "<|im_end|>"
PARAMETER stop "<|im_start|>user"
PARAMETER stop "<|im_start|>system"
PARAMETER stop "<|im_start|>assistant"
PARAMETER stop "<|endoftext|>"
Koda uses the LFM2 chat format.
Recommended Prompt Structure
For best results, provide concrete evidence and clearly distinguish known information from assumptions.
Analyze the following security event.
Known evidence:
- ...
- ...
- ...
Context:
- ...
- ...
Unknown:
- ...
- ...
Determine:
1. What is directly observed?
2. What explanations are plausible?
3. What evidence is missing?
4. What should be investigated next?
5. What severity and confidence are justified?
If your runtime provides tools, include the available tools and their capabilities explicitly.
Avoid presenting fabricated tool results or asking Koda to assume that an investigation has already been performed.
Available Files
| File | Format | Approx. size | Intended use |
|---|---|---|---|
koda-ids-f16.gguf | F16 GGUF | ~5.4 GB | Highest numerical fidelity |
koda-ids-Q4_K_M.gguf | Q4_K_M GGUF | ~1.7 GB | Lower-memory local inference |
The F16 model provides the closest GGUF representation of the trained model.
Q4_K_M substantially reduces memory requirements and is intended for practical local deployment.
Additional quantizations may be published separately.
Architecture
Liquid AI LFM2.5-2.6B
↓
Cybersecurity specialization
↓
Supervised fine-tuning
↓
Reasoning / preference optimization
↓
Koda IDS Frontier
↓
GGUF
The model is designed to remain lightweight enough for local deployment while providing specialized cybersecurity analysis capabilities.
Intended Use
Koda IDS Frontier is intended for:
- Security research
- Defensive incident analysis
- SOC experimentation
- Security telemetry analysis
- Local security assistants
- Incident triage
- Cybersecurity education
- Defensive security research
- Open-source security tooling
Limitations
Koda IDS Frontier is a research model and may:
- Misinterpret ambiguous telemetry
- Miss important context
- Produce incorrect hypotheses
- Miscalibrate severity or confidence
- Make reasoning errors
- Recommend an investigation that is not optimal
- Require additional evidence before reaching a reliable conclusion
Koda should therefore be treated as an analysis assistant, not an authoritative security decision-maker.
Model output should be validated against the underlying telemetry and appropriate security tooling before consequential decisions are made.
The model does not inherently have access to:
- Infrastructure
- Logs
- Networks
- Endpoints
- Databases
- Security platforms
- Threat-intelligence feeds
unless those capabilities are explicitly provided by the runtime.
Safety and Defensive Scope
Koda IDS Frontier is developed for defensive cybersecurity use.
It is intended to support:
Detection
↓
Analysis
↓
Investigation
↓
Validation
↓
Defensive response
The model should prioritize defensive analysis and should not be treated as an autonomous authority for security operations.
About NetGoat OSS
Koda IDS is part of NetGoat OSS, an open-source project focused on independent and self-hostable web and infrastructure security.
NetGoat aims to provide security infrastructure that can be operated under the user's control rather than requiring dependence on a centralized security provider.
Koda extends this ecosystem with lightweight, locally deployable AI-assisted defensive analysis.
Model Card
| Property | Value |
|---|---|
| Model | Koda IDS Frontier |
| Base model | Liquid AI LFM2.5-2.6B |
| Parameters | ~2.7B |
| Architecture | LFM2 |
| Language | English |
| Domain | Defensive cybersecurity |
| Formats | GGUF |
| Published variants | F16, Q4_K_M |
| License | Apache-2.0 |
| Status | Frontier research release |
| Organization | NetGoat OSS |
Disclaimer
Koda IDS Frontier is provided for research and defensive security purposes.
Model outputs may be incorrect, incomplete, or miscalibrated. They should not be treated as authoritative security evidence or as a replacement for qualified security professionals.
Security decisions should be based on verified telemetry, appropriate investigation, and established operational controls.
When evidence is insufficient, investigate rather than assume.