I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

Another week, another take on a security market trying to reinvent itself because of AI. In the past, I’ve talked a lot about the structural failures of detection engineering and traditional security operations centers (SOCs). I’ve been incredibly vocal about why I think building AI SOC agents is the wrong way to go.

In general, I don’t think traditional SIEMs and SOCs make sense for modern companies anymore. The model made sense when companies had longer deployment cycles, static infrastructure, and predictable rates of change. Today, the velocity of engineering is too fast, which inherently leads to an explosion of telemetry and alerts. Because these alerts are increasingly noisy, security teams spend a substantial amount of their finite resources tuning, filtering, and silencing the noise just to find a reasonable signal. You are burning elite engineering cycles on reacting to alerts rather than proactively fixing the underlying security posture. On top of that, building out a functional SOC has a massive upfront cost, which is a well-known, painful fact among practitioners.

It is no surprise that more companies are abandoning the internal SOC and turning to Managed Detection and Response (MDR) providers. They are likely to work out of the box without requiring a massive initial investment in specialized tooling and headcount. They provide a far better option than legacy MSSPs, where your data and investigations are trapped inside a total vendor black box at a time when you desperately need infrastructure visibility.

However, it is incredibly hard for these outsourced MDR providers to scale and build custom automations that work across different customer environments. They inherit a long time-to-response loop. While they handle basic, known alerts well, third-party MDR analysts completely lack the internal business context required to accurately judge whether a localized alert is a true incident or a false positive. You end up having to triage the alerts on your end anyway. MDRs provide a bit more visibility than old-school providers, but it is still rarely the deep context you actually want.

Now, we are seeing a whole new class of AI SOC startups emerging, e.g., companies like Prophet Security, 7AI, and Dropzone AI, that promise to drop an autonomous AI analyst straight into your existing queue to fix this triage loop. As I mentioned, I think this entire approach is a bad idea.

These startups are simply optimizing an existing, broken process. They make it faster to sort through a mountain of alerts, but they completely ignore the broader structural question: Does having a dedicated SOC or a siloed detection engineering function even make sense in an AI-native world?

You will never unlock true efficiency gains without fundamentally rearchitecting how your security organization operates. We’ve seen this exact pattern during every major industrial revolution, whether it was the advent of the internet or even the introduction of electricity. The economist Noah Smith wrote an excellent breakdown on this phenomenon before the current AI boom, summarizing Paul David’s work on factory electrification.

Most of the key electrical inventions (light bulbs, generators, AC, etc.) happened in the 19th century…But U.S. productivity growth…accelerated only during the 1920s….[F]actories were very slow to adopt electricity, and industries that electrified early didn’t see big productivity gains til the 1920s.

What happened? In a pair of famous papers in 1989 and 1990, economist Paul David offered an explanation (summarized here by Tim Harford). Basically, at that time, factories used centralized steam power, which was transmitted throughout the factory by a bunch of giant machinery. Simply swapping out a big electric motor for a big steam motor got you a small boost, but not much; it generally wasn’t worth the cost, so if you did this, your productivity would usually go down rather than up.

It was only once factory owners started building entirely new types of factories that they were able to realize the true gains from electricity. Basically, you could put a little motor at each workstation and power it through electric transmission lines. This meant that instead of having to keep a huge machine constantly turning, you could run each little machine only when you needed to. Not only did that save a ton of energy and make factories much nicer and safer places, it allowed workers to do things when they needed to be done instead of adjusting their workflow to the rhythm of a giant machine. That allowed all sorts of flexible production lines that you just couldn’t make with steam power. And productivity followed.

Applying this to cybersecurity risk management, you cannot achieve meaningful efficiency by simply layering an AI agent on top of a legacy steam-engine workflow. You have to change how the machine of the security organization actually works. A lot of modern companies don’t have a detection engineering team or a SOC at all, and they are completely fine. Heavily regulated enterprises will always need them for compliance checkboxes, but most cloud-native companies do not, especially since our core technology no longer lives in a physical datacenter that we fully manage and control.

Instead of buying an AI analyst to sit on top of a bloated Splunk or Sumo Logic instance that requires a massive team to run with completely unclear ROI, a new breed of security data platforms is emerging to solve the underlying storage, infrastructure, and context problem.

The three companies highest on my radar right now are RunReveal, Scanner, and Cotool. (Disclaimer: I am an early user of RunReveal). I’ve spent time looking at all three architectures, and I believe this direction is the correct path forward for AI-native companies that want to skip the SOC entirely.

Security organizations have historically gotten so large and specialized that they created highly fractured teams with divergent goals, completely losing sight of the bigger picture: effectively reducing enterprise risk. These tools fix that by democratizing the security data lake.

Scanner and RunReveal integrate directly with modern, cost-effective data infrastructure. Scanner indexes data directly inside your own S3 buckets without moving logs out of your environment. RunReveal offers a hosted ClickHouse stack or allows you to bring your own cloud storage bucket like your own ClickHouse, S3, or Cloudflare R2. Having a dedicated ClickHouse engine makes data processing and analytical queries substantially faster than running raw full-text searches on S3. Both alternatives are orders of magnitude cheaper than legacy SIEMs that charge an insane premium for cheap storage, forcing you to pay an enterprise software tax on top of what is essentially basic cloud data infrastructure.

From a detection perspective, Scanner and RunReveal both provide out-of-the-box rules. Writing custom rules in Scanner requires working directly in YAML or their proprietary editor, whereas RunReveal takes an AI-forward approach, deploying a native agent that can conversationalize rule creation and perform contextual investigations across your logs.

What makes this approach valuable isn’t immediate, autonomous code remediation. In the real world, the vast majority of alerts are false positives. Detection engineering is an inherently annoying discipline because it requires constant, iterative tuning. What a modern tool like RunReveal actually excels at is handling that triage and tuning lifecycle. When an anomaly triggers, the built-in AI kicks off a localized investigation immediately. If the agent determines the event is a definitive false positive based on historical log context, it can close it out automatically. If it cannot make a definitive call, it flags the alert for a human engineer, but surfaces it alongside all the relevant context and raw data lines required to quickly investigate. This model flips the workflow from chasing ghosts to easily tuning the signal baseline.

Cotool takes a completely different architectural approach. They aren’t trying to build the underlying data lake infrastructure. Instead, they are building a highly focused, programmable AI agent layer that acts as a blue-team orchestration engine. Founded by a technical team out of Material Security, Cotool pairs incredibly well with an open data lake like Scanner, and could potentially advance the investigation capabilities of a platform like RunReveal.

I don’t think the data lake platforms like RunReveal or Scanner are going to swallow the application layer entirely. Having ultra-fast data infrastructure is a separate, intense technical focus. Cotool, on the other hand, is entirely optimized around building an elite blue-team interface. These represent distinct markets and separate organizational priorities. Not every company needs a best-of-breed, highly sophisticated blue team workflow. For many lean operations, having a fast, solid data infrastructure layer is more than good enough.

Furthermore, traditional compliance blockers are becoming less of a concern. Modern pipelines easily fulfill audit obligations because regulators are increasingly looking at whether a team is meeting the actual spirit of what a SIEM is supposed to achieve: visibility, continuous monitoring, and log integrity. You don’t need a legacy enterprise dashboard or a 24/7 human room to prove you are managing log telemetry.

This evolution is exactly what the market needs. Scanner was founded by an infrastructure engineer, so the platform focuses deeply on data lake mechanics. RunReveal was founded by an early Cloudflare security engineer who deeply understands how hard it is for a lean team to set up a detection function from scratch, building an elegant platform optimized for the 80/20 compromise—80% of the security outcome for 20% of the operational effort. Cotool understands how to design an elite blue-team product interface.

These platforms are successfully rethinking how an AI-native company should craft a security team. They recognize that a single generalist or a software engineer with baseline security knowledge should be able to spin up a highly effective detection engineering function without hiring an army of analysts or maintaining a legacy SIEM. By using AI to handle the implementation detail and contextual routing, these tools allow engineers to focus entirely on security outcomes rather than operational busywork.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

I’m back to writing about markets that are poised to expand as AI adoption deepens inside the enterprise. Last week, we looked at AI proxies and the critical need for a low-latency, high-throughput network layer to govern streaming tokens. That post triggered a flurry of conversations about endpoint security, and it made me realize we need to look closer at the machine itself.

Right now, the vast majority of local AI agents run directly on developer laptops. While companies like Cursor are pushing hard toward cloud-hosted development environments, which I believe is the inevitable future due to the operational logistics of laptops going offline, we are not there yet. It will take time to fully migrate the engineering runtime to the cloud. Until then, the endpoint remains the primary execution layer for autonomous code.

This newsletter is going to look a bit different from my usual market deep dives. I don’t have a single, definitive conclusion yet. Instead, I want to map out the structural changes happening on the machine and look at the real opportunities for both incumbent giants and emerging vendors.

The changing of the guard

Endpoint security is a story as old as time. In the 2010s, we witnessed a massive architectural battle as enterprises migrated away from static offices to the cloud and distributed laptops. That era marked a clear changing of the guard. We saw a shift from old-school, signature-based prevention platforms like Symantec and early next-gen attempts like Cylance, moving toward the reactive, response-driven EDR model pioneered by Crowdstrike.

It is clear who won that war, but the outcome was far from obvious at the time. I wrote a detailed breakdown on the fragility of that specific market in an earlier piece.

Building endpoint agents is notoriously brutal. It requires deep operating system introspection, hooking into system calls without triggering kernel panics or destroying battery life. Very few companies do this well.

However, my view is that you can actually get away with a subpar agent if you back it with an elite global infrastructure. Look at Cloudflare’s Warp agent for their Gateway product. The local software itself is incredibly lightweight and doesn’t do heavy lifting on the machine; it simply intercepts and routes local traffic to their global edge network, where the actual policy enforcement and inspection happens. Legacy secure web gateways like Zscaler used this exact blueprint to scale.

AI endpoint security will likely follow this same infrastructure pattern. Because almost all heavy LLM computation happens on a remote server rather than the local silicon, the endpoint agent doesn’t need to be massive. It just needs to be a performant traffic cop routing to a specialized proxy.

Management vs. security: The blurring line

If we set aside the raw proxy network layer, the remaining endpoint opportunities fall into two traditional buckets: management and security. Historically, IT handled management and InfoSec handled security, but the rise of autonomous agents is completely blurring that line.

To establish the baseline, traditional endpoint management is about visibility, patching, and software deployment. The dominant players here are Microsoft, Jamf for Apple ecosystems, and Tanium for massive enterprise fleets. This software exists to ensure laptops are compliant and up to date, and it is the mechanism used to deploy EDR tools like Crowdstrike and SentinelOne. The EDR tools then sit on the machine to hunt for active runtime threats and malware.

The endpoint matters more today than it ever has because AI agents are no longer just suggesting code; they are autonomously executing privileged actions, interacting with local shells, and modifying system configurations. When an agent has the privilege to run commands locally, a simple logic or hallucination error can lead to a severe incident. Consider a local agent trying to optimize a dependency loop, accidentally downloading an unvetted, malicious open-source package, and running it locally because it determined the package looked legitimate.

The IT operational trap

This is a highly complex market to sell into because enterprise IT teams are currently stuck in a structural trap. They are either heavily overstaffed or completely understaffed, with very little middle ground.

In bloated enterprises, IT teams are overstaffed with individuals performing hyper-specialized, repetitive operational tasks. AI is on track to completely eliminate these commodity roles. The catch is that when AI automates those tasks away, it is incredibly difficult for a bureaucratic organization to reallocate those specialized workers to higher-value engineering problems. Consequently, selling AI-enabled endpoint tools into these overstaffed legacy environments is a massive uphill battle.

The real growth market belongs to lean, modern startups that don’t have a dedicated IT department at all. In these companies, software engineers or operations generalists are forced to moonlight as IT administrators. Because these teams are small and focused on velocity, they represent the true AI theme: using autonomous software because a single human couldn’t possibly manage the workload without it. They need an agent that regularly handles endpoint patching, monitors fleet health, and auto-enforces compliance in the background without filing a manual ticket. There are other massive IT responsibilities like access provisioning and identity, but fixing the machine baseline autonomously is the core endpoint hurdle.

Mapping the contenders and the checkbooks

Right now, there is no obvious frontrunner for the agentic endpoint.

There is a non-zero chance that frontier AI labs like OpenAI or Anthropic could capture this layer. They already own the developer interface and are building their own security primitives. However, securing an endpoint requires continuous, passive system monitoring, which is a fundamentally different product architecture than on-demand, prompt-driven chatbot interactions.

Instead, Microsoft and Google have the most realistic shot at integrating AI natively into endpoint management. Microsoft has a natural monopoly on Windows endpoints, though they rarely build elegant management experiences outside their own ecosystem. Google, on the other hand, is uniquely positioned to build a cross-platform play. Following their massive acquisition of Wiz, Google Cloud commands an ecosystem that can link threat intelligence directly with cloud-to-runtime visibility. If Google leverages this combined footprint to push out from ChromeOS into macOS and Windows endpoint compliance, they pose a serious threat to traditional IT setups.

The legacy EDR giants like Crowdstrike and SentinelOne obviously have the kernel-level real estate to win this space. But their primary buyer persona is the traditional security operations analyst, a cohort that is historically slow to adopt AI due to organizational inertia. While Crowdstrike is actively pushing marketing around their AI capabilities, their actual core product development inside local agent runtimes moves at a legacy enterprise pace.

The most fascinating dark horse here is Tanium, particularly with their push into the Atlas platform. Tanium already possesses the rare platform architecture that merges IT operations with security visibility. Their new platform layer uses an ensemble of models to ditch traditional fixed modules in favor of dynamically generated pages tailored to what the user is working on, alongside features targeting local LLMs and Model Context Protocol (MCP) servers running on developer endpoints.

It is still too early to say if Atlas will deliver on this promise, and the platform undoubtedly has a long way to go, but it is highly promising. I am cautiously optimistic. I’ve argued in the past that complex, feature-rich legacy platforms that are historically difficult to use actually stand to benefit the most from AI. If you have spent nearly two decades building a massive matrix of deep features, you can use an AI natural-language interface to abstract that complexity away entirely. It is entirely acceptable to have a massive product if you can completely hide the plumbing behind an intelligent assistant.

Ultimately, who wins this market depends entirely on who holds the checkbook, and that is going to split down organizational fault lines. In AI-forward companies, the budget is essentially one big blob. They don’t care about internal territory wars; they care about macro efficiency, so any tool that saves aggregate headcount and automates the fleet will win.

In older, traditional companies, this market is going to be incredibly political. The rise of these unified AI endpoint platforms represents an opportunity for serious consolidation of certain IT and IT security responsibilities. How that plays out depends entirely on how executive leadership wants to steer the political ship.

The ultimate winner in the endpoint market will be the vendor that can thread a very narrow needle: maintaining the deep, performant system telemetry required by legacy enterprises while delivering a frictionless, highly automated product experience that allows lean companies to automate their entire IT footprint out of the box.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

