What should teams do when token limits are reached during an active investigation?

They should prune in phases, starting with the oldest and largest tool-result content while preserving the newest user and assistant turns. If the workflow uses multiple providers, the pruning policy must respect each provider’s message structure so the investigation can continue without corrupting state.

Why This Matters for Security Teams

Token limits are not just a usability issue. During an active investigation, they can determine whether an analyst preserves evidential context, keeps the chain of reasoning intact, and avoids accidental corruption of the conversation state. When the working set grows too large, the system may drop high-value signals from earlier tool outputs, summaries, or triage notes unless pruning is deliberate and consistent.

This is especially important when the investigation involves multiple sources of truth, such as SIEM alerts, EDR timelines, case notes, and agent-generated findings. If truncation happens informally, the result can be partial context, duplicated effort, or mistaken conclusions based on only the most recent messages. Security teams should treat context management as an operational control, not a housekeeping task. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces the need for controlled processing, integrity, and accountable handling of security-relevant information.

In practice, many security teams encounter context loss only after an investigation has already been split across resets, rather than through intentional token-budget planning.

How It Works in Practice

Effective pruning follows a preservation hierarchy. Keep the most recent user instruction, the latest assistant reasoning that still reflects the active task, and the current investigation goals. Then remove or compress content that is both old and bulky, especially repeated tool outputs, verbose logs, and earlier dead-end hypotheses. The aim is not to make the thread shorter for its own sake, but to retain the minimum context needed for accurate next-step reasoning.

In mature workflows, teams define a pruning policy before an incident starts. That policy should identify which message types are always preserved, which can be summarised, and which can be dropped once their facts have been extracted into a durable case record. If the workflow uses multiple providers or model endpoints, the policy must also respect each provider’s message structure, because token accounting, role ordering, and truncation behaviour are not identical. For broader governance of operational controls, see the CISA Known Exploited Vulnerabilities Catalog, which reflects the same principle of prioritising what is most operationally material.

• Preserve the active objective, latest decisions, and any constraints that change analyst action.
• Summarise or compress long tool results into structured notes before discarding the raw text.
• Keep timestamps, indicators, hashes, and other evidentiary anchors outside the chat thread.
• Rebuild state from the case record after pruning, rather than relying on memory in the model.

Teams should also distinguish between analytical context and evidential context. Analytical context is what the model needs to continue reasoning. Evidential context is what the investigation record needs for auditability, handoff, or later review. The two often overlap, but they are not the same thing. A well-run process stores evidence externally and uses the conversation only as a working layer.

These controls tend to break down when long-running investigations mix raw telemetry, narrative analysis, and repeated tool calls in a single thread because the highest-volume messages crowd out the decision history.

Common Variations and Edge Cases

Tighter context preservation often increases analyst overhead, requiring organisations to balance investigative fidelity against the cost of manual summarisation. That tradeoff becomes sharper when token pressure occurs mid-incident, because teams may prefer speed over discipline and accept a higher risk of missing earlier facts.

There is no universal standard for pruning thresholds yet. Some teams prune by message age, others by token count, and some by content class such as tool output versus human-authored notes. Current guidance suggests that the best approach is the one that is predictable, documented, and repeatable under pressure. If a workflow relies on agentic AI, the pruning policy should also protect any state that governs tool permissions, handoffs, or approval boundaries, because losing that context can change what the agent is allowed to do.

Edge cases matter most when investigations span multiple providers, regulated evidence handling, or high-volume automated enrichment. In those environments, summarisation can introduce drift if it is not tied back to source artefacts. The safer pattern is to externalise evidence, keep a compact investigation ledger, and use the chat context only for the current decision path. For teams aligning response operations with formal control expectations, NIST AI Risk Management Framework supports disciplined management of system outputs and operational reliance.

Where the investigation is legally sensitive or regulator-facing, teams should be even more conservative. The practical rule is simple: if a detail might be needed for reconstruction, escalation, or audit, it should live outside the token window before pruning happens.

Related resources from NHI Mgmt Group

• What should teams do when workload posture changes during an active session?
• How should security teams automate access suspension during active incidents?
• What do IAM teams get wrong about active token use?
• How should security teams design access controls for operations during an active cyberattack?