Source-linked AI summary

Calibrated Decision Models for Autonomous Penetration-Testing Harnesses: JEV and Laya as System One Decision Layers for LLM-Driven Pentest Agents

Joas Antonio dos Santos Barbosa

arXiv:2609.28940v1cs.CRcs.AIcs.SE

TL;DR

Autonomous pentest harnesses rely on LLMs both to generate findings and to judge evidence, creating a gap in calibrated decisions. This paper formalizes four System One decision points and presents an exploratory NeuroSploit comparison; its single-run observations motivate the design but do not establish statistical significance.

  • Problem

    Pentest harnesses use LLM judgments for decisions about findings and severity, while the paper identifies calibration collapse, class-driven severity, and compute waste as resulting risks.

    Source: §I · p. 1
  • Method

    The paper formalizes four System One decision points and integrates typed, calibrated verdicts into NeuroSploit alongside deterministic validation.

    Source: §XVIII · p. 20
  • Results

    Coverage was comparable: Run A hit 10 of 13 scenarios, Run B hit 9 of 13, and combined coverage reached 11 of 13.

    Source: B. Coverage results · p. 10
  • Takeaways & Limitations

    The authors present the integration as an architectural proposal supported by a preliminary case study, not as established comparative evidence.

    Source: A. Setup and limitations · p. 10, §XVIII · p. 20

    The case study used one run per condition against one target, so its runtime and severity differences are not statistically powered evidence.

    Source: A. Setup and limitations · p. 10

Abstract

from arXiv · show

Autonomous penetration-testing harnesses use large language models (LLMs) for reconnaissance, exploitation, and reporting, but often rely on those same models to confirm findings, grade severity, and select agents. This can lead to false positives, inflated severity, and wasted compute. We examine how System One decision models, lightweight non-generative classifiers that return typed, calibrated verdicts, can support these decisions. We make five contributions. First, we define four decision points: finding adjudication, severity recalibration, agent pruning, and confirmation loops. Second, we present an exploratory NeuroSploit case study comparing one run with TypeSafe System One (Jev) and one without it against a web target containing 13 vulnerabilities. Differences in severity distribution, runtime, and grading by exposed data type motivate the architecture but do not establish statistical significance. Third, we review published specifications for Jev, Jev-Ultrafast, and the open-source Laya without assuming that results from other benchmarks transfer to penetration testing. Fourth, we discuss RLHF, RLAIF, RLCD, and RLHV as training approaches and their implications for trust in security decisions. Finally, we propose Rave, a domain-adapted System One model, and outline its training data, evaluation protocol, and potential effect on harness assurance.

I. INTRODUCTION

The paper frames trustworthy autonomous pentesting as an assurance problem: harnesses must turn evidence into reliable decisions, not only demonstrate capability. It proposes calibrated System One classifiers for those decisions and reviews their architecture and training paradigms.

I. INTRODUCTION

  • The paper targets a decision bottleneck in which LLMs that generate exploit narratives also judge findings, severity, and agent relevance, risking calibration collapse, class-driven severity, and wasted compute.The proposed alternative is a non-autoregressive classifier that evaluates typed questions against a state and returns structured, calibrated verdicts.Source: §I · pp. 1–2
  • System One models are non-autoregressive classifiers that answer typed questions with structured, probabilistically calibrated verdicts, unlike slow, deliberative LLM reasoning.The paper positions these models at four decision points: finding adjudication, severity computation, agent selection, and confirmation loops.Source: §I · pp. 1–2

A. Autonomous penetration-testing harnesses

  • Harness assurance concerns whether findings are grounded, scope is enforced, and audits are possible; capability and assurance are distinct dimensions.Prior work describes harness architecture as consequential even when the underlying model is unchanged, [19].Source: §I · p. 1, A. Autonomous penetration-testing… · p. 2

B. Reinforcement learning paradigms for calibrated models

  • RLHF can reward confident-sounding severity labels, while RLAIF can inherit and amplify an AI labeler’s calibration failures, [22].The paper contrasts these risks with RLCD’s use of strictly proper scoring rules,, and describes RLHV as using deterministic validator outcomes as verification signals.Source: B. Reinforcement learning paradigms… · pp. 2–3
  • RLHV couples decision-model training to per-CWE validator verdicts, and the paper proposes that engagement-generated prediction-verdict pairs can train later model iterations.The stated alignment rationale is that the Brier score’s unique minimum is the true conditional probability.Source: B. Reinforcement learning paradigms… · p. 3

