Introducing Sherlock AI V3.0

Sherlock AI V3.0 changes how runs are generated, validated, and delivered.

Recent upgrades focused on making runs steadier, improving the day-to-day development workflow, and expanding the product’s usefulness across more real engineering environments. V3.0 builds on that progress, but it is a bigger step forward than the releases before it. This is a rebuild of the run system itself.

We made this upgrade by looking closely at run performance, how findings were holding up under review, where users were getting stuck in triage, and what made the product feel slower or noisier than it should. The direction was clear: improve trust in the issue list, reduce repeated detections, make writeups more review-ready, and help engineers move from opening an issue to fixing it with less friction.

V3.0 is built around those goals.

What changed in V3.0

Verified findings before they reach your dashboard

V3.0 introduces a two-stage run architecture: discovery followed by verification.

Discovery generates candidate issues across the codebase. Verification then re-checks each candidate individually, walking the trigger conditions, tracing the logic, and confirming whether the described path can actually occur in your codebase. Each verified finding now includes a confidence score, verification reasoning, and the assumptions it depends on.

Candidates that do not hold up under verification are filtered out before they land in the issue list. The result is a tighter output and less time spent sorting through weak candidates.

Stronger discovery through Sherlock’s synthesis pipeline

One of the biggest shifts in V3.0 is the way runs are guided during discovery.

V3.0 uses Sherlock’s proprietary synthesis pipeline to generate stronger domain-specific analysis playbooks. That pipeline draws on past audit data, codebase context, and findings to synthesize better long-form security analysis inputs for the system under review. It also uses synthetic data creation techniques to improve how Sherlock AI reasons about different code domains and vulnerability patterns.

In practice, that means V3.0 can approach different systems with more context and better framing from the start. Instead of relying on one generic analysis path, it uses multiple synthetic, security-focused playbooks to examine the codebase from different angles before those outputs are reconciled through verification and deduplication.

This is a major part of why V3.0 performs differently. The run system is no longer just broader. It is more deliberate in how it explores a codebase and more selective in what it keeps.

Duplicate findings are grouped automatically

Multiple analysis passes improve coverage, but they should not create a bloated issue list.

When V3.0 surfaces the same underlying issue from different angles, it now groups those detections into a single primary finding with supporting variants attached. That keeps the review flow centered on distinct issues while preserving alternate perspectives when they are useful for reproduction or validation.

More consistent, review-ready writeups

V3.0 standardizes how findings are structured from initial detection through verification and final output.

Each finding now follows the same basic logic: what the issue is, where it lives in the codebase, why it happens, how it triggers, what must be true for it to hold, and what the impact is.

That consistency makes triage faster, improves internal handoff, and makes reruns easier to compare when teams are validating fixes.

Issue Chat inside every finding

V3.0 introduces Issue Chat directly inside each issue.

Once an engineer opens a finding, they can ask questions in context and get immediate help understanding the attack path, the root cause, and the likely next steps. The goal here is simple: reduce back-and-forth during triage and shorten the time between “I opened the issue” and “I know how to fix it.”

Runs are easier to follow while they are happening

We also cleaned up run visibility and degraded-run handling.

V3.0 makes progress easier to follow while analysis is in motion, and it handles partial failures more clearly. If one analysis path fails, the system retries and completes with the remaining successful paths, then marks the run as degraded with a percentage instead of failing without context.

That gives users a much clearer view of what actually completed and avoids dead-end review cycles caused by ambiguous run status.

Additional updates in V3.0

V3.0 also improves assumption handling across the product.

Assumptions can now be managed at the repository level, surfaced during run scheduling when review is needed, and viewed after a run completes so users can see which assumptions were confirmed at analysis time. Findings that do not hold because an assumption was invalidated are now tagged clearly, along with the reason tied to that invalidation.

These changes make runs easier to interpret and make assumption-dependent findings easier to trust.

What to expect after upgrading

After moving to V3.0, teams should see a tighter issue list, higher-confidence findings, fewer repeats, more consistent writeups, faster issue interpretation, and clearer run behavior during and after analysis.

The broader direction has not changed. Sherlock AI is still built to help teams catch issues while code is actively being developed. What has changed in V3.0 is the quality of the run itself: stronger discovery, stronger validation, and a cleaner path from detection to action.

Sherlock AI V3.0 is live now for all active customers. No changes to repository connection or onboarding are required.