I’m back to writing about the markets that will likely become massive as AI adoption proliferates across enterprises. Last week, we looked at how macro security budgets are fundamentally shifting toward elite generalists. This week, I want to talk about a specific structural primitive that these generalists will use to regain control of their networks: AI proxies.

If you Google the term “AI proxy” today, you mostly find a handful of open-source projects and a couple of high-level articles by legacy gateway players like Kong and Nginx explaining how you can use their technology to intercept AI traffic. In my opinion, these are highly unsatisfying solutions that miss the deeper architectural shift.

Let’s start with the actual problem we want to solve. Yes, it’s shocking that I’m first defining a problem rather than describing a pre-existing market with clean solutions that we are supposed to believe exist even when they aren't based on real first principles. Sorry, I digress.

Lately, social media and the news have been filled with wild stories about what happens when you let autonomous AI agents roam free and vibe code inside a production environment. For example, there was the recent incident with PocketOS, where a Cursor agent mistakenly wiped an entire production database. While this feels like an indictment of basic software engineering posture, i.e., why didn't they have immutable backups or restricted schema privileges in place, it continuously gives traditional security teams more ammunition to slow down AI adoption. You can easily find or anecdotally construct a terrifying story about why we need to put the brakes on LLMs due to misconfigurations and data leaks.

But as I’ve always advocated, trying to block AI is a losing battle. Its adoption is inevitable because it accelerates software development at a scale we have never seen before. You can see it in how fast teams are adopting tools like Claude Code and Codex, forcing a massive competitive race where Anthropic has rapidly closed the gap with OpenAI. Attackers are already leveraging AI daily, so every day a security team spends trying to prevent internal adoption is valuable time lost that should have been spent learning how to make AI work for them. The risk is evolving, and we should spend our cycles adapting to the runtime rather than pretending we can block the API.

To give security teams peace of mind without killing developer velocity, we need to lean on a concept that is actually nothing new: proxies.

Proxies are an age-old architectural tool that security has always used to regulate and govern new technology waves. We used web application firewalls to handle web traffic, and cloud access security brokers (CASBs) to govern SaaS usage. We use proxy-like abstractions from Cloudflare and Akamai to protect modern APIs. The pattern repeats because it works. We desperately need guardrails around AI, and an inline proxy is the most logical way to inject them.

Local vs. Cloud agents: The architectural split

When we look at how AI agents interact with an enterprise, the threat surface splits into two main environments: local agents running on endpoints and cloud agents running inside production infrastructure.

Local agents are the immediate hurdle. These are direct calls to LLM APIs originating from developer laptops via IDE extensions and terminal tools. Cloud agents, on the other hand, operate deeper within your production infrastructure to orchestrate backend workflows. Right now, only SaaS providers and highly advanced engineering organizations are running fully autonomous cloud agents, but they will become standard across the board over time.

Technically, both of these environments are just endpoints making API calls, but history shows us that security platforms struggle to secure both simultaneously. Giants like Crowdstrike and SentinelOne built dominant businesses on laptop endpoints, but struggled to capture the cloud, leaving the door wide open for companies like Wiz to dominate cloud infrastructure security. Cloud and infrastructure workloads operate on entirely different patterns, velocities, and privilege models than a developer’s laptop.

Because of this inherent friction, I imagine the market will split into two separate product types to handle local and cloud agents independently, mirroring the historical divide between traditional endpoint protection and cloud security posture management.

The real technical hurdle: Streaming token latency

But if you want to understand if an AI proxy is legitimate or just a marketing wrapper, you have to look at how it handles the streaming token problem. A viable product in this space must maintain exceptionally low latency while processing a massive volume of concurrent requests.

Traditional web proxies look at static HTTP payloads. They intercept a request, scan the complete block of text for a signature or a social security number, and either block it or let it pass. That model fails completely when applied to LLMs.

AI interactions are heavily reliant on real-time streaming tokens. When a developer uses an autocomplete function in their IDE, the tokens are fed to their screen millisecond by millisecond. If an AI proxy acts like an old-school gateway, i.e., holding the streaming response back until it can inspect the entire paragraph for a security violation, it adds massive latency. If your security tool adds even 200ms of lag to a developer’s terminal, it ruins the interactive experience, and engineers will immediately write a script to bypass it.

A modern AI proxy has to be engineered from the ground up to inspect data streams on the fly. It needs to evaluate context window shifts, scan for prompt injection techniques, and mask secrets dynamically within the token stream without breaking the connection or adding perceptible lag. This is a massive engineering challenge that traditional network architectures simply aren’t built to handle.

However, it’s possible that the developer can tolerate some latency since Claude does take some time to respond.

The infrastructure moat

This exact dynamic explains why companies like Zscaler and Cloudflare became so massively successful in the SWG and CASB worlds. They understood early on that performance is everything. You cannot deliver low latency and handle millions of concurrent requests across global teams if you are renting generic compute or routing through sloppy third-party networks.

Having your own dedicated global infrastructure is the ultimate moat in network security. Netskope spent years trying to route through third-party infrastructure before realizing they had to build their own global network to make the margins and the performance profile make sense. If an AI proxy doesn’t sit on a highly optimized, distributed network, the request throughput will crush it.

When you look at infrastructure access management and identity proxies like Teleport, StrongDM, and a more recent startup called Formal AI, you see a completely different profile. These are highly specialized proxies designed to grant secure access to non-public infrastructure, like a production database or a development box, without exposing them to the raw internet. Unlike SWGs, these proxies don’t handle massive, high-volume web traffic because their footprint is restricted to specific engineering sessions.

Among all of these players, only one has built an explicit product around intercepting and governing AI traffic: Formal AI. (Disclaimer: I am a customer of Formal AI and Cloudflare, and I’ve used Teleport in the past.)

Why haven’t the others jumped on this yet? For Teleport and StrongDM, their current infrastructure setups simply aren’t engineered to handle high-volume, continuous LLM data streams. For legacy giants like Zscaler and Netskope, they are currently blinded by the sheer size of the traditional cloud security market and are optimized for a slower corporate buyer. They are likely going to miss the initial window, which is wild considering they already own the global network infrastructure required to scale AI traffic interception, which will eventually demand handling tokens and prompts at a greater volume than standard web payloads.

The policy moat: programmable security

There is a deeper philosophical issue with the legacy proxy vendors. Almost all of them fail to provide a flexible way for users to define and enforce custom, programmatic policies. They offer rigid, out-of-the-box checkboxes, but they don’t give you a true code-based engine to write your own rules. This shouldn’t surprise anyone who has worked in this space for a while; security teams have historically not been good at programming, and vendors built their UIs to cater to that lack of technical depth.

Formal AI, by contrast, is built on the thesis that the next generation of security engineers will be highly technical practitioners who want to treat policy as code. They treat security engineers like developers who need a programmable proxy to parse, inspect, and mutate AI prompts and responses in real time.

Eventually, the endpoint giants like Crowdstrike and SentinelOne will try to enter this race as well. But right now, their main enterprise customer bases aren’t actively asking for AI proxy guardrails. The market feels small today because security teams are still stuck in a state of paralysis, trying to figure out how to block AI entirely rather than architecting a proxy solution. There simply isn’t enough education or sophisticated marketing around the concept yet.

The path forward for AI proxies

While Formal AI has a clear first-mover advantage, their current architecture requires customers to self-host the proxy. This places a significant operational burden on internal infrastructure teams who have to manage the scaling, availability, and latency of a critical path dev tool. To maintain their lead, they will eventually have to transition to a fully hosted model and invest heavily in their own global cloud infrastructure to survive the raw traffic load.

Building a basic proxy wrapper isn’t rocket science, but building a highly nuanced product that understands semantic context, prompt injection, and data loss prevention at the edge without adding latency to a developer’s IDE is incredibly difficult.

I find it hard to see legacy vendors like Zscaler or Netskope executing well here; their DNA is too corporate and far removed from the developer workflow. Teleport and StrongDM lack the global routing networks. Cloudflare remains the only legacy competitor with a real shot at winning this space because of their native closeness to developers. However, it feels like they have recently lost touch with the new generation of engineers who are building entirely with autonomous agents. Cloudflare seems content to double down on their core CDN and traditional traffic proxying rather than building opinionated runtime controls for AI.

Ultimately, this category will belong to the platforms that understand security engineers are now builders, not auditors. The winning AI proxy won’t just block bad strings; it will act as a highly programmable, low-latency translation layer that allows enterprises to embrace agentic velocity safely.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

Sorry for the brief hiatus! I went on vacation and had to handle some busyness at work. But the extra time away gave me space to step back and think. For the past few weeks, I’ve been writing about various markets and categories that I believe are completely misunderstood by legacy security research firms who haven't caught up to the realities of AI.

While evaluating specific tech blocks like product security is useful, I realized I missed the macro picture: the cybersecurity budget itself.

Markets are created through spending, and spending flows entirely from how budgets are allocated. If we don’t understand how the security dollar is morphing, we can’t accurately predict which startups are going to win.

I’ve talked in the past about how cybersecurity is facing an efficiency reckoning. The industry was neglected pre-2010s, which led to a historic wave of high-profile hacks. The reaction was a decade of blank checks. Security teams got used to spending without justification, hiding behind fear, uncertainty, and doubt (FUD) to balloon their headcount. In my new year’s predictions over the last couple of years, I’ve consistently argued that this era is over. Security is finally being forced to justify its existence as a business function, and AI is acting as the ultimate catalyst for that pressure.

The target market: AI-forward vs. legacy

Security has always had a spectrum of markets tailored to different types of organizations with different appetites for risk. I’m not going to focus on legacy companies here. They will evolve slowly, their budgets will remain tied to legacy infrastructure, and they aren’t where market-defining shifts happen. This is exactly like the early days of the cloud; cloud security budgets didn’t come from old-school enterprises dragging their feet. They came from the companies rapidly building on SaaS and AWS.

My focus is on AI-forward companies, i.e., the ones where the vast majority of new code is AI-generated, and the companies aggressively trying to catch up to them.

Right now, broad enterprise AI adoption is still relatively slow. But when it accelerates, it will happen much faster than the cloud transition did. Moving to the cloud required massive, multi-year architectural and infrastructure overhauls. Moving to AI is operationally trivial by comparison; you open an API or a chatbot and start interacting with it. As autonomous agents improve, the friction to adopt drops to near zero.

When an organization pivots to this level of velocity, its security budget undergoes a structural transformation across three main buckets: governance, headcount, and tooling.

Governance and compliance (The automated baseline)

We aren’t escaping the need for governance. Customers still demand proof of compliance, and navigating audits like SOC2 or ISO requires real operational work.

Depending on your customer volume and how consistent your compliance needs are, this will either live in-house or get outsourced. Historically, compliance scaling was linear: more headcount meant more systems, which meant more auditors and more internal program managers to babysit them.

In an AI-forward shop, team size stays small, meaning internal compliance friction scales much slower. My best estimate for the total cost of this bucket is roughly 3-4x the hard cost of the audit itself to account for tooling and baseline operational support. It’s a mandatory cost, but it’s no longer a headcount driver. It’s an optimized baseline.

The elite engineering premium and the post-ZIRP reality

The real structural shift happens in headcount. The traditional security organization is top-heavy, filled with specialized analysts whose primary job is manually triaging alerts or running internal processes.

In our current post-ZIRP world, we finally have to talk about the hidden cost of those large teams: management overhead and organizational bureaucracy. In the zero-interest rate environment, companies didn’t care about throwing managers at broken processes. Today, every layer of human management requires justification. If you look at the recent layoffs in tech, they are flattening the org to pre-2010s era.

In an AI-forward org, that model completely flips. The absolute magnitude of your security team shrinks dramatically because you no longer build vast, bureaucratic empires. Instead, your engineering ratios tighten to about 1 security engineer for every 30 developers. That number sounds crazy on paper, but it works because the overall team size is small. In fact, it might seem small in magnitude.

You aren’t hiring junior analysts to look at dashboards. You are hiring an elite tier of versatile security generalists, specifically software engineers who know how to automate defense. They will command a massive premium over traditional developers because they know how to scale themselves using autonomous agents.

We are currently in a massive state of transition. We are going to see real wage compression for commodity security roles, but the top-tier engineers who can design autonomous systems will be highly sought after. They don’t require armies of program managers or layers of executive bureaucracy to tell them what to do. They build the automated enforcement loops that auto-remediate infrastructure as developers deploy code at machine speed. When security work is slow, they jump into product and infrastructure code. They focus entirely on outcomes, swapping administrative waste for highly leveraged engineering.

Tooling: one-shot context over SaaS markups

Because headcount is shrinking, the remaining budget is flowing directly into AI tooling and model compute. But the mechanics of how we pay for this are changing fast.

Much like the early database and cloud markets, raw model compute is rapidly becoming a commoditized utility like AWS. As the market becomes hyper-competitive, model costs are going to plummet. Sophisticated buyers are already waking up to this reality and demanding to Bring Your Own Key (BYOK) for their security software. They want to avoid paying massive SaaS markups to tier-3 startups that are just passing model costs down with an arbitrary premium.

This brings us to a critical inflection point for vendors: If raw model access is cheap and commoditized, what is the actual value of a security product?

The value is expert context.

Right now, a lot of tools are just glorified chat interfaces. They require a user to have a continuous back-and-forth conversation with an AI to get a task done. That is not a product; that is a chore.

Good context means providing the LLM with the exact prompt infrastructure, code history, and environmental metadata it needs to operate autonomously. A winning product allows the AI to execute in a one-shot manner. It should see an infrastructure change, ingest the exact context required, make the correct security decision, and execute the fix without human intervention.

Specialized vendors will be rewarded not for their access to AI models, but for their ability to deliver these clean, highly optimized context layers. They will replace legacy application security platforms by removing the need for janky professional services, complex internal workarounds, and manual prompt-engineering. They will sell an out-of-the-box product experience that is easy to tailor to a company’s specific codebase.

There will still be things that remain cheaper for a human to do than a model. The economics of what tasks to hand over to an agent are still sorting themselves out, and you will still have a fixed baseline spend for foundational infrastructure primitives like Cloudflare or AWS that manage physical data distribution.

The new market reality

When you roll all of this together, the picture becomes clear: the cybersecurity budget of the future is shifting away from human management overhead and janky middleware, moving straight toward highly compensated generalists and autonomous, context-rich software.

Organizations will be completely flat. For security vendors, the legacy GTM playbook is officially an artifact of the ZIRP era. If your product relies on adding more tasks to a dashboard or requires a massive team of human analysts to justify its value, your budget slice is actively being reallocated. The future belongs to the platforms that enable elite generalists to run autonomous, one-shot defense at the speed of code.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

I’m continuing my series on evaluating categories and products through a practitioner’s lens. I started by defining "AI-Enabled Product Security" because the rapid shift in development velocity essentially broke the old AppSec categories.

