The difficult part of using an LLM in security work is deciding what to trust. A response can be fluent, specific, and wrong. A report can include a real quotation from an application and still reach a conclusion that the quotation does not support.
The Autonomous Offensive LLM Handbook is about that gap. Its central argument is simple: give the model room to propose, but make the surrounding application responsible for the boundaries and the record.
A citation is not a verdict
A captured response tells you what was observed. A matching quotation tells you that a statement really appears in that response. Neither automatically establishes the security claim attached to it.
An HTTP success status, for example, says little about whether a protected resource was exposed. The response could be a login screen, an application shell, or an error rendered with a successful status. Accepting the security conclusion requires evidence appropriate to that conclusion.
Evidence that a sentence exists is different from evidence that a finding is true.
This distinction matters because checking quotation accuracy is useful and comparatively narrow. Asking that check to decide exploitability gives it authority it has not earned.
Put responsibility in the application
The handbook separates the model's proposals from the application's control decisions. Authorization, allowed actions, evidence records, and acceptance rules should be explicit and reviewable. They should not depend only on an instruction buried in a prompt.
The same principle applies to severity. A system should have a reason for changing a finding's rating, and that reason should survive inspection. Reducing severity is not automatically correct either: an overly broad rule can suppress a real issue. Both positive examples and counterexamples matter.
Human review remains part of the process. A mechanical rule can establish a narrow property of a record without making every interpretation of that record correct.
Start with the offline lab
The repository's recommended starting point is its offline harness lab. It uses frozen inputs and a synthetic proof rule. It makes no network requests and calls no model. That makes it possible to inspect the controls without confusing a repeatable fixture with a repeatable live assessment.
The lab also makes its trust assumptions visible. Its host and adapters are trusted; every finding still requires human review. It is a control reference, not a finished acceptance or report-signing workflow.
For readers, the useful question is whether a decision can be traced from input through rule to outcome, including the reason work was refused, skipped, or left unresolved.
Read the failures as carefully as the design
The repository also preserves a historical implementation and a failure museum. Those materials explain why the controls became necessary. They are not interchangeable with the newer harness, and the new lab does not retroactively fix the historical system.
The published evaluation has limits too. The repository describes historical aggregate results, but does not publish the raw findings, ground truth, and matching procedure needed to independently reproduce that comparison. Broader benchmarking remains work in progress. The architecture is a design argument, not proof of superiority over other tools.
That boundary is part of the project: make the record inspectable, admit what it does not prove, and leave uncertainty visible.
Read the project
Start with the repository overview, then the offline harness lab. The failure museum provides the context behind the design.