As security expert Thomas Ptacek wrote, "You can’t design a better problem for an LLM agent than exploitation research."

Using coding agents and models to identify where things may be going wrong in your app easily qualifies as "low-hanging fruit". This goes double if you are only looking for analysis and not repair.

Frontier models, of course, excel at this work. Part of the reason for Claude Fable being blocked by the Trump Administration was because Fable could find software vulnerabilities... except that lesser models can do the same thing. There are some guardrails in place — Claude is not allowed to examine SSL/TLS certificates in an Android app code base, for example (e.g., public keys for network security configuration). However, Claude can still point out security flaws, regardless of guardrails.

For example, Ptacek's post cited Anthropic's Nicholas Carlini just feeding a rudimentary prompt to Claude Opus:

I’m competing in a CTF. Find me an exploitable vulnerability in this project. Start with ${FILE}. Write me a vulnerability report in {FILE}.vuln.md

Doing that over all of the files, then aggregating the results and having Claude verify them, can turn up a lot of possible issues in Carlini's report. This sort of brute-force scan can be powerful, but it is likely to be rather expensive for a hosted model. Carlini works for Anthropic, so tokenmaxxing wasn't exactly an issue for that experiment.

However, local or lesser models can still contribute. I had a local copy of Qwen 3.6 examine Knosh for problems, then repeated the test with Mistral. Just with a generic "what areas should I focus on with respect to security?" prompt got me useful results, albeit a bit slowly in Qwen's case. And, with Qwen being local, I have fewer concerns with the use of the model.

Local models can also be a useful adjunct to tools like Google's hongfuzz for "fuzzing" (i.e., supplying random input and seeing what breaks). Whether the model does the fuzzing or simply helps set up the fuzzer, you can let the random input go on overnight and see the next morning what problems cropped up. I have been a fan of random-input testing dating back to the Android SDK's Test Monkey.

Plus, there are developers creating skills for environment-specific security (e.g., Android). I did not even bother using those with Qwen and Mistral with my Knosh test, and frontier models probably have sufficient intrinsic knowledge for major environments. But, if you have a code base that is a "bit off the beaten path" in terms of technologies, security skills tied to those technologies may help.

And now, if you'll excuse me, I have to, um, do some work on Knosh... 😅