On a GenAI development programme for a Japanese automotive customer, we took the security effort per delivery cycle from roughly 40 hours to about 8. The number gets attention, so let me spend the post on where it came from — because the interesting part is not the automation.

40 h → 8 hsecurity effort per delivery cycle
~0 hof that saving came from doing less security

We did not do less security. We did more, earlier, and stopped paying for the thing that was actually expensive.

Not every deferred decision is an option

Gregor Hohpe has a framing I steal constantly: architects sell options. An option is the right to decide later at a known price, and that right has real value — especially under uncertainty.

The framing is also the fastest way to see what goes wrong with security in a delivery cycle.

An option only holds its value if the strike price stays roughly fixed. Defer a decision whose price rises every week and you have not bought an option. You have taken on debt, and the payments are denominated in your engineers’ calendars.

That is what a security gate at the end of a cycle does. It is not an option on the security decision. It is a scheduled interest payment on a decision that was already made, badly, in week one.

The 32 hours were never security work

Instrument a delivery cycle and ask where the security hours go. The answer is rarely “analysing security”.

It is: waiting for a review slot. Re-explaining the architecture to someone seeing it for the first time. Reconstructing a decision made six weeks ago because nobody wrote down why. Filing findings a build step could have caught. Arguing about severity because nobody agreed in advance what severity meant.

Two bars. Before: 40 hours split into roughly 32 hours of coordination and 8 hours of analysis. After: the same 8 hours of analysis, with the coordination shown as deleted rather than deferred.
The analysis never moved. Everything that disappeared was interest — the accumulated cost of finding things out late.

Every item on that list is a payment against late discovery. None of it is analysis. All of it scales with how long the decision sat unmade.

This is why automation is the wrong first move, and it is the wrong move that almost every programme makes. Automate a late-discovery process and you arrive at the same rework faster. The rework was never the bottleneck; the timing was.

A rising curve showing the cost to change a security decision across design, model, build, test, pre-production and production, with a marker at design and a marker at pre-production.
Nobody disputes this curve. The mistake is treating the right-hand side as the place where security happens, and then optimising your throughput there.

What we built

Two halves, deliberately separated.

Default security, in the platform. Threat modelling, code scanning and vulnerability prioritisation as part of the development process rather than a gate at the end. A team gets these by using the platform. They do not request them, schedule them, or learn a security engineer’s name.

This sat on top of the customer’s existing platform-engineering programme, and that mattered more than anything we designed. We added a security lane to a road that already existed. Where that road does not exist, this approach fails, and the honest advice is to go build the road first.

Self-service security, on demand. Penetration testing a team can trigger when they want it rather than when the calendar allows. Teams that want to move faster than the default should be able to buy assurance instead of queueing for it.

Two lanes: default security in the platform, which fails if it is slow or noisy; and self-service security on demand, which fails if it is hard to invoke.
Two lanes because they fail in opposite directions. Merge them and you inherit both failure modes and neither strength.

The separation is not tidiness. Default security sits on everyone’s critical path, so it dies of slowness and noise. Self-service is opt-in, so it dies of friction at the point of invocation. Those are different engineering problems with different owners, and a single system optimised for both is optimised for neither.

Deterministic checks, not vibes

The specifically-GenAI part was building trustworthiness checks that return the same answer twice.

There is a strong pull toward evaluating AI systems with AI systems — a model grading another model’s output for safety. It is genuinely useful for exploration. It is not a control, and the reason is not accuracy. A model-graded check can be more accurate than a rule and still be unusable, because you cannot reproduce it, diff it, or put a version number on it.

So anything that blocks is deterministic:

  • Is the tool scope declared, and does it match what the code can actually reach?
  • Are credentials short-lived and task-scoped?
  • Is there an action log with the authorising capability recorded?
  • Does an irreversible action have a deterministic approval path?

These are boring, checkable properties, and boring is the specification rather than a compromise. Boring is what survives a build pipeline, an auditor, and a change of team.

Model-graded evaluation still has a job here. It advises, it explores, it flags candidates for human attention. It does not hold the gate.

Threat modelling with the customer’s own leads

The other half of the saving came from threat-modelling questionnaires run with the customer’s technical leads, against scenarios drawn from their industry and their project.

The obvious effect is better threat models, because the people who know the system are the ones enumerating it.

The effect that actually paid was quieter. Once a team has walked their own architecture and written down what an agent could reach, the security requirements stop being external. Nobody argues about a mitigation for a threat they identified themselves — and a large share of those 32 hours was argument, which mostly comes from findings arriving as a verdict from outside.

This is the part I would keep if I could only keep one. It is also the part with the highest up-front cost, paid by the people you least want to interrupt, which is why it is usually the first thing cut.

What this does not solve

Every automated check needs a named owner for what happens when it fires, and a path to zero.

The same lesson drove me to take our recurring findings loop to full automation on the practice side. That loop was consuming senior time on work with no judgement in it — precisely the work that should not be on a person’s calendar. It returned 100+ hours to customer-facing delivery, and it only worked because the judgement calls that remained still had names against them.

The general shape, and where it breaks

Security effort is a function of when the decision gets made far more than of how much analysis it needs. Move the decision to the earliest point where it is cheap, make anything blocking deterministic, and let the teams who own the system enumerate their own threats.

Three conditions have to hold for this to work, and I would not promise the number without them. There has to be a platform to put the defaults into. The delivery cadence has to be repeatable enough that “per cycle” means something. And leadership has to accept a slower first cycle in exchange for faster ones after it — which is the trade I have most often failed to sell.

The 40-to-8 figure is real, but it is a symptom, not the point. The cause is that security stopped being a separate phase, and stopped charging interest for it.