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, and we have clients that we’ve been assessing yearly for 5+ years. Lately there’s been a lot of discussion about Mython and using LLMs to find security bugs. I’ve built my own harnesses to weave LLMs into my work, both for web assessments and CTF style stuff (I’m not using LLMs in competitions), and I’m realizing that quite soon security will 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 a ratio on the order of 500 to 1, although with some caveats. I will be talking about a scenario where a company is building, releasing and maintaining a SaaS web app.

Writing the code is a one-off endeavour, and it keeps getting cheaper. There are added costs from debugging and from continuous development, as programming is very token hungry by design. So we can 10x the value if we please, but it won’t really affect the maths much. The issue is that the codebase keeps changing and growing with the product in a way that requires constant work.

What changed #

For most of the last decade, the AI angle on security was boring in the good way. Static analysis caught the obvious things, humans caught the rest, and the false-positive rate was high enough that nobody felt any pressure to run everything through everything, constantly. It was a process that, if followed, created 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 “write a plausible-sounding CVE description” good. Actually really damn good.

When Anthropic’s Mythos-class models first surfaced, the claim was that they could find vulnerabilities across every major operating system and every major browser. Mozilla used an early Mythos Preview to surface 271 issues that shipped as fixes in Firefox 150, and an earlier two-week run with the previous generation had already turned up 22 across roughly 6,000 C++ files. Access was initially fenced off to a handful of vetted partners at $25/$125 per million tokens, on the grounds that the thing was 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, and it too launched behind a limited preview in which the U.S. government asked that users be vetted first. Its own system card notes the models can find vulnerabilities and assemble pieces of exploits, which is a wonderfully measured way of saying they work.

Reading past the launch drama it’s quite obvious to see the models that find vulnerabilities are now good enough that governments and companies get worried about it. A lot of it is marketing, especially from Anthropic, and the models aren’t exceptional hackers out of the box, but when piloted well, they’re very capable.

That’s exactly where the issue lies. Attackers, especially skilled and well funded ones, now have access to models that can 100x their capabilities. They have access to these models and there’s no real way to restrict this access. Between token black markets and jailbreaking, those security considerations that Anthropic is putting on Fable only manage to annoy its current users. (I’ve cancelled my subscription already.)

The thing is, those attackers can get to your application, through whatever means (scraping, downloading, reverse engineering, indexing) and then throw a virtually unlimited amount of compute in the hands of very skilled threat actors and just rip through it.

You’ve been entered into an auction you never asked to join, against a bidder who only has to be right once.

The math nobody publishes #

Allow me to lay down the maths. I tried to get these figures as accurate as I could and based them on current LLM API costs and usage.

Every vendor blog about AI security has a “what it costs” section with the dollar sign carefully left out. Let’s fix that. Here are my assumptions, laid out so you can argue with the parameters instead of the conclusion, which is the only honest way to do this, because the parameters are where all the disagreement actually lives:

At list prices today, Fable 5 is $10 in / $50 out per million tokens; GPT-5.6 Sol, if you want a second opinion, is $5/$30. Output is the one that cuts deep, three to five times the input rate on every model, and security findings are output-heavy by nature. I’ve deliberately priced the baseline on a single strong model, because a single strong model, not a nervous committee of five, is what actually finds the bugs.

The dial with no ceiling #

That table prices a single pass, but reliable vulnerability discovery is never a single-pass problem, but an iterative one.

Let’s look at what actually 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, re-run on the same benchmark, managed it 181 times, with register control on 29 more. The reliability didn’t come from this recursive self iterating process, from running the harness hundreds of times over and keeping the union of whatever any run happened to catch. This single genuinely good model, sampled repeatedly, is the configuration that produced the headline results.

The financial cost comes from the fact that the sample count has no ceiling. You can always run more. The public Firefox campaign ran roughly 1,000 scaffolded attempts for under $20,000, and nothing stopped it at a thousand except diminishing returns and someone’s budget. Nothing stops you at a thousand either.

So “are we secure?” quietly stops being a yes-or-no question and becomes “how much certainty did we buy this quarter?” If you want to be extra sure, you run it again, and again, and it will swallow every token you feed it. That is the genuinely new thing here. Old-fashioned pentesting was bounded by the supply of humans who could do it. This is bound only by your willingness to pay, and threat actors are shopping in the same unbounded market, needing far less certainty than you do to walk away with something.

Two things fall out of this, and you’ll want to get ahead of the second before someone throws it at you across a boardroom table.

