Automated cyber intelligence reports for military command

The intelligence problem facing military commands in the cyber domain is not a shortage of data. It is a format problem. Threat feeds deliver raw indicators — IP addresses, file hashes, domain names — optimized for ingestion by detection tools, not for decision-making by commanders. When a J6 officer needs to brief a commanding officer on the current cyber threat picture, the raw IOC dump from the SIEM is not the product that gets handed up the chain. Someone has to translate it. That translation work — converting machine-readable indicators into structured, attributed, command-ready intelligence — is currently done manually by analysts who are scarcer than the data they are processing.

Automated cyber intelligence report generation using LLMs and structured CTI data changes the economics of that translation. This article covers what command-ready automated CTI reports look like, what structured inputs are required to generate them reliably, how to build the LLM pipeline with hallucination controls that a military context demands, and how to disseminate the output through the channels a command chain actually uses.

The gap: raw IOC feeds versus command-ready intelligence

Raw IOC feeds serve a specific and valuable function: they populate block lists, drive SIEM correlation rules, and feed endpoint detection systems. For that purpose, the format is correct — machine-readable, high-volume, structured for automated ingest. The problem arises when the same feed is expected to serve the command layer's intelligence needs. A commander cannot act on a list of 2,000 IP addresses. They need to know which adversary group is likely behind the activity, what their objective is, which systems or networks are at risk, what the confidence level of the attribution is, and what course of action is recommended.

That translation from indicator to assessment requires several enrichment steps that raw IOC feeds do not perform: threat actor attribution using campaign infrastructure clustering, technique-level mapping to ATT&CK to characterize adversary behavior, historical context from the adversary's known targeting patterns, and an impact assessment tied to the command's specific critical systems. None of that is present in the feed. All of it takes analyst time to produce manually.

The timeliness problem compounds the format problem. A threat that is identified and classified twelve hours after the relevant indicators first appeared may no longer be actionable. An executive brief delivered to the commanding officer at 0800 covering threat activity from the previous 24 hours is useful. A brief delivered at 1600 covering the same period is not. Automated report generation addresses both problems simultaneously: it produces command-ready output in a consistent format, and it does so fast enough that timeliness is no longer determined by analyst availability.

Report types for the command chain

Not every report type serves every audience. Designing the report taxonomy before implementing the pipeline is essential — the LLM generates narrative within a template, and the template must be matched to its audience. Four report types cover the practical needs of most military command structures.

Executive threat brief

The executive threat brief is a two-page maximum summary intended for the commanding officer and senior staff. It states the current threat posture (elevated, nominal, degraded), names the adversary groups with active campaigns relevant to the command's area of operations, characterizes each group's likely objective in one or two sentences, and lists the top three recommended command-level actions. Confidence levels are expressed in plain language — "assessed with high confidence based on three corroborating source reports" — not as decimal probabilities. TLP classification appears in the header. Every factual claim is traceable to a source record in the CTI knowledge base, but source citations appear in an appendix rather than inline, to preserve readability at the executive level.

Technical indicator report

The technical indicator report serves the SOC and J6 staff who need to act on the specific indicators underlying the executive brief. It contains the full IOC table (with context fields: associated malware family, ATT&CK technique ID, confidence score, first-seen and last-seen timestamps, TLP classification per indicator), detection guidance mapped to the command's deployed sensor stack, and STIX 2.1 bundle export. This report type requires minimal LLM involvement in the body — the bulk is structured data rendered from the CTI knowledge base. The LLM contributes the introductory summary, the technique-level narrative for each ATT&CK technique cluster present in the indicator set, and the detection guidance text.

Adversary profile update

The adversary profile is a persistent document, updated when new campaign activity provides incremental knowledge about a tracked threat actor group. It describes the group's known organizational structure, primary targeting sectors and geographies, malware toolset, preferred TTPs mapped to ATT&CK, and historical operation timeline. The LLM generates the delta — what changed since the last profile version — by comparing the previous profile's source record set against the current one and generating narrative for the new additions. Version control of the profile document is mandatory; each update carries a profile version number and change log summarizing what was added or revised.

Incident timeline

