That framing can also change the economics of data collection. In many organizations, security has to justify the cost of collecting and retaining telemetry because it is viewed primarily as a security expense. But if the rest of the business needs that same data, the investment becomes an organizational one.
From Rules to Objectives
For years, security teams have built their security information and event management (SIEM) systems around rules. SIEMs identify patterns, look for specific log events, correlate sets of signals, and generate alerts when predefined conditions are met. Some platforms add machine learning and behavioral analytics on top of that. Even then, you’re still defining what normal looks like and where the thresholds sit. It’s rules either way. That model has served us well, but I believe it is about to change.
The SIEM of the future may not be the place where we write more rules. It may be the place where we give machines better objectives, context, and access to the data they need to reason.
It wasn’t security data. It was organizational data that security, engineering, and operations could use.
Although retaining data that goes back years and making it readily accessible for agents changes the performance requirements for a data platform. The speed of a query is becoming table stakes. But the timeframe of that query is where intelligence is gained. During an incident, analysts may start with a small query and then repeatedly pivot as they discover new information. A query that takes seconds over one day of data but hours over two years can become a serious bottleneck.
The Burden of Maintaining Detection Logic
Has this happened before?
Is this behavior unusual for this particular system or employee?
Did a similar pattern occur six months ago?
What changed in the environment before the behavior appeared?
Addressing Alert Fatigue With Agentic AI
The data is about the organization. Some of it may be used for security. Some may be used for other things. That becomes particularly important for AI agents because context is what allows them to reason effectively. Consider an investigation into suspicious activity. A traditional security workflow might examine what happened over the past few hours or days. An agent with access to a much larger historical record, however, may ask a different set of questions.
Matching those up is what an agent would do, and in seconds. An agent can potentially perform that reasoning across vulnerability data, endpoint information, network traffic, configuration information, and application or source-code data. This opens the door to a multi-agent SOC in which different agents investigate different categories of risk rather than requiring security teams to maintain thousands of narrowly defined detection rules. One agent could look for insider-threat activity. Another could look for network attacks from the outside. Another could look for vulnerabilities being exploited.
Rethinking What Counts as Security Data
Consider vulnerability management. A scanner might report a potential attack against a system, while other telemetry identifies the operating system of the target. A human analyst may then have to determine whether the attack is relevant. A Windows-specific attack against a Unix system, for example, may not represent the threat the initial alert suggests. An analyst has to ask, “Do these things match?” You’d think this was simple, but in all the years I’ve run a SIEM, I’ve rarely seen it actually work across a real environment with dozens of security vendors and asset data that doesn’t line up. It’s a basic example, but these are the things that add overhead for analysts.
With an agent, the approach can be much simpler. The analyst gives the prompt, “Look at my environment. We want to ensure we are protected from ransomware.”
For years, organizations have often justified keeping large volumes of logs and telemetry because regulations, investigations, or compliance policies required them to retain records for a particular period. But in an agentic environment, years of telemetry can become something closer to working memory for an AI system. Longer retention gives an agent more evidence against which to test a hypothesis. The value is not simply that an organization can retrieve an old log. It is that an agent can use years of historical behavior as context for understanding what is happening now.
It’s a significant departure from the way SIEMs have traditionally operated. Security analysts have had to translate organizational concerns into code specific enough for a machine to detect. The resulting rules are subjective. What constitutes suspicious behavior at one company may be completely normal at another. You have to understand the threats to your organization, determine which concerns you most, and then translate that understanding into a practical implementation as code. The work involved in maintaining that system can become enormous, particularly as organizations accumulate more infrastructure, applications, and data sources.
The SIEM as an Organizational Data Layer
Tools such as Splunk offered an early indication of what this model could look like. A user does not necessarily have to approach the system from a security perspective; they can search the underlying data for whatever question they are trying to answer. It’s all the same data.
If this vision plays out, the SIEM may ultimately become difficult to define as a security product at all. The security team may still use specialized views for detection, response and case management. But underneath those views is a common pool of organizational telemetry: identity information, application logs, infrastructure data, network traffic, source-code activity, business data, operational information and historical records.
Changing the Economics of Data Collection
I’ve been involved in investigations where a query over a short period was manageable, but expanding the same investigation to years of data could take four to six hours.
As agentic AI moves into security operations, the role of the security analyst could shift from telling a SIEM exactly what to look for to giving an AI agent an objective and letting it determine how to investigate the environment.
Why Context Is Everything for AI Agents
These are all specialist views of the same data. That could be the more consequential change brought by agentic AI. The technology may not simply make security analysts faster at working with a SIEM. It could change what the SIEM is used for.
I see agents taking over much of that work. Give the agent a goal, and then let it go out and do its job. But there is a catch. An agent can only reason over the evidence it can access. That means the move toward agentic security could make the breadth and depth of data available to a SIEM more important than ever.
Security might use identity data to investigate an account compromise. Marketing might use the same identity or application data to understand customer behavior. Engineering might use deployment telemetry to diagnose an outage. Operations might use application and login data to understand system performance.
Data Retention as Working Memory
The shift is not simply about replacing rules with a chatbot. Traditional SIEMs already perform correlation by bringing together different sources of telemetry and attempting to connect events that may represent parts of the same attack. The problem is that correlation often depends on carefully engineered rules and consistent data.
The Performance Demands of Historical Analysis
The more context you give an agent, the better outcome you can expect. The more historical data you give it, the more it can reason. That makes data retention more than a compliance decision.
Agentic systems could instead allow analysts to specify the problem they want investigated while leaving much of the reasoning and investigative process to the AI. That could also address alert fatigue, a chronic problem with SIEM deployments. Traditional detection systems can generate large volumes of alerts, many of which require analysts to determine whether they represent actual threats. Analysts then investigate, validate, and correlate the signals, often repeating essentially the same manual reasoning process across hundreds or thousands of events.
The future of detection and response, in other words, may depend less on how many rules an organization can write and more on how much of the organization’s history it can make available to an agent, and how quickly that agent can reason across it.
Beyond Correlation: Reasoning Across Data Sources
I think organizations should stop thinking about the information inside a SIEM as “security data” in the first place. Much of it is really organizational data that happens to be useful to security. I’ve seen this firsthand. At a previous organization, security and operational teams both used firewall and other security telemetry stored in a SIEM. Operations teams could use the same information to determine whether applications were functioning properly and whether users were logged in and performing their jobs.
I’ve seen that argument make a difference in practice. In a previous role, I might have never gotten approval for additional security-only capacity or storage due to cost. But when I demonstrated that the rest of the business needed the data too, it became much easier to justify the investment, and it was approved.
Toward a Multi-Agent SOC
That points toward a broader evolution of the SIEM. Rather than being a specialized repository containing only information deemed relevant to security, it could become a general-purpose telemetry and analytics layer for the organization, with security representing one specialized view of that data.
That’s an objective, not a rule. The agent can then reason through the available evidence to determine whether the controls and systems necessary to prevent ransomware are actually in place and functioning.
The SIEM Redefined
The number of high-level objectives could be relatively small compared with the number of rules organizations maintain today. The agents would then use the organization’s broader data and context to determine how to investigate those objectives. With agents, we won’t longer need the detailed rules we have now.
Rather than a security system that stores selected logs and applies predefined rules, it could become an organizational data and reasoning layer in which AI agents investigate questions, correlate evidence, identify anomalies, establish context, and work toward root causes. And in that model, the most valuable data may not be the newest data. It may be the historical record that lets an agent understand whether today’s event is actually unusual.
They looked at it for a different use case but the same data.
The Future Belongs to Objectives, Not Rules
The same principle applied to development data. We fed GitHub information such as check-ins and pull requests into a SIEM. Security teams could use that information for security investigations, while development teams used the same data to understand CI/CD activity.
It’s the difference between defining an objective and defining a rule. Traditional SIEM deployments require organizations to translate their understanding of risk into increasingly granular detection logic. If ransomware is a major concern, for example, a security team might build rules to examine endpoints, configurations, network traffic and other telemetry for signs of an attack. Over time, that can result in layers of rules, such as rules to capture data, interpret events, correlate those events and turn the resulting findings into alerts.
Investigators can’t afford four to six hours. Every query is a starting point to dive deeper into the data, and you’re constantly pivoting. For an AI agent operating across many investigative steps, that latency problem could be even more consequential. An agent that can reason across years of telemetry needs to retrieve that history fast enough for the data to be useful as part of an investigation.
