From Attack-Chain Completion to Causal Threat Licensing

Large language models are very good at completing patterns.

That is both their power and their weakness. Ask an LLM to describe a plausible cyberattack, and it will usually produce something that sounds right: initial access, exploitation, credential theft, lateral movement, ransomware, data breach, impact. The sequence feels familiar because it resembles thousands of incident reports, playbooks, CTI summaries, and training materials.

But “sounds like a cyberattack” is not the same as “is causally coherent.”

That distinction matters. Most current work on LLM-assisted cyber reasoning tries to make generated attack paths more useful, more complete, or more aligned with known security frameworks. That work is valuable. AEGIS combines LLMs, white-box access, and Monte Carlo Tree Search to generate attack paths for cyber-defense exercises. CTI-Thinker uses LLMs, RAG, and cyber-threat-intelligence knowledge graphs for structured extraction and attack-chain inference. ThreatCompute combines LLMs with attack graphs to generate threat hypotheses and risk models for Kubernetes environments.

The broader LLM-and-causality field is also active. CausalGraph2LLM evaluates how well LLMs answer causal-graph queries and shows that model performance is sensitive to graph encoding. CausalBench evaluates LLM causal-learning capability and reports that LLMs can handle simpler causal structures but struggle on larger causal networks.

So the point of this article is not “LLMs need causality.” That is already understood.

The point is narrower:

Cyber LLM generation should not be constrained only by descriptive cyber graphs. It should be licensed by a cause-side threat ontology.

That is where TLCTC enters.

TLCTC — the Top Level Cyber Threat Clusters framework — is not a technique catalogue, not a control catalogue, and not an actor taxonomy. It classifies cyber threats by the generic vulnerability exploited in each attack step. One step, one generic vulnerability, one cluster. Outcomes such as “ransomware,” “data breach,” or “service outage” are not threat clusters; they belong on the event or consequence side.

This makes TLCTC useful for something LLMs do not have natively: causal discipline.

The proposal is simple:

Use TLCTC not merely as a classification framework after generation, but as a causal licensing layer before and during generation.

The LLM may propose.
The TLCTC structure licenses.
Only causally valid paths survive.

The Problem: Cyber Generation Is Usually Correlation-Driven

LLMs generate by statistical continuation. At the text level, this is not controversial: given a context, the model predicts what is likely to follow. In cybersecurity, that leads to a specific failure mode. The model has seen that “phishing” is often followed by “credential theft,” which is often followed by “lateral movement,” which is often followed by “ransomware.” So it produces that sequence.

The result may be operationally familiar but causally loose. It may skip required steps, turn outcomes into threats, collapse credential acquisition and credential use, confuse topology with classification, or treat “privilege escalation,” “lateral movement,” and “impact” as if they were cause-side threat classes.

This is not merely hallucination in the everyday sense of “the model made something up.” It is a structural failure: the model has generated cyber language that is plausible but not licensed by a causal threat model.

That is the gap between attack-chain completion and causal threat reasoning.

The Existing Direction: LLMs Plus Graphs

The field is already moving toward constrained generation. That is the right direction.

But a generated path inherits the semantics of the structure that constrains it. If the graph is ATT&CK-based, the path is largely behavior- and technique-shaped. MITRE ATT&CK is a globally accessible knowledge base of adversary tactics and techniques based on real-world observations, and it is widely used as a foundation for threat models and methodologies. But ATT&CK is not a stable strategic cause taxonomy. It describes adversary behavior. TLCTC classifies why an attack step works.

If the graph is CVE-based, it is vulnerability-specific. That is useful, but too concrete and dependent on known defects. If the graph is topology-based, it describes reachability. That is useful, but topology is not classification. If the graph is asset-based, it describes what exists. That is useful, but assets do not explain the generic vulnerability exploited.

TLCTC changes the constraint. It does not ask:

“Which technique usually follows this technique?”

It asks:

“What generic vulnerability must be exploited for this step to be valid?”

That is a different kind of graph.

The Claim: Causal Licensing, Not Free Composition

The claim is not that TLCTC replaces the internal mathematics of an LLM. At the token level, the LLM still generates autoregressively. It still produces language by predicting likely continuations.

