Notifications
Clear all
Topic starter
02/08/2026 9:46 am
TL;DR: Open-source AI security projects fall into three harness families, LLM-led exploit generation, LLM-skill-boosting, and SAST plus LLM hybrids, with different tradeoffs in validation, execution, and patch generation, according to Semgrep. The key shift is that vulnerability discovery is becoming more agentic, but trustworthy findings still depend on adversarial verification and tight scope control.
NHIMG editorial — based on content published by Semgrep: LLM security harnesses and the new wave of open-source code vulnerability tools
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%).
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
Questions worth separating out
Q: How should security teams govern AI-assisted vulnerability research tools?
A: Teams should treat AI-assisted vulnerability research tools as privileged systems with explicit scope, sandboxing, and review boundaries.
Q: Why do LLM-based code analysis tools need adversarial validation?
A: Because LLM output is probabilistic, not authoritative.
Q: What breaks when AI coding agents are allowed to ship code without security constraints?
A: Teams get working software that can still carry old, well-known vulnerabilities back into production.
Practitioner guidance
- Define trust tiers for AI security harnesses Classify each harness by whether it can only read code, can propose fixes, or can execute binaries and fuzz targets.
- Separate discovery from acceptance Require a second validation step before any AI-generated finding becomes actionable, whether that is a human reviewer, an independent model, or a deterministic check.
- Constrain code execution and secret exposure Run execution-capable harnesses in sandboxed build environments with no standing access to production secrets, signing keys, or live credentials.
What's in the full article
Semgrep’s full article covers the operational detail this post intentionally leaves for the source:
- Comparative notes on specific open-source harnesses, including their scope, model dependencies, and maintenance status.
- Tool-by-tool distinctions between exploit-generation pipelines, skill-boosting workflows, and SAST plus LLM hybrids.
- Implementation characteristics such as whether a harness can execute code, generate patches, or remain fully local.
- The authors’ own categorisation of when each tool makes sense in a real vulnerability research workflow.
👉 Read Semgrep’s analysis of open-source LLM security harnesses and code vulnerability workflows →
LLM security harnesses: which approach fits vulnerability research best?
Explore further
02/08/2026 12:38 pm
LLM-assisted vulnerability research is becoming an identity-governed workflow, not just a tooling choice. Once a model can search code, reason over context, and propose fixes, the real control question becomes who or what is trusted to act inside the research loop. That creates a governance boundary around repositories, execution permissions, model access, and review authority. The practitioner conclusion is that agentic tooling must inherit the same entitlement discipline as any other high-trust system.
A question worth separating out:
Q: How do organisations decide between static triage and agentic exploit research?
A: Use static triage when you need breadth, repeatability, and low operational risk. Use agentic exploit research when the target class is narrow, the environment is well controlled, and you need higher-confidence exploitability evidence or verified fixes. The decision should be driven by workflow risk, not by the novelty of the model.
👉 Read our full editorial: LLM security harnesses are splitting into three distinct categories