III. SYSTEM ONE MODELS: ARCHITECTURE AND PRIMITIVES

  • Jev requests take 236–276 ms at the 50th percentile, while Laya requests take 32.8–39.5 ms on a T4 GPU,.The paper links bounded latency to real-time decision loops.Source: §III · p. 3
  • System One outputs are constrained to declared types—Choice, Score, or Noul—so they cannot invent categories or produce malformed output.The paper says this design removes a class of parsing errors and downstream failures.Source: §III · p. 3
  • Questions in a single request share state but are evaluated independently, preventing one answer from conditioning another architecturally.The paper connects this isolation to avoiding answer cascades in multi-step reasoning.Source: §III · p. 3

A. The Choice primitive

The section distinguishes three typed primitives for calibrated decisions: Choice selects among alternatives, Score represents ordered levels, and Noul screens a binary condition.

A. The Choice primitive

  • Choice returns a probability distribution over a defined set of options, letting the harness route uncertain findings to human review rather than relying only on a selected label.Its applications include finding adjudication, payload selection, exploitation strategy, and report classification.Source: A. The Choice primitive · p. 3

B. The Score primitive

  • Score returns a probability-weighted value and distribution over ordered levels, making it suitable for severity and data-type grading.For CVSS-informed impact grading, the paper uses the ladder none < reached < read < wrote < RCE < crossed.Source: B. The Score primitive · p. 4

C. The Noul primitive

  • A batch of 15 Noul questions costs approximately 12× less and runs 10× faster than 15 individual requests.Noul returns one probability for a binary condition, and batching makes it practical to evaluate every candidate agent in one API call.Source: C. The Noul primitive · p. 4

D. Batching and question independence

NeuroSploit integrates System One decisions into an evidence-grounded pentest pipeline while retaining deterministic validators and authorization controls. Batched, independent questions support the four decision points without allowing the System One layer to override validator rejection.

D. Batching and question independence

  • A single request can evaluate mixed question types independently against shared state, enabling speculative answers that the harness uses or discards after the response.The example combines verdict, impact, data-type, and CWE-match questions in one API call.Source: D. Batching and question independence · p. 4

IV. NEUROSPLOIT HARNESS ARCHITECTURE

  • NeuroSploit is a Rust, multi-model autonomous pentest harness designed around evidence grounding and auditability [1],.Its pipeline includes reconnaissance, surface-based agent selection, parallel execution, verification, attack-path chaining, and evidence-graded reporting.Source: §IV · p. 4, A. Pipeline stages · pp. 4–5

A. Pipeline stages

  • Reconnaissance represents uncertain target properties in a probability-annotated graph and favors observation over exploitation while observation value exceeds exploit value.The graph updates beliefs from observations, and diffuse beliefs bar asserting exploitability.Source: A. Pipeline stages · p. 4

B. Cross-cutting mechanisms

  • NeuroSploit gates actions with a signed authorization token that cannot widen scope, and records actions and decisions in a hash-chained audit log.External anchoring is described as protection against rewriting the full chain.Source: B. Cross-cutting mechanisms · p. 5

C. The decision bottleneck

  • The verification bottleneck arose because adversarial voting and evidence prosecution relied on LLM-generated judgments, leading to self-agreement, class-driven severity, and compute waste.The System One integration targets those verification steps.Source: C. The decision bottleneck · p. 5

V. SYSTEM ONE INTEGRATION ARCHITECTURE

  • The additive System One layer may lower confidence, flag review, or prune agents, but cannot override deterministic rejection or restore claims that failed grounding.The paper describes the worst case as equivalent to running without the layer.Source: §V · p. 5

A. DP1: Finding adjudication

  • DP1 evaluates evidence for confirmation, review, or rejection and separately assesses demonstrated impact, with both questions sharing one API call.Configurable probability thresholds route findings onward, to human review, or to withholding.Source: A. DP1: Finding adjudication · p. 5

