From periodic security review to every commit

Last month, one of our security agents flagged a finding on a payments feature. Real users, real money on the line. Before the finding reached a human, three separate agents tried to prove it wrong: hunting for a reason it did not apply, checking whether the code path was actually reachable, arguing the case both ways. Only what survived that got escalated. A person still decided what counted as risk accepted, and their name went on that decision.

That is the setup we are walking through in full on 14 October, but the interesting part is not the demo. It is why we built it this way.

Why the periodic cadence stopped working

Most security processes still run on a periodic cadence: a design review at kickoff, a pentest before launch, a scan report read whenever someone has time. That worked when a small security team was the scarce resource and the amount of code shipped in a quarter was bounded by how many developers you had.

Agents change the second half of that equation. The same team now ships several times the code, and the security team has not grown to match. A design review that used to reach every initiative now reaches a fraction of them. Threat modelling stays a goal on a wiki page instead of something that happens. Not adopting AI in security does not mean things move slower. It means most of what ships goes uncovered.

Making the standard something an agent can run

The fix we landed on: take the security standard you already have (a checklist, an industry catalogue, whatever exists today) and make it something an agent applies automatically when requirements are written, not after code ships. The relevant clauses get pulled into the spec before a line of code exists, so what gets generated is secure by default instead of getting patched afterwards.

From there, security runs in two cadences. Full-depth work happens at design time: mapping trust boundaries, reviewing the design against known anti-patterns, running a threat model against it. All of it is checked by a named person before it counts. On every pull request after that, lighter checks run automatically: has the diff drifted from the agreed requirements, does the threat model still hold, is there a security angle the code review missed. Each check, however small, appends to a record you can point at later and say: here is what ran, and when.

What we would tell you before you try it

The honest parts: agents produce false positives when a tool cannot see the whole application, findings aren’t always consistent between runs, and costs add up fast enough that you need to watch them per repository, not in aggregate. None of that is a reason to wait. It is a reason to start small: run a scanner estimate on one module, or ask your agent to review your last pull request against your own checklist, and see what it actually finds.

We are showing the full setup on 14 October, join us for this webinar!