This week, I’m tackling a category that has been around for decades: email security. While there is a lot of talk about this space, I believe research firms like Gartner are still looking in the rearview mirror. Their requirements often fail to reflect the radical heterogeneity of modern, AI-native environments. Gartner has decades of data on email evolution, but they are focused on legacy use cases that don’t apply to the lean, cloud-first companies of 2026. This post is my attempt to “modernize” the category and discuss the nuance that analysts miss.

A brief history of email friction

To understand where we are, we have to look at how we got here. In the pre-cloud era, IT teams hosted their own email servers like Exchange. Security was a gateway, i.e., a physical or virtual box that sat in front of the server and scrubbed mail before it arrived.

When the cloud arrived, hosting your own email server became a liability. Companies and IT teams realized Google and Microsoft could handle the scale and uptime better than they ever could. But as companies moved to SaaS, the gateway model broke. Asking all your mail to route through a third-party gateway before hitting Google created massive latency and broke core SaaS features.

The response was the rise of API-based email security. I wrote in the past how email security is changing. Instead of sitting in front of the server, these tools connect directly to the mail provider via API. There is a slight lag in reading the mail, but the performance tradeoff is worth it because you no longer have to manage a janky gateway.

The shift from “inbox” to “collaboration suite”

Almost three years ago, I did a deep dive on email security before I spent more time in it (and owned it as part of my role). I wrote that it’s hard to innovate, and there will be multiple winners. I did predict somewhat correctly that a successful product has to keep innovating and adapting to the changing landscape. There has been quite the change even in the past 3 years.

The bigger change, however, wasn’t technical—it was behavioral. We use email less for internal communication now. Slack and Teams have taken over that role. This means the internal threat vector of one employee phishing another has lessened in the inbox.

However, at the same time, our email providers like Google and Microsoft became our collaboration suites. We don’t just send mail; we share docs, slides, and spreadsheets. Most importantly, we use these providers for Identity and OAuth.

The inbox is no longer just a communication tool; it is the keys to the kingdom. If I compromise your Google account, I don’t just read your mail, but I have your SSO, your cloud storage, and your authenticated third-party apps. This has created two new threat vectors that traditional gateways can’t see:

1. DLP & Permissions: Who is sharing sensitive documents externally?

2. Identity/OAuth: What third-party apps have “God Mode” access to your suite?

The modern players: A review

If you look at the Gartner Magic Quadrant, you’ll see old-school gateway companies. For an AI-native company, these are useless. (In fact, I don’t even want the show the magic quadrant here. It’s not helpful for anyone.) They require dedicated security teams to babysit them. You want automation. Here is my take on the API-based modern players:

1. Cloudflare (Area 1)

Cloudflare acquired Area 1 and integrated it as an API option, though they still offer a gateway. If you already live in the Cloudflare ecosystem, this is a fine “better than nothing” option. However, the functionality is still immature and the UI feels clunky compared to the specialists. It’s an add-on, not a flagship product.

2. Abnormal Security

Abnormal is the heavyweight in the API space for a reason. They focus heavily on AI-driven detection for account takeovers, sophisticated phishing, and social engineering.

The Verdict: Abnormal is a powerhouse if you are on Microsoft. It works incredibly well out of the box and can effectively eliminate the need for a dedicated email security team. It’s flexible enough to augment a large org or automate a small one. The detections are top-tier, though they are increasingly moving into the platform space like SIEM, which might distract them from the core suite problem. They also aggressively move borderline emails into spam, especially at larger companies where it’s better to have false positives than false negatives.

3. Sublime Security

Sublime markets itself as the next-gen option, but in my opinion, it feels like a step backward for most teams. Their core hook is allowing security teams to write their own custom detections and rules.

The Verdict: Unless you are a massive company with a dedicated Detection & Response team that wants to write custom code for their inbox, this is a hard sell. Most companies want automation. They don’t have the time to write rules, and they certainly don’t have the cross-customer data that a vendor has to identify global attacks. It’s also not clear if it makes sense to do detections at the email security tool level instead of piping it into a SIEM and centralizing detections there.

Sublime is a niche tool for the 1% of teams that want to DIY their email security. Though, it does seem like they are moving toward more autonomous AI agents that can do the detections for you. Given where they started, they likely have much less data and analytics than their competitors. Experience and time in market matters a lot because that’s the main benefit/moat of such a product.

4. Material Security

In my opinion, Material has the strongest offering for the AI-native and cloud-native world, specifically those on Google Workspace. (Disclaimer: I’ve been a long-time customer.)

The Verdict: While Abnormal and Material are a wash when it comes to pure email detections, Material wins on coverage. They aren’t just an email tool; they are a collaboration suite security tool. They look for permissioning issues across your entire drive and have the most advanced OAuth protection on the market. Their timing on OAuth is perfect, especially given the recent Vercel OAuth breach, where malicious apps used hijacked tokens to bypass security entirely.

Material allows for deep customization around response and detection without requiring a team to maintain it. Also if you want, you can extract their data into your SIEM and write your own detections on top of that, you can. If you are on Google Workspace and you care about the entire Office threat surface, i.e., not just the inbox, Material is the clear winner. Their Microsoft offering is catching up, but their DNA is deep in the cloud-native ecosystem.

Conclusion: The “babysitter” test

When choosing an email security tool in 2026, you have to ask yourself: “Does this tool give me an engineer, or does it give me a task?” Gartner likes tools that give you tasks like gateways that need management. I prefer tools that give you an engineer — automated platforms that handle the Office surface area so I can focus on the product.

For the AI-progressive company, the goal isn’t just to stop phishing; it’s to secure the identity layer that powers your entire AI-driven workflow.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

In the past few weeks, I’ve written extensively about how AI has redefined markets so much that typical research firms can’t keep up. Large security categories are being birthed in the shadows of these firms, and startups will miss the generational opportunity of our era if they continue to buy into legacy definitions. This is why I started my own series, beginning with “AI-enabled product security.”

But as I’ve been talking to more founders, I’ve realized that the confusion isn't just about what to build, but it’s about who to sell to. It seems that many of them have forgotten a key part of the product strategy. The industry is currently drowning in marketing noise and an unnecessary surplus of venture capital money, and it’s led to a collective hallucination about where the actual "high-growth" market lives.

Security vendors reach out to me or my contacts constantly. They want me as a customer because I’m a "fast-growing startup logo” in the AI space. And to be fair, when I evaluate products, I look at the logo list too. I want to see other high-velocity teams to know the tool can handle the heat. This is my third time through the fast-growing startup gauntlet, and I’ve noticed a jarring shift in the "sales discovery" phase.

The wrong question for 2026

At my first and second startups, the discovery questions made sense. They asked about my pain points and how their tool would scale as I grew. Back then, “growth” was a linear function of people. I was a good fit because I had a growing security team and a growing company in both revenue and headcount.

Recently, these calls have been... different. Sales reps still start by asking, “How big is your team?” or “What’s your total headcount?”

This is the wrong question to ask an AI company. AI-native firms are famously lean; they have small headcounts but astronomical revenue. Usually, the vendors who ask this are tailoring their products to companies with high headcounts and low revenue to the “legacy SaaS” archetype. It’s a bizarre strategy. Why would you prioritize a customer with thousands of employees and thin margins over a lean team with massive revenue and spending power who probably need tools more than ever?

The SaaS flywheel is broken

To understand why this is happening, we have to look at the three resources that drive any company: people, processes, and tools.

In the 2010s SaaS era, these three elements formed a growth flywheel. To get more revenue, you hired more people. Because you had more people, you needed more complex processes to coordinate them. And because those processes were messy, you bought more tools to surface issues and automate the friction.

Security vendors loved this. High headcount meant more “human error” surface area. It meant broken processes that needed a security tool to “govern.”

Take Okta as the classic example. As companies scaled in terms of people, Google Workspace’s built-in functionality for groups and integrations eventually broke down. You needed Okta to manage the chaos of 5,000 employees. But in 2026, many AI-native companies are sticking with Google Workspace as their primary IdP. Why? Because they don’t have the “people scale” problem. They have 100 people doing the work of 1,000. The complexity that Okta solves simply hasn’t triggered yet.

Solving people problems vs. engineering problems

A lot of security companies are fundamentally trying to solve “people problems.” They care about headcount because their product is essentially a babysitter for human-led processes.

• access requests: In a 2,000-person company, access requests are a nightmare. In a 50-person AI startup, it’s a non-issue.

• third-party risk: Legacy GTM focuses on the bureaucratic overhead of vendor management. But for a lean team, the risk isn’t the number of vendors; it’s the depth of integration.

If your GTM playbook is based on the assumption that more revenue equals more employees, you are ghosting the most profitable market in the world. High-growth companies today are growing through tools (AI) and processes, not headcount. Headcount is no longer correlated with business success.

Choose your market: legacy vs. lean

Startups have to choose a market. It’s okay to target the “growing people” market, but you have to recognize that these aren’t the high-growth leaders anymore. They are a shrinking market, and they might grow in the short-term, but become more competitive in the long-term, as the revenues and margins of the company will stagnate compared to the AI-native firms. In fact, they face a completely different set of problems than the fast-growing, AI-native firms.

If you want to target a large market, stop focusing on headcount growth as your primary qualifier. You should focus your strategy on the “undersought market”: small companies doing big things.

The benefits are obvious:

1. Lower friction: Small teams have lighter procurement processes.

2. Faster revenue: Less buy-in is required, leading to a shorter sales cycle.

3. Higher stickiness: A lean team doesn’t have the bandwidth to constantly swap out core infrastructure.

I’ve talked about this before, i.e., our archaic third-party risk processes were built for a world that no longer exists.

A new playbook for lean security

The market for lean security teams is large and growing. These teams aren’t looking for a “seat-based” tool that assumes they’ll hire 20 more analysts next year. They are looking for force multipliers. They want tools that act like an extra engineer, not a management dashboard.

Why don’t more vendors follow this playbook? Honestly, I think it’s laziness. The old playbook is familiar. It’s “safe.” But isn’t the point of a startup to take high risks for high returns? Security, with its culture of fast exits and easy VC funding, has gotten distracted by “people and processes.” It doesn’t help that many of the security founders who have “product intuition” are also likely trying to solve problems they experienced at their former companies. However, context matters. Those problems are likely not going to be the problems in the AI future. The new generation of AI-native security founders doesn’t quite exist again.

But that’s ok because these companies can still build. It’s time to support the people who are building rapidly, rather than trying to solve the problems that result from having too many people and processes in the room. The future of security isn’t in managing the headcount. It’s in empowering the outcome.

If you are a founder or a GTM leader in 2026, you have a choice: you can build for the organizational bloat of the 2010s, or you can build for the high-output, low-headcount future.

Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

Last week, I defined what I believe is the emerging category of AI-enabled product security. This week, I’m following up with a "review" of a few major players. Hopefully, there will be more of this in the future, but this is my first attempt, and I’m sure the format will evolve.

Before I get into the companies, a quick word on methodology. I don’t currently own any of these products, but that doesn’t mean they don’t provide value. I spent time digging through the marketing, case studies, and technical docs for Clover Security, Clearly AI, DevArmor, Prime Security, securityreview.ai, Seezo, and Irius Risk.

A few of these vendors, specifically Clearly AI, DevArmor, and Prime Security, reached out to me directly, so I got a better sense of the founders and their vision. My goal was to narrow it down to the 1-2 vendors I’d actually take a deep dive into if I were buying today.

The problem: Scaling the unscalable

These companies aren’t trying to automate every corner of product security. They are focused on the “operationally intensive” work: security reviews and threat modeling.

If you aren’t in product security, security reviews are the process of evaluating new features for risk, while threat modeling is the strategic work of figuring out which threats actually matter to the business. I’ve written before on why I think the traditional way we do these is broken.

The problem is that a security review is an art. It depends entirely on the “artist”—the reviewer. Most reviewers lack the deep engineering nuance to provide truly helpful feedback. In the AI era, where development velocity has exploded, the manual “questionnaire and meeting” model is officially dead. You can’t hire enough people to keep up with developers who are using AI to ship 10x faster.

Beyond security, there is the compliance angle. While checking a box for an auditor is a necessary evil, it shouldn’t be the only reason you do a review. If it is, it becomes a race to the bottom of “who can check the box with the least amount of friction,” which does nothing for actual security.

The “pass” list: compliance-first and wrappers

Let’s start with the products I didn’t find particularly compelling for a high-growth, engineering-centric organization. The reason is that they are basic wrappers or compliance-first. These aren’t sustainable products and/or have short shelf lives.

• IriusRisk: They are too focused on threat modeling in isolation. In my experience, threat modeling is only a small piece of the puzzle. If you aren’t integrating that insight into the daily security review and development flow, it just becomes a stale document.

• securityreview.ai: This feels like it’s built almost exclusively for auditors. It promises “fast” reviews to check a box, but it does very little to convince me they care about actual security posture.

• Seezo: This felt promising until I read their FAQ at the bottom. This looks like a light wrapper around existing LLMs with a basic dashboard. Their value-add seems to be maintaining prompts and regulatory frameworks, i.e., things that any competent engineer can now build themselves with a few well-placed API calls. It’s a tool for teams that don’t know how to prompt or make AI work for them, which isn’t a sustainable moat.

The “middle ground”: Prime Security and Clover Security

Prime Security and Clover Security are clearly more mature, but they suffer from some “incumbent-lite” thinking. Both lean heavily on the word “agentic,” which has become a bit of a buzzword. It makes me worry they are just prompt-chaining wrappers that will eventually be commoditized by the foundational labs themselves.

• Prime Security: They seem to lack deep integrations (according to some competitive analysis), but the bigger issue is the philosophy. It feels like they are ingesting engineering data into a separate, security-owned stack. It’s an “outside-in” view that provides visibility but doesn’t actually live where the work happens.

• Clover Security: They talk a lot about “automating” the review, but it’s not clear that automation leads to better quality, just more reviews. They build a “live context graph” from docs and tickets, which is great for scale, but it feels like they are trying to accelerate a legacy process rather than reimagining what a review looks like in an AI-first world.

The future: Clearly AI and DevArmor

This leaves the two I found most promising: DevArmor and Clearly AI. What sets them apart is that they have an opinion on where engineering is going, rather than just helping security do “more of the same.”

Both have clever hooks into compliance, but they treat it as a byproduct of good engineering rather than the goal. They also understand that for security to scale at AI speed, it has to be integrated, not just “connected.”

• DevArmor: I really like their focus on the developer experience. They integrate directly into the PR flow, providing real-time remediation suggestions where the developer is already working. They are trying to “automate the expert,” using AI to analyze exploit requirements and network topology to eliminate the noise that usually kills developer trust.

• Clearly AI: They take a “security specs” approach. They intelligently connect to Confluence, Jira, and GitHub to pull context at runtime (using RAG) rather than requiring static document uploads. They are effectively building a “context engine” that feeds security requirements directly into the AI context files that developers use to write code.

What’s interesting is the team DNA. DevArmor’s founders come from a strong AI/ML and engineering background, while Clearly AI is led by deep security engineering experts. It shows in the products — both have engineering-friendly UIs and demos that actually look like tools a developer wouldn't hate, rather than trying to create yet another security dashboard so that security doesn’t get left behind.

