The Security Rent

“Security is a process, not a product.” - Bruce Schneier

Schneier wrote that in 2000, and it held for twenty-five years. As a pentester, I have been a cog in this wonderful machine. We have clients that we’ve been assessing yearly for 5+ years. Lately there has been a lot of discussion about Mythos and using LLMs to find security bugs. I’ve built my own harnesses to use LLMs in my work, both for web assessments and CTF style stuff (I’m not using LLMs in competitions). I’m starting to think that security will soon turn into a very expensive subscription that you can’t cancel.

It costs roughly $30 in raw inference to generate a hundred thousand lines of code. It can cost somewhere around $15,000 a year to keep proving those same hundred thousand lines are safe.

That is roughly a 500 to 1 ratio, although there are some caveats. For this post, I’m looking at a company that builds, releases and maintains a SaaS web app.

Writing the code is mostly a one-off endeavour, and it keeps getting cheaper. Debugging and continuous development add to that cost because programming is very token hungry. We can multiply the generation cost by ten if we want and it still doesn’t change the maths much. The problem is that the codebase keeps changing and growing, so the security work never ends.

What changed #

For most of the last decade, the AI angle on security was boring in a good way. Static analysis caught the obvious things, humans caught the rest, and the false-positive rate was high enough that nobody felt the need to run everything constantly. Following the usual process gave you a strong baseline and a strong distaste for Snyk products.

Then the frontier models got good at finding vulnerabilities around the end of 2025 with Opus 4.5. Not just good at writing a CVE description that sounds convincing. They became really damn good.

When Anthropic’s Mythos-class models first appeared, the claim was that they could find vulnerabilities across every major operating system and browser. Mozilla used an early Mythos Preview to find 271 issues that shipped as fixes in Firefox 150. An earlier two-week run with the previous generation had already found 22 issues across roughly 6,000 C++ files. Access was initially limited to a handful of vetted partners at $25/$125 per million tokens because Anthropic considered the model too dangerous to hand out freely. The public version, Fable 5, shipped in June and was caught by export controls within days.

OpenAI’s GPT-5.6 tier reached general availability on July 9. It also launched behind a limited preview where the U.S. government asked that users be vetted first. Its system card says the models can find vulnerabilities and assemble pieces of exploits. That is a very measured way of saying they work.

Once you get past the launch drama, the point is obvious. These models are now good enough at finding vulnerabilities to worry governments and companies. A lot of the drama is marketing, especially from Anthropic. The models aren’t exceptional hackers out of the box either. They are very capable when someone knows how to use them, though.

That’s where the issue is. Attackers, especially skilled and well funded ones, now have models that can multiply their capabilities. There is no real way to restrict access to them. Between token black markets and jailbreaking, the restrictions Anthropic puts on Fable mostly annoy its current users. I’ve cancelled my subscription already.

Those attackers can get to your application by scraping, downloading, reverse engineering or indexing it. They can then put a nearly unlimited amount of compute behind a skilled person and rip through it.

How much this costs #

I tried to make these figures as accurate as I could. They are based on current LLM API costs and usage.

Every vendor blog about AI security seems to have a section about cost with the dollar sign carefully left out. Here are the assumptions I used. You can change them in the calculator at the end and see how much the result moves.

At list prices today, Fable 5 is $10 in and $50 out per million tokens. GPT-5.6 Sol costs $5/$30 if you want a second opinion. Output is what gets expensive. It costs three to five times more than input on every model, and security findings use a lot of output. I priced the baseline using one strong model because that is enough to find bugs. Adding more models is a choice, not a requirement.

You can always run it again #

Look at what happened with Firefox. On the Firefox 147 JavaScript engine, the previous-generation model turned its findings into working exploits twice across several hundred attempts. Mythos ran on the same benchmark and managed it 181 times, with register control on 29 more. The headline result came from running one good model hundreds of times and keeping everything that any run found.

This gets expensive because you can always run the model again. The public Firefox campaign ran roughly 1,000 scaffolded attempts for under $20,000. It stopped at a thousand because of diminishing returns and someone’s budget. Nothing else forces you to stop there.

This changes the question from “are we secure?” to “how much did we spend checking?” If you want to be extra sure, you run it again. It will use every token you give it. Old-fashioned pentesting was limited by the number of humans who could do the work. AI scanning is limited by how much you are willing to pay. Attackers use the same models and need much less coverage than you do.

There are two important caveats in the numbers below.

First, every number is a floor. The estimates assume one conservative pass. Running more passes makes them climb quickly.

Second, the Firefox figure looks cheap. If important parts of Firefox can be scanned for less than $20,000, why am I estimating $15,000 a year for only a hundred thousand lines? The Firefox campaign was a one-time test built by the people who made the model. It focused on the highest-risk C++ code and ran once. A normal company needs continuous scanning plus human triage, and it repeats that work every week. That is before adding another model or more passes. The Firefox campaign shows what a focused test can cost. It is not the same thing as running a security program every week forever.

Here is what that looks like for three hypothetical companies.

Three companies #

The startup with 15 engineers and 300k lines #

This company might spend $25,000 to $35,000 a year on AI coding tools across fifteen seats.

Verifying the code costs about as much as the tooling that writes it. That uses one model and one pass. Add a second opinion or another weekly run and the security bill becomes larger than the coding bill.

The mid-size company with 400 engineers and 5M lines #

That is roughly the payroll of five to seven senior security engineers. It is a new operating expense that scales with line count and probably arrived one “let’s add a scanning step to CI” at a time. This is still the lean version with one model and one pass.

