Four questions that answer if a security product will survive in the AI-first world
A few questions I think about when I evaluate if a company or a market category is going to stick around.
AI is changing the world faster than anyone could have predicted. This isn’t because it is taking over jobs (this would be too simplistic), but because it is slowly taking over a growing number of tasks that used to be done by humans. Security is not in any way immune to these changes, and I am seeing that a growing number of security teams are becoming early adopters of everything AI. This makes a lot of sense: given that the headcount of security teams isn’t exactly increasing, the only way they can keep up with the ever-evolving threat landscape is by using the same technology that adversaries are using on their end.
In this new world, there will be companies that get squashed, those that survive, and those that will actively benefit from AI. In this piece, I am sharing a few questions I think about when I evaluate if a company or a market category is going to stick around.
This issue is brought to you by... Prophet.
Gartner: 70% of SOCs Will Pilot AI Agents. Only 15% Will See Results.
Dozens of startups have entered the AI SOC space in the past few months, each promising to transform how security operations teams handle alert triage, investigation, and response. So which AI SOC agents are actually living up to that promise in production environments?
Analysts Craig Lawson and Andrew Davies lay out a structured evaluation framework for cybersecurity leaders considering AI SOC agent deployments. Get the report here to access all seven evaluation categories, including detailed guidance on what to look for in vendor responses.
Is the problem about in-line access or security enforcement?
If the answer is yes, you can largely skip the next question. The category is unlikely to be disrupted by AI and will most likely actually become stronger because of it.
Security products that do in-line access and security enforcement don’t simply analyze, report, or recommend; they sit in the path of traffic, access requests, workloads, identities, or transactions and actively enforce decisions.
To be clear, I am not saying AI suddenly makes it easy to build a WAF, IAM platform, SASE solution, firewall, or any other enforcement tech. Building successful in-line security products has always been hard because these solutions require customers to change architecture, re-route traffic flows, redesign access models, and accept operational risk that comes with all this. Most companies trying to build these products have historically struggled to gain adoption, and AI doesn’t magically change that reality. What is changing is demand.
AI agents are creating a new demand for enforcement. In many ways, the industry is rediscovering proxies, gateways, brokers, and policy enforcement points. Every organization wants visibility into what AI systems are doing, what data they can access, where they can connect, and what actions they are allowed to take. One of the ways to answer those questions is often to put a control point in the middle.
As more and more companies deploy agents that can access data, interact with applications, and take actions autonomously, the need for enforcement will become even more important than before. That’s why I believe in-line security enforcement products and market categories won’t simply survive the AI transition; they are among the few that are most likely to benefit from it.
Does solving the problem require runtime data or analysis of runtime data?
Many security products are built on information that is increasingly becoming accessible to everyone. Think about all the tools built to analyze security findings, vulnerability databases, cloud configurations, policies, threat reports, and documentation. Today, all of these can be collected, processed, and analyzed by LLMs pretty easily, and as models get better, their ability to analyze static information is going to increase.
Runtime data is very different. Products that sit on endpoints, look at network traffic, monitor identities, inspect application behavior, analyze authentication events, or collect telemetry from production environments have access to information that is pretty hard and expensive to replicate. The value is not simply in the analytics applied to the data, but in having the data in the first place. This is one reason I think categories such as EDR, browser security, and application detection and response are here to stay. LLMs may make the analysis layer dramatically better, but somebody still needs to gather the telemetry and do some kind of initial analysis that is much cheaper to run before escalating select cases to LLMs.
Similar to the point I made about in-line enforcement, I think that in many ways, AI increases the value of runtime data. As intelligence becomes commoditized, access to proprietary telemetry could very well become one of the most durable moats in cybersecurity. There’s a reason why, for example, it’s so hard to build an endpoint agent, and why companies in the endpoint security space are so well positioned in the new world.
The second point is about the analysis of runtime data. LLMs are really good when they have time to think about the problem. Things like deep diving into a few outliers, running a deep investigation of an incident, or calling tools to understand the broader picture around a specific problem are something that should definitely be delegated to LLMs. Real-time enforcement or analysis of runtime data still has to rely on other approaches because the cost and latency of using LLMs make them not really suitable for these kinds of use cases. A lot (and I mean it - a lot!) of what cybersecurity is comes down to detection and response, so I think most security products aren’t doomed as much as some want to believe.
Does solving the problem require a model of the complex system?
AI is really powerful, but it still struggles with understanding complex environments it cannot see. Sure, LLMs are really good at reasoning, but that reasoning is only as good as the context LLMs have. Without an accurate model of the environment, they are often forced to make assumptions, and in security, assumptions are quite often wrong.
Security heavily relies on an accurate representation of the environment because everything is about the edge cases, about small gaps between controls, etc. Identity security needs a model of users, groups, permissions, roles, applications, and business relationships. Cloud security needs a model of accounts, workloads, networks, services, data stores, trust relationships, and traffic flows. In every case, the reasoning LLM does and the intelligence it produces is only as good as the environment model behind it.
The challenge is that someone has to build these models and maintain them as the environment changes. Unlike intelligence, which AI can increasingly generate on demand, these models have to be grounded in reality (aka be deterministic). This is why I think that products built around creating and maintaining the models of the environment will become more valuable in the age of AI. This is also a part of the reason why, I think, Veza had such a great exit, and definitely why CSPMs aren’t going away anytime soon, not for complex environments anyway.
A useful rule of thumb is this: if an AI can answer a question from a screenshot or a few paragraphs of text, and if that answer is pretty accurate, the category is dead. But if it first needs a detailed map of thousands of assets, identities, policies, dependencies, and relationships before it can produce a useful answer, the category may be more durable than it looks.
Can the problem be fixed with a single pull request?
The last question I ask when thinking if the product can be replaced with AI is this: after we find an issue, can it be fixed with a single pull request? If the answer is yes, that’s pretty bad news for the founders.
LLMs are really good at understanding, writing, modifying, and iterating on code. Basically, if a problem can be detected, translated into code changes, tested, and validated through a relatively straightforward development workflow, AI is likely going to destroy much of the value that security products in that category provide today. This is, by the way, why many areas of appsec face existential problems since the entire loop, from finding the problem to fixing it, can now happen inside the development workflow itself.
The categories that I think have a better future are those where the problem cannot be solved with a pull request. Think about the boring, complex problems that live outside of Terraform, outside of cloud-only environments, and that involve multiple teams, operational tradeoffs, business dependencies, change management processes, and sensitive production systems. This might finally be the time to go after really hard problems that require founders to understand how complex systems interact and safely change them without breaking the business.
Closing thoughts
There’s definitely more to figuring out which security products and categories will survive in the AI-first world than just these four questions, but with these four questions alone, I think we can deal with 80-90% of the entire security market.
It may be obvious, but it’s worth saying it out loud - that not every security problem will be solved by LLMs and AI agents alone (in fact, many of the new security challenges we will face over the next decade are being created by AI itself). The reality is that most meaningful security problems need a combination of approaches, from deterministic controls and predictable enforcement to non-deterministic reasoning, machine learning, knowledge graphs, and AI agents.
I also think that companies that win will be the ones that understand where AI creates real leverage, but also where deterministic systems make more sense, and how to combine different technologies into a coherent architecture that can operate reliably at scale. It doesn’t take much genius in 2026 to just say that agents are the answer to everything, but it’s whoever figures out where to use AI and where not to use AI that will build something differentiated, scalable, and suited for the real world.