When a cyber incident affecting the command's networks is confirmed or suspected, the incident timeline report reconstructs the chronological sequence of events from available sensor telemetry, threat intelligence matches, and OSINT corroboration. The LLM synthesizes a narrative timeline from event records ordered by timestamp, identifies likely ATT&CK technique sequences (indicating which phase of the kill chain the adversary reached), and produces a structured table of events for command staff review. The timeline is the product most directly useful for a post-incident command debrief and for informing defensive measures.

LLM pipeline for report generation

The pipeline architecture that produces reliable automated CTI reports for a military audience has five distinct stages. Each stage has specific input requirements, quality controls, and failure modes that must be addressed before the pipeline operates in a command environment.

Stage 1 — Structured CTI ingest. All source data enters the pipeline in one of two formats: STIX 2.1 bundles from feed subscriptions and MISP event exports, or enriched event records produced by the upstream classification pipeline. Raw IOC records without ATT&CK technique mappings, confidence scores, and TLP classifications are held at ingest and routed to the enrichment pipeline before report generation. The report generator requires structured inputs — attempting to generate commander-ready narrative from unenriched IOC lists produces low-quality output that fails hallucination checks and requires extensive analyst correction.

Stage 2 — Template selection and input assembly. Based on the report request (triggered by schedule, by threshold event, or by analyst request), the pipeline selects the appropriate report template and assembles the input record set. For an executive brief, this means retrieving all active campaign records for the current reporting period, grouped by threat actor, ranked by severity. For an adversary profile update, it means retrieving the delta record set — source records added since the last profile version. Input assembly is deterministic; the same request against the same record set produces the same assembled input, enabling reproducibility and audit.

Stage 3 — RAG-grounded narrative generation. The LLM generates narrative section by section against the assembled input records. Retrieval-augmented generation (RAG) is the required architecture: the model generates text grounded in the specific records provided in the prompt context, not against its parametric weights. Each prompt instructs the model to cite the source record ID for every factual claim. Output conforms to a strict JSON schema that maps to the report template sections. Schema validation runs immediately on receipt; parsing failures trigger an automatic retry with corrective instructions before routing to analyst review.

Stage 4 — Hallucination detection and fact-grounding verification. Every generated report passes through an automated fact-grounding check before it reaches a human reviewer. The check verifies that each cited source record ID exists in the input set and that the generated claim is semantically consistent with the content of the cited record. Semantic consistency is checked using a second LLM call with a binary judgment prompt — a lightweight approach that catches the most common hallucination patterns without requiring exhaustive entity matching. Claims failing the consistency check are flagged inline in the draft report. A registry of known-false claims (disproven attributions, false positive indicators) is scanned against every report; any match blocks dissemination until the analyst resolves the conflict.

Stage 5 — Human review and approval. No automated CTI report is disseminated without a human reviewer approving it. The reviewer interface presents the draft report with all fact-grounding flags highlighted, shows the source records supporting each flagged claim, and requires an explicit approval action before the report enters the dissemination queue. Reviewer identity, timestamp, and any corrections made are logged as part of the report's provenance record. This is not a bureaucratic formality — in a military CTI context, an automated report containing an incorrect attribution that drives a command decision is a threat to operational security, not just an intelligence error.

Structured input requirements

The quality ceiling for automated CTI reports is set by the quality of the structured inputs. There is no prompt engineering strategy that compensates for missing ATT&CK technique mappings, absent confidence scores, or unresolved threat actor aliases. The following input requirements are the minimum for reliable report generation.

STIX 2.1 bundles must contain resolved object relationships. A bundle containing only Indicator objects without Relationship objects connecting them to Threat Actor, Malware, and Attack Pattern objects does not provide the attribution context the report generator needs. Campaign objects linking Threat Actor to multiple Indicator objects across a time range are particularly valuable for executive brief generation, since they provide the structural evidence for activity attribution without requiring the LLM to infer it.

ATT&CK technique mappings must carry per-technique confidence scores. A technique mapping without a confidence score is treated as low confidence by default. The confidence score is used to calibrate the strength of the narrative claim: a high-confidence T1071 (Application Layer Protocol) mapping drives a specific claim about the adversary's C2 communication method; a low-confidence mapping drives a hedged claim using language like "possibly consistent with" rather than "uses." This distinction is operationally significant at the command level, where overconfident intelligence has historically led to poor decisions.

TLP classifications must be present on all source records before report generation. The pipeline computes the report's TLP level as the maximum over all source record TLP levels and applies it automatically. A source record without a TLP classification is treated as TLP:AMBER by default — the most conservative non-blocked level — until an analyst assigns an explicit classification. This default-conservative approach prevents accidental over-sharing.

