AI in network detection and response: What still requires deterministic evidence

The block that could not be explained

At 03:14 an automated response fired and isolated a production network segment. The verdict came from a behavioral model. The isolation itself worked exactly as designed.

Six hours later, a post-incident review could not reconstruct which flows triggered the decision. The retention window for raw flow records had closed. The model had scored the traffic. The score was gone. The flows were gone. What remained was a timestamp, an action log, and a gap where the justification should have been.

Nothing malfunctioned.

The assumption the network team was carrying — that a detection arrives with enough supporting evidence to reconstruct the reasoning behind a response — no longer holds when the detection is a model-generated score. A signature match names the rule and the matched value. A behavioral score names neither. When the response action is irreversible and the evidence window closes before anyone reviews the record, the gap is not a logging failure. It is a retention policy that was never recalibrated for the evidence that automated response now depends on.

What a network detection used to carry

A signature-based alert delivered the alert and its own justification in the same artifact. The rule name, the matched byte sequence or header value, the source and destination, the protocol: these were co-located. A reviewer reading the alert could reproduce the detection logic without contacting anyone or running a separate query.

That pairing mattered operationally because the detection was also a control with an articulable strategy. NIST SP 800-53 Rev. 5 CA-7 requires a system-level continuous monitoring strategy that defines what is being measured, at what frequency, and how the continued effectiveness of controls is assessed — treating monitoring as something with explicit criteria, not an output stream that is assumed to be working. A signature satisfies that framing naturally: the rule is the criterion, the match is the measurement, and a human can inspect both. A behavioral score satisfies the output half of that requirement without automatically satisfying the criteria half, unless the monitoring strategy is written to specify what the model is measuring and what evidence standard an alert must meet before a response action fires.

The practical consequence is that review and accountability obligations that were previously satisfied implicitly now require explicit architectural decisions about what gets retained, for how long, and in what form.

Where inference is genuinely better

Behavioral inference does detection work that signature matching does badly or cannot do at all. Beaconing regularity — consistent packet intervals indicating C2 polling — is detectable through statistical pattern analysis across thousands of sessions where a human analyst would miss the signal in the noise. Rare-destination scoring flags endpoints contacted by few or no other hosts in the environment, a population-level signal invisible to any per-session rule. Lateral movement that produces no malformed packets and no known-bad signatures produces behavioral deviation from normal peer communication patterns that a model can surface and a rule set cannot.

These are genuine detection wins, not marginal improvements on signature matching. They represent capability that did not previously exist at scale. That concession is unconditional as inference earns its place on the detection side.

The response actions that need a corroborant

Confidence is the wrong variable for this decision. An inference at 98% probability is still an inference. Whether that score justifies a response action depends on the cost of being wrong and whether the action can be undone.

A high-confidence score that triggers a cheap, reversible action needs no corroborant. Raising alert priority, tagging an asset for enrichment, or queuing a flow for analyst review carries near-zero cost if the model is wrong. The error is recoverable and the operational impact is negligible. These actions can legitimately fire on inference alone.

Isolating a production segment cannot, at any confidence threshold. The cost of being wrong — service disruption, incident response overhead, business impact — is borne immediately and does not disappear when the model is re-run. The same logic applies to route changes, firewall rule insertions that drop production traffic, and credential revocation on a shared service account. The irreversibility and immediate cost of these actions are what require a corroborant. Not doubts about model accuracy.

Cost asymmetry, not confidence, is the axis that determines which column an action belongs in.

The corroborant column is not a threshold recommendation. The specific evidence required should be defined per action class in your runbook, based on the production impact profile of that segment and the retention windows actually configured in your environment.

What deterministic evidence the network still holds

The network produces record types that are facts, not scores. Each carries different investigative weight and has different retention characteristics that most environments have not reexamined since automated response was introduced.

Five-tuple flow records with byte counts establish that a connection occurred, between which endpoints, over which protocol, and how much data moved. They cannot establish payload content, but they can corroborate or contradict a behavioral model's claim that unusual data volumes left a segment. Retention periods for flow records in many environments were configured for capacity planning, not investigation timelines — review whether your current window actually covers the review cycle for automated response actions.

DNS resolution logs establish what name a host resolved, when, and to which address. A behavioral model flagging a host for suspicious outbound communication is corroborated when a DNS log shows resolution of a recently registered or rarely queried domain immediately before the flagged sessions. Without the DNS record, the flow record shows a connection to an IP. With it, you can establish application-layer intent.

TLS SNI values are visible in the ClientHello before the session is encrypted. They establish the hostname a client presented, which survives full TLS inspection avoidance and can corroborate or contradict claims about which service a flagged session was targeting. SNI logging is not enabled by default on every network tap or sensor: verify it is collecting before you depend on it as a corroborant.

Packet capture provides the highest fidelity but is expensive to retain at volume. It can establish payload characteristics that flow records cannot, and for high-cost response actions such as segment isolation, it may be the only record that definitively corroborates the behavioral pattern a model detected. Selective capture triggered on high-score events is worth evaluating if full capture is operationally infeasible.

CM-3 under NIST SP 800-53 Rev. 5 requires that configuration change decisions, including the security impact analysis that preceded them, be documented and retained. Where an automated response action modifies network configuration, that retention obligation attaches to the corroborant evidence the decision rested on, not only to the action log. An action log without a retained corroborant satisfies the form of the record without satisfying the substance of the review obligation.

One other constraint that does not change with AI assistance: an unlogged flow is still invisible to both a model and a reviewer. If a sensor was not capturing SNI values or DNS queries when the automated response fired, no retrospective analysis recovers that evidence.

The decision before automated response is enabled

The decision is not whether to enable automated response. It is what corroborant each action class requires, written down before the action class is enabled.

For each automated response action in your runbook, name the deterministic record type that must exist to justify it. Then verify that record type's retention window is longer than the review cycle that will consume it. A segment isolation that fires at 03:14 and is reviewed at 09:00 requires that the relevant flow records, DNS logs, and SNI values still exist at 09:00. If your flow retention is configured at four hours for capacity reasons and your review cycle is six hours, the corroborant will not be there when the reviewer needs it. That is a policy decision, not a logging failure.

For actions in the "may fire on inference alone" category, the verification step is confirming that the action is genuinely reversible and that its cost profile has not changed as the environment has grown. An IP block that was low-impact when a segment carried internal tooling may carry different consequences when that segment now hosts a production integration.

The reviewer at 09:00 needs to see the flow records, the DNS resolution sequence, and the SNI values that the model was scoring against. They are deciding whether the isolation was justified and whether it should be lifted or extended. Finding that flagged traffic is attributable to a known process is grounds to lift it. Finding that DNS logs show domain resolution consistent with C2 infrastructure confirmed in threat intelligence is grounds to extend it. Neither decision is possible if the retention window has already closed.

Write the corroborant requirement next to each action class. Verify the retention window outlives the review. Treat that pairing as the policy artifact — not the confidence threshold, and not the model version.

Sources