AI as a research partner, not a replacement.

This is probably the most interesting look I have seen at what AI-assisted security research can actually become. James Kettle does not simply ask a model to find bugs: he breaks his own research process into ideation, evaluation, weaponization and cascading follow-up research, then looks carefully at which parts benefit from AI and which are better handled by deterministic code or a human researcher. One particularly interesting observation is that giving a model more context can actually make it less creative by anchoring it too strongly to known techniques. The resulting HTTP research is good, but the bigger lesson is the methodology for turning AI into a research partner rather than a vulnerability scanner. Can AI do novel security research?.

WorkOS shares the prompt and pipeline it uses to look for the sort of authorization and logic bugs that are difficult to find by chasing sources and sinks. The key idea is to model security as bindings between things that are supposed to stay connected, such as a credential, tenant, actor, resource, action and current state, then look for paths where one of those bindings disappears or comes from a different source of truth. I like this because it gives a much more concrete way to ask an LLM to reason about application security. The pipeline around the prompt may be even more interesting: repeated scans are cheap, human triage is expensive, so they spend a lot of effort validating findings and teaching the system from previous mistakes. A prompt that finds deep logic bugs, and the pipeline we built around it — WorkOS.

Most AI guardrails ultimately ask another probabilistic model whether something is allowed. CommBank explores a very different approach: use the LLM only to translate messy natural-language policies and facts into structured rules, then let a deterministic constraint solver decide whether the requested action can actually satisfy them. The result can be proved, refuted or left ambiguous rather than assigned a fuzzy confidence score. The most important part is that they are clear about where the uncertainty went: if the LLM translates the original policy incorrectly, the solver can still produce a perfect proof of the wrong rule. I like the architecture because it does not pretend the probabilistic component can disappear; it tries to make that component as small, explicit and reviewable as possible. AI Guardrails That Prove, Not Guess.

The team at elttam found six different ways to get code execution in Flowise, but the useful part is not the number of vulnerabilities. The article is a great example of what happens when fixes remove a payload without removing the underlying dangerous primitive. Sandbox restrictions, module allowlists, environment handling and file operations keep turning into new ways to reach execution. It is also a good example of AI fitting naturally into traditional vulnerability research: the researchers found that models were much more useful once a human had identified an interesting direction, helping explore variants and alternatives, than when asked to independently find the subtle bugs. That distinction between AI-driven and AI-assisted research is becoming increasingly important. Cruising for Shells in Flowise - elttam.

open·kritt is another AI vulnerability research tool, but the interesting part is the methodology its authors developed while actually using agents for bug bounty research. Instead of giving a model an entire repository and asking it to find vulnerabilities, they map entry points once and split the investigation into small, focused jobs where an agent can spend most of its context understanding one reachable flow. They also treat vulnerability discovery probabilistically, asking how often a workflow finds a known bug across many attempts rather than whether it happened to succeed once. I particularly like the idea of using missed vulnerabilities as training material for the harness itself: ask another model why the research workflow failed, modify the workflow, and try again. This starts to look less like an AI scanner and more like an experimental framework for improving security research. GitHub - Kritt-ai/open-kritt: Open-source, self-hosted AI vulnerability research tool that orchestrates agents to find and validate security issues in code. · GitHub.

This starts with a constrained PHP execution primitive and progressively turns it into native code execution and eventually root, with plenty of interesting exploit engineering along the way. What makes it especially relevant now is how heavily Codex was used to accelerate parts of that process. The authors argue that work which previously might have taken a skilled exploit developer weeks could now be compressed dramatically, but that does not remove the need for expertise: someone still needs to know which primitive should be possible next and what direction to push the model in. That raises an interesting longer-term problem. If AI increasingly performs the mechanical part of exploit development, how do new researchers acquire the experience and intuition required to direct it? The WordPress Chain Massacre - Calif.