Stage 2 loses ~30% of candidates to provider moderation refusals, with no aggregate reporting

[NahumKorda]

Summary

Stage 2 verification returned a verdict for fewer than a third of the candidates it was given. The rest were refused by the inference provider's moderation layer or recorded as needing manual review. Stage 2 consumed roughly three-quarters of total run cost while adjudicating 29% of its input, and no aggregate coverage figure is surfaced anywhere in the console output or the summary report.

Evidence

Refusal rate by phase — same route (OpenRouter) and same model (Claude Opus 5) in both cases, single run:

Phase	Units	Refused	Rate
Stage 1 detection	1,349	2	0.15%
Stage 2 verification	467	139	29.8%

Of 467 Stage 1 candidates, Stage 2 produced a verdict for 135 (82 upheld, 53 disagreed, 1 overturned); 139 errored and 192 were flagged as needing manual review — 331 unadjudicated.

The Stage 2 rate was stable across the phase, sampled every 50 candidates: 32.0%, 33.7%, 33.3%, 31.3%, 33.0%, 30.8%, 30.7%. It is a property of the phase, not a transient. Refusals arrive from OpenRouter as finish_reason='content_filter' and are correctly mapped to a typed refusal error by the adapter. Note both phases used the same model and route, so the difference is attributable to prompt content rather than to model or provider choice.

The asymmetry has a plausible mechanism: Stage 1 asks the model to classify code, whereas Stage 2 asks it to construct a working exploit — which is what content moderation exists to block. One trivial utility function was refused deterministically on three separate occasions across two runs, so specific inputs reliably trip it rather than it being random sampling.

Why it matters

This is the finding I would prioritise, because it undercuts the core value proposition rather than a peripheral feature. "What survives is real" becomes "what survives is real, and roughly a third was never tested" — and a user has to read the JSON to discover which. verify.report.json exposes error_count but nothing frames it as a coverage percentage, and the console summary omits it entirely.

Suggested fix

1. Report Stage 2 coverage as a headline figure — e.g. "328/467 adjudicated (70%); 139 refused by provider moderation." This is cheap and would have changed how we read our own results.
2. Retry a refused unit once on a configured fallback binding. Moderation behaviour differs between routes and vendors, so a second attempt elsewhere often succeeds.
3. Document the route sensitivity. Per-phase provider binding already makes this fixable without code changes — pointing verify at the Anthropic API directly rather than through OpenRouter is the obvious mitigation — but nothing tells a user that the choice materially affects verification coverage.

---

Observed on one full-pipeline run at production scale: a private TypeScript monorepo (Angular front end, NestJS back end), 1,351 analysis units from 866 source files, run with --verify and no --limit, ~6.5 hours wall clock. The engine was invoked directly (python -m openant scan …, Python 3.13); the Go CLI was not built, so none of this involves the Go↔Python envelope. Stage 1 detection and Stage 2 verification ran on Claude Opus 5; application context, enhancement and reporting on Claude Sonnet 5 — all seven phases routed through OpenRouter (anthropic/claude-opus-5, anthropic/claude-sonnet-5) via a locally-added openrouter provider adapter, on a build based on upstream 2ed78f6. Cost figures are expressed as proportions of the run total; absolute amounts are omitted deliberately, as is the identity of the scanned repository.

[NahumKorda]

Correction: I mis-attributed the refusals, and the mitigation I proposed is wrong

Following up on my own report with a correction, plus new evidence that makes the underlying problem look considerably more serious than I first described.

What I got wrong

I described the refusals as coming from the inference gateway's moderation layer, and suggested that routing verify directly at the model vendor instead of through OpenRouter would avoid them. That recommendation is wrong — please don't act on it. The gateway filters nothing here, and routing around it changes nothing.

I inspected the raw gateway response. OpenRouter normalises the upstream stop reason into the OpenAI-shaped finish_reason, but preserves the original in native_finish_reason:

Model	finish_reason	native_finish_reason	Outcome
Claude Opus 5	content_filter	refusal	blocked, no usable content returned
Claude Opus 4.8	length	max_tokens	answered normally
Claude Sonnet 4.6	length	max_tokens	answered normally

