What is our AI security strategy? If you are leading an engineering team right now, you have been asked this. The natural, reasonable response is to frame it as a build-versus-buy decision: do you assign a couple of engineers to build something, or do you evaluate vendors?
That instinct is not wrong. But the threat has evolved faster than the decision frameworks most teams are using. This article draws on the threat landscape these decisions respond to, the supply chain analysis, and the defensive architecture deep-dive. No universal answers, just the right sequence of questions.
Build or buy: how should engineering-led organisations decide when budget and time are tight? #
The build-versus-buy question is not binary. It runs across three dimensions.
Is the capability core to your product’s differentiation? If your customers are not paying you for AI security, buying reduces maintenance burden and lets your engineers ship product. Focus your engineering resources on what differentiates your product.
How fast is the threat evolving? If the domain is moving faster than your team can iterate, you are structurally behind before you start. Mandiant reports a negative-seven-day mean time-to-exploit: attackers are weaponising flaws before patches ship. That speed makes the case for having dedicated threat research teams whose full-time job is keeping pace, which is what buying gives you.
What is the true integration cost? Building gives you control but consumes engineering time that is not shipping product. The real cost includes ongoing maintenance, token consumption, and the opportunity cost of diverted talent, all of which exceed the initial development cost. The LLM firewall market is projected to grow from $1.20 billion to $14.17 billion by 2035: commercial options are maturing. Microsoft and other platform vendors are building AI security into their existing ecosystems. If capabilities are already included in your licensing, factor that in before paying twice.
There is no universal answer here. But the speed of autonomous attacks challenges the build-versus-buy framing itself, not just the criteria within it. Before you apply these criteria, there is a more fundamental question.
AI offence vs AI defence: who is actually winning right now? #
The offence is winning the tempo battle. The evidence is converging from multiple independent sources.
Sysdig documented JADEPUFFER in July 2026. It is the first fully autonomous AI-driven ransomware attack, and it executed the entire kill chain from reconnaissance to encryption without human intervention. This is operational malware in the wild.
Unit 42 at Palo Alto Networks uncovered Shai-Hulud and CHAINDROP, supply chain compromises that affected over 500 npm packages with AI-assisted targeting. CISA issued an alert noting the worm spread by authenticating to the npm registry as the compromised developer and injecting code into other packages. For a closer look at how the npm supply chain became a vector, the full analysis is here.
IBM reports that roughly one in six breaches now involves AI. Zscaler’s data shows AI transaction volume grew 83% year over year, with targeting shifting from spray-and-pray to surgical precision.
Defensive progress is real: AMTD, Zero Trust for AI, and the LLM firewall market growth signal investment. But 86% of IT managers expect AI agents to outpace their guardrails within the next year. The gap is not closing fast enough.
How do you make the business case for moving beyond EDR? #
The business case rests on one argument: autonomous AI attacks eliminate the detection-to-containment window that EDR’s entire model depends on.
EDR assumes a window between detection and containment. JADEPUFFER eliminates that window by executing at machine speed. When exploits happen in under 10 hours and attackers weaponise flaws before patches ship, the assumption that detection can precede containment is no longer reliable.
The cost of a successful breach, at a global average of $4.88 million, is substantially greater than the cost of adding a prevention-first layer. Framing this as a risk-transfer calculation captures the economics more accurately than a marginal efficiency argument.
Zscaler’s data on AI-profiled targeting means your organisation’s people are selected based on AI reconnaissance. EDR was designed for opportunistic attacks, not surgically targeted ones.
A prevention-first layer sits alongside EDR; it stops attacks before EDR’s detection engine ever sees them. Morphisec exemplifies what this looks like: moving-target defence that denies attackers the predictable memory layout they depend on. The autonomous attack capabilities that make traditional EDR insufficient are already operational.
That same prevention-first commitment applies to the pipeline as well as the endpoint. What you build or buy to protect your code needs the same architectural logic.
Does AI-powered code review replace deterministic tools like SAST and SCA? #
It does not. The optimal architecture layers AI reasoning on top of deterministic baselines. Skipping the deterministic layer produces noise you cannot afford.
Naive LLM scanning of a codebase generated nearly 14,000 candidate sinks, and zero were confirmed real vulnerabilities.
Deterministic tools solve pattern-matching problems that do not require reasoning: known vulnerability signatures, dependency version checks, hardcoded credential patterns. An LLM attempting to replicate SCA at scale burns tokens on grep calls and manifest reads that a dedicated tool resolves in one call.
The pattern that works: run deterministic checks first, then feed compact, pre-computed evidence to an LLM reasoning layer. This reduces token consumption by 91.7% and tool calls by 4.5 times. You need both, but the AI layer is thinner and cheaper when the deterministic layer is doing its job. If you are building, build or integrate the deterministic layer first. For the broader architecture this pattern sits within, the AMTD and Zero Trust for AI piece covers the technical detail.
What are the real costs of building internal AI-powered security tools? #
Token consumption is the hidden line item most TCO models miss.
Agentic workflows that re-send accumulated context across multiple reasoning steps burn 5 to 30 times the tokens of single-turn chat interactions. Frontier model pricing is rising: Claude Fable 5 launched at double the previous generation’s rates, at $10 per million input tokens and $50 per million output. For a 150-developer organisation using frontier models for AI-powered security scanning, Endor Labs estimates $600,000 to $2.4 million per year in inference costs alone, before engineering salaries or infrastructure.
The deterministic pre-filtering pattern shrinks that cost envelope by 91.7%, but building this integration yourself is non-trivial. One 50-engineer team ran a per-PR security agent and watched it generate an $8,400 bill in the first month. The root cause was a 50,000-token security policy injected into every prompt.
There is also the talent question. With 4.8 million unfilled cybersecurity roles globally, the engineers who can build AI security tooling are expensive and flight-prone. The vendors are hiring from the same pool, and they can offer focus that a product team cannot.
31% of build-it-yourself projects are cancelled due to unforeseen expenses. Model your TCO on a three to five year horizon. Year-two maintenance and token cost growth create a compounding curve that initial estimates miss.
What should you look for when evaluating AI security tools on a limited budget? #
Evaluate tools across five criteria that separate real capability from vendor positioning.
Pre-execution prevention or just faster detection? Autonomous attacks eliminate the detection-to-containment window. Tools that only alert faster are not solving the speed problem.
Integration with your existing CI/CD pipeline and cloud infrastructure. The average enterprise security team manages 76-plus security tools and almost none of them talk to each other. Integration friction is a cost multiplier.
False-positive rate and operational cost of investigation. Each false positive consumes engineering time. Triage time per alert, multiplied by your engineer’s hourly cost, multiplied by alert volume, is the real bill. A vendor with a low license cost and a modest false-positive rate can end up costing more than doing nothing once you model the full investigation workflow.
Threat research track record. Does the vendor discover novel attack techniques, as Sysdig did with JADEPUFFER and Unit 42 did with CHAINDROP, or are they repackaging public research? A vendor that only follows others’ discoveries is a lagging indicator.
Total cost of ownership including engineering time to maintain integrations. License fees are the visible cost. Integration maintenance, tuning, and upgrades are the invisible cost. Check whether Microsoft or your existing platform vendors already include AI security features in your current licensing. For the technical architecture that should underpin your evaluation, see the prevention-first architecture deep-dive.
Where this leaves you #
The build-versus-buy question resolves into something more useful when you ask it second. The first question is whether your architecture prevents attacks or detects them after execution. Once you commit to prevention-first, the build-versus-buy criteria, the cost modelling, and the tool evaluation framework all align around one question: which architecture stops attacks before execution?
JADEPUFFER, CHAINDROP, and the Mandiant negative-seven-day mean time-to-exploit describe the current operating environment. The sequence matters: prevention-first architecture, then the layered deterministic-plus-AI pattern, then cost modelling with a three to five year horizon, then evaluation against the five criteria. In that order.
The 86% of IT managers who expect AI agents to outpace guardrails are not wrong, but they are not helpless. The organisations that act on this framework now will close the gap. For the full picture of the arms race and deeper technical context on any dimension covered here, the complete cluster is available.
Frequently Asked Questions #
Is prevention-first architecture achievable for a small engineering team, or is it only for enterprises?
Prevention-first is not reserved for enterprises. The architectural pattern itself (deterministic pre-filtering plus a thin AI reasoning layer) is what makes it affordable for smaller teams. A 30-developer organisation following the layered approach described in this article can deploy meaningful prevention capability without the $600K-plus inference costs that come from skipping the deterministic baseline. The key is sequencing: start with SAST and SCA coverage, then add AMTD at the endpoint.
What does a prevention-first architecture actually look like in a typical deployment pipeline?
It looks like deterministic tools (SAST, SCA, secrets scanning) running first in the CI/CD pipeline, producing compact results that feed into an AI reasoning layer applied only to confirmed anomalies. At the endpoint, it looks like moving-target defence (the Morphisec model) that randomises memory layout so attackers cannot rely on predictable execution paths. The two layers work together: the pipeline catches supply chain risks before deployment; the endpoint stops what slips through without waiting for a detection-to-containment window.
How do I convince the board to invest in prevention-first architecture when we have not been breached yet?
Frame it as a risk-transfer calculation, not a fear pitch. Autonomous AI attacks (JADEPUFFER, CHAINDROP) are operational in the wild today, and Mandiant’s negative-seven-day mean time-to-exploit means the gap between vulnerability disclosure and exploitation is now negative: attackers are exploiting before disclosure happens. The cost of a single successful breach (ransom, downtime, regulatory exposure under Australian and EU frameworks) dwarfs the cost of adding a prevention layer. You are not asking for security theatre; you are closing a structural gap that the current threat model exploits.
Is not Zero Trust already sufficient? Why do I need this additional prevention layer?
Zero Trust addresses access and authentication. It does not address what happens after an authenticated session is compromised, which is precisely what AI-profiled targeting achieves. The Zscaler data shows attackers are using AI reconnaissance to select specific mid-level IT managers and compromise them surgically. Once inside, autonomous malware executes at machine speed regardless of how robust your access controls are. Prevention-first architecture (AMTD, deterministic pre-filtering) addresses the execution layer that Zero Trust was never designed to cover.
How long does it typically take to transition from an EDR-only model to a prevention-first architecture?
A phased transition over six to twelve months is realistic for most organisations. The first month is audit: map your current detection surface and identify where deterministic pre-filtering can slot into the pipeline. Months two through four: deploy SAST, SCA, and secrets scanning if not already present, and begin the deterministic-plus-AI layered integration. Months five through eight: add moving-target defence at the endpoint alongside existing EDR (it is additive, not a replacement). Month nine onward is tuning false positives and building the threat research feedback loop.
What happens if we wait a year? Will commercial AI security tools be cheaper and more capable by then?
Yes, commercial tools will be cheaper and more capable. The LLM firewall market is projected to grow from $1.20 billion to $14.17 billion by 2035, and that growth will drive competition and price pressure. But waiting a year also means your organisation spends that year exposed to autonomous attacks that are already operational, not theoretical. The Mandiant negative-seven-day mean time-to-exploit means the threat surface is expanding faster than tool prices are dropping. The rational decision is to begin the architectural transition now, even if tool selection remains a phased decision.
Are autonomous AI attacks really targeting mid-market companies, or is this just a large-enterprise problem?
Autonomous attacks do not discriminate by revenue band. AI reconnaissance profiles targets based on access value, not company size, and a mid-market SaaS company’s mid-level IT manager with infrastructure access is just as valuable a target as a Fortune 500 equivalent. The CHAINDROP supply chain attack affected 1.3 billion monthly downloads indiscriminately. If your organisation has data worth encrypting or credentials worth stealing, you are in the targeting pool. The spray-and-pray era has been replaced by surgical AI profiling that treats every organisation as a specific target.
How do I know whether my current security posture is detection-based or prevention-first?
Ask a single diagnostic question: does any layer in your stack stop an attack before execution, or does every layer require detection first? If your security toolchain is SIEM plus EDR plus SOAR, you are detection-based. Your entire model depends on a detection-to-containment window that autonomous attacks have eliminated. If you have deterministic pre-execution blocking (SAST preventing vulnerable code from deploying, AMTD denying predictable memory layout, secrets scanning blocking credential exposure before it reaches production), you have the beginnings of a prevention-first posture.
What is the single most impactful first step a budget-constrained engineering leader can take this quarter?
Deploy deterministic pre-filtering (SAST, SCA, secrets scanning) across your CI/CD pipeline if you have not already. These tools are relatively inexpensive, well-understood, and produce immediate value by catching known vulnerabilities, supply chain risks, and credential leaks before deployment. Once that layer is operational, you have a compact, high-signal evidence stream to feed into an AI reasoning layer later, and you have already achieved the 91.7% token reduction pattern described in this article without spending a dollar on frontier model inference.
Is it true that AI security tools are mostly marketing hype and nothing has fundamentally changed?
No, and the evidence is converging from independent sources, not vendor marketing. Sysdig documented JADEPUFFER executing autonomous ransomware without human intervention. Unit 42 uncovered CHAINDROP at 1.3 billion monthly download scale. IBM confirmed that one in four breaches now involves AI. These are not marketing claims; they are threat research findings from organisations whose business model depends on accurate intelligence, not hype. What has changed is that the speed of attack has crossed a threshold where human-in-the-loop detection is structurally insufficient. That is a material change, not a marketing narrative.