Quality controls: hallucination prevention in a CTI context

Hallucination prevention in a military CTI context requires more than the standard LLM output validation approaches used in commercial applications. Three specific controls are required.

First, attribution claims must be grounded against the actual campaign infrastructure evidence, not against the model's parametric knowledge of threat actor groups. A model that has been trained on public CTI reports knows a great deal about APT groups — their tooling, their targeting patterns, their historical operations. That parametric knowledge must not be allowed to drive attribution claims in a generated military report. The RAG architecture enforces this: the prompt context contains only the specific records assembled for this report, and the model is instructed to make attribution claims only from that context.

Second, confidence language must be calibrated to the input confidence scores, not to the model's linguistic preferences. LLMs tend toward confident assertion in fluent prose. In a CTI context, a report section generated from records with an average confidence score of 0.62 must use hedged language — "assessed with moderate confidence," "consistent with but not confirmed as" — regardless of how fluent it would be to write the claim assertively. Enforcing this requires explicit confidence-to-language mapping rules in the prompt and a post-generation check that scans the output for high-confidence assertion language paired with low-confidence input records.

Third, version control of recurring reports is a quality control mechanism, not just an operational convenience. When a new version of an adversary profile is generated, diffing it against the previous version and presenting the delta to the human reviewer makes hallucination detection significantly easier. A reviewer who sees that the new profile asserts a capability the group was not attributed with in the previous version immediately knows to check the source records supporting that claim. Without version comparison, newly introduced errors are invisible against the background of the full report.

For a deeper look at how CTI platforms structure threat data for command-level intelligence products, see our guide to defense-grade CTI platform architecture.

Dissemination: matching the channel to the report type

Automated reports are only valuable if they reach the right audience through the right channel with appropriate access controls. Military command environments have specific dissemination requirements that commercial CTI platforms do not address.

XMPP and real-time push

For time-sensitive executive briefs and high-severity incident notifications, XMPP push delivers a short alert message — threat posture, adversary group, recommended action, and a secure retrieval link — to command staff within seconds of the report being approved. XMPP is the preferred protocol for tactical command communications in many defense environments due to its federated architecture and offline message queuing. The full report is available via the retrieval link; the XMPP message is the notification, not the report itself.

MISP push for technical dissemination

Technical indicator reports push directly to the command's MISP instance as structured events with ATT&CK galaxy tags, TLP markings, and associated STIX objects. Downstream SIEM correlation rules and endpoint detection tools subscribe to the MISP event stream and automatically ingest new indicators without requiring analyst intervention for each report. MISP's distribution controls enforce TLP restrictions at the sharing-group level, ensuring that indicators marked TLP:AMBER do not reach unauthorized servers in the federation.

PDF and DOCX for the command chain

Executive briefs and adversary profiles are rendered to PDF for formal dissemination through command document management systems. PDF output includes the report's provenance metadata — report ID, generation timestamp, ATT&CK version referenced, reviewer identity, TLP classification — in a standardized header. DOCX output is provided for reports that will be annotated and forwarded by command staff. Both formats are generated from the same source JSON record, ensuring the structured and human-readable versions remain synchronized. Formatting templates enforce consistent layout across all report types so that command staff develop familiarity with the document structure rather than re-orienting to a different layout each time.

For context on how OSINT monitoring pipelines feed structured CTI data into command-level intelligence products, see our guide to defense-grade OSINT threat monitoring architecture.

Corvus.Sense: structured threat intelligence briefings from OSINT monitoring

The pipeline described in this article requires a continuous source of structured, enriched CTI data as its upstream input. Telegram channels, open messaging platforms, and OSINT sources are among the highest-signal inputs for adversary activity monitoring in current conflict environments — but they deliver unstructured content that requires automated classification and enrichment before it can drive report generation.

Corvus.Sense provides that upstream layer: continuous monitoring of Telegram channels and OSINT sources, automated LLM-based classification of threat content, ATT&CK technique mapping with confidence scores, TLP classification, and STIX-exportable structured intelligence records. The output is the structured CTI input that the report generation pipeline requires — threat actor records, technique timelines, indicator sets, and adversary profile data assembled from monitored open sources in near real time.