The change happens one layer above text.

Instead of asking the model to freely generate an attack story, we introduce a causal path layer:

s₁ → s₂ → s₃ → s₄

Each sᵢ is not a word or sentence. It is a licensed attack-step state. In TLCTC terms, each step must map to exactly one cause cluster:

#9 → #4 → #1 → #7

The model may propose a path, but the path must satisfy TLCTC constraints: each step must exploit one generic vulnerability; credentials must be split into acquisition and use; foreign executable content must be recorded when it executes; man-in-the-middle position and man-in-the-middle exploitation must not be collapsed; flooding must mean finite-capacity exhaustion; supply-chain classification must occur at the Trust Acceptance Event; and outcomes must not be treated as threats. The TLCTC application procedure states this directly: classification operates on attack steps, not whole incidents, and each step is classified independently into exactly one cluster.

This turns generation into constrained path construction.

The LLM becomes the narrator and hypothesis generator.
The causal ontology becomes the licensing authority.

This is also why the phrase “causal threat licensing” is better than “causal generation.” The LLM still generates. TLCTC licenses the semantic path.

What Actually Does the Rejecting?

A critical point: the rejection power is not mainly “edge sparsity.”

A naïve version of this idea would imagine a sparse transition graph where most cluster-to-cluster edges are forbidden. But at the top level, the ten TLCTC clusters can combine in many ways. In real intrusions, #9 can enable #4, #7, #1, or even #3. #4 can enable #1, #2, #7, or additional #4 steps. #2 and #3 can enable #7. #7 can enable credential acquisition, function abuse, exfiltration, and further execution. A top-level enablement graph over ten clusters may therefore be fairly dense.

That is not a weakness. It just means the real licensing power lives elsewhere.

First, it lives in the node ontology. “Ransomware,” “lateral movement,” “data breach,” “privilege escalation,” “impact,” “discovery,” and “persistence” are not TLCTC cause nodes. Some are outcomes. Some are operational labels. Some are effects. Some are ATT&CK tactics or technique families. A TLCTC-constrained generator rejects them as threat-cluster states.

Second, it lives in the R-rules. Credential acquisition and credential use must be split. Foreign executable content execution must be recorded as #7. A server-role implementation flaw is #2; a client-role implementation flaw is #3. A communication-path position is not automatically #5; exploiting that position is. A volume-driven outage is #6; a crash triggered by a bug is #2 or #3.

Third, it lives in step granularity. When one natural-language sentence contains two causes, TLCTC forces the sentence to split. The decision tree makes this explicit: when an observation seems to match multiple questions, that is a signal to split it into separate steps and re-enter the tree for each one.

So the honest claim is not:

“The graph forbids most transitions.”

The honest claim is stronger:

“The ontology rejects invalid nodes, and the rules force causal decomposition.”

That is where LLM output becomes auditable.

Hallucination Becomes Three Different Things

This gives us a more precise vocabulary for LLM error in cyber generation.

1. Structural hallucination

The model generates a node, edge, boundary, or event placement that violates the causal ontology.

Example:

#9 → ransomware → data breach

Invalid. “Ransomware” is not a TLCTC threat cluster. “Data breach” is not a threat cluster. The path must express the cause-side steps and record the data risk events separately.

2. Grounding hallucination

The generated path is structurally valid, but the evidence does not support it.

Example:

#9 → #4 → #1 → #7 + [DRE: Ac]

This may be a valid TLCTC path, but it is still wrong if the incident evidence does not show credential use, function abuse, or foreign executable content execution. The graph can license the structure. It cannot invent evidence.

3. Granularity hallucination

The model skips required atomic steps.

Example:

phishing → credential theft → admin access

This collapses at least two different TLCTC questions. Was the human psychologically manipulated? That is #9. Were credentials disclosed? That is an outcome of the enabling step, usually + [DRE: C]. Were the credentials later presented to authenticate? That use is #4. TLCTC’s credential rule states that acquisition maps to the enabling cluster, while application is always #4; if both occur, they must be represented as at least two steps.

