How should security teams handle raw IOCs in LLM-driven investigations?

Why raw indicators become a reliability problem in LLM-led investigations

Raw IOCs such as hashes, domains, IPs, paths, and user-agent fragments are useful evidence, but they are awkward inputs for an LLM when the same indicators reappear across many investigation steps. The model can waste context on repetition, drift when an IOC is copied slightly differently, or mis-handle structured output when long strings dominate the prompt. For investigation workflows, the issue is not whether the IOC is valuable, but whether the model sees it in a form it can reference consistently. OWASP’s OWASP Top 10 for Agentic Applications 2026 is relevant here because it highlights how agentic systems fail when inputs and tool interactions are not tightly controlled.

Security teams usually get better results when they treat raw IOCs as evidence to be normalised, indexed, and referenced, rather than as text to be re-pasted into every prompt turn. That preserves fidelity without forcing the model to reason over brittle literal strings. In practice, many security teams discover this only after duplicated indicators start producing inconsistent summaries or broken extraction outputs rather than through intentional prompt design.

What a compact IOC registry changes during an investigation

A compact registry changes the unit of reasoning. Instead of asking the model to remember a 64-character hash or a verbose URL every time, the workflow assigns a stable reference, such as an internal indicator ID, and stores the raw value outside the reasoning loop. The model can then associate that reference with the observable, the source, confidence, scope, and any transformations applied during normalization. This is especially useful when multiple tools need to consume the same indicator, because the registry becomes the shared source of truth rather than a chain of copied strings.

That approach also improves consistency when the same indicator appears in alerts, enrichment results, containment steps, and analyst notes. The model can compare references instead of re-parsing raw text, which lowers the chance that a formatting difference creates a false distinction. It also reduces prompt congestion, leaving more room for timeline reasoning, correlation, and hypothesis testing.

• Store the original IOC once, then refer to it by a short internal key in subsequent turns.
• Keep normalization rules explicit so a domain, URL, or hash always maps the same way.
• Track provenance alongside the reference so analysts can recover the original evidence when needed.
• Use the registry to separate observed indicators from deduplicated entities and derived relationships.

For AI governance and investigation workflows, NIST’s NIST AI Risk Management Framework is a useful companion because it stresses reliable, traceable AI outputs rather than ad hoc prompt handling. Where teams overfit to raw strings, the workflow breaks down when the model has to compare many indicators at once, ingest untrusted content, or produce a machine-readable response from dense evidence.

When raw IOC handling stops being a simple formatting choice

Tighter normalization often increases upfront handling overhead, requiring teams to balance analyst speed against evidence fidelity and automation reliability. The trade-off is real: a registry adds one more layer to maintain, but it avoids the far larger cost of inconsistent references across a multi-step investigation.

The standard pattern breaks down when an IOC must be preserved exactly as seen for legal, forensic, or enrichment reasons. In those cases, the raw value should remain available, but not as the primary object the model reasons over. There is also a difference between high-volume campaign triage and a one-off analysis: at small scale, direct use of raw indicators may be tolerable; at scale, repeated literal strings make model behavior less stable and more expensive to operate. Guidance is still converging on how much transformation is appropriate for sensitive observables, so teams should label that boundary explicitly rather than assume one universal rule.

Another edge case is weak or ambiguous indicators. A short substring, partial IP, or noisy file path can be too unstable to normalise aggressively because the transformation may erase useful context. In those situations, the registry should carry both the compact reference and the uncertainty attached to the original observable. The method becomes less effective if the registry is treated as a storage shortcut instead of a controlled layer for identity, provenance, and comparison. The guidance fails when investigators need exact literal matching inside the model itself rather than stable external references.

Practitioner Guidance

What to prioritise: Preserve the raw IOC outside the model, but make the model reason over a stable reference plus metadata. The first design question is whether the investigation needs exact literal recall or consistent cross-step reasoning; most workflows need the latter more often than the former.

What to verify: Confirm that every normalized indicator can be traced back to its original form, source, and confidence level. If analysts cannot reconstruct that chain quickly, the registry has become opaque rather than useful.

Common mistake: Copying the same raw IOC into multiple prompts because it feels safer. That usually increases token waste and inconsistency while giving a false sense of precision.

What practitioners underestimate: The real gain is not just shorter prompts. It is that the model can compare indicators as objects in a controlled vocabulary, which makes correlation, deduplication, and downstream automation far more dependable.

Practitioner takeaway: Treat raw IOCs as evidence records, not as the reasoning substrate. The more your workflow depends on repeated model interaction, the more important it becomes to separate exact observables from the compact references the model uses to think.

Related resources from NHI Mgmt Group

• How should security teams handle exposed secrets in AI-driven environments?
• How should security teams handle prompt injection in production LLM applications?
• How should security teams handle AI-driven phishing in identity workflows?
• How should security teams handle trust assumptions in LLM and AI agent workflows?