Conclusion: fast horse vs. cars

If you want your security team to become integrated with development, or if you’re hiring engineering-focused security people, Clearly AI and DevArmor are the leaders. If you want a separate security stack to monitor from the sidelines, Prime and Clover might be better.

I’m biased toward the integrated approach. In a world where AI is writing the majority of the code, trying to “review” that code from a separate stack is a losing battle. You can’t just do what you were doing faster; you have to change how you do it.

Think of it like the transition from horses to cars in the early 1900s. You can buy a faster horse (automation for legacy processes), or you can learn how to drive the car (integrated, AI-native security). The companies that lean into the “car” will be the ones that actually survive the collapse of the exploitation window from weeks to minutes. Really, AI has opened up the possibilities for us, and we shouldn’t treat it like a faster horse.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

Last week, I wrote about how AI is breaking security categories and how current research firms don’t properly provide guidance that’s useful for modern companies. The first category I want to dive into is one I'm calling AI-enabled product security. Yes, I just made up that name, but I’ll explain more about why it’s a necessary distinction.

I want to preface this by saying this is the first analysis of its kind for this newsletter. I don’t think this even qualifies as a research report or a deep dive, given that it’s somewhat high-level. The format might change as I figure out how to write something substantive with the limited time I have. A long report isn’t practical, but I do want to make sure my thoughts are consumable.

So, I’m going to start by defining the space and the market in this post. I think a newsletter that defines the space and what makes a compelling product is its own substantive piece of work. People will get the format as it happens.

What is AI-enabled product security?

This is a timely topic given the release of Project Glasswing from Anthropic. It’s a move that is redefining a core part of application and product security: finding and remediating vulnerabilities.

Product security has gone through some complicated changes lately. Nowadays, it’s been reduced to mostly operational work, e.g., bug bounties, scanning, and security reviews. But it’s actually much more than that. It’s about finding issues in application business logic or helping with secure design. Much of that is being lost because there’s so much operational noise. Given the velocity of engineering today, there’s no time for deep work. The bigger problem is that vulnerability scanning tools like Snyk and Semgrep are actually making this harder by generating alerts that leave security teams stuck triaging priority with engineering. Aren’t tools supposed to reduce work?

This is where ai-enabled product security comes in. These are tools that help with the operational aspects by automating the triage and coordination. In the past, to meet engineering velocity, you had to hire more people. But with AI, hiring more people isn’t feasible or scalable. You have to combat AI velocity with AI velocity.

I didn’t think things would change this fast. Foundational models like Claude are outpacing the specialized application security companies. About 1.5 years ago, I thought companies like Semgrep could use AI to help with remediation. I didn’t realize Claude would be able to do this so quickly and effectively on its own.

Segmenting the customer: Who is this for?

Working at an AI company has given me a lot of perspective on how nuanced this market is. To understand what these products should look like, we need to segment the customer personas. This is an oversimplification, but it’s a good starting point.

I see three main customer types:

1. The AI-native company: They are heavy users of AI and have successfully integrated LLMs into most of their workflows without outside tooling. They aren’t likely to buy these products because they’ll just build them themselves using Claude or OpenAI.

2. The legacy company: They are slow to change. They haven’t figured out their AI strategy and will likely stick with traditional appsec companies that have “AI features.” This is a shrinking, an increasingly competitive market.

3. The AI-progressive company: This is the most interesting group. They want to use AI and have a strategy, but they haven’t figured out the execution yet.

I believe the AI-progressive companies are the real growing market. Their engineering teams are actively adopting AI and increasing feature velocity, which puts immense pressure on product security. These teams aren’t going to undergo a massive organizational change overnight; they are looking for AI as an augmentor. This could also include smaller companies that don’t have the resources to hire a dedicated security engineer, so software engineers are forced to do most of the security work themselves.

Two paths for successful products

There are two types of AI-enabled products that will be useful here.

The first is service as a software that Sequoia describes as the future of AI software. This is software that helps companies use Claude more effectively by providing data and abstraction layers. I believe companies like Snyk or Endor Labs can pivot into this as Claude takes over their core “scanning” business. These companies have insight into private codebases that aren’t available to Claude. They can apply reinforcement learning or fine-tune models to help companies become more AI-enabled. I know of some services helping with Claude Code usage, but almost no one doing it at scale to improve product security specifically. It’s hard to do without business or code context.

The second type focuses on operational velocity. These tools improve processes around threat modeling and security reviews. They do two things: they streamline the process to obviate the need for a manager to handle triage, and they provide context so a security engineer can do more reviews faster. They do a “first pass” to detect serious vulnerabilities before they are deployed.

There are many new companies here: Clover Security, Clearly AI, DevArmor, Prime Security, Seezo, and Irius Risk. Their marketing all sounds similar right now, which is actually clever because it allows organizations to buy into the promise of being AI-progressive.

Why this is good for the industry

What I find most exciting about this shift is that it democratizes talent. Historically, elite security expertise was concentrated in a few top-tier firms or specialized research teams. If you didn’t have the budget to hire a “rockstar” team, your product security suffered.

AI-enabled product security changes that. By spreading expertise through software, we are effectively decentralizing talent. A software engineer at a 10-person startup can now access the same level of threat modeling and secure design guidance that was once reserved for big tech companies. This leads to fewer vulnerabilities across the entire ecosystem over time. It’s not about replacing humans; it’s about making sure that high-level security knowledge is available to everyone, regardless of their headcount.

The roadmap to stickiness

The key for these startups, especially the ones in the second category focused on operational velocity, is to guide customers on their AI journey. This can’t be the final product; it’s too easy to churn once a team learns to use Claude Code and OpenAI Codex directly. To stay sticky, these companies must become the ramp that allows ai-progressive companies to look like ai-native ones. They provide security services enabled by AI, using the data they gather to tailor solutions to a company’s specific product security needs.

The era of winning through GTM spend is over. Product superiority is everything now. In my next post, I’ll talk about my thought process as I lightly evaluate a few of these products. I plan to watch demo videos or sit through 15-minute demos with companies that reach out.

The key is helping a company guide their own unique journey to becoming AI-native.

Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

RSA was quite a conference this year. Honestly, I’m exhausted even though I didn’t spend much time on the actual show floor. It didn’t help that San Francisco is “back.” But I loved how high the energy was and how people were eager to lean into the good vibes and catch up in person.

Of course, the happy hours were filled with talk about Delve’s fake compliance reports. But I don’t think that news deserves its own blog post. While it makes for juicy gossip, it’s ultimately uninteresting. There’s no reason to waste breath on a startup trying to cheat on reports that aren’t even that hard to create honestly, in the first place.

Instead, I want to talk about the deeper conversations I had regarding the thoughts in my previous newsletter.

The most fascinating part of these conversations wasn’t people’s general opinions on AI, but how nuanced those opinions were based on how “AI-native” their specific organization was. I dug deeper and found that AI-native companies are structured differently across the entire organization, not just security. It’s no surprise that a giant like Meta is undergoing a massive reorganization. When AI changes the fundamental way work is performed, the old structures and management assumptions simply stop working.

The spectrum of evolution

Different companies evolve at different rates technologically. I’m not here to argue that every company should evolve faster, but rather to state a fact: companies now exist on a wildly diverse spectrum of AI literacy.

We’ve seen this movie before. When the cloud arrived, it ushered in faster release cycles and the emergence of DevOps. Security was left behind because it treated infrastructure like legacy IT, while the rest of the org treated it like engineering. That disconnect created a vacuum filled by companies like Semgrep and Snyk. But when those companies first arrived, they weren’t in the Gartner Magic Quadrant. They weren’t considered “real players” by the traditional research firms because they didn’t fit the existing checkboxes.

The Gartner paradox

I have strong beliefs that Gartner lacks a true practitioner’s view — a view required to navigate today’s nuance. However, I’ll also defend them for a moment: they have an impossibly difficult job.

In the “old world,” most companies had similar setups: on-prem servers, waterfall development, and Active Directory. It was easy to categorize products because the environments were homogeneous. Today, companies have wildly different stacks. Some are hybrid, some are all-Mac, some are pure-cloud.

AI has made this heterogeneity explosive. I know companies where 95-100% of the code is written with AI, and others where it’s less than 10%. How do you create a “security category” that encompasses that divide? You can’t. Any report that tries to average those two extremes ends up being useless to both.

As someone deep in the AI space, I don’t know a single person who still reads Gartner and trusts the results for modern stacks. It doesn’t mean they aren’t useful for legacy environments, but Gartner has to make assumptions about what a “typical” company needs to determine if a product is “good.” In 2026, those assumptions are broken.

Consider Privileged Access Management (PAM). This category has been well-defined for years by companies like CyberArk. But those tools make zero sense if you don’t use Active Directory, live in the cloud, and give your engineers local admin rights on their Macs. Let’s not forget that CyberArk started by selling a physical appliance.

In AI, things move even faster. The use of AI evolves so quickly that it shocks even me. I can’t imagine how fast it feels to people who don’t operate in it every day. You can’t do a few interviews, talk to some practitioners, and push a research report six months later. By the time the PDF is published, the category has already shifted.

The practitioner’s pivot and what I’m going to do about it

I’ve become disillusioned with traditional “research.” I prefer to talk about products and contextualize them for the environments they actually serve. That’s why I started this newsletter: to provide a direct, nuanced view that research firms can’t offer.

I believe former practitioners, like Mike Privette with Return on Security, provide a much better ROI than the big analyst firms. Especially with AI, where fear and uncertainty are rampant, having a “live” view of categories is more important than ever.

What I realized at RSA is that I need to use this platform to define the categories that research firms are missing. I plan to discuss AI-native categories in real-time. Staying at the forefront will help companies catch up and evolve without scrambling to adapt an outdated report to a modern organization.

This is a mini-announcement: I will be writing more posts that define and analyze these emerging categories. I’m looking for categories that wouldn’t even exist without AI — tools that are designed for the AI-side on the spectrum of heterogeneity. It’s a space and position I feel comfortable discussing. I’m also doing this without paywalls!

The first category I’m diving into is AI-enabled product security. As many of you who follow my newsletter may know, I was trained as a software engineer and have always been somewhat fascinated by the role of application and product security. When LLMs came out, I did see that there was a clear disruption in this space.

At the end of that post, I wrote that I don’t know what a good AI-enabled appsec company will look like, but I’m amazed to see this emerging category of companies applying AI to threat modeling and security reviews. It’s clear that there needs to be disruption, and the current set of mature companies might not take us into the next phase. I haven’t formed an opinion on whether this will be the right next-gen, but it’s certainly clear that a set of companies is defining a new security category meant for AI-native companies.

I’m talking about companies like Clearly AI, Clover Security, DevArmor, and Prime Security. These teams are using AI to assist with application security, threat modeling, and security reviews. It’s a fascinating category because its effectiveness depends entirely on the engineering culture and environment it’s dropped into.

I’m still working on the exact naming and boundaries of this category. If you’re at one of these companies, reach out. Send me a demo video. I’m going to go through the marketing materials and sites to develop a practitioner’s perspective on this space.

We need more practitioners helping to figure out these emerging categories. Gartner and the legacy firms are no longer enough. To stay ahead of the trend, we have to build the map as we move, rather than waiting for a research report to tell us where we’ve already been.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

This is going to be a new type of post. I’m starting to hear the low hum of BSides and RSA chatter in the air. Rather than having a single-topic focused newsletter, I’m going to share a stream of consciousness on what’s on my mind as we head into the Moscone Center. These aren’t all well-formed theories, but they are the ideas I plan to talk with others about on the ground.

Recently, I’ve felt like I’m in a bubble. I go to events where I mostly talk with AI-native companies and talk with people who are super excited about AI. I also live in SF, where AI activity is at its peak. However, I’m aware that this isn’t representative of how people and the security community are experiencing AI. As the community gathers, I want to use this time to better get a sense of the whole security landscape and knowledge space.

1. How much do AI security startups actually understand AI?

AI is changing so fast, and knowledge about its usage will be compounding with the amount of use. It’ll be interesting to see the types of customers these AI security startups are designed for. Are they designed for large companies that are just starting to use AI, or are they planning to design for AI startups that are looking to offload some of their security work so that they can be leaner?

As many of you know, I believe that designing for startups that have advanced knowledge is the way to go. I also believe that AI adoption will be much more rapid than cloud, which required significant organizational change. It’s actually quite easy to adopt and start using AI; it’s just hard to use properly as companies struggle with basics like effective prompts and how to integrate it into existing workflows.

The security companies that are focused more on understanding AI and using their knowledge to contextualize security threats will ultimately be the winners. They will be the ones that solve the operational and business problems for the customer rather than propagating fear, which has historically never been a long-term strategy. You have to sell a solution, not fear. Customers want a partner, not a validator. A lot of AI usage is quite nuanced, so any products and teams that can guide companies in navigating the quickly evolving AI landscape will come out ahead.

2. How will security organizations structurally change?

I’ve always thought that applying AI to existing security organizations isn’t a long-term strategy. It’s akin to the invention of the internet and how it was about more than just building a website; it was a strategy to make all companies more tech-focused and global. The same goes for AI. That’s why I believe that AI SOC companies won’t sustain.

I do think organizations will look leaner, and there will be more generalists. The reason is that AI, with the proper context, will fill in the gap for a lot of current expertise around tools and analysis. Organizations will be more effective, but the question is how this evolution will occur. We are seeing a lot of it with application security and how AI labs like Anthropic, with Claude Code Security, are making traditional application security tools irrelevant. It’s also empowering software engineers to do more security.

Like software engineers, I believe security generalists will train the AI where the AI lacks expertise. Security engineers will spend more time training the AI, which will do most of the security work. Smaller organizations require less justification of their existence, and focus will likely shift away from vanity metrics to concentrate on actual threat surfaces.

3. Security organizations are already starting to look different.

Related to the above, it’ll be interesting to see how AI-native companies are approaching security. I know there’s a heavy focus on building with AI, speaking from personal experience.

What’s most interesting is to see how companies that have pivoted to become AI-native, i.e., offering an AI-native product, have transformed their security teams. This is a fascinating case study that will give insight into how a potential evolution will occur. There will be a lot of value creation for products that help this transformation, though I’m not sure I’ll see many of those products at the booths this year. The gap in security effectiveness will likely grow because people tend to have groupthink in security. The AI-native security professionals will share notes and build on knowledge while the others are playing catch-up. It’s tough to have time to learn and grow AI knowledge when you have to handle all the overhead of a larger organization.

4. How will the AI frontier labs show up at RSA?

Do they even show up and have a presence? Google will be an interesting case because they actually have several security products, especially with Mandiant and the acquisition of Wiz. How will their AI side show up? Are they just spectators? It’s definitely new territory for them, especially given their SF presence and increased presence in the security market.

I think the security community wants them to participate more, but a lot of security vendors have a fear of too much participation, as evidenced by the reaction to Claude Code Security.