B. DP2: Severity recalibration

  • DP2 recalculates impact metrics without unsupported receipts when estimated impact is low, while a data-type Score distinguishes none, common, sensitive, and secrets.The credential-aware check is intended to preserve severity when credentials appear in evidence outside a structured field.Source: B. DP2: Severity recalibration · p. 5

D. DP4: Confirmation loop

DP4 uses alternating System One decisions to select payloads and judge their effects for enumerable vulnerability classes. The implementation examples illustrate typed responses and threshold-based branching rather than free-text parsing.

D. DP4: Confirmation loop

  • For enumerable vulnerability classes, DP4 alternates a Choice payload selector with a Noul effect judge until confirmation or payload exhaustion.Each iteration takes 236–276 ms for Jev or 33–40 ms for Laya, allowing 10–30 payload evaluations in the time of one LLM call.Source: D. DP4: Confirmation loop · p. 6

E. Implementation examples

  • The implementation examples show callers defining typed question schemas and branching on returned calibrated probabilities rather than parsing generated text.The examples cover finding adjudication and agent pruning.Source: E. Implementation examples · p. 6

VI. DECISION-THEORETIC FOUNDATIONS

The section frames harness decisions as expected-loss problems and explains how calibrated probabilities support decisions across adjudication, reconnaissance, agent selection, and confirmation.

A. The finding adjudication decision as a classification under loss

  • Finding adjudication minimizes expected loss across asserting, reviewing, or discarding, with costs for false positives, false negatives, and human review.Calibrated posterior probabilities make cost-based thresholds actionable; uncalibrated probabilities can produce suboptimal decisions.Source: A. The finding adjudication decision… · p. 7

B. Value of information in reconnaissance

  • Reconnaissance should continue while the expected value of another observation exceeds its cost, using calibrated vulnerability-class priors to guide allocation.The section illustrates that a low SQLi plausibility prior can lower the value of further SQLi reconnaissance.Source: B. Value of information in… · p. 7

C. Agent selection as a multi-armed bandit

  • Agent selection can be treated as a contextual multi-armed bandit, with calibrated relevance probabilities serving as priors for agents’ expected rewards.The described pruning policy drops arms below a threshold, while proportional budget allocation can preserve exploration when discovery is prioritized.Source: C. Agent selection as a multi-armed… · p. 7

D. Sequential confirmation as optimal stopping

  • Confirmation is an optimal-stopping problem: accept or reject when the posterior crosses a loss-based threshold, or choose another payload between thresholds.Sequential probability ratio testing can accumulate evidence across payloads, which requires probabilities rather than binary verdicts.Source: D. Sequential confirmation as optimal… · pp. 7–8

VII. LATENCY AND SPEED ANALYSIS

The section argues that low, predictable decision latency can change the feasible pace of pentest workflows. It also discusses how calibration affects severity decisions and cautions against transferring calibration results across unrelated benchmarks.

A. Decision latency budget

  • A 15-agent relevance evaluation takes 22–45 seconds with sequential LLM calls, versus 276 ms for batched Jev and 72 ms for batched Laya.The cited latency sources cover different tasks and hardware, so the direct comparison is informational rather than a controlled benchmark.Source: A. Decision latency budget · p. 8, Table III · p. 8

B. Confirmation loop throughput

  • For 50 XSS payloads, decision time falls from 100 seconds at 2 seconds per LLM decision to 1.65 seconds at 33 ms per Laya decision.The section proposes exhaustive candidate testing with calibrated probabilities to prioritize payloads without excluding them, yielding higher recall at lower reasoning cost.Source: B. Confirmation loop throughput · p. 8

C. Real-time browser exploitation

  • Jev-Ultrafast’s published browser benchmarks report 90% fewer browser calls and 25% faster execution, while the paper maps structured browser decisions to exploitation workflows.The cited Google Flights task completed in 7.1 seconds; the security workflow discussion is an architectural application, not a reported pentest result.Source: C. Real-time browser exploitation · p. 8

D. Latency-sensitive offensive scenarios

  • The latency discussion identifies race-condition testing, short-lived tokens, blind-injection timing, and real-time protocols as scenarios where rapid decisions may matter.The passages distinguish scenarios where milliseconds or sub-second evaluation matters from typical 15–30-minute session timeouts.Source: D. Latency-sensitive offensive scenarios · pp. 8–9

