The Foundational Problem of Using Agents for Security

Everything the industry built before agents was built to cope with that volume. The SIEM exists to store it and search it, the normalization pipelines exist to make it uniform enough to search, the detection signatures exist to pull a few hundred events out of the millions, and the alert queue exists to hand those few to a person.

None of that has changed with the arrival of agents, and neither has the telemetry itself. What has changed is that there now seems to be a new way to deal with all of it.

The obvious move, once you know how capable these models have become, is to hand the whole problem to one. Point an agent at the stored telemetry, tell it to find the bad stuff, and wait for the findings.

But the truth is, for a number of reasons, an agentic layer does not automatically solve this problem.

Start with the arithmetic. One raw event, a process launch or a connection serialized as JSON with its identifiers, its timestamps and its parent chain, comes to somewhere between a hundred and a few hundred tokens.

At that size a 200,000-token context window holds about 1,500 events, and against a day that produced a few hundred million, that is 0.0005 percent of the day's logs. Half of one thousandth of one percent fits in a single call.

Now picture running it. You point the agent at the day's logs and it starts reading. To get through the day it has to compact its context over and over, replacing what it has read with a summary, and every one of those compactions throws detail away. By the time the agent has "read" the day, most of the specifics it would need to see a pattern are gone.

The obvious fix is to stop reading before the window fills, but that only trades one failure for another: now the agent is reasoning over a sliver of the day, and the pattern you are hunting for may only exist across the whole day or even many days, not inside any one small sample of it.

There is another fundamental problem with filling an agent's context window — there is an inverse relationship between the amount of information in a model's context window and its performance. This phenomenon has been reproduced across many model types and generations, and the effect is remarkably consistent.

Liu and colleagues showed in 2023 that when a model has to find one fact inside a long context, recall is strongest near the beginning and the end and collapses in the middle, and once you have filled a window, the middle is where most of it sits. The effect became known as lost in the middle.

Chroma's 2025 study ran eighteen models through tasks that got no harder, only longer, and found that performance fell as the input grew, on tasks as simple as repeating a list of words. It fell fastest when the extra material resembled the answer without being the answer. That decline with length is what people mean by context rot: the model does not fail at the ceiling, it gets steadily worse the whole way up.

When the instruction is "find the bad stuff," you do not yet know what is relevant. So by definition you are packing the window with unrelated events and asking the model to think in the middle of them, which is exactly the condition these studies measured.

Of course to some extent this is unavoidable — if we already knew exactly what the threat was, no need to find it. But we need to implement mechanisms which will probabilistically concentrate the signal of malicious activity.

There is also the cost. Every raw token is paid for on every turn, because the harness re-sends the whole conversation each time. Prompt caching helps when the front of the request stays the same between calls, but it does nothing for a payload that changes on every query, so you pay, in dollars and in seconds, for every token of noise you never needed.

A language model is an eager pattern-matcher. Hand it a pile of events and ask for findings, and it will look for connections between them, because a model is reinforced to produce answers. That is fine when the events are related. Raw logs are mostly not related.

A DNS lookup, a login, a scheduled task and an outbound connection can sit within seconds of each other on the same host and have nothing to do with one another. The model sees four dots close together and draws the line.

The more unrelated events you put in the window, the worse this gets. Every event you add can be paired with every event already there, so the number of possible connections grows quadratically with the number of events, and most of those connections are coincidences. Somewhere in a thousand raw lines there will always be a handful that line up by chance, and the model will find them and write them up: confident, well written, and wrong.

Statisticians call this the Texas sharpshooter fallacy, after the marksman who fires at the side of a barn and then paints the target around the tightest cluster of holes. The model tends towards dressing a coincidence up as a narrative.

Now suppose none of that were true. Imagine an infinite window, free tokens and perfect recall. Pointing the agent at raw logs would still be the wrong design, because it puts the wrong worker on the job.

You would never hand a human analyst a million lines of connection logs and ask them to read through and tell you whether any host is beaconing. Not because they lack expertise, but because that question is raw computation. Answering it means working out the time between connections, the variance in those gaps, the jitter, for every pair of hosts in the file. People are not good at that kind of arithmetic at that kind of volume, and nobody would assign the job that way.

A language model is not good at it either, for a structural reason: it was trained to predict tokens, not to run statistics over twenty thousand numbers. Models are better at judgment than at raw calculation.

Ask a capable agent to do it anyway and watch what it does. It does not grind through the arithmetic token by token, because it cannot predict statistics it has never seen. Instead it works out that the question is statistical, goes online and does some research on how to detect beaconing, writes a Python script, and runs it. Left to itself, the agent lands on the right division of labor: code for the computation, the model for the judgment.

The problem is that it lands there fresh on every run. It works the problem out again, writes a new script again, picks its thresholds again. That is expensive, slow and inconsistent: ask the same question on two different days and you can get two different analyses.

A process that central should not be improvised at runtime. When you see an agent building the same thing over and over, that is your signal to take it away from the agent: design it once, properly, and put it in place as a standing part of the system.

So between the telemetry and the agent there has to be something deliberately engineered: a system that decides what crosses from the telemetry side to the agent side, and on whose initiative, built once and standing for every run instead of being reinvented inside each one.

Two useful questions to start with are when the data is prepared, ahead of a request or in response to one, and how it is represented to the agent. These are guiding design questions, with room for different representations and combinations rather than a fixed catalogue of interfaces.