So far, I haven’t seen any indication of heavy participation from them; it’s mostly the traditional vendors. I know many labs tend to have a presence on more of the builder side, as evidenced by DEFCON participation last year instead of Black Hat. It’s possible they are shying away from RSA and focusing on BSides or having a “parallel track,” given their massive presence in San Francisco. They might realize the real buyers are the builders and not the executives anymore (or rather, the concept of executives is rapidly changing, but that’s for another post).

5. What will the actual theme for RSA be?

It’ll definitely be something related to AI security. Last year, I felt there was more “AI applied to security,” while “security for AI” wasn’t as prominent. There was a focus on AI SOCs and applying AI to operational aspects. However, a lot has changed in the past year. Agents are becoming more prevalent and better. Developments like Openclaw and Claude Code Security have completely changed the threat landscape.

I want to be qualified here and say it’s not fully clear to me that it’s opened up the threat landscape rather than just changed it. Either way, AI is here to stay and quickly evolving with agent usage. Will the main theme be broad, e.g., discussing AI and agents wreaking havoc, or will we have more nuanced themes around specific problems that are reasonable to solve? I worry that the security community is often behind the curve, so we might get distracted by the noise without fully understanding the nuances of AI. One thing is for sure: we need to keep finding ways to learn AI and learn faster as a community. I want to help, and I actually believe AI is a great equalizer for us to defend against AI-enabled attackers.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

I’ve spent the last year writing about why I believe large cybersecurity companies are destined to fail. The narrative is familiar: they will be overtaken by AI-native startups with modern architectures, agent-friendly cores, and GTM motions that actually match the speed of an AI-transformed enterprise. These newcomers are designed for a growing, dynamic market, while the incumbents are fighting for scraps in a stagnating one, a recipe for high GTM costs and dwindling margins.

But failure isn't a foregone conclusion. If you are a legacy giant with thousands of customers and decades of data, do you just wait for the "software apocalypse" to claim you? Not necessarily. But the path to survival isn't just "adding AI features." It requires a fundamental transformation of what the product actually is.

The Palo Alto Networks route: Acquisitions as a strategic wedge

If you want to understand how an “older” company survives a paradigm shift, you have to look at Palo Alto Networks. When the cloud came out, PANW could have easily become a legacy firewall company. Instead, they took a high-risk, high-reward route: aggressive, strategic acquisitions and the enforcement of “platformization.”

Nikesh Arora and his team didn’t just buy companies; they integrated them into a unified vision. By acquiring players like RedLock and Twistlock early on, they built Prisma Cloud. More recently, their 2026 strategic moves, including the $25 billion acquisition of CyberArk to own the identity primitive and their deep integration with Chronosphere for cloud-native observability, show they understand that the next battle isn’t over “tools,” but over the infrastructure of the agentic era.

This strategy is risky. It only works if your company has either substantial cash flow from a legacy business (like their hardware firewalls) or the ability to raise significant debt. Most “second-tier” incumbents don’t have that luxury. Cybersecurity has become so competitive that operating margins have been thinned out. PANW succeeded where others failed because they moved past “stitching” products together. Most incumbents tried “platformization” by simply slapping a single UI over ten different acquired backends. In the AI era, this is a death sentence.

The “middleware” trap: Why legacy consolidation usually fails

An AI agent doesn’t care about a pretty dashboard; it cares about semantic integrity. If an agent queries an “identity” module and a “cloud security” module within the same legacy platform and gets conflicting schemas or mismatched data models, the agent breaks.

The “middleware trap” is the belief that you can hide technical debt behind a single UI. Incumbents must unify their data models at the API level. PANW’s “platformization” worked because they enforced a unified data lake (Cortex Data Lake) early on. To survive 2026, incumbents must stop being a collection of tools and start being a consistent data primitive.

For twenty years, security companies competed on who had the best “single pane of glass.” We built massive, complex dashboards designed to keep a human analyst staring at a screen for eight hours a day.

In the agentic era, the “single pane of glass” is the LLM Context Window.

AI agents are becoming the primary “users” of security software. According to Gartner’s 2026 Trend Report, 40% of enterprise applications will feature AI agents by year-end. These agents don’t want to log into a portal; they want to query a Model Context Protocol (MCP) server. Legacy giants shouldn’t be fighting to be the interface where the human makes a decision. Instead, they should win by becoming the “truth layer,” the high-fidelity context provider that an agent queries to understand the environment.

By exposing their features through MCP servers, as Datadog and Cloudflare did in early 2026, incumbents allow agents to “use” the tool directly. This turns a legacy liability (complexity) into an asset (depth). A feature-rich platform that is MCP-native offers more “levers” for an agent to pull than a lightweight startup.

The death of the “enterprise feature” moat

Historically, legacy companies relied on a “feature-rich” platform as their moat. They built niche features that a startup couldn’t replicate. But AI is destroying this moat. Development cycles have compressed, and startups can now replicate legacy “enterprise features” in months using agentic coding.

Switching costs are also dropping. We are moving toward a world of Forward Deployed Engineers (FDEs) who help integrate custom AI pipelines. According to recent 2026 hiring data, job listings for FDEs have surged by 800%. If an FDE can use an agent to migrate your entire policy set to a new vendor in a weekend, your “stickiness” is gone.

This transition fundamentally changes the business model. Seat-based pricing is a relic. In an agentic world, “per-seat” usage is a tax on productivity.

Legacy companies must move to an infrastructure model, pricing based on API calls, tokens, or autonomous actions. This might actually be favorable. Companies can argue that this ends up being very similar to what they would have paid otherwise in a normal seat-based situation, but it aligns the cost with the business outcome rather than the headcount.

The per-seat charge is an artifact of the 2010s SaaS era that tried to abstract away APIs into nice-looking UIs, but in the meantime, they developed a problematic business model. But, with AI, customers can build their own UIs and interact not in ways the vendor has defined, but in ways that make sense to them. This also makes the pricing make more sense for both sides: pay only for what you use. Anyway, I digress.

This creates a new kind of stickiness: the incumbent becomes the “operating system” of security, while the startup is just a single app. Users can do it themselves without requiring a solutions engineer.

The “service-as-software” model

Beyond MCP servers, there is a third path: leaning into the last mile of security. AI models are incredibly powerful, but in security, “90% accurate” is a failure. There is still a massive gap between an AI suggestion and a production-ready fix.

Legacy companies, with their existing professional services arms and massive historical datasets of customer tickets, are uniquely positioned to provide the human-in-the-loop services that make AI safe for the enterprise. This is the “service-as-software” model. By embedding their experts alongside their AI agents (the FDE model), incumbents can provide a level of “white-glove” security that a pure-software startup cannot match. You aren’t just selling a license; you’re selling the guaranteed outcome.

What happens to the “tool babysitters,” the analysts who mastered the “jank” of legacy UIs? We have to retrain them. I’ve argued before that we need more security generalists.

When the tool is no longer the skill, the professional focus shifts to problem-solving. They design the scenarios, and the agents execute them. The mastery moves from the tool to the discipline. This shift will initially be painful, but it is better for the business long-term. It creates a segment of users who problem-solve and thwart real threats rather than spending time mastering a tool to implement workarounds.

The “software apocalypse” is a filter. Large cybersecurity companies that continue to hide behind “enterprise features” and “seat-based” moats will be automated out of existence.

But those that embrace the Palo Alto Networks route, those that embrace the infrastructure pivot and become the reliable, agent-accessible primitives of the security world, will thrive. They will bridge the gap between their legacy data gravity and the new agentic workflows. They won’t just be the survivors of the AI era; they will be the foundation it’s built on.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

I needed a brief hiatus from the talk about how AI is going to kill all software companies. Well… not really. There’s just been a lot going on, and I needed some time to breathe. Sadly, I was hoping to come up with a topic that didn’t bring up AI or the impending structural changes in our industry. Sadly, AI will likely be a regular topic of this blog, but given the popularity of the [un]prompted conference, I think this is true everywhere, and the reality of where we are today.

I’m frankly not satisfied with most of the writing around this. A lot of the content on LinkedIn lacks the nuance that only exists in longer-form writing. People simplifying this haven’t spent enough time actually being a security professional, navigating the complexities of day-to-day operations where "turnkey" is a lie and "integration" is a four-letter word. This newsletter is meant to provide a practical evaluation of these shifts. Anyway, I digress.

The Catalyst: Claude Code Security

Where to start? Well, it really all started when Anthropic released Claude Code Security about 2 weeks ago. This didn't surprise me. I’ve been saying "AppSec is dead" since 2022. AI just accelerated the timeline.

What was surprising is that Anthropic, a foundational lab, chose to build this directly. For a third-party startup to build a reasoning-based scanner of this caliber, it would require a level of capital investment and computing resources that most simply can’t access.

Anthropic's focus on a specialized coding application makes strategic sense. There is a growing belief (which I share) that LLM infrastructure and raw models will eventually become a commoditized, competitive business. The real value and the "moat" will move to the application layer. But this is likely a longer discussion. However, this is an important assumption that I will carry throughout the post, and I believe this is especially true for security. Most security companies have historically made their money at the application layer, even "infrastructure" players like Cloudflare.

Do I think a lot of current security companies will go away? Yes, if they don’t adapt or create a real moat. In the Cloud/SaaS age, the moat was the sheer effort of development. You needed a small army of engineers to build a product, and a competitor had to raise massive capital to catch up.

But that moat was always thin. Switching costs in security are surprisingly low if the new tool is better at “finding stuff.” Most incumbents survived on GTM spend and FUD (Fear, Uncertainty, and Doubt). With AI, that barrier is gone. It is much easier to build a high-functioning product in a weekend now than it was a year ago in 2020.

Pramod Gosavi recently released a matrix on LinkedIn categorizing the risk levels for different security sectors. He argued that anything "hardware" or network-based (SASE, Endpoint, Firewalls) is safe, while workflows like IGA, ASPM, and SAST are essentially "dead" or at high risk of replacement by LLMs.

and this is the post describing it:

1) Anything "hardware" or sensor or agents or network is safe. This includes SASE, CWPP, Endpoint Agents, vuln/patching agents, firewall, data collection, etc.

2) Controls like Identity directory, Zero-Trust, PAM, CIEM, Data access governance are probably safe as well.

3) I think LLM based malware analysis will enhance antivirus. CSPM is mostly posture management and can be replaced with LLM based workflows. SAST is near dead with code assistants. Next will be SCA if LLMs can patch OSS similar to chainguard, etc. Supply chain/lineage can also be implemented with LLMs

4) Workflows like IGA, ASPM, SOAR, IR can be replaced by LLMs.

5) Most detection and response will be enhanced with LLMs. You need some ML for faster, pointed detection for historic patterns

6) In data security, classification and discovery can be done more elegantly without regex. With AI, DLP is a bigger problem across context and will need AI to solve it. Privacy workflows can be automated with LLMs as well.

7) Email/Human/Collaboration/Training: This will be a big area of attack with LLMs and need an AI first approach.

8) I struggle with exposure/vuln mgmt. LLMs are being used for remediation workflows and knowledge graphs can offer more context but still prioritizing what to fix remains an AGI problem. Pen testing becomes really cheap and should be used more often as defense than compliance.

I think Pramod is directionally correct, but there’s a lot more nuance here. In my opinion, a category is only “at risk” if one of two things happens:

1. The Foundational Labs choose to build it themselves.

2. Security teams choose to build it themselves with LLMs.

The lab risk: can they build everything?

There is always the risk that Anthropic, OpenAI, or Google will decide to eat the entire stack. They have the “brain” (the model) and the data. However, they can’t build every application and do it well. Security is, comparatively, a small market for a company with a $380 billion valuation.

Claude Code Security was a natural extension of a coding assistant. But I find it hard to believe these labs will push into traditional “gritty” security areas like Detection and Response (MDR/SOC) anytime soon. That requires a completely different GTM motion and a level of “boots-on-the-ground” service that labs aren’t built for.

That said, never say never. We used to ask why Google or Meta didn’t just build every startup idea. The answer was “focus.” There’s always some risk here, but I don’t think this is a worthwhile one to harp on.

The real risk: The “build” renaissance

The bigger, more subtle risk to the security industry is that teams will simply stop buying products.

Nothing would make me happier. Security needs to “build” again. We need more security generalists solving problems rather than “tool babysitters” triaging alerts from a dashboard they don’t control. The barrier to entry for building your own custom CSPM, automated remediation agent, or data classifier is now near zero.

If I can prompt Claude to write a custom script that audits my AWS IAM policies and auto-remediates over-privileged accounts, why am I paying an external vendor six figures for a tool that does the same thing (often with more “jank”)?

The companies that are truly safe are the ones that have three things: data, infrastructure, and a network. Think of it like DoorDash. The app itself is easy to replicate with an LLM. But the driver network, the restaurant partnerships, and the customer feedback loop are almost impossible to recreate overnight.

In security, this is the “Cloudflare/Crowdstrike/Zscaler” moat. They have the network effects. They see threats across millions of endpoints and billions of packets in real-time. An LLM might be able to analyze a threat, but it doesn’t have the “sensor” to see it first. I’d argue that detection and response (MDR) and email security are also safer than people think because they rely on this cross-customer network effect to identify emerging patterns.

People often push back on the “build” renaissance by citing technical debt. They argue that if every security team builds its own tools, we’ll end up with a fragmented mess of unmaintained code.

I think this is an outdated way of looking at debt. In the past, “homegrown” tools died when the person who wrote them left the company. But with LLMs, the cost of understanding, maintaining, and refactoring legacy code has plummeted. We might be entering an era where technical debt is actually okay because the “interest rate” on fixing it is near zero. If an LLM can explain a 5-year-old script to a new hire in seconds, is it really “debt” anymore? However, the effects of this are still yet to be seen.

The New Talent War

We are seeing a massive shift. Newcomers will inevitably disrupt IDPs (Identity Providers), data security, and compliance. The winners will be the ones who leverage AI-native operations to bridge the gap between “talent” and “scale.”

This is why there is such a fierce talent war right now. The gap between companies that can leverage AI properly and those that can’t is widening. We are going to see a new breed of companies, e.g., AI-enabled access management, LLM-driven data protection, that don’t just “have AI” as a feature, but are built on AI as the engine.

It feels daunting. Security teams are being forced to deal with entirely new threat vectors (agentic exfiltration, prompt injection) while simultaneously being pressured to become more efficient by adopting the very same technology.

Claude Code Security is a warning shot. It’s not the end of cybersecurity, but it is the end of “security as a dashboard.” The future belongs to the builders, the ones who can leverage the models to build their own moats, rather than just buying someone else’s wrapper.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

I’ve spent the last few weeks writing about the “Efficiency Reckoning,” i.e., the reality that security teams can no longer scale by simply adding more people. As AI-driven development expands the threat surface at machine speed, we are reaching a breaking point. Human teams cannot write enough rules to stay ahead of nondeterministic threats.

This brings us back to a category that was once the “cool kid” of the security conference circuit: deception.

