Why do generic prompts fail on endpoint investigations with noisy telemetry?

Why generic prompts collapse once endpoint telemetry gets noisy

Generic prompts usually assume the model can sort a mostly clean event stream into a neat story. Endpoint investigations are different: the analyst is looking through legitimate binaries, admin activity, service churn, scheduled tasks, and repeated low-value telemetry to find a small number of suspicious actions. When the prompt does not narrow the search to the right signal class, the model tends to flatten the investigation into broad but weak observations.

That failure is not just about wording. It is about the mismatch between a language model’s tendency to weight whatever is most visible and the investigator’s need to prioritise what is most diagnostic. If the prompt does not force the model to separate baseline noise from anomalous behaviour, it will often describe the whole dataset instead of the few events that matter.

In practice, the prompt has to help the model reason about MITRE ATT&CK Enterprise Matrix style clues, such as process lineage, credential access, lateral movement, and privilege escalation, because those are often buried inside otherwise ordinary endpoint activity.

What the noise floor does to endpoint triage

Noise floor is the key analytical problem. Endpoints generate a large amount of expected activity from operating system components, endpoint tools, software updates, developer tooling, and human administrators. None of that is suspicious by itself, but all of it can look similar to attacker tradecraft if the prompt asks only for "interesting events" without defining what interesting means in context.

The result is a ranking problem. Generic prompts encourage the model to overfit on frequency, novelty, or vocabulary that looks unusual in isolation. Endpoint investigation requires the opposite: attention to small deviations from normal sequences, unusual parent-child relationships, unexpected command-line parameters, and context that only becomes meaningful when correlated across time.

That is why investigation prompts work better when they explicitly ask for audit, integrity, and configuration control signals alongside suspicious process behavior. The model needs a frame that separates routine administration from behavior that changes the trust posture of the host.

How to write prompts that survive noisy telemetry

Effective prompts constrain the task instead of asking for a broad summary. They should define the host, the time window, the telemetry type, and the suspicious pattern you care about, then ask for evidence of deviation rather than general commentary. A prompt that asks for encoded commands, unusual process ancestry, persistence artifacts, or remote execution indicators gives the model a smaller and more useful search space.

It also helps to instruct the model to ignore benign repetition unless it supports a specific hypothesis. On endpoints, repetition is often the default state, so the investigation needs explicit filters for admin tooling, known updater paths, and vendor agents. A good prompt pushes the model toward differential analysis: what changed, what is rare for this asset, and what sequence would be hard to explain as ordinary operations.

For API-driven telemetry pipelines or host data exposed through services, the same discipline applies to access and resource boundaries. Broken access assumptions can distort what data is visible, so it is worth anchoring the investigation to the actual telemetry source and its trust boundary, as described in the OWASP API Security Top 10.

Risk and Threat Considerations

Noisy endpoint telemetry can hide small but high-value attacker actions, especially when the attacker blends into normal administration, scripted maintenance, or repetitive process activity. The main risk is missed detection: the model returns a plausible narrative while the decisive clue sits below the noise floor.

Failure mechanism: Generic prompts do not force a distinction between baseline activity and rare, adversary-relevant deviations, so the model distributes attention too evenly across the dataset and misses the few events that carry investigative weight.

Impact: Analysts can lose time, mis-rank alerts, and overlook process chains, command encodings, or execution patterns that would have raised confidence in compromise if the prompt had been more specific.

Practitioner Guidance

What to prioritise: Start with the signal class, not the story. Ask first for process lineage anomalies, encoded commands, unusual child processes, suspicious persistence, and evidence of privilege change, then let the model explain the rest.

What to verify: Check whether the prompt forces comparison against a baseline for that endpoint role. If it does not, the result will usually overstate benign admin activity and understate adversary behavior.

Common mistake: Do not ask the model to "summarize the alerts" when you actually need it to isolate rare attacker clues from high-volume legitimate telemetry. Summary is the wrong abstraction when the investigative problem is discrimination.

Practitioner takeaway: The quality of the endpoint investigation depends less on prompt elegance than on whether the prompt makes the model hunt for deviations that matter instead of narrating the entire noise field.

Related resources from NHI Mgmt Group

• Why do broad LLM prompts fail in endpoint log analysis?
• How should security teams design AI-driven SOC investigations when network telemetry is fragmented compared with endpoint or identity data?
• Why do generic prompts and synthetic datasets often fail to improve agent performance?
• Why does noisy Active Directory telemetry make investigations harder?