A. Why calibration matters for severity grading

  • Calibration means stated confidence should match empirical accuracy; uncalibrated severity labels can overgrade unsupported impact or undergrade evidence of sensitive-data exposure.The section describes combining a calibrated data-type probability with a CVSS calculator to reflect demonstrated evidence.Source: §VIII · p. 9, A. Why calibration matters for… · p. 9

B. Measuring calibration: ECE and Brier score

  • Published ECE values are 0.081 for Laya after temperature scaling and 0.246 for Jev, but they come from different tasks and datasets and are not directly comparable.Whether those calibration results transfer to offensive-security decisions remains open and requires paired evaluation on the same task.Source: B. Measuring calibration: ECE and… · p. 9

C. Calibration and threshold-based automation

The section relates calibration to threshold-based automation, then reports exploratory harness runs and a separate post-fix re-test. It emphasizes that the single-run comparisons do not establish causal effects or statistical significance.

C. Calibration and threshold-based automation

  • The automation rate is the fraction of decisions processed without human review, and its achievable level depends on calibration measured for the pentest task.The section identifies labeled evidence-verdict pairs from real engagements as a prerequisite for establishing pentest-adjudication ECE before production deployment.Source: C. Calibration and threshold-based… · p. 9

D. Temperature scaling for domain adaptation

  • Jev and Laya support temperature scaling, and the section recommends fitting calibration on domain-specific validation pairs, potentially with separate temperatures by question type.The proposed validation data comprise evidence-verdict pairs; question types include Choice, Score, and Noul.Source: D. Temperature scaling for domain… · p. 9

E. Hypothetical example: how calibration quality affects threshold-based automation

  • The hypothetical example says a poorly calibrated model’s 0.8 threshold can yield 55%–100% empirical frequency, so reliable thresholds require domain-specific recalibration.The example is explicitly illustrative, not measured on Jev, Laya, or a real dataset.Source: E. Hypothetical example: how… · p. 10

A. Setup and limitations

  • The initial comparison used one run per condition against one target with 13 seeded vulnerabilities, so its observations are not statistically powered experimental evidence.The authors call for multiple runs per condition, alternated execution order, and fixed random seeds before causal claims.Source: A. Setup and limitations · p. 10, Table V · p. 10

B. Coverage results

  • Coverage was comparable in the initial runs: Run A hit 10 of 13 scenarios and Run B hit 9 of 13, with combined coverage of 11 of 13.Neither run solved the second-order SQL injection or CRLF injection at vote-n 1; both required multi-step chains the configuration did not pursue.Source: B. Coverage results · p. 10, Table VI · p. 10

C. Gap re-test (separate experiment)

  • The separate re-test confirmed all 7 previously missed scenarios in both arms, but its changed harness version prevents a controlled comparison with the initial run.The re-test included prompt-level chaining fixes, evidence-field salvage, and a data-type classifier.Source: C. Gap re-test (separate experiment) · p. 10, Table VII · p. 11