I haven’t thought about deception for a while, since 2010s, until I had coffee with Andy Smith, founder of Tracebit, which is making a cool canary product that I’m eager to try out. Back in the 2010s, startups like Illusive Networks, Attivo Networks, and TrapX dominated the scene. They promised high-fidelity alerts that would end the era of "guessing." But while the promise was high, the adoption hit a wall of operational friction. Research into the first generation of deception reveals "three deadly sins": scalability, maintenance, and integration friction. In short, it was an administrative headache. Keeping decoys "believable" in a changing environment was a full-time engineering task that most understaffed security teams couldn't afford.

But as we look toward 2026, we are seeing a "Strategic Rebirth" of deception. It’s moving from a niche "trap" to a core infrastructure primitive.

Redefining the “incident”

We’ve gotten too obsessed with the idea of “zero incidents.”

In general, the term “incident” is far too broad. A “zero incident” goal is actually counterproductive; it encourages teams to hide small security events and prevents the organization from building resilience. Much like in modern infrastructure or Site Reliability Engineering (SRE), we need to focus on learning from events rather than just suppressing them. I’ve written about this in the past.

Most major breaches are not sudden explosions; they are an escalation of a small, undetected “lurking” phase. Attackers, or malicious AI agents, will snoop around, exploring the environment to figure out what security systems are in place without actually triggering a high-level alarm. They are looking for the boundaries.

If your only strategy is prevention, you are blind to this lurking phase. But if you have a deceptive infrastructure, this snooping becomes your best source of intelligence. It is okay to have an “incident” if the blast radius is small and the detection is immediate. In fact, catching an attacker in a decoy provides better training data for your defense than a blocked connection ever could.

The deterrence model: law enforcement for the AI era

Historically, we built security like a high-security prison: fixed gates and high walls. But AI agents navigate “latent space” — they don’t use gates. In this nondeterministic world, being “reactive” is actually the only way to move fast.

Think of it like modern law enforcement. The police don’t stand at every corner to prevent every crime; they create a system of deterrence. They make the likelihood of being caught so high that the “crime” isn’t worthwhile. Deception is the deterrent that makes exploitation too expensive and too noisy for the attacker.

We need to move from a “Mean Time to Detect” (MTTD) metric to a “Mean Time to Deterrence.” The goal isn’t just to see the attacker; it’s to make their mission impossible by polluting their reconnaissance with fake data.

Why AI SOCs are a faster horse (and why they fail)

I’ve talked in the past about why “AI SOCs” are not the future. The current trend is fundamentally a “Copilot for a broken process.” These companies are taking the legacy SOC workflow—collecting millions of logs, generating thousands of alerts, and using an LLM to help a human triage them, and simply trying to make it 20% faster.

But we don’t need a faster horse; we need a fundamental change in how “work” is done. The AI SOC model fails because of three primary flaws:

1. Garbage In, Garbage Out: They rely on traditional logs (SIEM, EDR) that are inherently noisy. Feeding noise into an LLM just results in “hallucinated triage.”

2. The Multiplier Effect: Using AI to write more rules just generates more alerts. You haven’t fixed the “tool babysitter” problem; you’ve just given the babysitter more children to watch.

3. Lack of Intent: Traditional detection looks for patterns. Deception looks for intent.

Interaction with a decoy is a high-fidelity signal that bypasses the need for the complex, “janky” triage layers that AI SOCs are trying to automate.

The proper evolution: The Detection-as-Code engine

Instead of an AI SOC, the proper evolution is a deception-led detection engine. This moves the “work” from monitoring to Engineering.

In the legacy world, tools like Google Chronicle have been criticized for their steep learning curves and proprietary languages like YARA-L. If it’s “painful” to write a rule, a team isn’t going to have the bandwidth to manage a complex deception web. AI finally eliminates this friction by automating the tuning loop

• Dynamic Decoy Generation: LLMs can now generate “Honey-Logic,” e.g., API keys, database columns, and file systems, directly into your CI/CD pipeline.

• Autonomous Iteration: When an attacker touches a lure, the system doesn’t just alert; it iterates. It automatically writes and tests a new detection rule to block that specific behavior across the production fleet.

• The “Security PM” Role: The security engineer moves from being a “tool babysitter” to a product manager for risk. They design the threat scenarios and audit the AI’s rule-writing to ensure coverage.

This is the “managed detection” that could finally beat incumbents like Expel. It’s not about having better analysts; it’s about having a better deterrence infrastructure.

This is particularly relevant for players like Google and Wiz. By integrating deception with frontline intelligence from Mandiant, they can use actual APT tactics to automate the creation of deceptive scenarios. However, to truly win, Google still needs to bridge the “prominence gap” of its SIEM to make it the foundational infrastructure for this automated deterrence.

The SRE parallel: Redefining risk in the AI era

The biggest hurdle to this shift isn’t the technology. It’s the philosophy. We have to accept that events and incidents will happen.

This is very similar to how we think about infrastructure incidents in Site Reliability Engineering (SRE). We don’t aim for zero downtime; we aim for an “error budget” and a culture of blameless post-mortems. In the AI era, your deception budget is your error budget. Every time a decoy is hit, you’ve bought yourself the intelligence needed to secure the rest of your infrastructure.

The job of the security team that understands AI is to redefine how we think about risk. If you allow small “lurking” events to happen in a controlled sandbox, your AI models can learn the attacker’s intent and strengthen production guardrails.

In this vision of an automated loop, where does the human sit? They are no longer triaging. They are designing. The human decides the “capture” logic based on the risk the company wants to tolerate. Is it an automated account lockout? Or a deceptive “rabbit hole” that keeps the attacker busy while the team investigates?

This is where the human moves from “operations” to “strategy,” designing the nightmare scenarios that the AI uses to harden the system.

A call to builders

The “Software Apocalypse” is a reckoning for point products, but it is an opportunity for those who understand developer-first security.

If you are a security engineer, stop buying “turnkey” tools that you have to spend months learning. Start building your own deterrents using available LLMs. The goal is a parallel and thriving security business, similar to what Microsoft did after it focused on the cloud, but optimized for the builder-centric, agentic world.

Deception isn’t a gimmick anymore; it’s the only way we scale. We are moving toward a world where the highest ROI security move isn’t building a better wall, but building a better mirror.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

I’ve spent the last few weeks writing about the “Efficiency Reckoning” and why the next generation of security companies might fail. The common thread is that point products are being cannibalized by platforms, and the traditional “per-seat” revenue model is collapsing under the weight of AI-driven headcount reduction.

But as we see this "Software Apocalypse" unfold, an interesting consolidation opportunity is emerging. While many investors are chasing "sexy" AI-security startups, there is a massive, defensible business to be built by gathering the "boring" but essential IT security tools, such as SSO, EDR, and email security, into a single infrastructure platform.

I’ve been tracking the performance of the most recent security IPOs, like Netskope, which debuted in late 2025. While it saw a brief 18% pop, the broader narrative is clear: it’s not a great time to be a traditional security company. To truly succeed in this market, every tool now requires a fundamental AI angle.

In general, SaaS has had a rough showing in the public market. Even previously hot companies like Figma, which rolled out an aggressive AI suite, including Figma Make and Synapse analytics at Config 2025, have seen their shares struggle, trading at a steep premium while the broader sector remains volatile.

It seems that companies enabling AI infrastructure are doing better. But how do you do this as a security company? This gave me the thought that there are a lot of underrated or "subtle" security companies like Cloudflare, which are core to security, their identity isn’t that of a traditional security company.

Microsoft is the other key example. They have a robust and thriving security business, and they’ve done an incredible job of bundling it into the Office 365 ecosystem. It’s honestly quite impressive how they have adapted to the cloud.

This got me thinking: which company can secretly become a more relevant security player in the next few years without anyone realizing it? The title gave it away, but I believe it’s Google. They are the dark horse that could quietly build the foundational security infrastructure for the AI era.

An alternative to Microsoft

Microsoft’s security tools are powerful and well-integrated, but they are often hard to use and specific to companies with employees who have spent their lives in Windows. Much like Salesforce, their usage is predicated on specialized experience rather than intuition. They are built for the legacy IT administrator who wants a turnkey solution, even if it’s proprietary and non-intuitive. There’s still a market for this, and it’s an important one. It was what they had to do to adapt to the cloud and changing enterprise landscape.

But today’s security engineers are builders. They want to use a tool to solve a problem and then move on. They don’t want to lose track of the mission while fighting a complex UI or navigating a “walled garden.” There is a deep, growing desire for a neutral alternative that focuses on problem-solving rather than tool administration.

Today’s AI engineers and security generalists don’t want to “stitch together” closed products; they want to customize on top of a stable infrastructure. Google, by virtue of its software-first heritage, is perfectly positioned to provide this. It also helps that most of the AI engineers grew up using Google products rather than Hotmail (yes!) and Windows.

Efficiency reckoning: scaling without people

We’ve reached a point where security can no longer justify scaling with headcount. As threat surfaces expand exponentially due to AI-driven development, the traditional 1:1 ratio of “more risk = more people” has broken. Security must now scale like an AI company: with code, agents, and highly leveraged generalists.

This is the end of the “tool babysitter.” In the AI era, the value is in problem-solving intuition and the ability to orchestrate agents to remediate risk at machine speed. Data from the 2025 IBM Cost of a Data Breach Report shows that organizations using AI and automation extensively shortened their breach lifecycles by 80 days and lowered costs by $1.9 million compared to those who didn't. To succeed, security teams will need to hire more engineers and move away from manual “click-ops.”

Google’s advantage

This is where Google has a massive advantage: vertical integration. Like Microsoft, Google owns the cloud (GCP), the productivity suite (Workspace), and a world-class AI model (Gemini). They don’t have to worry about cloud economics in the same way a point-product startup does. They can afford to provide the “Security Plumbing” as a baseline infrastructure utility.

Think of Google’s security strategy like Vanta for the enterprise. Vanta became a one-stop shop for “good enough” tools to get you what you need without a dedicated compliance person. Google can do this for IT security. By providing a consolidated stack of “boring” tools (SSO, EDR, Email), they allow a lean, understaffed team to focus on high-level risks like AppSec and CloudSec.

The Wiz acquisition, now fully approved, is a declaration that Google is serious about enterprise cloud security.

• Wiz as the “Security Graph”: Wiz provides the baseline visibility, the “Security Graph”, that developers can actually build on top of. If Google allows Wiz to operate as a neutral infrastructure layer, it becomes the foundation for the 80% of new companies that already start on Google Workspace.

• The Gemini Catalyst: While Microsoft has the enterprise footprint, Google has the Gemini model. For a builder-engineer, Gemini is a far more intuitive and flexible catalyst for customizing workflows and automating remediation than the more rigid implementations found elsewhere.

I’m not sure if they thought this when they bought Wiz, especially given how behind Gemini was compared to ChatGPT at the time. Here’s my article assessing the deal.

I believe this is a mixture of Theory 1 and Theory 3. However, it didn’t account for how Gemini could be a boost here.

Transitioning to an infrastructure business

Google’s historical failure in the enterprise was a “focus issue.” They weren’t built for enterprise DNA, but AI and the usage-based pricing shift give them a second chance.

• Usage-Based Infrastructure: Google can lead the shift from “per-seat” to infrastructure-based pricing, aligning with their cloud heritage. This removes the “per-head” efficiency tax and makes security a utility rather than a discretionary SaaS expense.

• Acquiring Cachet: To complete the roll-up, Google should acquire a few more builder-focused startups with real cachet. This gives the builder persona everything they need in one intuitive, API-first platform. Some ideas are Material Security for email security, SentinelOne for EDR (this was something Wiz was already exploring), and Okta or Teleport for identity. Google currently lacks strong capabilities and technologies in this area.

Conclusion

The “Software Apocalypse” will consume the point products that can’t justify their headcount. But it will also create a new giant: a platform that understands that the next generation of security leaders isn’t administrators — they are engineers.

Google secretly has a chance to be the most interesting security company of the decade. By catering to the builders and providing a vertically integrated, neutral infrastructure, they will build a parallel and thriving security business similar to what Microsoft did after it focused on the cloud, except they are doing it in the AI era.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

As many of my subscribers and fellow security professionals know, I’m a selective buyer of tools. In fact, I’ve written in the past that security has too many tools, and the increased funding to create more tools is actually doing the industry a disservice.

However, don’t get me wrong. Having more tools has made security much easier, but perhaps too easy. One of my major criticisms is that security believes tools are the ultimate solution to their problems, when they are really just facilitators. In the past, I’ve discussed how I think about build vs. buy, and how I don’t actually plan to keep most of the tools I buy. I’ve also been a huge advocate of security teams building more of their own tools, and I believe that AI is the catalyst that finally makes this possible.

The structural shift

This isn’t to say all security companies are doomed. Instead, innovation is changing the type of useful security tools. People are underestimating how much the structure of work and organizations will change under AI, and it’s important to address this first to provide context on how this affects the tools that provide value.

First, security organizations must accept that headcount will be limited going forward. We are seeing startups doing much more with fewer people, and larger companies cutting staff in favor of increased AI usage. Companies are looking to cut the “zero-interest rate” bloat of the 2010s. Successful organizations will be those that reallocate resources from headcount to AI compute and agentic workflows. Whether that’s the most efficient use of money is still yet to be seen. I think the the ideal state likely lies in moderation.

Second, simply adding AI into existing workflows, i.e., the “Copilot” approach, won’t be effective. The way security does “work” has to change. I am bearish on “AI SOC” companies that simply apply AI to the current broken assembly line. When machines were introduced to car manufacturing, it didn’t just speed up manual labor; it led to the invention of the assembly line, which fundamentally changed the role of the worker.

In security, this means we will see a rise in generalists who can solve high-level problems and integrate AI guardrails, while specialists will transition into training AI models or contract roles. Security will spend less time on manual operations and “paperwork” and more time on engineering fixed workflows with built-in security primitives. To succeed and move fast, security will need to hire more engineers rather than just tool administrators.

The “seat apocalypse”: usage-based vs. per-user

The traditional B2B software model is built on the “seat,” charging per user, per month. But AI has broken this correlation. We are entering what some call the “Seat Apocalypse.” Charging per seat punishes a customer for becoming efficient with AI.

I believe this will likely kill per-seat models in favor of usage-based or infrastructure-based pricing. For the vendor, this is actually better. It reduces sales overhead because it eliminates the complicated margin calculations that the per-seat model created. It aligns the cost of the tool with the actual compute or risk-mitigation value it provides. While some vendors offer “insurance-like” warranties, I’m skeptical; for now, these feel more like marketing ploys than fundamental shifts in risk transfer.

Why the old calculus is dead: From click-ops to code

Historically, the build vs. buy argument was about what was “strategic.” Since engineering resources were limited, building security tools was a non-starter. This led to tool sprawl and shelfware, because “buying” was perceived as cheaper than hiring developers.