First, every number below is a floor. The tiers assume a single conservative pass. Turn the dial past 1× and they climb with no natural stopping point.

Second, and this is the objection you’ll hear, that same sub-$20,000 Firefox figure looks cheap at a glance. All of Firefox’s crown-jewel C++ for less than twenty grand; so why do I claim $15,000 a year for a mere hundred thousand lines? Because they are not the same purchase. The Firefox campaign was one-time, expert-tuned by the people who built the model, aimed squarely at the highest-risk C++ core, and executed once. What an ordinary organisation signs up for is continuous, with a human triage bill stapled to it, repeating every week forever, and that’s before anyone adds a second model or touches the dial. The showcase number is the floor of what’s possible when you’re Anthropic running a demo. The recurring number is what it costs when you’re not.

Let’s look at three hypothetical companies under those lenses.

Three companies #

The startup: 15 engineers, 300k lines #

This company’s entire AI coding-assistant spend for the tooling they adopted specifically to move fast without hiring is maybe $25,000–35,000 a year across fifteen seats.

Verifying the code costs about as much as the tooling that writes it. And that’s on one model, at a single pass, before anyone gets nervous and adds a second opinion or a weekly re-run. Nudge either dial and it clears the coding bill comfortably.

The mid-size company: 400 engineers, 5M lines #

Five to seven senior security engineers’ worth of payroll, showing up as a brand-new operating expense that didn’t exist two years ago, that scales with your line count, and that nobody ever approved as a project. It just accreted, one “let’s add a scanning step to CI” at a time. And this is still the lean version of one model, one pass.

The Fortune 100: 10,000 engineers, 100M lines #

Notice what dominates at scale. It is not the dramatic full-codebase sweep everyone pictures when they imagine an AI security bill. It’s the PR gates, sixty thousand small scans a week, a few dollars each, every week of the year. It becomes an industrial papercut machine and your bottom line is its target.

The per-100k-line answer #

Strip the org sizes away and the model converges on a figure you can carry in your head:

Roughly $10,000–$20,000 per 100,000 lines of code, per year, for continuous single-model assurance. About 15 cents per line, per year, forever, and subject to revision by whoever ships the next model. And that’s the floor, before a second model or a single turn of the dial.

Next time someone tells you AI made software cheaper, do nod along politely, and then think about the maintenance cost.

The tokenmaxxing trap #

Recently a lot of people and companies have been operating on the mentality of generate as much code as possible, as fast as possible, and ship as much as possible.

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

Because line count is the one variable driving every table above. Deep-scan cost scales with lines. Triage scales with findings, which scale with lines. Even PR-gate cost scales with how much code each change touches. The single input one fully controls, how much code exists in the first place, is the exact input tokenmaxxing pushes in the wrong direction.

Tokenmaxxing feels like maximising output but it actually maximises liability. Every line you generate is a line you now have to scan forever. You end up creating technical debt at a monumental scale.

And it compounds in ways that are easy to overlook.

Generated code you didn’t write by hand is more expensive to triage. When a scanner flags something, a human still has to decide whether it’s real. If nobody on the team holds a mental model of that code, because a model wrote it in one shot at two in the morning, that decision costs more tokens, more models, and more human hours.

The models write the vulnerabilities that other models then bill you to find. One system emits the flawed pattern for a few cents; a second system laboriously rediscovers it for a few dollars; a human confirms and fixes it for rather more than that. The generator and the scanner are the same class of tool. You’re paying on both sides of a loop you built yourself.

More code means more surface, which means more to re-scan. Doubling your line count doesn’t double your risk in a tidy linear way, it widens the attack surface, deepens the call graph, and multiplies exactly the cross-file interactions that the expensive 10× deep-scan multiplier exists to chase.

The velocity is real, and I’m not pretending it isn’t. But “we ship ten times the code” and “our assurance bill grows tenfold, recurring” are the same sentence written twice. The cheapest line of code to secure is still the one you never wrote.

Why you can’t just stop #

The natural reaction to all of this is: fine, we’ll scan less. Cut the cadence, drop the second model, skip the quarterly sweep, save the money.

You can. But be clear about what you’re deciding, because it stopped being an engineering call somewhere back up the page.

Your attacker sets your floor. They target one product, scan once, need one finding. At frontier-class capability that’s a low-thousands expense, paid once. You have to cover everything, continuously, with margin, because you don’t get to know which line they’ll pull. The asymmetry is total: their cost is a flat line at a few thousand dollars, and yours is a curve that rises with every line you ship. The floor of your security budget is now set by somebody else’s API bill.

