LLM Threat Intelligence Enrichment: Report-to-STIX (2026)

Q: What does it mean that the LLM should be a translator and not a witness in a threat intelligence pipeline?

It means the model is only permitted to perform transformations whose output can be checked against the input document or a public reference: extracting an indicator that appears in the text, mapping a described behaviour to an ATT&CK technique ID, summarising a section with every sentence anchored to a source span, or proposing that two names refer to the same malware. It is not permitted to make assertions whose truth lives outside the document, such as who conducted the campaign, how confident analysts should be, whether the activity is current, or whether it matters to your organisation. Those remain analyst judgements and the pipeline enforces the boundary with schema and validation rather than prompt wording.

Q: How does quote-anchored extraction prevent fabricated indicators?

The extraction prompt requires strict JSON where every candidate object carries the verbatim source quote and its character offset in the normalised document text. Before any object is shown to an analyst or stored, deterministic code checks that the quote exists at the claimed offset. A fabricated IP address, domain or hash has no sentence to point at, so it fails this check and is dropped and logged. This single control removes most hallucinated indicators and also neutralises many injection attempts, because an instruction embedded in the report that makes the model invent an object produces an object with no valid anchor.

Q: Why should the model never emit threat-actor or intrusion-set objects?

Because attribution is the highest-damage hallucination in threat intelligence. A model structuring a report about, for example, a credential-phishing campaign will often add the intrusion set it associates with those techniques, since those names co-occurred with that tradecraft thousands of times in its training data, even when the source says nothing about who was responsible. The result is a STIX relationship connecting a campaign to a named actor, created by nobody, that then appears in executive briefings. The control is structural: the extractor's output schema has no actor or intrusion-set type. If the source itself attributes, the model may capture that only as a quoted claim with the source as the asserting party.

Q: How should confidence be assigned to LLM-extracted threat intelligence?

Confidence should be computed from two inputs the model does not control and the model's own confidence field should be ignored. The first input is a source-tier table the CTI team maintains: a national CERT or vendor primary research might start at a base of 80, an ISAC member or established researcher at 60, and a forum paste or unknown blog at 25. The second input is the validation result, which can only lower the score, for example when the object resolves syntactically but references a malware or actor name not yet in your platform. Only deterministic code and analysts move confidence, and only analysts may raise it, with a recorded reason, which preserves the STIX confidence property as a meaningful signal downstream.

Q: What validation should run on extracted objects before they reach the threat intelligence platform?

Indicators must parse as the type claimed, with refanging done by a deterministic pass before the model sees the text so the model never guesses at hxxp or bracketed-dot notation. ATT&CK technique and sub-technique IDs must exist in the current STIX export of the knowledge base with the canonical name, rejecting invented, renamed or revoked IDs. CVE identifiers must exist in NVD. Malware, tool and actor names must match an existing object or be flagged as new rather than silently created. TLP markings from the source document must propagate as STIX marking definitions on every derived object. Every object must record the extraction model and prompt version so that a bad prompt's output can be recalled later.

Q: How is LLM threat intelligence enrichment different from AI-native SIEM alert triage?

They sit on opposite sides of the detection stack. AI-native SIEM triage consumes intelligence and telemetry to correlate thousands of alerts into a handful of incidents; its inputs are your own logs and its output is an incident queue. Threat intelligence enrichment produces intelligence: it takes unstructured external reports from vendors, CERTs, ISACs, researchers and leak sites and turns them into structured STIX indicators, techniques, malware and relationships that the SIEM, EDR and hunting teams then consume. The failure modes differ too. Triage errors mostly waste analyst time; enrichment errors create false indicators that every downstream control trusts, which is why the enrichment pipeline needs provenance and validation rather than just accuracy.

Q: Can an attacker use a threat report to attack the enrichment pipeline?

Yes, and the pipeline must assume some incoming documents are hostile. The simplest attack is pollution: a plausible advisory posted to a low-tier source lists a victim's or competitor's legitimate infrastructure as command-and-control, hoping an automated pipeline pushes it to blocklists and causes an outage. The second is prompt injection: text addressed to the extractor instructing it to emit particular objects or raise confidence. The source-tier model means low-tier material can never reach the confidence threshold used for automated blocking, and span-anchored validation with model confidence ignored means injected instructions that produce fabricated objects fail exactly as hallucinations do. Automated detection use additionally requires analyst review.

Q: Should a security team buy an AI-enabled threat intelligence platform or build the enrichment layer?

Buy the platform and build or closely scrutinise the extraction layer. Graph storage, STIX compliance, TAXII serving, connectors and sharing are solved by OpenCTI, MISP and commercial TIPs. Extraction quality decides the value of your intelligence and is where vendor AI features are least transparent. Ask whether every AI-generated object carries its source span and offset, whether the extractor can emit actor or intrusion-set objects and whether that can be disabled, whether confidence is model-assigned or computed from a source-tier table you control, whether ATT&CK mappings are validated against the current knowledge base, and whether extractor and prompt versions are recorded on each object for recall. Good answers to all five indicate a vendor worth paying for.