AI Lab Blog

Using LLMs for Incident Timeline Compression

February 21, 2026

Tags: Incident Response, Automation

Incident response is often a fight against time and volume. The attacker may have taken only seven meaningful actions, but the responder is staring at thousands of log lines, duplicated alerts, endpoint events, proxy records, identity events, and cloud audit entries. The work is not simply to read more. The work is to preserve the story without losing the evidence.

That is where LLMs can help. Not by “solving” the incident, and not by replacing forensic analysis, but by compressing raw event streams into an analyst-readable timeline. Done well, timeline compression reduces time-to-understanding. Done badly, it creates a confident narrative that hides the very gaps a responder needs to see.

The difference is process.

Compression is not summarization

Summarization asks, “What is this about?” Timeline compression asks, “What happened, in what order, according to which sources, and what remains uncertain?”

That distinction matters. A summary can flatten time. It can merge events that happened minutes apart. It can ignore duplicate records or treat repeated failures as noise. In an investigation, those details may be the signal. A failed login before a successful login matters. A process launch before a network connection matters. A privilege assignment before a storage access event matters.

A compressed timeline should preserve sequence integrity. It should reduce volume without erasing causality.

Start with a strict event shape

Before sending logs to a model, normalize them into a simple event shape. The exact schema can vary, but the fields should be consistent:

{
  "timestamp": "2026-02-22T14:03:18Z",
  "source": "edr_process",
  "host": "WS-1842",
  "user": "CORP\j.smith",
  "event_type": "process_start",
  "summary": "powershell.exe launched with encoded command",
  "evidence_ref": "edr:48291:process:7",
  "raw_excerpt": "powershell.exe -enc ..."
}

This does three things. It makes the model’s job easier, it reduces the chance that fields get blended together, and it creates a stable evidence reference the analyst can use later. The model should not be asked to infer evidence references after the fact. They should travel with the event from the beginning.

If the team cannot normalize everything, normalize the top layer: timestamp, source, entity, event type, summary, evidence reference. That is enough to improve timeline quality.

Use phased compression

Do not feed a large incident into a model and ask for a final narrative in one pass. A better approach is phased compression.

First, group events by entity. Build separate slices for host, user, IP, process lineage, cloud resource, or mailbox. Ask the model to identify meaningful events within each slice and preserve evidence references.

Second, merge the slices into a candidate timeline. At this point, the model can help deduplicate repeated records and align events that appear in multiple sources.

Third, map events to incident phases. The phases do not need to be perfect, but the exercise forces the model to explain why an event matters. Common phases include initial access, execution, persistence, privilege escalation, defense evasion, discovery, lateral movement, collection, exfiltration, and impact.

Fourth, produce an analyst brief that separates confirmed events from inferred links.

This staged process gives analysts control points. They can review host timelines before reading the merged timeline. They can catch bad assumptions earlier. They can decide whether the model compressed too aggressively.

A useful compression prompt

A practical prompt should constrain the model’s behavior:

You are assisting an incident responder with timeline compression.
Use only the events provided.
Preserve chronological order.
Do not merge events unless they describe the same action from different telemetry sources.
For each timeline entry include:
- timestamp or time range
- event summary
- involved entities
- source systems
- evidence references
- why it matters
- uncertainty or caveat
After the timeline, list gaps that prevent confident assessment.
Events:
[PASTE NORMALIZED EVENTS]

The output should look more like an investigative worksheet than a polished story. Polished stories are for final reports. During response, the analyst needs a working timeline with caveats.

Deduplication without distortion

Security telemetry is repetitive. An endpoint alert, process event, network connection, and SIEM correlation may all describe the same attacker action. Compression should reduce duplicates, but it must not erase independent confirmation.

A good compressed entry might say:

14:03:18Z - Encoded PowerShell executed on WS-1842 under CORP\j.smith.
Sources: EDR process telemetry, SIEM alert rule PS-EncodedCommand.
Evidence: edr:48291:process:7, siem:alert:99312.
Why it matters: Possible execution stage. Encoded command may indicate obfuscation.
Caveat: Command content has not been decoded in the supplied evidence.

This is better than listing the EDR and SIEM events separately. It is also better than saying, “Attacker executed malicious PowerShell.” The compressed entry keeps the evidence and avoids overstating intent.

Preserve negative space

One of the most valuable things a timeline can show is absence. No evidence of successful authentication after a password spray. No outbound transfer after file staging. No persistence event after execution. No administrative role use after suspicious consent.

Models are not naturally good at preserving negative space unless asked. Add an explicit section:

Identify important events that are missing from the supplied evidence.
Do not assume they did not happen. State only that they are not present in this dataset.

That language matters. “Not present in the dataset” is different from “did not occur.” A professional incident report should respect that difference.

Use compression ratios carefully

Teams sometimes want a neat metric: 10,000 events compressed into 30 timeline entries. That can be useful, but compression ratio is not quality. A timeline with 30 entries can still be wrong. A timeline with 120 entries may be appropriate for a complex intrusion.

Better quality indicators include:

• every entry has an evidence reference;
• timestamps remain in order;
• inferred links are labeled;
• missing telemetry is listed;
• duplicated events are merged without losing source diversity;
• the analyst can pivot from each compressed entry to raw records quickly.

The goal is not the shortest timeline. The goal is the shortest timeline that remains true.

Where LLMs help most

LLMs are useful for entity grouping, rough phase mapping, duplicate detection, and drafting analyst-readable language. They are also useful for transforming awkward vendor-specific event descriptions into consistent phrasing.

They are weaker at forensic certainty. A model may infer causality from proximity. It may treat a common admin tool as malicious because it appears in an incident context. It may miss a subtle timestamp issue, such as local time versus UTC. It may over-trust an alert name. If the alert says “credential dumping,” the model may repeat that label even when the underlying evidence only shows access to a sensitive process.

That means the model should be used as a compression engine, not a truth engine.

Operational guardrails

A production timeline compression workflow should include guardrails.

Limit the evidence window. Tell the model whether it is looking at 30 minutes, 24 hours, or seven days. Without that frame, it may overstate completeness.

Normalize time zones before analysis. Mixed local time and UTC will poison the timeline.

Require evidence references. Any entry without a source reference should be rejected or marked as unverified.

Separate confirmed from inferred. A connection after a process launch does not prove causality unless the telemetry supports it.

Keep raw logs accessible. The compressed timeline should link back to raw records, not replace them.

Review the timeline before action. Do not let a compressed narrative become the basis for containment unless an analyst has verified the underlying evidence.

A final report is different

During response, the timeline should be caveated and operational. After response, the team can turn it into a narrative report. The same model can help with that transformation, but the prompt should change. A final report needs clarity for leadership, legal, compliance, or customers. It also needs careful wording around confidence and impact.

Do not skip the working timeline. The final narrative is only as good as the investigative timeline underneath it.

The bottom line

LLMs can compress incident timelines in a way that materially helps responders. They can reduce noise, align related events, and produce a working sequence faster than a human starting from raw logs alone.

But timeline compression is only trustworthy when sequence, source, and uncertainty survive the compression. If the model produces a cleaner story by hiding evidence gaps, it has made the incident harder to understand, not easier.

The best use of AI in incident timelines is not to make the investigation sound finished. It is to help the analyst see what happened next.