AI code scanning costs expose the real economics of AppSec scale

At a glance

What this is: Arnica argues that AI code scanning cost is driven less by headline model pricing than by workload design, repository cadence, and model routing choices.

Why it matters: For IAM and security teams, this matters because AI-assisted code scanning changes how backlog risk, developer workflow, and operational governance are budgeted and controlled.

By the numbers:

• A midmarket company with 400 developers generates roughly 5,200 pull requests each month based on Arnica's benchmark of 13 PRs per developer per month.
• At $15 to $25 per pull request, that same workload implies $78,000 to $130,000 in monthly provider costs before full repository scans are added.
• Mid-market defaults to 4.0 repositories per developer and 60% stale repositories in Arnica's benchmark model.

👉 Read Arnica's AI code scanning cost calculator breakdown for AppSec planning

Context

AI code scanning is no longer a niche experiment. As large language models begin to surface source-visible issues across repositories, the real governance question shifts from capability to cost, coverage, and operational control. For identity and security teams, that means treating AI-assisted scanning as part of the control plane around development risk, not just another developer productivity tool.

The hidden problem is that provider pricing does not map cleanly to enterprise reality. Scan volume, token consumption, repository age, and model selection all shape spend, which makes simple per-call pricing a weak planning model. That is especially relevant where security tooling is tied to developer workflows, because the organisation is effectively deciding how much assurance it can afford per change event.

Arnica's example reflects a common pattern in emerging security automation: the early conversation starts with whether the technology works, but the operational conversation quickly becomes whether it can be governed at scale without creating budget drift or blind spots.

Key questions

Q: How should security teams handle code scanning when AI agents generate large volumes of code?

A: They should move security feedback into the same workflow where code is created, especially pull requests and agent-time checks. Batch scans after merge are too late for fast-moving pipelines. Teams should also prioritise findings by reachability and exploitability, so reviewers focus on issues that can actually be reached in production.

Q: Why do AI code scanning costs rise faster than simple pricing models suggest?

A: Because the bill is driven by more than model price. Token volume, repository size, repeated scans of unchanged code, retries, and broader coverage requirements all multiply spend. A per-call estimate hides how quickly cost expands when teams apply the same expensive model to every repository and every change event.

Q: What breaks when organisations scan all repositories the same way?

A: They create waste on dormant code and under-optimize coverage for active code. Equal treatment ignores change velocity, so the programme pays for unnecessary scans while still missing the governance distinction between backlog discovery and forward prevention. The result is inflated spend without better risk prioritisation.

Q: Who should own AI scanning budget and retry governance?

A: Security engineering, AppSec leadership, and platform owners should jointly own it, because retry logic, provider limits, and scan orchestration are operational controls with financial impact. If nobody owns those decisions, a failed job or misconfigured retry can quietly turn into monthly cost drift.

Technical breakdown

Why AI code scanning costs scale non-linearly

AI code scanning spend does not rise in a straight line with repository count. It rises with the number of prompts, the size of code contexts, retry behaviour, and whether the same content is analysed repeatedly. In practice, changed code, full repository sweeps, and stale repositories all produce different token profiles. That makes cost a function of scan architecture, not just model choice. When teams use frontier models for every workload, they often pay for depth where breadth would have been sufficient.

Practical implication: size cost around scan architecture and cadence, not around a single per-call price.

Active repositories, stale repositories, and scan cadence

A useful cost model separates active repositories from stale ones. Active code changes frequently, so it needs a tighter scan cadence to catch introduced issues quickly. Stale repositories still matter because dormant code can contain exploitable vulnerabilities, but they do not justify the same scan frequency as high-change repositories. The governance point is that equal treatment of all repositories inflates spend and obscures where risk is actually moving. A cadence model tied to change velocity gives finance and security a defensible basis for coverage decisions.

Practical implication: assign distinct scan cadences to active and stale repositories based on change velocity.

Model routing, caching, and deduplication as cost controls

The strongest cost reducers are architectural. Caching avoids paying twice for unchanged analysis, deduplication prevents repeated work on identical code, and model routing lets smaller models handle simpler checks while reserving larger models for deeper reasoning. This is not just an optimisation exercise. It is a governance control because it determines whether AI scanning produces proportionate assurance or inflated consumption. The central lesson is that the cheapest scan is the one that avoids unnecessary computation without reducing the fidelity of findings.

Practical implication: build routing and caching into the scanning workflow before scaling coverage.

Threat narrative

Attacker objective: The objective is to exploit or preserve unresolved code vulnerabilities long enough for them to become production, audit, or breach risk.

1. Entry begins when attackers or auditors can reach latent flaws in repositories that were not scanned often enough or deeply enough to surface them early.
2. Escalation occurs when repeated scanning of unchanged code, weak routing, or inadequate backlog coverage allows exploitable issues to remain in the codebase.
3. Impact is realised through delayed remediation, higher exposure windows, and avoidable risk reaching production or external review.

