Your Software Needs to Be Tested Against an AI Attacker

Obscurity Really Did Work

For most of the history of the web, small businesses were protected by arithmetic rather than by security. Finding a novel flaw in a bespoke application took a skilled person days or weeks. That person had to eat, so they spent their time where the money was. Everyone else got the leftovers: automated scanners running a fixed list of known exploits against known software. If you were not running an unpatched version of something popular, those scanners went away.

This is why "we are too small for anyone to bother with" was, uncomfortably, a reasonable risk assessment. Not a good one, but a reasonable one. The bespoke code that runs your business was genuinely unlikely to be examined by anyone who understood it.

What Changed

The expensive part of that equation was the skilled person. It is not expensive anymore.

A capable model can now read an unfamiliar codebase or probe a running application roughly the way an experienced developer would: forming a view of what the system is for, noticing where the assumptions are, and trying things that a signature-based scanner would never think to try. That is a difference in kind, not in speed. The old scanners asked "is this a known vulnerable version?" The new ones ask "what would break this particular application?"

The scale of the change is not hypothetical. In June 2026, Senator Mark Warner told a Senate hearing that Anthropic's Mythos model, tested against US government systems under a program called Project Glasswing, "broke into almost all of our classified systems, not in weeks but in hours", attributing the account to the head of the NSA and US Cyber Command. A US official later told the Associated Press that the model had identified vulnerabilities within hours, while noting that finding a vulnerability is not the same as exploiting it. Both the NSA and Anthropic declined to comment publicly. The same model is reportedly now being used by CISA to scan federal code for flaws before someone else finds them.

Take the specifics with the caution they deserve; this is a senator's characterization of a classified exercise. The direction of travel is not in doubt though, and the important part for everyone else is not the government angle at all. It is that this capability is commercially available. What was demonstrated against classified systems can be rented by anyone with a credit card and pointed at your order form.

People Cannot Cover Everything, and That Is the Whole Problem

The uncomfortable detail in the government story is that those were not neglected systems. They had been through serious, expensive, repeated security review, by people who are very good at it, under rules that most commercial software never has to meet. The flaws were found anyway, in hours.

That is not an indictment of the reviewers, and it is not a matter of them being outclassed at the individual steps. It is a coverage problem, and it is structural.

A human tester has to pick targets. That is the actual skill of the job: looking at a system, forming a view about where the weaknesses are most likely to be, and spending the limited hours available on those. It is informed, experienced, well-judged sampling, and it is still sampling. Nobody has ever had the budget to check every input on every endpoint in every combination of application state and permission level, so nobody does. They check the paths that experience says are worth checking, and they are usually right, and the ones they skip are the ones nobody finds until somebody does.

A model does not have to pick. It can walk every access point, every parameter, every field, in the boring order, without deciding that an obscure legacy endpoint is probably fine because it has not been touched in four years. It does not get tired on the four hundredth variation, it does not have a hunch that leads it away from the dull path, and it does not stop at five o'clock. Exhaustiveness is not a thing it has to be talented at. It is just what it does.

So this is not a contest your developers can win by being careful, and it is not fixed by hiring better reviewers. A sampling defense cannot cover an exhaustive attack. The only thing that covers every access point is something that checks every access point, which means the answer to an AI looking for a way into your software is an AI that got there first.

You Do Not Get Time to React

The usual answer to security risk is monitoring: watch for trouble and respond when it appears. That reasoning assumes an attack takes long enough to notice.

Cheap automation removes that assumption in two ways. Probing happens continuously rather than in a campaign someone launched at you specifically, so there is no distinctive spike to alert on. And when something is found, the gap between discovery and use is however long it takes to run the next command. There is no window in which you notice you are interesting, and then harden.

Which means hardening is not a response, it is a precondition. The state your software is in on the day it is probed is the state you get to defend with. Whatever you were planning to do afterwards does not enter into it.

The Defense Is the Same Tool, Pointed at Yourself

