Why do AI security tools struggle when evidence is split into chunks?

Why This Matters for Security Teams

Chunked evidence is common in AI security pipelines because it makes search, retrieval, and model inference tractable. The problem is that chunks often arrive stripped of the instructions, provenance, and collection context that explain what the data means. Once that context is lost, the model can correlate unrelated fragments, miss temporal order, or treat one event as if it were a complete incident.

This matters most in NHI and secrets investigations, where a single token leak, OAuth grant, or plugin event only becomes actionable when linked to the surrounding workflow. NHIMG research on The State of Secrets in AppSec shows how fragmented controls and slow remediation already weaken response, while incidents like the JetBrains GitHub plugin token exposure and Code Formatting Tools Credential Leaks show how quickly isolated evidence can mislead defenders if the surrounding context is not preserved.

Security teams usually do not fail because they lack data. They fail because they let retrieval systems decide what the evidence means after the original context has already been discarded. In practice, many security teams encounter false confidence only after a partial reconstruction has already hidden the real attack path.

How It Works in Practice

The operational fix is to treat each chunk as a context-bearing object, not a standalone fact. That means preserving the original query, source, timestamp, source system, collection method, and any chain-of-custody metadata alongside every segment. When a model or analyst reviews a later chunk, it should still know what question triggered collection, what entity the evidence relates to, and whether the fragment is primary evidence or supporting material.

For security tooling, this usually means designing the pipeline so retrieval returns both content and provenance. The model should receive enough surrounding context to interpret the chunk, but not so much that it becomes noisy. Current guidance from the CSA MAESTRO agentic AI threat modeling framework and emerging work such as Anthropic Project Glasswing both point toward context-aware handling as a core control, although there is no universal standard for this yet.

• Attach source, timestamp, case ID, and collection method to every chunk.
• Carry the original prompt or investigative question into downstream retrieval.
• Preserve sequence so the model can distinguish pre-event, event, and post-event material.
• Mark whether a chunk is raw evidence, derived inference, or analyst annotation.
• Reassemble context before scoring risk, not after the model has already judged the fragment.

For NHI workflows, this is especially important when evidence spans secrets scanning, API activity, and identity telemetry. A token string alone is ambiguous; the same string can be harmless in documentation, dangerous in logs, or critical when paired with an active OAuth grant. NHIMG’s The State of Non-Human Identity Security highlights how visibility gaps already undermine confidence in NHI controls, which is exactly why chunk-level provenance matters in analysis. These controls tend to break down when evidence is re-chunked across disconnected systems because the receiving model no longer sees the full event chain.

Common Variations and Edge Cases

Tighter context preservation often increases storage, retrieval, and orchestration overhead, requiring organisations to balance fidelity against pipeline complexity. That tradeoff becomes sharper in multi-tenant SOC tooling, long-running investigations, and agentic AI workflows that chain multiple tools across separate stores.

Best practice is evolving for hybrid approaches. Some teams keep a compact evidence envelope with each chunk, while others maintain a linked provenance graph that the model can query on demand. Both approaches are better than naive chunking, but neither is complete if the system cannot reconstruct who collected the evidence, when it was collected, and why it was retrieved. This is especially true for autonomous agents that may follow up on one chunk with another tool call, because the second action can drift away from the original investigative intent.

Chunking also creates edge cases when a single fragment contains sensitive material, but the surrounding chunks are stored separately. That can cause over-redaction, under-redaction, or incorrect incident grouping. In practice, the safest pattern is to preserve enough metadata to rehydrate context without exposing unnecessary content. Security teams should assume that chunk boundaries are an analysis convenience, not a meaningful security boundary.

Related resources from NHI Mgmt Group

• Why do DLP and CASB tools struggle with generative AI security?
• Why do legacy security tools struggle to control AI-related data exposure?
• Why do AI security tools struggle with privilege escalation chains?
• Why do general-purpose AI tools struggle with security fixes at scale?