Why security companies should try hard to get an AI-native customer
It helps with product-market fit
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:
I’ve spent a lot of time over the last few weeks mapping out the security markets that will become dominant as AI adoption deepens across the enterprise. We are currently living through a massive transitionary period. Legacy organizations are mired in bureaucracy, trying to figure out how to securely adopt basic LLMs without exposing their data, while AI-native companies are completely pulling ahead by embedding autonomous agents into their core engineering loops. This friction is causing a severe bifurcation in the security market.
There is a massive opportunity right now to help these newer, cloud-native companies figure out how to productively use AI while managing the blast radius of autonomous code. But this newsletter isn’t about the threat landscape itself. It is about a fundamental GTM reality that most founders are missing: why having an AI-native customer as your design partner is the only way to build a sustainable security product.
This reality applies equally to early-stage startups and legacy incumbents. Larger companies obviously have the luxury of time, maturity, and cash reserves to weather market shifts. Startups do not. Yet, too many security companies are still running an old-school sales playbook. They exclusively hunt for the traditional enterprise buyer, defining a tier-1 customer solely by headcount.
But as I have written before, successful AI-native companies aren’t defined by the size of their workforce. They are lean, highly automated, and they frequently command massive budgets that rival legacy enterprises.
We are in an era where the architecture of the enterprise is shifting beneath our feet. If a security company fails to adapt its sales and product playbook to capture this lean, high-budget segment, it is going to find itself in serious trouble. The company won't necessarily fail overnight, but its success will become entirely random. You will be left fighting in an increasingly crowded, legacy market where the margin for error is razor-thin and there are very few opportunities to rise above the noise.
The network effect of the frontier buyer
The first and most obvious reason to anchor your product development around an AI-native customer is simple: market validation breeds market density. If you successfully solve a technical bottleneck for one AI-forward company, you instantly become the default choice for the rest of the cohort.
We are already seeing this exact dynamic play out with platforms like RunReveal and Formal AI. They didn’t build dashboards for compliance managers at legacy banks; they built high-throughput, programmable infrastructure for companies running massive engineering workloads. Because they solved the problem for the frontier, they built a highly defensible list of AI-native logos.
When you anchor your product around these buyers, you are forced to intimately understand their specific engineering workflows. AI-native companies do not operate like traditional enterprises. Their workflows are automated, their release cycles are continuous, and their internal organizations are completely flat.
By building software that maps to this high-velocity operational model, you are effectively skating to where the puck is going. Over time, as legacy companies are forced to adopt more AI to stay competitive, they will inevitably have to restructure their organizations to mimic these lean pioneers. When they do, they will need the exact tools you built for the AI-native frontier.
The build vs. buy threshold and the disintermediation trap
Building for the AI-native customer also acts as an early warning system against product obsolescence.
A lot of AI companies still rely on foundational security primitives. They use Material Security to protect their collaboration suites and Crowdstrike to secure their local endpoints. These platforms remain highly resilient to AI-driven shifts because they protect structural elements that do not change based on whether a human or an LLM is initiating the action. Mail infrastructure and operating system kernels must be secured regardless of the tenant.
However, application-layer security companies do not enjoy this structural defense. Many of them are still trying to sell legacy, seat-based subscriptions to solve problems that are purely organizational. Look at the traditional application security market. A massive percentage of AppSec features on the market today are explicitly designed to help bloated security teams pass vulnerabilities back and forth with disconnected developer teams via janky ticket systems.
In an AI-native company, those bloated teams do not exist. Furthermore, traditional AppSec scanners don’t perform any better than standard, native tools like Claude Code. When your developers can use frontier models to find, contextualize, and auto-patch vulnerabilities directly in the IDE, your standalone security dashboard becomes completely redundant.
This brings up a tricky, evolving dilemma: When will an AI-forward company choose to build a homegrown tool over buying your product?
The threshold isn’t determined by a simple feature checklist; it is an organizational capability threshold. Once a company transforms its workflow so that it can deliver features quickly using AI, and its team structure becomes flat and highly efficient, its leadership starts calculating the true ROI of their AI investments. To get there, they have to retrain their existing org and deliberately hire talent that knows how to push frontier models to their absolute limits.
If an AI-native company believes that a security application requires deep, hyper-specific customization that needs to be adapted and mutated quickly, they will simply build a homegrown tool themselves. They have the talent and the speed to do it over a weekend. An enterprise will only choose to buy your software when they believe your platform acts as a genuine partner toward a useful, complex outcome. Ultimately, whether a company builds or buys depends entirely on whether their leadership accurately understands their internal software and talent capabilities. If you are a vendor selling a surface-level wrapper, you will be disintermediated instantly.
The three barriers to building the paradigm
There is a massive, unfulfilled opportunity for a security tool that is built natively for AI-first environments, but also provides a clear, frictionless path for migrating legacy companies to adopt it as they begin their own AI journeys. I believe there are three distinct reasons why this type of platform hasn’t completely dominated the market yet.
The first reason is raw focus. Security companies are notorious for trying to be everything to everyone, diluting their engineering talent across dozens of half-baked feature sets. It is infinitely easier to achieve true product-market fit by focusing relentlessly on a single, highly sophisticated customer segment and nailing the product architecture before moving down-market.
The second reason is a matter of timing. Frontier AI models have only achieved the level of reasoning and reliability required for true agentic engineering within the last six months. There simply hasn’t been enough clock time for security startups to build, iterate, and deploy deep product architectures that can match the speed of these new models while maintaining enterprise-grade performance.
The third barrier is the hardest for modern founders and venture capitalists to swallow: the absolute necessity of forward-deployed engineering services.
There is a pervasive belief among software founders that they must build a pure, high-margin SaaS product company from day one. They look down on professional services as unscalable overhead. But history tells a completely different story. Many of the most successful, product-led security companies in history, including Crowdstrike, Mandiant, and Palo Alto Networks, started as deep, services-heavy operations. They embedded their engineers directly inside client environments, handled the incidents manually, learned the raw operational friction points, and then codified that expertise into scalable software.
While AI autonomous agents will likely eliminate the need for traditional, human-intensive professional services in the long run, we are not there yet. In the short term, bridging the gap between legacy infrastructure and AI-native design requires hands-on implementation and custom context engineering. Currently, frontier tools are still hard to use, and many organizations don’t understand the deep nuances of AI. They don’t know which models to use for specific tasks, or how altering the complexity of a model changes the security outcome.
Security startups must invest in high-caliber forward-deployed engineers (FDEs). The job of the modern FDE isn’t manual implementation scripting; it is providing the precise context, parameters, and model orchestration the AI needs to hit the organization’s target security outcomes efficiently. This services infrastructure makes the business model look less attractive to traditional, margin-obsessed VCs in the early rounds, but it is the only reliable way to build a bulletproof product.
The Palantir playbook for the legacy chasm
This exact services requirement becomes your secret weapon when you decide to take your AI-native product down-market to legacy enterprises.
Traditional enterprises don’t have the clean data structures, modern API layers, or cultural alignment needed to ingest an autonomous security tool out of the box. To bridge this enterprise chasm, you cannot just drop a SaaS login and walk away. You have to actively deploy services and imbed teams to work alongside the customer, systematically adapting your product to their environment.
Palantir built a massive, highly resilient business using exactly this playbook. They succeeded at driving the digital transformation of highly traditional, outdated industries by deploying forward-deployed engineers to wrestle with messy data landscapes and bridge the operational gap until their platform became indispensable. There are endless lessons for modern security founders to learn from that model. Services are how you survive the reality of a market in transition.
The strategic filter
Ultimately, treating the AI-native enterprise as your target customer serves as the ultimate strategic filter for your product roadmap.
For early-stage startups, it provides cold, immediate data on whether your technical architecture can sustain itself in a high-velocity environment. It is completely acceptable if you realize your product isn’t built for the frontier and you choose to pursue slower, legacy enterprise markets instead. The real danger is when founders hallucinate that their legacy software is highly attractive to AI-native companies when it isn’t, wasting millions in go-to-market capital trying to force a product-market fit that doesn’t exist.
For established incumbents, tracking the AI-native buyer is the only way to inform your M&A and corporate strategy. It shows you exactly where your current architecture is failing to scale, giving you the visibility needed to acquire next-generation platforms before you are permanently locked out of the enterprise budget.
The future belongs to the vendors who can withstand the operational scrutiny of the AI-native buyer. If your product cannot survive an environment with zero human middle-management and instant developer velocity, it will not survive the decade.