An AI connected to your network can only answer for the stretch of time your data still covers. Point it at a question about last spring, and if the flow records from last spring are already gone, the model has nothing to work from. It will either tell you it can’t know, or guess in a way that sounds certain.
That gap is the quiet limit on every AI investigation, and almost nobody checks for it before they connect the tool.
Why this matters
The questions that matter most in security work almost never arrive on the day the traffic happens. A workload was beaconing in March. Someone asks about it in July. By then the incident is a scope question: how long, how far, which hosts, what left. Answering it means reading the network’s own record of what happened months ago. If that record was rolled up or deleted to save disk, the investigation stops at the edge of your retention window, no matter how good the AI sitting on top of it is.
The problem: a short window you set and forgot
Most teams keep a short window of full-detail network data and then let it go. Weeks, sometimes a single week, occasionally a month. Full-fidelity records are large, and the storage bill grows with every day you keep, so somewhere a decision got made to trim the history down to what fits the budget. That decision usually predates anyone thinking about AI at all, and it silently caps what any connected model can ever tell you.
What operators actually see
You ask the assistant a straightforward question. What was this host talking to in the last week of March? Did this IP show up on the network before the alert fired? Was this segment ever monitored the way we assumed? When the underlying data still reaches back that far, you get a real answer with the records behind it. When it doesn’t, you get a shrug, or worse, a confident-sounding answer built on nothing, because the model can only reason over what it can retrieve.
Why the usual setup misses it
Two habits create the blind spot. The first is treating packet capture as the record of last resort. Packets are enormous, so full capture rarely survives more than a few days, which means the deep record you would most want during a months-old investigation is the first thing to age out. The second is the way the AI conversation gets sold. The pitch is about the model, the assistant and, the connection. The data layer underneath it, how far back it goes and at what detail, barely comes up. So teams connect a capable tool to a shallow history and are surprised when it can’t answer the questions they actually have.
The shift: give the model a longer memory to read
The fix is not a smarter model. It’s a longer, affordable memory for the model to read. Flow records are the lever, because the network already exports them. Every router, switch, and firewall describes the conversations crossing it in a compact record, far smaller than packets, cheap enough to keep for months or years instead of days. Tier that data so recent, high-detail records sit on fast disk and older records age to cheaper storage on your own terms, and you decide how far back the history goes instead of the storage bill deciding for you. Then, when you connect an AI, it has something to see.
How to investigate a signal that surfaces months late
When a signal surfaces long after the traffic, the work goes in order.
- Fix the window. Establish when the suspicious activity actually started, which is usually well before the alert.
- Confirm the host was there. Check whether the IP appears in your host history for that period, and when it was first and last seen.
- Pull the conversations. Retrieve the flow records for that host across the window: who it talked to, how much, and how often.
- Trace the spread. Follow the host-to-host pattern outward to see which other systems it reached, and when.
- Bound the scope. Establish the earliest and latest activity so containment covers the whole thing, not just the part the alert caught.
- Keep the record. Save the timeline and the flow records behind it, so the same evidence answers the auditor’s question later.
A scenario: the indicator that has been quiet since spring
A mid-size financial services team gets a threat-intel hit in July on an internal host. The indicator has been active since spring.
- 9:00 a.m. The analyst asks the connected assistant whether the host was on the network in March. Host history confirms it: first seen in early March, last seen the previous week.
- 9:20 a.m. The team pulls flow records for the host back to March. The retention window still covers it, because the data was tiered rather than deleted.
- 10:15 a.m. The records show a repeating outbound pattern to an external peer. Low volume, steady interval, the shape of beaconing that never tripped a threshold.
- 11:30 a.m. Tracing host-to-host activity, the team finds two more internal systems the host reached in April. Scope is now three hosts, not one.
- 1:00 p.m. Containment covers all three, and the timeline, with the flow records behind it and goes into the case file.
Without the history, that same investigation ends at 9:05 a.m. with "we do not keep data that far back."
Common reasons the window is too short
- Storage cost. Full-detail records are large, so retention gets trimmed to fit the budget.
- Packet-first design. Capture is so heavy it can only survive days, so the deepest record ages out first.
- Rollup by default. Older data gets aggregated into summaries that lose the per-conversation detail an investigation needs.
- A retention setting nobody revisited. The window was set years ago, for reasons that no longer apply, and never changed.
Why the length of the window is a real exposure
Here is the number that makes the retention window an exposure and not a housekeeping preference. IBM puts the average time to identify and contain a breach at 247 days, most of eight months, and this year that figure rose for the first time after five straight years of decline (IBM Cost of a Data Breach Report 2026). If it takes the average organization the better part of a year to find and shut down an intrusion, and your network data only reaches back a few weeks, then the entire early life of the breach happened in a period you can no longer see. The investigation you will one day need to run is against a window you have already thrown away.
Where most teams get stuck
The instinct, once this lands, is to keep everything at full detail forever. That swings the storage bill the other way and gets cut at the next budget review, and the short window comes right back. The workable version is control, not maximalism: keep recent data in full detail, age older data down on a schedule you set, and hold a lightweight index of every host long enough to answer the "was this thing ever here" question cheaply. Depth where it earns its cost, breadth everywhere else.
Where Plixer fits
Plixer has been collecting and analyzing flow for 25+ years, and the retention model in Scrutinizer and Plixer One is built for exactly this problem. It collects the flow your network already exports, so the record costs a fraction of packet capture and can be kept far longer. Multi-tier storage lets you keep recent flows in full detail and age older data to cheaper tiers on storage you control, so you set how far back the history reaches. A year of searchable host history comes by default: for any IP, when it was first and last seen, how much it moved, and which exporter saw it. That answers the "was this host on our network last April" question without keeping every packet.
That is also the layer the AI reads. Scrutinizer ships with a built-in MCP server, so the AI your team already uses, or Scrutinizer’s own AI Assistant, can query this history directly and answer from your real flow records instead of a guess. Access is read-only out of the box. Investigating your network takes nothing more than connecting; changing a setting or acknowledging an alarm stays off until you deliberately turn it on. The AI investigates. Your team decides what happens on the network.
This pattern is not hypothetical. At Kitsap Credit Union, a Plixer customer, the team uses retained flow history to answer audit questions straight from the record instead of rebuilding them after the fact. As Roger Bascom, their Senior Network Engineer, put it: "What used to take hours or days to confirm audit results, now takes as little as 30 seconds."
What actually determines whether the answer is worth anything
Anyone can connect a model to a system. What decides whether the answer is worth anything is how far back the data goes, and how much it costs to keep it there. Plixer keeps months to years of the flow your network already exports, on storage you control, with no probe to rack for every segment, so the AI you connect can answer as far back as you chose to keep. It’s the same network record your performance team already uses to find the root cause of last quarter’s slowdown, and your security team uses to reconstruct an intrusion that started in spring. One history, both jobs.
Key Takeaways
An AI investigation is bounded by the data beneath it, and network retention is the boundary most teams never check before connecting one.
- An AI can only answer for the period your data still covers. If the history is shallow, so are the answers.
- The investigations that matter most run months after the traffic, so the record has to reach back that far to be useful.
- Flow records make long retention affordable, because the network already exports them and they’re far smaller than packets.
- Tiering plus a default host-history index give you depth where it counts and breadth everywhere else, without an unbounded storage bill.
- Connecting an AI is the easy part. The value comes from the depth and control of the data you point it at.
Next Steps
If you’re working through what an AI connection to your network actually involves, two pieces are worth reading next.
- For the groundwork on how an AI plugs into your systems in the first place, "What Is MCP, and Why Is Everyone Suddenly Talking About It?" explains the protocol in plain language before you point it at your flow data.
- For a closer look at the kind of months-old investigation this post describes, "How To Detect Lateral Movement: A Step-by-Step Guide" walks through tracing host-to-host activity with flow data and behavioral baselines.
Prefer to start smaller? Connect the Plixer MCP server to the AI your team already uses and ask it something about your own flow data. You’ll see the answer come back from your own history, inside the tool your team already works in.
Frequently Asked Questions
Only as far back as the underlying data goes. An AI connected through something like MCP queries your live systems, so if your network records reach back only a few weeks, that’ is the limit of what it can tell you, no matter how capable the model is. The depth of your retention sets the depth of the answers.
Packet capture is very large, so keeping it for more than a few days across a real network gets expensive fast. That’s why full capture is usually the first data to age out, and why it’ is a poor fit for investigations that surface months later. Flow records describe the same conversations at a fraction of the size, which makes long retention affordable.
Packets are the full contents of every conversation, and they’re huge. Flow records are compact summaries of who talked to whom, how much, and when, exported by your existing network gear. For reconstructing an incident weeks or months later, flow records give you the timeline and scope you need without the storage cost that forces packets to be deleted quickly.
Long enough to cover the investigations you’ll actually need to run, which, given how long breaches take to surface, means months rather than weeks. The practical approach is tiered: keep recent data in full detail, age older data to cheaper storage, and hold a lightweight host index longer still. That gives you reach without an unbounded bill.
This is the most common worry, and it comes down to what the AI is allowed to do. A well-built connection separates read-only investigation from any action that changes a setting. The AI can look at your flow history and report the moment it’ is connected, while anything that alters the network stays off until someone deliberately enables it.
In principle yes, by manually pulling and correlating logs and whatever flow or capture data you still have, but it’ is slow and it depends entirely on what you kept. If the relevant data was rolled up or deleted, there’ is no reconstructing it after the fact. A platform that retains flow and indexes hosts over time is what makes the question answerable quickly.
Plixer collects the flow your network already exports, which is far smaller than packet capture, and stores it in configurable tiers so recent data stays in full detail while older data ages to cheaper storage you control. A year of searchable host history is included by default, so you can confirm when any IP was on the network without keeping every packet.
Both, in different directions. Long retention without a way to query it quickly is just a large archive. An AI without deep retention is a sharp tool with nothing to cut. The value shows up when a capable assistant can read a history that actually reaches back to when the incident began.
