From finding to exploit: the new automated exploit loop

Detection is no longer the end of the workflow

KASS is a useful security paper because it asks for a stronger result than a vulnerability label. The framework retrieves relevant audit knowledge, builds an attack plan, generates a Foundry proof of concept and executes it. If the code fails, it can repair the implementation; if the assumptions fail, it can replan the strategy.

The authors report successful executable exploits for 98 of 104 SmartBugs-Curated contracts and validation of nine of 11 CVE-tagged contracts. Those are paper-reported evaluation results, not evidence that 94.23 percent of contracts in the wild are exploitable by an agent.

The important capability is the loop. A finding is translated into a concrete hypothesis, code is generated, execution provides feedback and the system keeps working until the test either reaches the expected state change or the strategy has to change.

The same loop now appears in threat reporting

Anthropic's GTG-10007 case describes a very different environment and intent, but the workflow has a recognizable shape. The actor reportedly acquired and unpacked firmware, used parallel agents to search components for vulnerability patterns, generated exploit code and tested it against lab copies of the target product. Successful chains were retained in a private exploit portfolio.

Anthropic says one continuously iterating appliance workflow produced more than a dozen possible zero-day findings in a month. It also reports a persistent reconnaissance system and 13 standing collection agents running on a schedule.

KASS and GTG-10007 should not be collapsed into one category. One is published defensive research evaluated on controlled contracts. The other is a threat-intelligence account of an espionage operation. Their similarity is useful precisely because the intent and governance are different while the automation pattern is comparable.

Exploit generation is not exploitability proof unless execution is controlled

A generated proof of concept is evidence only when the environment is defined. For smart contracts, that means the exact bytecode, chain state, balances, privileges and fork or local test setup. For firmware, it means the exact build, configuration and lab target. Without that context, a successful-looking script can be little more than plausible text.

KASS tries to bind the plan to execution constraints and uses the state-changing test as the verifier. That is the part worth carrying into assessment work. A future DiggingBeagle assessment should be able to distinguish:

• a detector that reports a weakness;
• a model that proposes an exploit;
• code that compiles;
• code that executes;
• a controlled test that reaches the claimed security-relevant state change.

Those are separate proof levels.

Comparative numbers need discipline

The KASS paper reports 94.23 percent success on its 104-contract SmartBugs-Curated set. It also reports higher performance than a reproduced Claude Code baseline under the authors' protocol. Some comparisons to other systems use previously reported results because implementations were unavailable.

That caveat should stay visible. A benchmark can be useful without pretending every percentage came from the same harness, model version, prompt budget and evaluation rule.

The same caution applies to threat reports. "More than a dozen possible zero-days" is not the same as a dozen vendor-confirmed CVEs. It is evidence of a productive exploit-research workflow, not a substitute for disclosure and independent validation.

What changes for defenders

The practical change is that exploit research can become persistent and parallel. A human analyst no longer has to manually carry every hypothesis from static analysis to code to execution. That can improve defensive validation, but it also reduces the labor cost of offensive research.

The control surface therefore moves earlier in the pipeline. Organizations operating powerful exploit-generation systems need target allowlists, disposable execution environments, artifact provenance, rate and scope controls, and audit logs that distinguish generated hypotheses from validated exploits.

For software vendors, the response cannot be "AI found this" or "AI did not find this". The useful evidence remains the same: exact affected version, reproduction steps, state change, preconditions, remediation and independent confirmation.

That is where KASS is more interesting than another headline about AI hacking. It shows how exploitability itself can become a structured, repeatable output.