This taxonomy of error is the practical payoff. A TLCTC-constrained system does not make all hallucination disappear. It makes one class — structural hallucination — mechanically checkable, while forcing grounding and granularity errors into reviewable categories.

A Demonstration: From Attack Story to Licensed Path

Here is the kind of output an unconstrained LLM often produces when asked to summarize a multi-stage enterprise intrusion:

The attacker exploited an internet-facing appliance, moved into Confluence,
stole credentials, performed lateral movement into Active Directory, escalated
to Domain Admin, exfiltrated data, disabled backups, and deployed ransomware.

Operationally, this is recognizable. Causally, it is under-specified.

A TLCTC validator would flag at least six problems.

First, “exploited an internet-facing appliance” is not specific enough. If the attacker triggered a code flaw in a server-role component, the step is #2 Exploiting Server. If they used valid credentials against the appliance, the step is #4. If they abused a legitimate admin function, it is #1.

Second, “moved into Confluence” is not a cause. Did the attacker exploit a Confluence server flaw? Use credentials? Abuse an integration token? Upload and execute foreign content? The label names a target, not the generic vulnerability.

Third, “stole credentials” collapses acquisition and use. Credential acquisition belongs to the enabling cluster, with a confidentiality data risk event if credential material is exposed. Credential use is a separate #4 step.

Fourth, “lateral movement” is not a TLCTC cluster. It is an operational movement label. The causal step might be #4 if credentials were used, #1 if legitimate remote administration functions were abused, #2 if a server flaw was exploited, or #7 if malware executed.

Fifth, “escalated to Domain Admin” is an effect, not a cluster. The causal path might be abuse of Active Directory functions, credential use, exploitation of a server, or a chain of these.

Sixth, “ransomware” is not a threat cluster. If foreign executable content runs, that is #7. If files remain present but encrypted, the data risk event is Loss of Accessibility: + [DRE: Ac]. TLCTC records DRE tags as outcomes, never as steps, and distinguishes Av from Ac when the distinction matters.

A TLCTC-licensed rewrite might look like this:

#2 ||[edge][@Attacker→@Org(F5)]||
→[Δt=?] #2 ||[app][@Attacker→@Org(Confluence)]||
→[Δt=?] #7
+ [DRE: C]
→[Δt=?] #4 ||[auth][@Attacker→@Org(AD)]||
→[Δt=?] #1
+ [DRE: C]
→[Δt=?] #4
→[Δt=?] #1
+ [DRE: Av]
→[Δt=?] #7
+ [DRE: Ac]

The Δt annotations mark elapsed time between adjacent attack steps; they are edge properties, not clusters. TLCTC uses them to express attack velocity and compare attacker speed with detection and response speed.

Several steps are marked Δt=? because the transition timing is unknown. TLCTC also allows epistemic-state annotations such as #X [conf=low], #X [inferred], and unresolved ? / … when evidence confirms a gap but no defensible cluster assignment exists. Unresolved operators are epistemic annotations, not clusters, and a path containing them must explain what is unresolved.

The important point is that the licensed path is not merely “more detailed.” It is categorically different. The original is an attack story. The rewrite is a causal trace.

It says:

• the appliance and Confluence exploitation are server-role flaw steps if the evidence supports code-flaw exploitation;
• credential exposure is recorded as + [DRE: C];
• use of exposed credentials is a separate #4;
• Active Directory enumeration, group changes, DCSync, or backup deletion are usually #1 when they abuse designed functions at the authority the attacker holds; DCSync receives + [DRE: C] because the abused replication function exposes credential material, so the confidentiality event occurs at the replication/read step;
• execution of attacker-controlled binaries is #7;
• exfiltration and credential disclosure are confidentiality events;
• encryption is Loss of Accessibility, not a new threat.

The Active Directory ransomware cascade example in the TLCTC application paper follows the same logic: a valid-credential foothold is #4, post-foothold AD activity such as enumeration and DCSync is structurally #1, DCSync is #1 + [DRE: C], later credential presentation is a separate #4, backup destruction is #1 + [DRE: Av], and ransomware payload execution is #7 + [DRE: Ac].

That is the demonstration: a familiar attack narrative becomes a set of licensed cause-side steps plus explicitly placed data risk events.