D. Severity distribution (re-test, post-fix harness)

  • Run A produced 4 Criticals and 10 Lows, while Run B produced 3 Criticals, 8 Highs, 6 Lows, and 5 Info in the re-test.Three class-inflated Criticals were recalibrated to High based on demonstrated impact, while four evidence-backed Lows were promoted to High after evidence salvage; single runs cannot rule out stochastic variation.Source: Table VIII · p. 11, D. Severity distribution (re-test,… · p. 11

E. The credential-dump BOLA case

The BOLA case shows how evidence-graded severity can differ from narrative-based grading, and how structured evidence affects the System One result. The run also surfaced chained findings and operational observations, but the single-run comparison cannot establish that pruning caused the runtime difference.

E. The credential-dump BOLA case

  • After the data-type fix, Run B scored the BOLA Critical: 9.1, matching Run A’s Critical 9.1 while grounding confidentiality in structured credential evidence.Initially, Run B scored Low: 3.1 because its structured confidentiality field was empty; after salvage, the data-type Score returned p(secrets) = 0.94.Source: E. The credential-dump BOLA case · p. 11

F. Beyond the seeded set

  • The TypeSafe-enabled run found admin takeover, secrets exposure, GraphQL authorization bypass, and authenticated RCE beyond the seeded set.The BOLA enabled the admin takeover, which enabled the RCE; whether pruning contributed to finding the GraphQL bypass is undetermined from one run.Source: F. Beyond the seeded set · p. 11

G. Operational observations

  • Run B finished 5 minutes 19 seconds faster, but one run per condition cannot distinguish pruning effects from stochastic response times, network latency, or server load.Establishing reliable attribution requires multiple runs with controlled execution order and fixed seeds.Source: G. Operational observations · pp. 11–12

H. Benchmark-driven harness refinements

  • The benchmark exposed a session-limit response mistaken for model output and an empty structured evidence field; the fixes were to park the run and salvage evidence.The data-type classifier and salvage step address the empty-field issue.Source: H. Benchmark-driven harness refinements · p. 12

X. OFFENSIVE-SECURITY APPLICATION SCENARIOS

  • System One is presented as supporting six additional offensive-security scenarios beyond the four decision points.The section supplies concrete question schemas and operational contexts.Source: §X · p. 12

A. Scenario 1: Large-surface finding triage

  • For 200+ candidate findings, System One batching is projected to reduce adjudication from 200 calls and 5–10 minutes to 16 calls and 4.4 seconds.The scenario uses a batch limit of 13 findings per API call and 276 ms per call.Source: A. Scenario 1: Large-surface finding… · p. 12

B. Scenario 2: Payload routing for input filtering

  • For input-filtering payload routing, System One evaluates 20 candidates simultaneously, and similar candidate probabilities can justify trying several rather than only the top-ranked payload.The passage gives three candidates at approximately p = 0.15 each as an example.Source: B. Scenario 2: Payload routing for… · p. 12

C. Scenario 3: XSS reflection verification

The scenarios apply typed System One questions to verify executable XSS contexts, detect prompt injection, prioritize attack surfaces, and assess chains, scope, timing, and reporting depth. The cost model describes System One costs and reductions in other cost components.

C. Scenario 3: XSS reflection verification

  • For XSS reflection verification, a Noul evaluates whether reflected content is executable code or instead rendered as text or escaped.The passage contrasts executable contexts such as event handlers with escaped content, which can be dismissed.Source: C. Scenario 3: XSS reflection… · p. 12

D. Scenario 4: Prompt injection detection

  • A prompt-injection detector can flag suspicious responses before they reach the planner, but adversarial content could still shift its classification and this risk is untested.The detector supplements evidence grounding, which does not prevent planning-layer influence before verification.Source: D. Scenario 4: Prompt injection… · p. 12

E. Scenario 5: Attack-surface relevance ranking

  • Attack-surface relevance questions use recon observations to allocate more agents and longer timeouts to plausible vulnerability classes and fewer resources to unlikely classes.The example treats Express.js indicators as plausible for XSS, SSRF, and prototype pollution, but not SQL injection absent database indicators.Source: E. Scenario 5: Attack-surface… · p. 12

F. Scenario 6: Multi-step chain validation

  • Multi-step chain validation checks whether each step’s output serves as the next step’s input, requiring every link to exceed a threshold.This is intended to avoid narratively connecting findings that lack causal links in the evidence.Source: F. Scenario 6: Multi-step chain… · p. 13

G. Scenario 7: Dynamic scope management

  • Dynamic scope checks compare discovered assets with the authorization token’s scope; calibrated uncertainty can send ambiguous cases to a human decision.The example gives an asset scoring Noul 0.55 as a case for human scope review.Source: G. Scenario 7: Dynamic scope management · p. 13

H. Scenario 8: Temporal attack sequencing; I. Scenario 9: Adaptive reporting depth

  • Timing probabilities can guide allocation across likely windows, while reporting-depth scores route findings to full, standard, brief, or omitted treatment.The passages describe these as ways to allocate timing attempts and adjust documentation to severity, evidence quality, and client context.Source: H. Scenario 8: Temporal attack… · p. 13, §I · p. 13

A. Cost model

  • The cost model adds System One expense while describing reductions in LLM, infrastructure, and review costs; projected Laya self-hosting costs $0.0000007 per decision.The estimate assumes a T4 GPU at approximately $0.35/hour and 8,333 batched decisions per minute.Source: A. Cost model · p. 13

B. Hypothetical engagement profile analysis

The paper presents engagement cost and break-even projections alongside a multi-model architecture in which System One judges executor output, allocates work, arbitrates disagreement, and feeds decisions back into the harness. The cost projections and automation assumptions are not validated by production measurement.

B. Hypothetical engagement profile analysis

  • The engagement profiles are analytical projections, and their assumed automation rates have not been empirically established for pentesting.The projected savings depend on achieving the assumed automation rate.Source: B. Hypothetical engagement profile… · p. 13

C. Break-even analysis

  • System One adjudication is projected to be 10–100× cheaper per decision than LLM-based adjudication, while human-review break-even depends on automation and false-positive rates.The stated ROI illustration is hypothetical, and the actual offensive-security automation rate has not been measured.Source: C. Break-even analysis · p. 14

A. The judge-executor separation

  • The architecture separates the LLM executor from a System One judge with different architecture, training objective, output space, and no shared parameters or training data.The separation is presented as addressing the self-evaluation problem.Source: A. The judge-executor separation · p. 14

B. Heterogeneous executor pools

  • For heterogeneous executor pools, a batched Choice question selects models by vulnerability class and target technology, with probabilities guiding proportional agent allocation.Similar probabilities can lead to allocating agents to both models; a dominant probability concentrates the budget.Source: B. Heterogeneous executor pools · p. 14

C. Consensus and disagreement protocols

  • For conflicting executor claims, System One evaluates evidence for each claim, severity, and existence rather than counting votes.The protocol can confirm a stronger evidence set, discard weaker evidence, or flag a case for review.Source: C. Consensus and disagreement protocols · p. 14

D. Cascading decision chains

  • The adjudication cascade escalates from deterministic validation through System One and LLM review to human review, resolving about 40% of benchmark findings at Level 0.The benchmark reports 25% at Level 1, 20% at Level 2, and 15% at Level 3; none required Level 4.Source: D. Cascading decision chains · pp. 14–15

E. Feedback loops between models

  • Feedback loops can send rejection reasons to agents for re-investigation, update pruning priors, and use detected secrets to focus reconnaissance on related endpoints.These mechanisms respectively connect adjudication to agent behavior, pruning outcomes to future selection, and severity signals to subsequent exploration.Source: E. Feedback loops between models · p. 15

XIII. THE SYSTEM ONE LANDSCAPE

The paper reviews Jev, Jev-Ultrafast, and Laya as System One options, then proposes Rave as a domain-adapted model whose training and evaluation are future work. The proposal uses harness validators for training and is limited by validator coverage.

A. Jev (TypeSafe AI)

  • Jev exposes Choice, Score, and Noul through a cloud API; published evaluations report results across several non-pentest tasks.Reported examples include 92.2% accuracy as a preference judge at 0.36% of GPT-6’s cost and F1 0.908 on 195,857 narratives.Source: A. Jev (TypeSafe AI) · p. 15

B. Jev-Ultrafast (Browser Use)

  • Jev-Ultrafast uses Jev in a browser-control loop, with published benchmarks reporting 90% fewer browser calls and a 7.1-second flight-search task.The paper presents this as evidence of real-time control-loop speed, not a pentest benchmark.Source: B. Jev-Ultrafast (Browser Use) · p. 15

C. Laya (open-source)

  • Laya is an open-source, non-autoregressive System One engine with English, multilingual, and typed-decision checkpoints.Jev and Laya trade-offs depend on deployment: Laya supports self-hosting and fine-tuning, while Jev’s managed API requires no infrastructure; benchmark comparisons are not controlled across tasks or hardware.Source: C. Laya (open-source) · p. 15, Table IX · p. 16

XIV. FUTURE WORK: RAVE

  • Rave is a proposed domain-adapted System One model; it has not been implemented or evaluated.It would retain the Choice, Score, and Noul interface while adapting training data and reward signal, with Laya as the preferred fine-tunable base.Source: §XIV · p. 16, A. Design rationale · p. 16

A. Design rationale

  • Rave’s proposed training data covers finding adjudication, exposed-data classification, agent relevance, and payload-effect judgments.Targets include 10,000+ adjudication examples across 30+ CWE classes, 5,000+ data-type examples, logs from 50+ targets, and 20,000+ payload-response pairs.Source: A. Design rationale · p. 16

B. Training with RLHV

  • Rave’s RLHV loop scores predictions against deterministic validator verdicts, but validator coverage limits which CWE classes can use that signal.For classes without validators, the proposal supplements validator signals with human-verified labels in a hybrid RLHV+RLCD regime.Source: B. Training with RLHV · p. 16

C. Evaluation protocol

  • The proposed evaluation measures held-out adjudication accuracy and calibration, severity calibration, end-to-end harness performance, and confirmation-loop efficiency.The end-to-end protocol calls for at least five vulnerable applications and at least three runs per target, with ablations for each decision point.Source: C. Evaluation protocol · pp. 16–17

D. Expected impact

Rave’s expected benefits are projections, and the proposal depends on sensitive security data and future deployment work. The benchmark has limited external validity, while System One integration can suppress true findings and may be manipulated through attacker-influenced inputs.

D. Expected impact

  • Rave is projected to reduce false positives by 30–50%, agent compute by 20–40%, and reach ECE < 0.10 with sub-100ms adjudication latency on a T4 GPU.These are expected impacts based on benchmark and calibration analysis, not measured Rave results.Source: D. Expected impact · p. 17

E. Training data acquisition strategy

  • The proposed data sources are synthetic vulnerable targets, anonymized engagement logs, and expert annotations for classes without deterministic validators.Synthetic generation requires at least 50 distinct targets; expert labels use three certified penetration testers and Fleiss’ κ as a data-quality measure.Source: E. Training data acquisition strategy · p. 17

F. Deployment architecture

  • Rave’s proposed deployment uses a self-hosted inference server, versioned checkpoints, a logged fallback chain, and parallel A/B testing against Jev or Laya.The training-pipeline figure describes domain adaptation from Laya’s RLCD-trained base with offensive-security data and RLHV verification.Source: F. Deployment architecture · p. 17, Figure 4 · p. 17

A. Benchmark limitations

  • The benchmark’s scope is limited by one target, single-vote runs, no offensive-security Laya comparison, and possible NimbusCart training-data memorization.The text calls for diverse targets with at least three runs each and partly private targets for external validity.Source: A. Benchmark limitations · pp. 17–18

B. The additive design principle

  • Deterministic validators block false positives, but System One can still downgrade or suppress real findings, making false-negative risk asymmetric.The proposed safeguard is monitoring, such as flagging disagreements between the LLM and System One.Source: B. The additive design principle · p. 18

C. Adversarial robustness

  • Attacker-influenced responses may shift System One probabilities, suppress findings, deprioritize relevant agents, or undergrade severity.The text says the layered defense is incomplete: validators block false positives, but do not prevent System One from suppressing true positives.Source: C. Adversarial robustness · p. 18

D. Cross-domain transfer

The case study suggests general-purpose System One models may transfer imperfectly to offensive security, while the paper identifies context, calibration, and integration risks. It argues that typed calibrated models combine properties absent from the alternatives it reviews, and proposes monitoring calibration over time.

D. Cross-domain transfer

  • The case study’s nine recalibrated findings are consistent with useful but imperfect transfer, but a single run cannot establish the result conclusively.The BOLA case exposed an empty-evidence-field failure requiring domain-specific engineering; whether Rave improves long-tail performance remains an empirical question.Source: D. Cross-domain transfer · p. 18

E. Regulatory implications

  • Structured probability outputs can be logged for retrospective calibration analysis, which the paper says may better support calibration guarantees than opaque preference alignment.The passage frames this as a potential regulatory advantage, not a stated regulatory requirement.Source: E. Regulatory implications · p. 18

F. Context window limitations

  • Laya’s 512-token English and 1024-token multilingual context windows constrain evidence per call; extensive findings require truncation or decomposition.The paper says benchmark evidence typically fit within 400 tokens, but complex chains or embedded scripts may degrade adjudication quality.Source: F. Context window limitations · p. 18

G. Failure mode taxonomy

  • The paper identifies evidence-format mismatch, domain-specific vocabulary, adversarial evidence, calibration drift, and threshold sensitivity as integration failure modes.Suggested mitigations include format-aware evidence salvage, domain adaptation, layered defenses, temperature scaling, and reliability diagrams.Source: G. Failure mode taxonomy · pp. 18–19

H. Comparison with alternative architectures

  • System One combines typed questions, calibrated outputs, non-autoregressive evaluation, and multi-question batching; the paper says no reviewed alternative provides all four.The alternatives discussed include task-specific classifiers, LLM ensembles, and deterministic rules.Source: H. Comparison with alternative… · p. 19

XVI. RELATED WORK

  • The paper positions calibrated non-generative decision models and assurance-oriented metrics as additions to capability-focused pentest-agent work.It relates the approach to harness assurance and argues that trustworthy outputs require measuring severity calibration, false-positive rate, and recalibration count, not only capability.Source: §XVI · p. 19

A. Continuous calibration monitoring

  • The proposed production monitor adds each engagement’s prediction-outcome pairs to a running reliability diagram and triggers recalibration when ECE exceeds a threshold.The passage gives example thresholds of 0.15 for Laya and 0.30 for Jev.Source: A. Continuous calibration monitoring · p. 19

B. Federated training across engagements

The paper identifies privacy, calibration, and harness-engineering boundaries for System One integration, then concludes that the approach is promising but remains an architectural proposal with limited empirical support.

B. Federated training across engagements

  • Federated training could pool engagement-log training signal without sharing evidence, but heterogeneous pentest data and privacy noise may make aggregation difficult and degrade calibration.The trade-off between training quality and data privacy remains open.Source: B. Federated training across engagements · pp. 19–20

C. Toward autonomous Level 5 pentest systems

  • System One may support Level 5 autonomy through auditable decisions, but remediation verification and regulatory acceptance need further work, while scope management and operational safety require harness-level engineering.Current systems operate at Levels 3–4, with human review required before vulnerability submission.Source: C. Toward autonomous Level 5 pentest… · p. 20

D. Real-time calibration for novel vulnerability classes

  • For vulnerability classes outside its training distribution, System One calibration may be unreliable; shift detection and fallback adjudication introduce a threshold trade-off between frequent fallbacks and miscalibrated decisions.The proposed detection signals include prediction entropy or calibration error on a sliding window.Source: D. Real-time calibration for novel… · p. 20

E. Integration with other harness assurance properties

  • System One addresses evidence grounding and computed severity, while future integration could apply it to claim destructiveness, scope checks, and audit-event classification.These remaining assurance properties are non-destructive claim reduction, enforced authorization, and tamper-evident accountability.Source: E. Integration with other harness… · p. 20

XVIII. CONCLUSION

  • The paper formalizes four decision points for replacing free-form LLM judgment with typed, calibrated verdicts, while keeping generation, judgment, and deterministic grounding as distinct layers.The architecture was implemented in NeuroSploit and tested with TypeSafe Jev.Source: §XVIII · pp. 20–21
  • Single runs with and without Jev on one target showed a more graduated severity distribution in the TypeSafe-enabled run and exposed two masked harness bugs, but do not establish improvement statistically.The authors identify multiple runs, diverse targets, and controlled execution order as the key next replication step.Source: §XVIII · p. 20
  • Jev and Laya report different advantages on their own evaluations, but whether these transfer to offensive-security decisions remains untested; Rave is proposed for domain-specific fine-tuning using RLHV.The paper calls for paired evaluation on the same pentest-relevant dataset and describes Rave as a design proposal requiring training data and an evaluation protocol.Source: §XVIII · p. 20

ETHICS AND RESPONSIBLE USE; COMPETING INTERESTS AND FUNDING

  • The benchmark used a locally hosted, deliberately vulnerable application controlled by the author, with no third-party systems, credentials, or personal data; the author developed NeuroSploit and reports no external funding.The paper describes the assurance properties as constraints on misuse and support for defensible authorized engagements.Source: ETHICS AND RESPONSIBLE USE · p. 21, COMPETING INTERESTS AND FUNDING · p. 21
Loading 2609.28940v1…