Build vs. Buy in the Age of AI Security

If your team is using AI agents on security findings, you have already decided AI is how the work gets done. The open question is who builds and runs the harness around the model, and what you give up by starting from zero.

The build-vs-buy decision used to be about features. Does the vendor's scanner find what ours finds? Does it integrate with our tools?

With AI security, the model is not the differentiator. Nullify runs on the same classes of frontier and open-weight models your team can call. What decides the outcome is everything around the model: which model handles which question, what evidence it can see, and what it is allowed to do with its answer.

That surrounding layer is the harness. If you build, you start it from zero on three hard problems.

Problem 1: Token routing

Not every finding deserves the same amount of intelligence.

Across 14,847 SAST findings in five production tenants, 57% were false positives. Sending each finding through full frontier-model investigation costs roughly $0.40 to $1.60 per finding, so a harness without routing spends most of its budget confirming noise.

Routing is how you avoid that. A cheap first pass settles the easy cases, and expensive reasoning is reserved for findings that are genuinely hard or high-stakes. Getting it right means answering questions that have no default:

• Which questions can a small model answer reliably, and which need a frontier model?
• How many turns and tokens does each stage get before it stops?
• What happens when a stage times out or a provider is down?
• When prices or models change, which stages should move?

When we rebuilt one early triage stage from a one-shot frontier call into a tool-using open-weight agent, it used 97.5% fewer input tokens and resolved a finding the old design had pushed downstream. That result came from routing and architecture, not from a better model.

Problem 2: Context management

A model can only decide correctly if it can see the deciding fact, and that fact is rarely in the code snippet a scanner hands you.

A hash function looks like a weak security control until you read its caller and see it only builds a cache key. A library with four critical and ten high CVEs looks urgent until you learn it never runs in production. In both cases, a stronger model looking at the wrong evidence still gets the wrong answer.

Building context management means deciding, for every kind of finding:

• What the agent can read: the full repository at the scanned commit, or only a local window
• How it links a finding to the service, cloud resource and data it touches
• Where organisational knowledge lives, such as who owns a service and what the policy says
• How to keep all of that fresh as code and infrastructure change

Too little context and the agent guesses. Too much and you pay for tokens that do not change the decision.

Problem 3: Guardrails

An agent that can dismiss findings or open pull requests needs a contract for what it may do, and what happens when it is unsure.

The failure modes are not symmetric. A wrongly escalated finding costs some review time. A wrongly dismissed finding hides a real vulnerability. A good harness gives dismissal a much higher evidence bar: no affirmative evidence, no dismissal. Uncertainty, budget exhaustion and tool errors all fall through to deeper review.

Fixes need the same discipline. A generated patch has to build, preserve behaviour and actually close the vulnerability before a developer sees it. Otherwise the review burden just moves from triage to code review.

When building makes sense

Building is a reasonable choice when:

• Your estate is small, with a handful of repositories and one or two languages
• You have engineers whose full-time job can be the harness, not a side project
• You are prepared to re-evaluate models and routing every time the landscape shifts
• You have a way to measure false-dismissal rates, not just throughput

For a single repository and a skilled engineer, a DIY agent can write an excellent fix. The difficulty is doing it across hundreds of repositories, every day, at a cost you can forecast.

When buying makes sense

Buying tends to win when:

• Findings span many repositories, languages and cloud accounts
• Your security team is small relative to engineering
• You need to explain automated decisions to auditors or customers
• You want results in the first week, not after a quarter of pipeline work

A five-question checklist

1. Routing: Do we know which model answers which question, and what it costs per finding?
2. Context: Can the agent see the evidence that decides each finding, beyond the snippet?
3. Guardrails: Is dismissal gated on evidence, and are fixes validated before anyone reviews them?
4. Ownership: Who maintains the harness when models, prices and integrations change?
5. Time to value: How long until the harness is triaging our real backlog?

If you cannot answer the first three confidently, you are not choosing between build and buy yet. You are choosing whether to start a new internal platform.

What Nullify gives you on day one

Nullify deploys a harness that has already solved these problems in production, so tokens and engineer hours go to high-impact triage from the start.

Routing: cheap, tool-using agents settle findings where evidence is available, and deeper reasoning is reserved for the rest.

Context: triage agents investigate findings from SAST, SCA, secrets and cloud posture with the repository and a shared asset graph in reach, including internet reachability and ownership.

Guardrails: findings are dismissed only with evidence, exploit validation proves which issues are real, and fixes arrive as merge-ready PRs in GitHub, GitLab or Buildkite for your developers to review.

Make the decision deliberately

Buy vs. build in AI security is not a question about models. Both paths use the same ones.

It is a question of whether you want to own the harness, or own the outcomes it produces.