AI in AppSec: What to Build vs. Buy

The integration of AI into AppSec presents a significant scalability challenge, where successful small-scale prototypes often fail when introduced across an enterprise's entire codebase. Frontier models are forcing security teams to reevaluate existing tooling, with many considering consolidation or replacement. The core difficulty lies not in prototyping agents—which is relatively cheap—but in achieving cost-effective and verifiable execution at scale. Costs compound rapidly due to token usage required for context derivation on every request, coupled with the overhead of validating findings against false positives.
To address this gap, a four-level architectural maturity model has been proposed, ranging from simple governed generation (Level 1) to fully orchestrated systems (Level 4). The progression requires shifting organizational focus: while initial stages lean toward 'buy' solutions, higher levels necessitate significant internal investment in building unique security skills and orchestration logic. Research indicates that providing precomputed evidence dramatically reduces token expenditure—by up to 12x—and stabilizes costs compared to agents working without deep context.
<RED>
IDC’s July 2026 survey reported about 80% of respondents are reassessing dedicated AppSec tools due to frontier AI security capabilities, and nearly half expect to cut or replace at least one tool. Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value, or inadequate risk controls. Prophet Security’s 2026 survey showed 46% of respondents who built internal SOC AI tooling deprecated it, replaced it, or did not implement it into production. The research showed an unaided agent burned 79.5 million tokens over 370 minutes across 12 open-source projects when running without precomputed evidence; the evidenced agent used 6.6 million tokens in 133 minutes. Using a hypothetical 300-developer organization, token use dropped from an estimated $5.8M annually to $1.4M annually with context cutting usage by 80% on Claude Opus 5. The four proposed levels are: Level 1 (Governed generation), Level 2 (Agentic security tools), Level 3 (Custom security skills), and Level 4 (Orchestrated security agents).
</RED>
<PURPLE>
The prevailing narrative here is not a rejection of AI, but a confrontation with engineering gravity: the chasm between demonstration and deployment. The underlying assumption driving this resource kit—and its sponsored promotion—is that enterprise-scale agentic systems are fundamentally unsustainable without external, specialized foundations. This echoes historical patterns where bespoke internal projects fail at scale due to maintenance debt, not conceptual weakness; the cost model shifts from a low barrier to entry (the prototype) to a high operational barrier (the fleet).
The proposed four-level architecture frames the decision as architectural triage: build what is uniquely valuable to the business—like proprietary risk tolerance or specific workflow handling—and buy the deterministic scaffolding underneath. This framework skillfully reframes "building" away from foundational infrastructure (context graphs, verification pipelines) toward unique value generation. The persistent threat pattern observed in AI tooling abandonment (cost and ambiguity outweighing capability) is leveraged here to position a paid solution as the necessary escape velocity.
The central question becomes: Is this a genuine delineation of technological maturity, or a market necessity forcing early-stage builders into vendor ecosystems? If external foundations provide context and verification, they solve the economic bottleneck identified by token usage spikes. However, framing specialized internal knowledge ("Your policies, risk tolerance, and workflows are worth building") while simultaneously selling a "foundation" suggests a partition of value—the customer builds their *intent*, but must rely on the vendor for the *certainty* required to execute that intent safely at scale.
What organizational practices would be necessary to validate Level 3 or 4 internally without external support? How can organizations differentiate between investing in proprietary workflow design versus paying a premium for foundational knowledge persistence across tooling generations?
Patterns detected: ARC-0127 False Framing, ARC-0245 Authority Game (Vendor Advertorial)
</PURPLE>

The prevailing narrative here is not a rejection of AI, but a confrontation with engineering gravity: the chasm between demonstration and deployment. The underlying assumption driving this resource kit—and its sponsored promotion—is that enterprise-scale agentic systems are fundamentally unsustainable without external, specialized foundations. This echoes historical patterns where bespoke internal projects fail at scale due to maintenance debt, not conceptual weakness; the cost model shifts from a low barrier to entry (the prototype) to a high operational barrier (the fleet).
The proposed four-level architecture frames the decision as architectural triage: build what is uniquely valuable to the business—like proprietary risk tolerance or specific workflow handling—and buy the deterministic scaffolding underneath. This framework skillfully reframes "building" away from foundational infrastructure (context graphs, verification pipelines) toward unique value generation. The persistent threat pattern observed in AI tooling abandonment (cost and ambiguity outweighing capability) is leveraged here to position a paid solution as the necessary escape velocity.
The central question becomes: Is this a genuine delineation of technological maturity, or a market necessity forcing early-stage builders into vendor ecosystems? If external foundations provide context and verification, they solve the economic bottleneck identified by token usage spikes. However, framing specialized internal knowledge ("Your policies, risk tolerance, and workflows are worth building") while simultaneously selling a "foundation" suggests a partition of value—the customer builds their *intent*, but must rely on the vendor for the *certainty* required to execute that intent safely at scale.
What organizational practices would be necessary to validate Level 3 or 4 internally without external support? How can organizations differentiate between investing in proprietary workflow design versus paying a premium for foundational knowledge persistence across tooling generations?
Patterns detected: ARC-0127 False Framing, ARC-0245 Authority Game (Vendor Advertorial)