The AI security market is in the middle of a gold rush, with investors pouring capital into startups that promise to drop large language models into the security operations center. Fresh funding rounds and product launches land almost every week, and the spending sits inside a much larger wave. Worldwide AI infrastructure spending hit $318 billion in 2025, more than double the prior year. The appetite makes some sense, after all security teams face rising alert volume, adversaries are experimenting with AI of their own, and there is a need to automate the work that burns out analysts.
However, almost all of the investor money flows toward a single design in which a vendor wraps a proprietary layer around a frontier model from one of the major labs and sells access as a managed product. That raises the uncomfortable question the category keeps avoiding. Why do organizations keep funding tools that are structurally built to fall behind the technology they depend on?
Buyers assume that purchasing an AI security product hands them the latest AI. That pitch works because the underlying models are genuinely capable and teams want help putting them to work, yet the structure quietly works against that assumption. Each upstream leap that should reach you immediately instead waits on a downstream vendor’s release schedule, and that wait carries a cost.
What is more, the lack of transparency in these systems creates a lock-in. As the agentic AI market matures, increasingly users are learning which models work best for their use cases and their users. By relying on a proprietary vendor who packages AI within their system, you lose this level of control. You become increasingly locked-in, which also makes it harder to control spending.
How a wrapper builds in its own delay
Frontier labs now release major capability gains on a fast cadence, and the jumps are large. Stanford’s 2025 AI Index found that scores on SWE-bench, a software engineering benchmark, climbed 67.3 percentage points in a single year. Providers including Anthropic, OpenAI and Google push updates that reshape what is possible for detection, triage and response within weeks of each other. Each release resets the clock for every proprietary layer built on top, and the gap between what the model can do and what the wrapped product exposes widens with every cycle.
Run a wrapped product in 2026 and you are working with whatever the vendor last certified, which already trails what the model itself can do, narrowed further to the features and integrations the vendor chose to expose. The delay compounds with every release the vendor defers.
Who learns – you or your vendor
Another concern is that the scaffolding, or software, around your LLMs itself can be improved by LLMs over time. This improvement can allow you to add custom capabilities and can also lead to better performance. Very concretely, a well engineered learning loop will take into account your systems and the feedback from your operators and will use this to make better decisions. Many proprietary vendors state that they will not learn from your usage of “their product”. While that is admirable and required by many enterprises, it leaves it up to you to somehow customize their products as needed over time. This learning loop should be built into your AI SOC and you shoudl own it.
Follow the money and the incentives
The incentives established by proprietary systems wrapping around fast improving underlying AI run counter to customer interests. A proprietary vendor earns recurring revenue by owning the relationship between you and the model, and it gains little by shrinking the time between an upstream improvement and your access, since that delay is what justifies the subscription.
Slowness can even become the product the vendor is actually selling, dressed up as managed convenience. The vendor controls the roadmap, the release schedule and the surface area you are allowed to touch, with each control serving as a lever for monetization rather than for your security posture. Security leaders who have run a few procurement cycles will recognize the pattern from earlier enterprise software.
Open source removes the middle layer
Open source removes that intermediary entirely and changes the underlying math. Upstream improvements reach you the day they land, you choose what to adopt and how fast, and your engineers can read the code, audit the behavior, extend it for your environment, support your own learning loop that you own, and even safely contribute fixes the whole community inherits.
The Linux Foundation’s State of Global Open Source 2025 report states that organizations see the benefits of open source as reducing vendor lock-in at 84%, facilitating innovation at 82% and shortening time to market at 75%.
Flexibility weighs as heavily as raw speed for most security teams. Their environments carry their own data shapes, log formats and existing tooling, and an open foundation lets them build the exact detection and response logic those environments need. A closed wrapper offers only the options its vendor decided to ship.
Verification gives buyers a third reason to prefer the open path. A closed wrapper asks you to trust a vendor’s claims about how a model is prompted, constrained and monitored, while open tooling lets your engineers check those claims for themselves. That visibility is a stronger position for any team accountable for risk.
What the orchestration wars already settled
The industry ran this exact experiment 10 years ago, and the result is on the record. When containers took off, several players raced to control how organizations would run them at scale. Google open sourced Kubernetes in 2014, drawing on its internal Borg system, while Docker promoted its proprietary Swarm product to monetize its platform.
The proprietary approach lost, and the trajectory was steep once Kubernetes joined the Cloud Native Computing Foundation, where its contributor base grew from roughly 700 to more than 8,000 and it became the default standard every major cloud now offers as a managed service. Docker eventually folded Kubernetes support into its own products, and the DC/OS platform built on Mesos reached end of support in 2021.
The same dynamic now plays out in AI security, where a community building in the open moves faster than any single vendor guarding a closed roadmap, because thousands of contributors solving their own problems will outpace one company solving for its margin. The organizations that won the orchestration wars bet on the open standard early and built on top of it.
Where security teams should place their bets
For all its advantages, open source still demands real investment to deliver. Plenty of projects are early-stage, and buyers carry the support, governance and integration costs that a managed product would otherwise absorb. The same surveys that show surging adoption also flag gaps in governance and skills, so teams must staff the people who run the tooling to capture the payoff.
The strategic call is simpler than the operational one, and the underlying economics settle it. The base technology keeps getting cheaper as it improves, and Stanford’s 2025 AI Index measured the cost of running a system at GPT-3.5 level falling more than 280 times between late 2022 and late 2024. When capability moves that fast, control over speed and direction outweighs the convenience of a managed wrapper. Buyers who want the latest AI capabilities running in their environment should ask whether a closed layer is helping them move or quietly charging them to stand still.
The AI inside security tooling will keep advancing regardless of which vendor keeps pace. The teams that benefit most will be those positioned to absorb each improvement directly, on their own timeline, with full visibility into how it works, while capturing their own learning loop.
