From OSINT Chaos to Knowledge Graph: Building Production-Scale AI-Powered Threat Intelligence

From OSINT Chaos to Knowledge Graph: Building Production-Scale AI-Powered Threat Intelligence

Speaker: Dongdong Sun (Senior Staff ML Engineer, Palo Alto Networks)

Conference: [un]prompted 2026 — The AI Security Practitioner Conference

Date: March 4, 2026, San Francisco

Watch on YouTube: https://www.youtube.com/watch?v=lib_KZKISOo

Reading time: ~9 minutes

TL;DR

Palo Alto Networks built a production system that converts unstructured open-source threat intelligence reports into a continuously updated knowledge graph, then deploys an LLM agent to answer complex multi-hop threat research questions against it. The result: threat intelligence that used to require hours of expert reading can now be synthesized in seconds — grounded in curated, source-attributable data rather than model memory.

Introduction

Threat intelligence has a structural problem that more feeds and more reports only make worse: the best information is buried in unstructured text, written by analysts for other analysts, and published faster than any human team can read it. Indicator feeds solve the machine-consumption problem but strip out the contextual understanding that makes intelligence actionable. Threat reports preserve context but are prohibitively time-consuming to process at scale.

Dongdong Sun, a Senior Staff ML Engineer at Palo Alto Networks working on threat intelligence systems, presented a solution that addresses both dimensions. His team built a pipeline that ingests open-source intelligence (OSINT) reports, extracts structured entities and relationships using LLMs, assembles them into a knowledge graph, and makes that graph queryable through a conversational AI agent that can reason across multiple hops and cite its sources.

The engineering challenges along the way — evaluation methodology, prompt engineering failures, human-AI collaborative curation — make this one of the more technically grounded production ML talks of the conference.

The OSINT Problem: Free, But Not Really

▶ Watch: Why OSINT data is harder than it looks (00:00)

Sun opened with a gentle provocation: threat intelligence data from open sources is free. "But is it really free?" The data exists, but extracting usable signal from it requires infrastructure, curation, and continuous maintenance that carry real cost.

The use cases Sun described are universal among threat intelligence teams. An analyst wants to know which malware families APT29 has used recently. Another analyst sees an unknown indicator in their logs and wants context from the community. A third needs the attack chain for a recently disclosed vulnerability. All of these are answerable from OSINT — but only if someone has already read and synthesized the relevant reports.

The scale of this problem is not trivial. A single detailed threat report, such as a vendor post on a critical vulnerability exploitation campaign, takes eleven minutes to read thoroughly. Sun demonstrated this with a real example: a recent report on the BeyondTrust critical vulnerability, covering the VShell and Spark-RT malware families, attack scope, historical context, and a list of indicators — a report that yields over 100 distinct entities and over 100 relationships when processed by their system.

Feeding all these reports directly into an LLM is impractical — context windows are finite, and model knowledge can be outdated or just wrong. What's needed is a structured intermediate representation that preserves both the machine-readability required for AI reasoning and the contextual richness that makes intelligence valuable.

Why a Knowledge Graph? The Semi-Structured Sweet Spot

▶ Watch: Knowledge graph as a semi-structured format (02:02)

Cybersecurity data is inherently relational. Malware families use specific attack patterns. Threat actors exploit specific vulnerabilities. Campaigns share infrastructure. The STIX format exists precisely to capture these relationships in a machine-readable way — but STIX's verbosity makes it difficult for humans to navigate and, interestingly, also creates challenges for LLMs. "AI likes unstructured text," Sun noted, "but you can't really give it too much."

The knowledge graph approach occupies a middle ground: a defined ontology that constrains what kinds of entities and relationships can be represented (providing structure), combined with natural-language descriptions attached to each node (preserving context). The result is what Sun called a "semi-structured data format" — enough constraint to support reliable reasoning, enough richness to support nuanced answers.

Nodes in the graph include malware families, threat actors, vulnerabilities, attack patterns, campaigns, and indicators of compromise. Edges capture relationships: exploits, uses, targets, relates-to, co-occurs-in-report. The ontology is the key design decision — it determines what questions the system can and cannot answer.

▶ Watch: Extracting the BeyondTrust report as a knowledge graph demo (04:02)

The Extraction Pipeline: LLMs as Structured Information Parsers

Getting from an unstructured threat report to a graph node isn't straightforward. Sun walked through the extraction architecture in detail.

The pipeline begins with a router LLM that scans each incoming report and determines whether it contains threat intelligence worth extracting. If it does, the router dispatches to specialized extraction components — one per entity type. Each component is designed to extract specific categories of information: malware, threat actors, vulnerabilities, attack patterns, campaigns, indicators.

For most entity types, the system grounds extraction to the exact phrasing in the report. "We try to ground it just to extract exactly how it's phrased in the report," Sun explained. This is a deliberate choice to minimize model confabulation — if the report says VShell, the graph says VShell.

Attack pattern classification presents a harder problem. Threat reports rarely include MITRE ATT&CK IDs directly; they describe behaviors that an analyst must map to the framework. The team's initial approach — simply asking the LLM to identify the appropriate MITRE technique — produced noisy results. Similar techniques got confused. The solution uses a chain-of-thought approach: the LLM first extracts the described behavior, then retrieves relevant candidate attack patterns from the MITRE knowledge base, reads those definitions, and self-corrects to a final answer. "LLM read related attack patterns from a knowledge base, and it will basically correct itself to land on a final attack pattern."