But AI has demolished this barrier. AI agents and assistants have introduced a 5-10x multiplier in engineering output. Tasks that used to be buried in “click-ops” because they were too slow to code are now being automated at machine speed.

Take infrastructure deployment. It used to take forever to write Terraform, so people resorted to “click-ops” in the console—a practice that is insecure and impossible to audit at scale. Today, it’s easy to do this with code and AI assistants, although we still require human review on the most critical parts to prevent hallucinations. This 10x multiplier means security engineers can build custom internal tools without a backlogged engineering team.

Characteristics of a “buy” in 2026

So, what is actually worth buying? I believe security tools must now meet three specific characteristics to justify their place in a modern budget:

1. Autonomous Operation & Zero Maintenance A tool must run without human management. It should be “set and forget,” learning from your environment so it requires less input over time. If a tool requires a dedicated “administrator” or specialized certifications to operate, it has failed the efficiency test.

2. Outsourced Specialized Talent The most attractive tools provide a “slice of talent” that isn’t strategic for you to hire full-time. For example, Formal provides a lightweight proxy platform that is a stable abstraction for infrastructure that regularly changes, something most companies shouldn’t build and manage themselves. It makes sense to treat these specialized teams as an outsourced function. I’ve discussed how AI might lead to these types of structural and organizational changes in the past.

3. Customizability and Agent-Readiness The modern security tool must have robust APIs that allow it to be easily automated by AI agents or prompts. A tool that is hard to customize will be replaced by a custom agent that builds a better interface on top of raw data.

In the short term, AI will likely widen the security poverty line. There will be a massive gap between the teams that understand how to orchestrate AI and the ones that don’t. Teams that can use agents to deploy infrastructure as code will move 10x faster than those still clicking through consoles.

However, as AI becomes more democratized, leading to easier access and creation of tools, this gap might eventually shrink. Security is moving into a new era where we aren’t just buying applications; we are buying specialized building blocks that allow our lean, engineering-focused teams to ship secure code at machine speed.

Conclusion: The return to building

The ultimate conclusion of this pivot is that security needs to build again. AI has raised the bar needed for a team to buy a security product. If a tool doesn’t provide substantial value on top of what an engineer can build with Claude or Codex, it won’t survive the next budget cycle.

Security is no longer a separate silo; it is being folded into the broader engineering organization. This means security leaders must justify their spend based on velocity and direct value. It’s a great time to be a problem solver who knows how to orchestrate talent rather than just click through a dashboard.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

I wrote a few years ago about how I buy tools and don’t necessarily plan to keep them. In the startup world, strict prioritization is the only way to survive. The smartest move is often to buy rather than build, especially if the tool isn't core to your product. By outsourcing specialized challenges, like infrastructure access, to established tools, you gain immediate development velocity. The plan isn't always to keep these tools forever, but to use them as levers to reach the next stage of growth without burning engineering cycles on maintenance.

However, the bar for buying security tools has changed since the advancement of AI. I’ve become pickier. With AI, it’s now trivial to build simple internal tools, causing many niche categories, particularly in application security and basic scripting, to disappear. For me to consider a new tool today, it has to provide substantial, non-commodity value.

But there is an even more underrated factor in the “stay vs. switch” debate: the massive, hidden cost of switching.

The Switching Cost Trap

Security leaders often fall into the trap of seeking “the best.” When a new leader takes over, they often want to swap out the existing stack. The official excuse is usually that the current product fails to mitigate specific risks. But the real reason is often personal: they want a tool they are familiar with or want to “make their mark.”

In today’s leaner environment, this is a colossal waste of time. Switching security tools isn’t just about a new license fee; it’s about the operational friction.

• Administrative Effort: New procurement cycles, legal reviews, and contract negotiations.

• Learning Curve: Every new tool has its own logic, interface, and query language.

• Integration Debt: Re-wiring the new tool into your SIEM, SOAR, or ticketing workflows.

Data from 2025 shows that organizations with fragmented, “best-of-breed” stacks manage an overwhelming average of 83 security tools from nearly 30 different vendors. This complexity isn’t a badge of honor; it’s a tax. Organizations that move toward consolidated platforms can identify and mitigate security incidents 74 to 84 days faster than those struggling with fragmented environments.

Why Mediocrity is a Viable Strategy

I know many security professionals are unwilling to admit it, but it’s actually okay to use a mediocre tool as long as it gets the job done. I’ve argued before that security has too many tools and has become a community of tool administrators rather than problem solvers.

If your team is already used to a tool, and it covers the basic requirements for a low-to-medium risk area, the incremental benefit of switching to the “best” product is often outweighed by the risk of the transition. The argument that “the best tool would have prevented the breach” is flawed. You don’t know the counterfactual. In practice, security system complexity is actually a top cost amplifier.

For a medium risk, it is often better for the business to keep a cheaper, mediocre tool that everyone knows how to use than to spend millions in resources to move to a slightly better product that requires six months of tuning.

The Rise of “Good Enough” Platforms

We are seeing this play out in real-time with infrastructure platforms like Datadog. Datadog has been expanding into paging (replacing PagerDuty), incident response (replacing incident.io), and feature flags (replacing LaunchDarkly).

Are these Datadog offerings as feature-rich as the standalone winners? Probably not. They are “mediocre” by comparison. But they win because they offer simplicity and context. In 2025, organizations using consolidated platforms are generating four times greater ROI (101%) compared to those with fragmented stacks (28%). This ROI is more obvious because the goal of engineering and DevOps is efficiency.

Where Mediocrity Works (and Where it Doesn’t)

You have to be strategic about where you accept mediocrity.

• Compliance: This is a race to the bottom. Most companies want to spend the minimum amount required to pass an audit. A tool like Vanta doesn’t need to be the “best” security tool; it just needs to be the best compliance platform that lands in the door and stays there by being “just good enough” to solve the pain point.

• AppSec & CSPM: Many application-level categories like CSPM have become commoditized. If a tool doesn’t provide deep analytics or value beyond a nice interface and some scripts, it’s a prime candidate for “mediocrity.” It’s okay to have a product that does the basics unless your risk profile specifically demands a mature, high-end program.

• Managed Services: If you are using a managed service (MDR/MSSP), they can often help deal with the unnecessary complexity caused by a mediocre tool. The service provider handles the headache, making the “mediocrity” of the underlying software much more acceptable.

However, you should never cheap out on credentials. With compromised credentials still being a top three attack vector and the average cost of a U.S. data breach surging to a record $10.22 million in 2025, your identity and access management (IAM) must be top-tier.

A Strategy for Startups: The Wedge of Mediocrity

For security startups, “mediocrity” can actually be a competitive advantage. If you can provide a simple, lightweight product that solves a specific compliance gap, you can land in an organization and become part of the furniture.

The goal for many should not be to build the most technically advanced product in the world, but to build one that is not bad enough to switch. If you can land, provide immediate value, and integrate easily, the high switching cost of the enterprise becomes your greatest defense.

Final Thoughts

Security leaders set the wrong expectations when they promise to prevent every breach by buying the “best” tool. This creates a business mismatch. In reality, we should be managing risk by acknowledging that some areas only require “good enough” solutions.

AI makes it easier than ever to remove mediocre tools because it reduces the implementation effort required to replace them with simple, custom scripts or platform features. But until you have a reason to move, don’t let the pursuit of “the best” distract you from actually solving problems.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

I’ve written in the past about how many cybersecurity companies like Wiz, Cloudflare, Zscaler, and Palo Alto Networks might fail. It’s been a while since I wrote one of these, and people have been telling me to write a refreshed version, given the advancements in AI and my new opinions on its role in the industry.

For those who don’t know, I’m extremely bullish on AI. I’ve seen it have a tremendous impact if used correctly, i.e., a multiplying factor of 5-10x. I know many security people are skeptical, but I believe this shift is similar to the cloud transition and will likely lead to the downfall of many legacy security companies and teams. More time should be spent figuring out how to use AI effectively rather than squeezing out marginal gains through bureaucracy.

The stagnation trap and the panic of the incumbents

The recent wave of acquisitions, e.g., Google buying Wiz, Cisco buying Axonius, feels like an attempt by cash-rich companies to stay relevant. Unfortunately, I don’t believe these are the “right” acquisitions; they are often expansions into shrinking or stagnant markets like legacy OT security. While I appreciate Palo Alto Networks’ focus on acquiring AI talent with the acquisitions of Protect AI and Chronosphere, there is a fundamental supply issue: AI security startups are too early, “AI for security” startups are still too rare, and AI talent in security is quite limited. However, security companies, especially the ones primarily focused on IT-driven organizations, are desperate to stay relevant in the AI era that has been dominated by developers and machine learning experts.

The real reason security companies are exiting is that the market is too competitive and over-focused on GTM (Go-To-Market) rather than innovation. This is a tough market to be in because it requires substantial capital, especially in a market where capital use has become more efficient with AI companies. This is also a signal of companies being concerned about stagnation.

How do they fail? They fail to adapt to the new technological reality. They focus on existing markets that will slowly shrink, while new players go after the fast-growing AI-first companies. These AI-native organizations will no longer want to use "legacy" security products, similar to how CrowdStrike replaced Symantec and Zscaler replaced Cisco.

The shift from gatekeepers to builders

The most profound shift AI brings to security is the democratization of code. Traditionally, security didn’t write code; we identified risks and threw them over the fence for engineering to fix. This “gatekeeper” model is dying. With AI, security can now handle its own fixes and build custom internal tools without constant engineering support.

Before, “ownership” of code was a major barrier. Security was afraid to touch production code because they lacked context. Now, AI makes it easy to ramp up on unfamiliar codebases, generate a secure patch, and maintain it. This 10x multiplier in output means that the traditional “department of fifty” is being replaced by lean, highly technical teams. When a security team can build its own automated remediation agents, the value of a bloated, per-seat license for a legacy security product collapses. If an AI agent doesn’t need a dashboard or a seat license, how do these companies maintain their multiples?

The rise of the AI-native challenger

While legacy vendors try to bolt AI onto static architectures, a “new guard” is emerging. Companies like Formal and DryRun Security are winning because they aren’t just “using AI” — they are AI-native.

(Disclaimer: I’m currently piloting Formal and have known the team for a while. I haven’t tried out DryRun Security. I’m sure there are many more, but I’m just using these two as an example because I’m somewhat more familiar with the product and the way they sell. If you also fall into this category, feel free to reach out!)

Formal provides a lightweight, highly customizable abstraction for infrastructure that is constantly changing. In the “vibe coding” era, where developers ship at machine speed, Formal offers a stable baseline that moves as fast as the code. Similarly, DryRun Security is building SAST (Static Application Security Testing) that actually works in an agentic world. They aren’t just scanning code; they are providing substantial value that a security team couldn’t just build themselves using a raw LLM.

These AI platforms have raised the bar. To sell a product in 2026, you must provide more utility than what a technical leader can prompt Claude Code or Codex to build in an afternoon.

The death of the segmented budget

One of the most significant structural changes is the death of the protected “security budget.” Security is no longer a separate silo; it is being folded into the broader engineering organization. This means security leaders must justify their spend like any other engineering manager based on output, velocity, and direct value.

In this world, the budget is a mix of compute for AI tools and a few highly skilled engineers. Segmented budgets allowed CISOs to buy “random tools” that didn’t provide direct value but checked a compliance box. That era is over. If a tool can be easily built in-house or doesn’t provide a clear 10x improvement over the “free” tools provided by AI platforms, it won’t get funded. The CISO will likely become a division of engineering where risk management is integrated into the stack, like infrastructure or DevOps. Engineering-focused and technical security hires will be highly sought after.

The competitive unbundling

We saw this with the cloud: Wiz and Cloudflare were successful because they were easier to deploy in cloud environments than their legacy counterparts. The same will happen with AI. New players will enter and not engage in the existing, competitive markets. Instead, they will go after the fast-growing AI-native market.

These companies will become irrelevant unless they can drastically change themselves to adapt to faster development cycles with AI agents writing most of the code. Organizations will change structurally, and companies will do more with fewer people. Enforcing policies will be easier with agents and AI, but the surface area for those policies will be massive. If a security product requires a long sales cycle or manual configuration that can’t be handled by an API, the new AI-native companies simply won’t work with them.

As a result, these companies will miss out on the new and fast-growing market and be forced to compete in stagnant markets, meeting the fate of the “legacy” security companies, such as Symantec, Proofpoint, and Palo Alto Networks’ firewall business, primarily used for their cash flow but with no additional investment into the product or longevity of the business.

Closing thoughts

I don’t know exactly how this will look in its final state. AI usage is evolving faster than our ability to categorize it. However, the theme is clear: the “blank check” for security is bouncing.

Adrian Ludwig recently described the future CISO as a “Chief Electrician,”
someone who ensures the infrastructure is safe so that the rest of the world can just work. But as I’ve argued, an electrician only fixes wiring; a technical security leader writes the code that makes the wiring self-healing.

The companies that fail will be the ones that stayed focused on being “tool babysitters.” They will hold on to their legacy market share until they realize that the market itself has moved under them.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

I’m trying something a little different this week. Instead of my usual deep dive into a single topic, I’m launching a new format where I sit down with a notable security professional to pick their brain on the future of our industry. To kick things off, I recently had the chance to sit down with Adrian Ludwig, the CISO at Tools for Humanity.

If you’ve followed his career, from the early days of the DoD to leading Android security at Google and serving as the Chief Trust Officer at Atlassian, you know he doesn’t exactly follow the traditional “compliance-first” CISO playbook.

A Note on our Conversation: The following insights are based on a recent Q&A session I held with Adrian. While they capture the core of his philosophy and our shared (and differing) opinions, these are my own paraphrased notes from our discussion rather than direct verbatim quotes.

The security chameleon: adapting across eras

One of the most impressive aspects of Adrian’s career is his ability to adapt to vastly different security contexts. He’s seen the industry through every major transition over the last 30 years. At Adobe, he was at the front lines when the primary goal was just keeping the internet from crashing due to web vulnerabilities. At Google, he led the security for Android at a time when mobile devices were just beginning to touch billions of lives. Then at Atlassian, he steered the ship as massive organizations finally embraced the cloud, a move many thought would be a security nightmare, but that Adrian correctly saw as an opportunity to build on more secure foundations.

His current role at Tools for Humanity (TFH) is perhaps his most unique challenge yet. TFH is the core contributor to World Network (formerly Worldcoin), which uses Orbs (advanced cameras) to provide a privacy-preserving proof of human. Adrian’s move from established giants to a high-velocity, identity-focused startup shows his deep understanding that security is not a one-size-fits-all function. Whether he’s securing the operating system on billions of phones or building a global, decentralized identity layer, his core philosophy remains: security must be an engineered primitive that enables, rather than restricts, the world.

Insights from our conversation about AI, Identity, and the evolution of the CISO

On career lessons and the shift in scale