The Opus 5 response also carries a populated message.refusal stating that the request "triggered restrictions on violative cyber content and was blocked under Anthropic's Usage Policy."

So this is Claude Opus 5's own safety classifier, not gateway moderation. Opus 5 ships with elevated cybersecurity safeguards, and a Stage 2 prompt asking a model to construct a working exploit sits squarely inside their scope. Two sibling models handled the identical prompt without refusing. The correct mitigation is to change the model bound to verify, not the route.

(Incidentally: OpenRouter routed the Opus 5 request to Amazon Bedrock and the 4.8/4.6 requests to Anthropic. Upstream provider selection is dynamic, which is worth knowing when reasoning about where a refusal originated.)

New evidence: the refusals were selective for true positives

I re-ran the refused candidates with verify bound to anthropic/claude-opus-4.8, leaving every other phase unchanged. Same repository, same Stage 1 candidates, same prompts.

	Result
Candidates refused by Opus 5	136
Refused by Opus 4.8	0
Confirmed vulnerable	121 (89%)
Downgraded to protected	14
Downgraded to safe	1
Wall-clock for the re-run	23m 25s

For comparison, in the set Opus 5 did adjudicate, 25% of candidates were upheld (82 of 328).

So the refusals were not randomly distributed across the candidate pool — they were concentrated on the genuinely exploitable code. That follows intuitively: the more real a vulnerability is, the more a verification prompt about it resembles actual exploit development, and the more reliably it trips a cyber classifier.

The practical consequence for that scan: confirmed findings went from 82 to 206 purely by re-verifying on a different model. Roughly 120 real vulnerabilities had been sitting in an "unverified" bucket that reads to a user like uncertainty rather than suppression.

The refusals are deterministic, which makes them recoverable

Worth noting for anyone implementing a retry: these are not transient. One trivial utility function was refused on three separate occasions across two runs, and the same 136 candidates were refused consistently. Conversely, Opus 4.8 refused none of the 136. So the outcome depends on the model and the content, not on chance — a retry on a different binding is highly likely to succeed rather than hit the same wall.

A second, smaller coverage leak

Separately, 3 candidates in the same run failed with malformed-response errors (2 × JSONDecodeError, 1 × LLMResponseError) rather than refusals. Those are never retried either. When I re-ran them, all 3 were confirmed vulnerable. Small in number, but the same shape of problem: a transport-level failure silently becomes a permanent gap in verification coverage.

An additional defect this exposed

The adapter receives native_finish_reason and message.refusal in the response and discards both, reporting only that the completion was "withheld or truncated by the moderation layer." That message is what led me to the wrong conclusion, and I would have reached the right one immediately if it had surfaced what the provider actually returned. Reporting "blocked by the model's safety policy (violative cyber content)" points a user at changing the model; "withheld by the moderation layer" points them at changing the route.

Revised suggestions, in priority order

1. Retry a refused candidate once on a configured fallback model. This is now the highest-value fix rather than a nice-to-have: the recovered findings are disproportionately real (89% upheld, against 25% in the set that was adjudicated first time), and because refusals are deterministic per model, a fallback binding recovers them reliably.
2. Surface the real refusal reason by reading native_finish_reason and message.refusal instead of reporting a generic moderation message.
3. Report Stage 2 coverage as a headline figure, e.g. "328/467 adjudicated (70%); 139 not adjudicated." Unchanged from the original report, and still the simplest improvement to make.
4. Document the verification-model choice, noting that a model with elevated cyber safeguards will refuse a large share of Stage 2 prompts. Per-phase provider binding already makes this a config change rather than a code change.
5. Retry malformed responses, so a parse failure does not become a permanent coverage gap.

Happy to supply the raw response payloads or the per-candidate verdict diff if useful.

Note on the title: it currently attributes the refusals to provider moderation. Something like "Stage 2 loses ~30% of candidates to model safety refusals, and the recovered findings are disproportionately real" would reflect what is actually happening.