Relationship extraction at scale is the hardest problem. With over 100 entities per report, the number of possible relationships explodes combinatorially. The team constrained this by defining a fixed set of triplet types — (entity A) [relationship type] (entity B) — limiting extraction to the ontology rather than open-ended relationship discovery.

▶ Watch: The extraction architecture and MITRE classification challenge (08:02)

Evaluation: The Hardest Part of the Whole Project

▶ Watch: Building evaluation from scratch (10:02)

Sun was emphatic that evaluation consumed more than 50 percent of his team's engineering time — and he argued this is the right allocation. "If you're relying on this graph, and this graph is trash, then it's like trash out. You really can't fix anything from that point."

The challenge is that no benchmark existed for this task. Extracting threat entities and relationships from long, dense threat reports is specialized enough that the team had to build their own ground truth. The early approach — checking LLM outputs against external sources, using LLM evaluators — is limited to errors the team already knows how to look for. Missing information and incorrect attack pattern classifications require human expert judgment.

The team's workflow involved threat researchers doing initial annotation, with the system flagging disagreements between annotators. One unexpected finding: the automated reflection process discovered inconsistencies among the human annotators themselves. Analysts examining the same report independently sometimes classified the same entity differently — one as malware, another as a tool; one as a campaign, another as something else. The system surfaced these disagreements and forced resolution.

Automated prompt optimization was another tool in the evaluation loop. The team built a system using an LLM "reflection aggregator" that examines evaluation failures, generates hypotheses for why extraction went wrong, and proposes prompt modifications. This worked well but required a critical guardrail: the LLM was only allowed to modify specific sections of the prompt. Left unconstrained, it would sometimes fix one failure by breaking another, creating an unescapable loop.

A counterintuitive finding from production operation: newer LLMs do not necessarily outperform older ones on this task. And thinking/reasoning models perform worse than standard models. "Thinking model thinks too much, mostly relies on model knowledge, where actually the task we're doing is trying to reduce the model bias as little as possible, just rely on the sources at hand." Reasoning models are too confident in their internal knowledge to stay grounded in the document.

The LLM Agent: Querying the Graph Conversationally

▶ Watch: The LLM agent answering multi-hop threat questions (14:02)

With the graph built, the team deployed an LLM agent capable of traversing it to answer natural-language threat intelligence questions. The agent interacts with the graph by searching for nodes, walking edges, and retrieving subgraphs — assembling a picture of what the curated intelligence says about a given threat.

Sun demonstrated three increasingly complex queries live:

"What is the most recent BeyondTrust vulnerability and how is it being exploited?" The agent searched for BeyondTrust entities, found the relevant vulnerability, retrieved its subgraph, identified related threat actors and campaigns, and produced an attack chain — with citations back to the specific reports that sourced each claim.

"What malware does APT29 use?" The agent retrieved the threat actor's node, walked relationships to associated malware families, looked up aliases, and returned a synthesized list with sourcing. The multi-alias handling was notable: APT29 has multiple aliases in different reporting sources, and the agent knew to search across all of them.

"What vulnerabilities does APT28 exploit, and do any other threat actors exploit the same ones?" This multi-hop query required the agent to find APT28 → vulnerabilities → other threat actors exploiting those same vulnerabilities. Along the way, the graph surfaced that both APT28 and APT29 share certain infrastructure and targeting patterns — and that both are attributed to Russian intelligence services (GRU and SVR respectively), despite operating as distinct entities.

▶ Watch: APT28 vs APT29 multi-hop query demo (16:03)

The agent also uses co-occurrence search as a fallback for relationships not explicitly captured in the ontology: finding entities that appear together in the same source report, even if no formal relationship edge connects them. This lets the system surface connections the ontology didn't anticipate.

Critically, every answer includes provenance — which nodes and reports contributed to each claim. This source attribution is a key trust mechanism. Rather than relying on the model's internal knowledge (which may be outdated or simply wrong), the agent is constrained to cite the curated graph. This directly addresses the hallucination concern that the audience raised.

Notable Quotes

"Best thing about open source intelligence data, it's free. But is it really free?"

— Dongdong Sun (00:00)

"Thinking model thinks too much, mostly relies on model knowledge, where actually the task we're doing is trying to reduce the model bias as little as possible."

— Dongdong Sun (24:03)

"More than fifty percent of time I spend on just building evaluation — fighting with threat researchers A and threat researchers B. 'You guys disagree, get in a room, let's fight this out.'"

— Dongdong Sun (20:03)

Key Takeaways

• Knowledge graphs provide the right abstraction for threat intelligence. Semi-structured data preserves both machine-readability for AI reasoning and contextual richness for human understanding — bridging the gap between raw OSINT and usable intelligence.
• Invest heavily in evaluation before scaling. Garbage-in-garbage-out applies with unusual force to knowledge graph systems. More than half the engineering effort should go into evaluation methodology, including human expert ground truth.
• Reasoning models can hurt, not help, for grounding tasks. When the goal is to stay anchored to source documents rather than model knowledge, standard models outperform thinking models that over-rely on internal reasoning.
• Co-occurrence is a powerful fallback relationship. Entities mentioned in the same report share implicit context even when no formal ontology relationship captures it — exposing connections that structured extraction alone would miss.
• Source attribution is the key trust mechanism. An agent that cites the specific reports and graph nodes behind each claim is far more trustworthy than one that generates answers from model memory.