NHI Mgmt Group analysis

AI code scanning cost is now an architecture problem, not a procurement problem. The article shows that provider pricing alone is a weak proxy for enterprise spend because the real drivers are scan frequency, code churn, repository age, and model choice. That means governance teams need to evaluate scanning design the same way they evaluate any security control plane, through volume, control scope, and operating model. The practitioner conclusion is that the cheapest headline model can still produce the most expensive programme.

Cost control and assurance control are now inseparable in AppSec automation. If teams treat every repository and every scan as identical, they overpay for stale code and under-invest in active risk. That creates a control failure in which budget optimisation and risk reduction pull in opposite directions. The better framework is proportional assurance, where active repositories get tighter scrutiny and dormant code gets lower-frequency coverage. The practitioner conclusion is that governance must distinguish between risk velocity and analysis intensity.

Model routing is the named concept that matters here: not all security work deserves the same model. This is the practical insight behind the calculator. Frontier models may be justified for harder reasoning, while cheaper models can handle narrower analysis tasks without collapsing coverage. For teams managing AI-assisted AppSec, the key governance issue is whether the architecture records why a given model was used and whether that decision is reviewable. The practitioner conclusion is that model selection should be policy-driven, not ad hoc.

AI-assisted code scanning becomes an identity-adjacent control when it governs developer workflow decisions. The article does not focus on IAM directly, but the control implications overlap with identity governance because the system is making decisions about code risk in a developer operating environment. That means access to findings, approval paths, and remediation routing should be treated as governed workflow, not informal messaging. The practitioner conclusion is that AI security tooling increasingly belongs in the same operational conversations as access review and control accountability.

What this signals

AI code scanning is shifting from a tooling question to a governance question. Once the model is used across development pipelines, teams have to decide which repository classes deserve continuous attention, which can tolerate slower cadence, and how much budget should be reserved for repeated analysis. That is a programme design issue, not just an AppSec feature choice.

Secrets management and AI-assisted review now overlap in the same failure zone. If code scanning exposes sensitive patterns but the organisation cannot remediate quickly, the control loses value before the exposure window closes. The relevant discipline is therefore not only detection, but the ability to route findings into secrets management and access governance workflows without delay.

From our perspective, the most durable control is proportional review. Teams that treat every repository, every pull request, and every model call as identical will overspend and still miss the riskiest changes. The better path is to tie analysis intensity to change velocity and use policy to justify when deeper review is warranted.

For practitioners

• Define separate scan policies for active and stale repositories Set different cadences for repositories based on change velocity, then review exceptions monthly so low-change code does not inherit high-cost treatment.
• Route simple checks to lower-cost models Reserve frontier models for deeper analysis tasks and use smaller models for routine vulnerability triage, with explicit policy on when escalation occurs.
• Cache unchanged analysis outputs Avoid paying again for identical file and prompt combinations by reusing prior results when code has not changed and the analysis context is still valid.
• Set budget owners for scan retries and failure handling Assign ownership for provider limits, retry logic, and failed scan behaviour so operational errors do not become silent cost overruns.

Key takeaways

• AI code scanning costs are governed by workload design, not just model pricing.
• The biggest cost leaks come from treating active, stale, and unchanged code as if they needed the same analysis intensity.
• Model routing, caching, and cadence policy are the controls that convert AI scan spend into usable security assurance.

Key terms

• AI Code Scanning: AI code scanning is the use of machine learning or large language models to analyse source code for security flaws, insecure patterns, or sensitive data exposure. In practice, it combines code analysis with workflow integration, so the governance challenge is not only accuracy but also cost, cadence, and remediation handling.
• Scan Cadence: Scan cadence is the schedule at which repositories or pull requests are analysed for security issues. It is a control lever because frequency directly affects cost, detection latency, and the likelihood that new or dormant risk is discovered before it reaches production.
• Model Routing Layer: The model routing layer is the policy and orchestration logic that decides which model handles a request, when to escalate, and what tools the request can reach. In AI programmes, it behaves like a control plane because it shapes data exposure, privilege boundaries, and auditability.

What's in the full article

Arnica's full post covers the operational detail this post intentionally leaves for the source:

• The calculator's configurable assumptions for developer count, repository mix, and pull request volume.
• The side-by-side model comparison inputs that translate provider pricing into annual spend estimates.
• The scan cadence settings for active and stale repositories, including how different frequencies affect cost.
• The operational controls Arnica highlights for caching, deduplication, retry behaviour, and budget enforcement.

👉 The full Arnica post shows how scan cadence, model choice, and repository mix change provider spend.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It is designed for practitioners who need to connect identity control to broader security operations and governance.