The Fortune 100 with 10,000 engineers and 100M lines #

At this scale, the full-codebase sweep is not the main cost. The PR gates are. Sixty thousand small scans a week at a few dollars each adds up fast.

The per-100k-line answer #

Ignoring company size, the useful figure to remember is this.

Continuous scanning with one model costs roughly $10,000 to $20,000 per 100,000 lines of code each year. That is around 15 cents per line every year. The price can change whenever the next model ships, and this estimate does not include a second model or extra passes.

AI made software cheaper to write but it did not necessarily make software cheaper to own.

Tokenmaxxing for failure #

Recently a lot of people and companies have adopted the idea that they should generate as much code as possible, as quickly as possible, and ship all of it.

We called it tokenmaxxing. Point the agents at the backlog, let them write, ship the diff and move on. Everyone is doing it. LLMs are the future. People need to learn how to use them. There is nothing to lose, right? Right?

Line count drives every table above. Deep-scan cost scales with lines. Triage scales with findings, and findings scale with lines. Even PR-gate cost depends on how much code a change touches. The variable a company controls most is how much code it creates, and tokenmaxxing pushes that variable in the wrong direction.

Tokenmaxxing feels like maximising output, but it can maximise liability too. Every line you generate is another line you have to keep scanning. You can create technical debt at a monumental scale.

There are a few other costs that are easy to miss.

Generated code can be more expensive to triage. When a scanner flags something, a human still has to decide whether it is real. If nobody on the team understands the code because a model wrote it in one shot at two in the morning, that decision takes more tokens and more human time.

The models write vulnerabilities that other models then bill you to find. One system creates a flawed pattern for a few cents. A second system finds it for a few dollars. A human then confirms and fixes it for a lot more. You pay on both sides of a loop that you built yourself.

More code also means more attack surface and more to scan. Doubling the line count can make the call graph and cross-file interactions much more complicated. Those interactions are why the deep scan reads so much more than the raw codebase size.

The extra velocity is real and I’m not pretending otherwise. But if you ship ten times more code, you also have much more code to secure every year. The cheapest line of code to secure is still the one you never wrote.

Why you can’t just stop #

The natural reaction is to scan less. You can reduce the cadence, drop the second model or skip the quarterly sweep.

You can do that. Just be clear about the risk you are accepting.

An attacker targets one product and needs one finding. With a frontier model, that can cost a few thousand dollars once. You have to cover the whole application repeatedly because you don’t know where they will look. Their cost can stay low while yours grows with every line you ship. In practice, their API bill helps set the minimum for your security budget.

There may also be legal and insurance pressure to scan more often. Once a vulnerability can be found by a commodity model, insurers will probably ask about scanning cadence just as they ask about backups. Regulators may decide that your company should have found anything that a widely available model could find. At that point, scan frequency becomes a liability decision rather than just an engineering choice.

Every model release can also change the risk. Mythos didn’t create the vulnerabilities in your codebase. They were already there. It just made them cheaper to find. The next model might do the same thing again. A risk that was acceptable yesterday could look negligent tomorrow, and the frontier labs decide when that happens.

Are you willing to outspend everyone who might want to break your product? Probably not. Nobody can do that forever. Spending more on scanning cannot be the entire strategy.

What you can do #

The situation isn’t hopeless. The best ways to reduce the cost are mostly pretty boring, which is probably why the industry doesn’t talk about them much.

Delete code. Every line you remove is one less line to scan every year. Dead-code removal and dependency pruning used to be housekeeping. They now directly reduce a recurring security cost.

Build things securely in the first place. Do defence in depth. A vulnerability you never write costs nothing to find or triage later. Safer defaults, memory-safe languages and frameworks that make insecure code harder to write are cheap compared with finding the same mistakes forever. It took more than a decade for parameterised queries to become normal. We need to make secure patterns normal much faster now.

Use the pricing options. Prompt caching lowers input cost when every run reads the same context. Batch pricing can halve the cost of scans that do not need an immediate answer. Delta scanning lets you focus on what changed instead of reading the entire codebase every time. None of this solves the problem, but it helps.

Learn from the Firefox test. The expert-tuned Firefox run cost under $20,000, while a normal company could spend much more over time. The difference comes from scope and repetition. Focus on the code that matters, tune the harness so it does not waste tokens on noise, and use one model that is good at the job. Most companies can do those things too.

Measure your own cost per thousand lines. Put a dollar figure on your security scanning. Most teams cannot say what scanning costs per unit of code. If you measure it now, you will be able to make better decisions when the next model changes the price again.

Conclusion #

You don’t have to outspend attackers everywhere. Security companies would probably love that idea because it gives them a blank cheque. You do need to figure out which parts of your product have to be really solid.

Do threat modeling on your assets. Work out where good enough security will discourage attackers, where you need the best security you can buy, and where cyber insurance makes sense. Keep the rest of the product small and boring enough that there is less to defend.

It costs about $30 to write a hundred thousand lines of code.

It costs about $15,000 a year to keep proving they’re safe.

Schneier was right that security is a process. The update is that the process now has an API bill attached to it. The labs decide what becomes cheap to find, and attackers decide how hard they want to look. Before generating another hundred thousand lines, it is worth asking whether you can afford the rent on them.

Model your own rent #

Don’t take my parameters on faith. Change them below. Set your line count and cadence, add another model, increase the number of runs and see what happens to the cost.