If an attacker can cheaply have a model study your application and look for the way in, so can you, and you have advantages they do not: your source code, your architecture, your knowledge of which data would actually hurt to lose, and no need to be quiet about it.

In practice this means adding a step that most projects do not have. Not a once-a-year audit, but a standing part of development: point capable models at the codebase and at the running system, deliberately trying to break in, and fix what comes back. Run it again when you ship something significant. The results need a developer to triage, because models report things that are theoretically true and practically irrelevant alongside things that genuinely matter, and telling those apart is a judgement call. But the finding itself is now cheap, and anything cheap enough to do to yourself is cheap enough for somebody to do to you.

The old checklist has not gone away either. Most of what these tools find is not exotic. It is unvalidated input, permissions that were never tightened after go-live, an admin page nobody remembered, credentials in a config file, an API that trusts a parameter it should not. Those have been on every security checklist for twenty years. What has changed is that there is no longer a shortage of people willing to look for them on your particular site.

A New Model Release Is a Security Event

This is the part that is easy to miss, and it is the reason a one-off audit does not settle the question. Your software does not have to change for its security to get worse. When a materially more capable model ships, everything already deployed becomes easier to break, and nobody has touched a line of it. The code that was fine last quarter is the same code. What changed is what can now be found in it.

So model releases are something to plan around rather than something to read about. When Fable 5 was released we went back over the projects we actively work on and fixed what it turned up. That is now simply part of our release cycle: we do not put out a release without it.

That is not us selling an add-on. It is that we are not willing to ship code we have reason to believe is breakable. Once a tool exists that will find the problem in an afternoon, choosing not to run it before release is a decision about who carries the risk, and we would rather not hand that to a customer who is trusting us to know better.

The honest gap is older code. We cannot audit a system nobody is paying us to touch, and plenty of software was built before this kind of testing existed at all. Those systems sit unexamined until somebody funds a look at them. What we can do is fold the audit into the work itself, so when you engage us to add features the security pass comes with it rather than appearing as a line item you can decline. If you have something running that nobody has looked at since it was written, that is the category worth worrying about, and it is worth asking us about even if the answer is just to tell you what we would check.

Almost nobody works this way. Security effort is usually triggered by a code change, a compliance deadline, or an incident. Very little of it is triggered by the tools getting better, even though that is now the most common reason a system's real exposure changes.

Where We Fit

We build software using AI for the implementation work, so pointing the same class of tool at security is an extension of how we already work rather than a service we bolted on.

Concretely: Claude Code does most of the implementation here, and we use Google Gemini as a second opinion on it. Part of that is mundane, in that our usage limits differ. The more useful part is that models from competing labs are built and trained differently, so they are wrong about different things. A model asked to review its own work tends to agree with itself, in much the way a developer re-reading their own code at midnight does. A rival model has no such attachment, and the places where the two disagree are a cheap and surprisingly reliable map of where to look harder. It is the same reason you would not have one person review everything.

There is a wrinkle worth knowing about if you are thinking of trying this yourself. Frontier models decline most of this work by default. Ask one to analyze how a vulnerability could actually be exploited, or to behave like an attacker against a running system, and it will refuse, because the same request from a different person is an attack. That restriction is the correct default, and it means the defensive version of the work is gated too.

We are approved under Anthropic's Cyber Verification Program, which vets organizations whose legitimate defensive work overlaps with those dual-use techniques. Verification lifts the dual-use restrictions for that work, so we can run genuine adversarial testing, exploitation analysis and red teaming against systems we build and maintain, rather than the sanitized version a general-purpose model will agree to. Prohibited uses stay blocked regardless of verification, which is as it should be, and we only do this against systems we are authorized to test.

It is built into how we work rather than sold separately: the audit is part of the project, it runs before a release goes out, and it runs again across everything we actively work on whenever a materially better model ships.

If you have an application carrying customer data, taking payments, or exposing an admin interface to the internet, and it has never been examined this way, that is worth an afternoon of somebody's attention. It is a cheaper conversation than the one that follows a breach. Get in touch and we will tell you what we find, whether or not you have us fix it.