The cadence isn’t yours to set anymore, either. Once a vulnerability is findable for a known quantity of tokens, the legal and regulatory meaning of not looking changes underneath you. Cyber insurers will start asking about scanning cadence the way they already ask about backups. Regulators phasing in vulnerability-handling obligations will read “discoverable by a commodity model” as “you should have found it.” Scan frequency slips from a performance-tuning knob to a liability decision, made under rules you didn’t write.

And every model release reprices the debt. This is the one that should genuinely cost you sleep. Mythos didn’t create the vulnerabilities in your codebase; they were always there. It repriced them, by making them cheap to find. When the next model lands, and the one after that, every codebase on earth is marked to market overnight. Yesterday’s acceptable risk becomes today’s negligence, and you get no vote on when the revaluation happens. Your latent liability is a position you’re short, and the frontier labs keep moving the strike.

Which turns the alarmist question on the tin into the honest one: are you willing to outspend everyone who might want to break your product? Asked plainly, the answer is no. Nobody can. Which is precisely why the strategy cannot be “spend more on scanning.”

What actually bends the curve #

The situation is harsh but it isn’t hopeless, and the moves that help are mostly not the ones the industry is selling. You don’t beat this by buying more scanning. You beat it by needing less.

Delete code. It’s now a recurring saving, not a one-off tidy-up. Every line you retire stops paying rent, not once, but every year, across every future model generation. Dead-code elimination and dependency pruning used to be housekeeping; they’re now among the highest-ROI security work you can do, because they attack the one variable that drives the entire model.

Prefer secure-by-construction, because it wins on pure token economics. Do defence in depth. A vulnerability you never write costs nothing to find, nothing to triage, and nothing to re-scan for the rest of time. Tokens spent at design time, safer defaults, memory-safe languages, frameworks that make the wrong thing hard to express, are close to free next to the perpetual cost of detecting the same mistake forever. This is where history is on your side. It took over a decade for “parameterise your queries instead of concatenating strings” to travel from one obsessive’s hobby-horse to something you can almost assume. That loop, from known-better to default, now has to close in quarters rather than decades.

Use the pricing levers. Prompt caching slashes input cost on the stable context you re-read every run, batch pricing halves the cost of scans that don’t need an answer this second, delta scanning means you pay for what changed, not for re-reading the whole tree every time. None of this makes the problem disappear, but it softens it somewhat.

Close the gap to the showcase floor. Remember the two Firefox numbers: under $20,000 for the expert-tuned one-off, against the recurring millions an ordinary org will spend. It’s the distance between a scoped, tuned, single-good-model effort and a panicked run-everything-through-everything-forever. Most of what made the campaign cheap, scoping to the code that actually matters, tuning the harness so runs don’t burn tokens on noise, choosing one model that’s genuinely good, is available to you too.

And measure your own tokens per thousand lines. Put a real dollar figure on your assurance overhead. Almost nobody can currently tell you what their scanning costs per unit of code. The teams that instrument this, that can say “assurance is X% of total AI spend, and here’s the trend”, are the ones who’ll make sane decisions when the next model reprices everything again. The teams that can’t will simply watch the invoice grow and hope.

The honest close #

You don’t have to outspend your attackers everywhere. That framing is a trap, and it’s the one the industry is quietly hoping you’ll accept, because “it would be a terrible shame if something happened to your codebase” is a wonderful way to get handed a blank cheque. But it is your responsibility to figure out which parts need to be really solid.

What you have to do is narrower, and more achievable. Make your cost-per-finding exceed the attacker’s expected value on the surfaces that genuinely matter, and make the rest of the estate small enough, plain enough, and secure-by-construction enough that there’s simply less to defend. Do threat modeling on your assets, figure out where the thresholds are for just making your product good enough to discourage attackers, where it needs the best security money can buy and where cyber insurance can make sense.

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 was a process. The uncomfortable update is that the process no longer terminates, the meter no longer stops, and the rate is set by strangers on both sides of you, the labs who decide what’s cheap to find, and the attackers who decide how hard they’ll look. Before you generate the next hundred thousand lines, it’s worth asking, quite seriously, whether you can afford the rent on them.

Model your own rent #

Don’t take my parameters on faith, though. Argue with them. Model your own organisation below: drag the line count, set your cadence, add a second model, turn the certainty dial, and watch what happens to the rent.