Adrian reflected on how each of his major roles prepared him for the next by shifting the definition of scale. At Adobe, scale meant preventing a single buffer overflow from crashing the web. At Google, it shifted to securing an ecosystem for billions of Android users. At Atlassian, it became about proving that the cloud was actually a more secure primitive than on-prem. Now, at TFH, he’s tackling identity as a security problem, arguing that privacy and security are intrinsically linked because if you can’t verify a human without leaking their data, the system eventually becomes untrustworthy.

The win for platform-driven security

He sees a clear win in the industry’s move toward platform-driven security. He believes that the cloud is fundamentally more secure than legacy data centers and that AI will further accelerate this by making rule implementation easier. However, he remains concerned about the human gap. As fundamental protocols like FIDO passkeys begin to fix phishing, he believes attackers will simply pivot to refactoring how decisions are presented so that humans are manipulated into making bad choices regardless of the protocol.

The AI structural change: accelerant or transformation?

While we align on the move toward more engineering-forward security, I believe Adrian’s optimism regarding AI and platforms might be missing the structural magnitude of the coming shift. While he sees AI as an accelerant for rules and repeatability, I view it as a fundamental change to the threat landscape. We aren’t just solving old problems faster; we are dealing with systems that are non-deterministic, hallucinatory, and prone to behavioral drift. In my view, this is more than just more of the same — it is a second major test that the industry is already showing signs of failing.

The "Chief Electrician" and the future of the CISO

Adrian’s hottest take is that the role of the CISO is destined to go away. He compares the future of the role to that of a Chief Electrician. We will always rely on electricity, but it will eventually be provided so reliably by the platforms we use that we won’t need a dedicated executive just to keep the lights on.

I am less certain that platforms will actually become more secure over time. In the SaaS era, platform security has often made security more decentralized, pushing critical risk decisions onto the providers themselves. We are effectively trusting these vendors to take the right risks on our behalf, and it’s a gamble. While current AI platforms are taking security seriously today, the pressure to move fast may eventually cause secure coding practices to be deprioritized in favor of features.

Where Adrian and I do find common ground is on the organizational future of the CISO. We agree that the role will likely become a division of engineering or AI engineering. In this model, the CISO is no longer a separate gatekeeper but an integrated function where risk is concentrated and managed similarly to how Infrastructure or DevOps is handled today. This is the only way to move at the speed of the business while actually reducing risk rather than just auditing it.

Finally, Adrian believes the industry is far too hard on users. While many security pros see users as dumb, he argues that a compromise is usually a failure of design. If a user makes a mistake that leads to a breach, it’s a designer’s fault the first time and the security team’s fault the second time they allow that design flaw to exist.

Quick Hit Questions

• Preferred coding language: Rust

• Favorite security tool: Netcat

• Least favorite security tool: Hash algorithms

• AI stack: ChatGPT for chatbot, Cursor for coding

• Coke or Pepsi: Coke

• Tea or Coffee: Coffee

Closing Thoughts

Adrian Ludwig’s career is a testament to the fact that security is an engineering discipline first. His ability to adapt from the DoD to Google, Atlassian, and now the decentralized identity world shows that a successful leader must be as agile as the technology they protect.

Adrian is right that security should be invisible. But until we move away from the “tool babysitter” culture, most CISOs will stay stuck as “chief firefighters” rather than electricians. Tools for Humanity is showing what’s possible when you build with privacy and security as primitives, but for the rest of the industry, the “Efficiency Reckoning” is still just beginning.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

I’m back from a brief holiday break, and I’m continuing my yearly tradition of predicting where this chaotic industry is headed. If you want to see how my past outlooks fared, you can check out my 2025 predictions.

Near the end of last year, I also published a “wish list” for the community. While I admitted then that many of those wishes, like the total elimination of security awareness training, weren't necessarily "realistic," the predictions below are grounded in the cold reality of market consolidation, shrinking budgets, and the undeniable force of AI.

The death of the "tool babysitter"

The security industry has long complained about a “talent shortage,” but as I’ve argued before, the talent has simply been misplaced. Most security engineers today aren’t solving security problems; they are acting as “tool babysitters” for complex platforms. We created this mess by designing increasingly convoluted “enterprise” tools that require specialized certifications just to navigate their basic interfaces. Whether it’s Jamf, Zscaler, or Snyk, these systems are often so difficult to use that a simple task like deploying a package to a fleet of laptops requires a dedicated operator.

In 2026, the value of being a "tool expert" will plummet because the knowledge gap is finally closing. With the integration of LLMs directly into these platforms, you no longer need to scroll through pages of documentation to find an obscure setting; you simply prompt the system for the outcome you want. This turns the tool back into what it should have been all along: an appliance. Companies will realize they don't need to hire a full-time specialist just to operate it. It’s like saying you bought a microwave, only to need someone to operate it. Instead, they will seek out security generalists who use these tools as a means to an end rather than a primary identity.

Security budgets shrink to fund the AI race

The “blank check” era for security is officially over. For years, security enjoyed an ever-expanding budget because executives were terrified of becoming the next breach headline, but the ROI on these massive spends has never been clear. In 2026, tech budgets have become zero-sum. To fund the massive infrastructure required for AI experimentation, companies are actively cannibalizing their security spend. Security teams can no longer hide behind the excuse that “AI is insecure” to slow down adoption or demand more money.

With smaller budgets, security must focus on “must-haves” over theoretical risks. I expect to see a massive migration away from expensive, seat-based licenses for dedicated security tools. Teams are realizing that AI agents and tools like Codex or Claude Code are already “good enough” for many vulnerability management and remediation tasks, allowing them to save millions in licensing fees while maintaining effectiveness.

Security talent becomes more distributed

One of the most profound shifts in 2026 will be how and where security talent is deployed. As budgets contract at large enterprises, it will become increasingly difficult for those organizations to justify and retain massive, centralized security departments. However, I believe this is overall good for the industry. We are moving away from a concentration of talent at a few mega-corporations and toward a world where top-tier security expertise is distributed across a much larger pool of companies.

In this new environment, the “department of fifty” will be replaced by lean, highly efficient teams where 1–2 dedicated security people support 500 employees or 30 engineers. This is only possible because AI allows a single technical leader to scale their impact across multiple domains that previously required separate specialists. We are redefining what a talented security engineer can do; instead of being a cog in a large auditing machine, the modern practitioner acts as a force multiplier who leverages AI to secure an entire organization autonomously.

If we see companies generate millions of dollars per employee with small teams, why can’t we see smaller security teams doing more to reduce risk?

The rise of the technical security leader

This shift toward distributed talent is powered by the rise of the technical security leader. The days of a CISO managing a department of “risk managers” who only surface problems are ending. These new leaders won’t just “advise” on risk; they will write the code and build the guardrails that automatically prevent it.

This might look like automated pull requests that resolve dependency issues before they hit production, or cloud infrastructure that self-heals when it detects an overly permissive identity. These leaders understand that to manage risk in a modern software-driven business, they must understand software engineering and business context as deeply as the product teams they support. They realize that if a company can generate millions of dollars per employee with a small team, a small, highly technical security team should be able to reduce risk just as effectively.

Security startups look for exits through acquisitions rather than IPO

Security startups are figuring out their exit plans after many good years and slowing growth, especially given the shrinking budgets and increased focus on AI. Luckily, large security companies will look for new capabilities that they can’t create organically. As I’m writing this, there are talks of Cisco acquiring Axonius, and the year ended with ServiceNow buying Armis. Last year was full of blockbuster acquisitions, such as Cyberark, Wiz, Upwind, etc. Netskope was the only notable IPO, and it seemed to go fine, but nothing too major. It seems favorable to be acquired or even go private, such as Proofpoint, rather than having to spend large amounts of money on GTM in a competitive market, which seems high-risk.

Although the acquisition activity might convince more people to start security startups, these returns will seem risky. Investment money in security will shrink, but I believe that after some consolidation in the industry this year, the security industry will return to a more stable point.

AI-native UX and the end of the “enterprise sales motion”

This evolution will be supported by a new generation of AI-native products that move beyond the traditional “dashboard” UX. These tools will live where the work happens, i.e., in Slack, GitHub, or the IDE, and use autonomous tuning to handle 90% of alerts without human intervention. Security products have historically been “regulatory theater” designed to pass an audit, but AI is finally allowing us to build abstractions that save time rather than creating more manual work.

Finally, the most outdated part of our industry is the sales motion itself. The current third-party risk management (TPRM) and procurement process is a relic of a waterfall world that makes zero sense in an AI-driven economy. Fast-moving AI companies simply don’t have time for six-month sales cycles or “discovery calls” for every minor tool. Security vendors will be forced to adopt Product-Led Growth (PLG) motions, favoring credit card swipes and instant trials over traditional enterprise bloat. The market forces of 2026 are demanding efficiency, and while this reckoning might be painful for some, it is a thrilling time for the practitioner. We are finally moving away from “program management” and back to actual security engineering.

I’m hopeful that the market forces these security companies to changes their ways.

I predict that market pressures this year will make security more efficient and hopefully more innovative as well. They need to make our lives as security professionals easier, and I believe this will lead to overall improvements across the industry that I’ve been advocating for many years.

I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:

Support me with a paid subscription

I decided to try something new this week and offer a more “holiday-themed” post. I’ve been vocal about my frustrations with the current state of the cybersecurity community—its inertia and reluctance to change. With the rapid emergence of AI fundamentally altering the threat landscape, the industry is increasingly unwilling to accept, confront, and adapt to these new realities.

As I’ve argued in the past:

This week, let’s look forward. Here is my Christmas wishlist for the cybersecurity community, directly addressing what needs to change for us to regain effectiveness.

Wish 1: We finally get rid of outdated security practices.

Security’s core function is managing and mitigating risk. We now have better access to large amounts of data to evaluate that risk, which means our guidance should be constantly refined against changing data and new threat landscapes.

Two practices immediately jump to mind for elimination:

• Mandatory 90-Day Password Rotation: This is an obsolete compliance requirement and an annoyance that breeds poor user hygiene. Most people simply append a number or a simple change to their current password, defeating the purpose. While rotating machine secrets (like database passwords and service account keys accessed by multiple people) remains critical, forced human rotation is counterproductive.

• Security Questions: They fundamentally fail. Designed to be easy to remember for the user, they are now dangerously easy to guess, given the wealth of personal information available online via social media. There are much better, more resilient ways to verify identity, especially with the increased use of robust password managers and stronger authentication methods.

The modern practice should be simple: use a password manager and enable multi-factor authentication (MFA) everywhere.

Wish 2: Get rid of security awareness training.

This is another painful, low-ROI compliance requirement. The data is mixed on whether these generic, mandatory, annual trainings are actually effective. Employees usually play the training in the background or try to click through it as fast as possible. This format delivers information without providing regular, practical experience, resulting in employees who don’t know what to do in specific scenarios. At larger organizations, enforcing this training wastes significant operational effort for little clear return on investment (ROI). Specialized training, like developer security training, is often even worse.

I would rather see investment shifted to regular, targeted engagement like realistic phishing simulations. More importantly, we should focus on continuous monitoring and implementing guardrails that automatically change user behavior and prevent errors, rather than relying on the hope that someone paid attention to a video months ago.

Wish 3: Security builds again.

I don’t want more security tools; I want security teams to actually go and solve problems rather than being risk pushers. Somewhere along the way, security leaders decided their value was simply program managing risk rather than actively mitigating it. They became advisors with “solutions” but lacked the ownership or technical capability to implement them. This detachment is the root cause of the industry’s effectiveness problem.

Security must adopt a more hands-on, engineering-focused approach. While I don’t believe security should own all risk, it must take ownership for a substantial part of the risk reduction effort. Spending time and money to merely surface risk, which then remains unmitigated, is not helpful for the business. As a result, security needs to build again and work toward being a direct part of the solution, rather than just surfacing problems. This shift requires technical leaders and a willingness to contribute directly to the code base. Jonathan Price states this well in his LinkedIn post:

Wish 4: More security tool consolidation.

Related to the previous wish, let’s have fewer security tools. As I’ve argued, most security tools are too theoretical and often solve marketing problems rather than actual technical ones.

It’s often unclear what the ROI of these point tools is. They primarily create more alerts and surface more risk without a meaningful, actionable solution for mitigation. We waste time cutting through alert noise and managing complex tools that rarely work out of the box and require lengthy Proofs of Concept (PoCs). This enterprise sales motion is broken and mismatched for the speed of the cloud and AI world.

My hope is that we invest more into unified platforms—and ideally, AI platforms—that are intuitive and allow security teams to solve problems on one surface, rather than buying dozens of point solutions. We are already seeing this consolidation trend with increased mergers and acquisitions (M&A). Too much competition in point-solution markets is actually bad for overall customer value, so I’m hoping the market adjusts itself naturally toward fewer, deeper solutions.

Wish 5: Security becomes more focused and enabling.

This is a broad wish about culture and strategy. Security spends too much time complaining about problems in general, rather than having constructive conversations that enable the business.

Let’s take AI as the primary example. The technology is here to stay and will gain wider and wider adoption. Instead of generating FUD (Fear, Uncertainty, and Doubt) about all the potential problems of AI, which implies that we shouldn’t use it, we should be having conversations about how to use it safely and efficiently. With any new technology, new challenges will emerge. It is the job of security to focus on solving those challenges rather than advocating for restricted usage. This is the difference between being a roadblock and being an enabler, as I discussed regarding how to be a security person that engineers don’t hate.

Another area for focused change is compliance. Security compliance must become more aligned with genuine security risk. Right now, our frameworks are often full of checkboxes that are time-consuming to meet, but which barely reduce actual risk. We are expending limited security resources and talent on proving we passed outdated certifications rather than solving tangible security problems.

Final Thoughts: The choice to adapt

These are some of my wishes for the industry as we head into the new year. I know some changes might take a long time, but others, driven by market consolidation and technological necessity, will happen faster.

The fundamental challenge is that security has been too set in its ways. We have operated as an operational, auditing function for too long, relying on processes and leverage dynamics that are relics of the pre-cloud, pre-agile, and certainly pre-AI world.

We are seeing a new class of technical security leaders emerge, i.e., people who understand that to manage risk in a modern software-driven business, they must understand software engineering and business context deeply. This shift in leadership is what will truly drive the change demanded in this wishlist.

The market is already applying pressure:

• Security budgets are under scrutiny: Executives are demanding measurable ROI and efficiency gains. They will not continue to write blank checks for theoretical risk reduction.

• Vendor consolidation is inevitable: The plethora of point tools—many of which are effectively solving organizational problems with technical solutions that don’t fit the actual workflow—will not survive. The focus is moving to platforms that can provide end-to-end context and automation.

• Trust replaces FUD: Security must learn to build trust both internally with engineering teams and externally with customers by delivering effective, transparent operations and communicating clearly during incidents. We need to embrace a philosophy where a security incident is seen not as a failure of the initial security control, but as an opportunity to demonstrate world-class detection, response, and transparent communication.

The choices are clear: embrace the necessary shift to a technical, efficiency-focused, and collaborative function, or continue to fade into irrelevance as businesses build and move around an outdated gatekeeper. It’s time for security to accept the new reality and adapt to win.