Why ATT&CK-Constrained Is Not the Same as Cause-Constrained

MITRE ATT&CK is extremely useful. It gives practitioners a shared vocabulary for adversary behavior and supports detection engineering, threat intelligence, red-team emulation, and incident analysis.

But ATT&CK-constrained generation and TLCTC-constrained generation answer different questions.

An ATT&CK-shaped path may say:

Exploit Public-Facing Application
→ Valid Accounts
→ Account Discovery
→ Remote Services
→ Data Encrypted for Impact

This is not nonsense. It is operationally useful. But it is still not fully causal.

What made “Remote Services” succeed? Credential use? Abuse of a legitimate admin function? Malware? A server exploit? What caused “Data Encrypted for Impact”? Foreign executable content? Built-in encryption tooling? Abuse of a storage function? What exactly happened between credential acquisition and credential application?

ATT&CK describes behavior. TLCTC asks for the generic vulnerability exploited by each step. The TLCTC application paper positions the ATT&CK mapping as a reference aid for translating observed adversary actions into clusters, but not as a replacement for the per-step cause-first procedure.

That is why the two frameworks should not be treated as competitors.

ATT&CK can supply operational candidates.
TLCTC supplies causal licensing.

A useful system should be able to run this loop:

ATT&CK candidate path
→ TLCTC cause validation
→ missing-step expansion
→ licensed attack path
→ analyst-readable narrative

The model may propose an ATT&CK-shaped path. TLCTC decides whether the causal skeleton is valid.

The Graph Becomes the Product

If generation is constrained by a causal ontology, the durable asset is no longer the model alone.

The durable asset is the graph.

The model can change. The weights can change. The vendor can change. The interface can change. But the expert-authored causal model remains the auditable artifact.

That graph can be versioned, reviewed, tested, diffed, governed, cited, embedded in tools, and used across incident documentation, detection engineering, reporting, and risk governance. This is a different product philosophy from “fine-tune a model and hope it learns the domain.”

The LLM becomes interchangeable infrastructure.
The causal graph becomes the source of truth.

This matters because cybersecurity already suffers from semantic diffusion. The same words are used for causes, outcomes, actors, controls, consequences, and reporting labels. LLMs do not solve that problem automatically. They can amplify it. They ingest the field’s language confusion and reproduce it fluently.

That means the answer is not just better prompting. The answer is a better semantic substrate.

TLCTC already points in this direction through its Open Knowledge Format idea: render the taxonomy, clusters, axioms, rules, mappings, and attack paths into an agent-consumable structure so an LLM-based tool can ground classification in authoritative cluster and rule definitions.

Causal threat licensing is the generative version of that idea.

Counterfactuals Become Mechanically Expressible

A TLCTC graph does not automatically give us full Pearl-style causal inference. For that, we would need structural equations, variable definitions, empirical probabilities, and intervention semantics.

But even before that, the graph gives us something useful:

mechanically expressible counterfactuals.

For example:

Observed path:
#9 → #4 → #1 → #7 + [DRE: Ac]

Now ask:

What if #4 had been blocked?

The system can remove or block the credential-use continuation and re-evaluate which downstream paths remain reachable.

Or ask:

What if #7 execution were prevented?

The system can preserve the earlier compromise path while blocking the malware execution step and its associated + [DRE: Ac].

Or ask:

What if phishing occurred but no credentials were disclosed?

The system can preserve #9 but remove the credential-disclosure consequence and the later #4 application.

This is not full statistical causal inference. But it is already better than free-form speculation. The model is no longer merely imagining “what might have happened.” It is traversing a constrained causal structure.

A Minimal Architecture

A near-term implementation does not need to be complex.

It needs five components.

1. TLCTC state space

The strategic layer supplies the ten top-level clusters:

#1 Abuse of Functions
#2 Exploiting Server
#3 Exploiting Client
#4 Identity Theft
#5 Man in the Middle
#6 Flooding Attack
#7 Malware
#8 Physical Attack
#9 Social Engineering
#10 Supply Chain Attack

The operational layer can refine these with machine-addressable TLCTC-XX.YY notation where needed.

2. Candidate transition model

Edges encode possible enablement relationships, but the system should not rely on edge sparsity alone. At the top level, many transitions may be possible depending on evidence and context.

The edge model should therefore be treated as a hypothesis space, not the main validator.

3. Ontology validator

This rejects invalid nodes:

ransomware           → not a threat cluster
data breach          → DRE / consequence, not a threat cluster
lateral movement     → operational label, not a threat cluster
privilege escalation → effect, not a threat cluster
actor group          → actor metadata, not a threat cluster
control failure      → control-risk fact, not a threat cluster

4. R-rule validator

This enforces TLCTC’s causal boundaries:

R-CRED: acquisition ≠ use; use is always #4.
R-EXEC: if FEC executes, record #7.
R-ROLE: server-role flaw = #2; client-role flaw = #3.
R-MITM: gaining position ≠ exploiting position.
R-FLOOD: capacity exhaustion = #6; defect-triggered crash = #2/#3.
R-SUPPLY: #10 occurs at the Trust Acceptance Event.

5. LLM narrator

The LLM performs the tasks it is good at:

propose candidate paths;
translate incident prose into candidate steps;
map ATT&CK/CVE/CWE language into TLCTC candidates;
ask for missing evidence;
explain why a path was rejected;
generate analyst-readable narratives.

But the ontology and R-rules decide what is admissible.

What This Is Not

This is not full causal AI.

It is not a replacement for incident evidence.

It is not a claim that TLCTC alone determines probability.

It is not a claim that an LLM can infer causality reliably from text without external structure.

It is not a replacement for ATT&CK, CVE, CWE, attack graphs, or detection engineering.

The claim is narrower and stronger:

Cyber LLM generation should be constrained by a cause-side threat ontology, not only by descriptive technique graphs.

A first implementation could simply reject invalid nodes, force missing-step expansion, and convert outcome labels into proper DRE or consequence annotations. Even that would improve cyber reasoning dramatically.

Why This Matters

Cybersecurity already suffers from semantic diffusion. We call ransomware a threat, even though it is an outcome pattern. We call phishing a threat, even though different phishing cases enable different causal paths. We call data breach a threat, even though it is a confidentiality event. We call lateral movement a threat, even though it is an operational label that can be caused by different clusters.

LLMs amplify this problem because they reproduce the field’s ambiguity fluently.

Causal threat licensing offers a way out.

It does not make the LLM omniscient. It does not make evidence unnecessary. It does not magically solve grounding. But it does force a generated cyber path to respect cause-side structure before it becomes prose.

The long-term vision is not a chatbot that talks about cyberattacks. It is a causal cyber reasoning layer that can classify attack steps, reject invalid sequences, preserve the distinction between causes and outcomes, generate counterfactual scenarios, map operational frameworks into a stable strategic layer, and produce auditable attack-path records.

That is the shift from attack-chain completion to causal threat licensing.

The LLM proposes.
The ontology licenses.
The analyst audits.
The organization learns.

And one class of hallucination stops being bad prose and becomes a graph violation.

References

AEGIS: White-Box Attack Path Generation using LLMs and Training Effectiveness Evaluation for Large-Scale Cyber Defence Exercises. The paper presents an LLM-based workflow with white-box access and Monte Carlo Tree Search for generating attack paths in cyber-defense exercises.

CTI-Thinker: An LLM-driven system for CTI knowledge graph construction and attack reasoning. The system uses LLMs for CTI extraction, knowledge-graph construction, and attack reasoning.

ThreatCompute: Leveraging LLMs for Automated Threat Modeling of Cloud-Native Applications. The system uses LLM-generated threat hypotheses and attack graphs for cloud-native, Kubernetes-oriented threat modeling.

CausalGraph2LLM: Evaluating LLMs for Causal Queries. The benchmark contains more than 700k causal-graph queries and reports sensitivity to graph encoding.

CausalBench: A Comprehensive Benchmark for Causal Learning Capability of LLMs. The benchmark evaluates LLMs on causal-learning tasks and reports weaker performance on larger causal networks.

MITRE ATT&CK: official knowledge base of adversary tactics and techniques based on real-world observations.