Agent Research Environments: What Is Actually Being Measured?

MLS-Bench, AutoLab, EdgeBench, Terminal-Bench, SForge, and Harbor are often grouped under “agent benchmarks.” That hides the decisive differences. Some define tasks, some run tasks, some protect hidden grading, and some study how long-horizon feedback changes an artifact. They are not points on one capability ruler, and their scores should not be compared as if they were. This note extends that map in two directions: when an environment is synthesized by a world model, how to separate a plausible frame from a verifiable state transition; and when an environment is used to produce synthetic training instances, how to keep those instances executable, auditable, and transferable.

1. Not One Leaderboard, but a Measurement Map

2. Four Different Claims Behind “Scientific Tasks”

“Scientific task” is not one object. These four claims require different evidence:

EdgeBench has 39 Scientific Problems & ML tasks. Many are open-ended and have no known optimum, but that does not mean every task lacks scoreable components. The project describes local simulators, validation, and physical constraints together with feedback from an isolated judge. Its log-sigmoid is an author-reported curve averaged across tasks, not a claim that every scientific task follows the same smooth curve.

Terminal-Bench Science sits near the opposite boundary: its call requires scientific workflows that can be checked by deterministic, pytest-based programmatic evaluation, and explicitly excludes open-ended hypothesis generation and literature review. It is designed to ask whether an agent can complete a specified scientific-computing workflow, not whether it can originate a new scientific theory.

Release Status Determines What Can Be Claimed Today

1. EdgeBench Scientific Problems & ML. The project describes 39 science and ML tasks, but its initial public release contains four of them. Their experimental errors, constraint violations, and physical-consistency checks permit repeated feedback. The closest supported claim is therefore how an agent’s best-so-far artifact changes with environment feedback under a fixed task, harness, and time window. This does not make the full science subset a fully public, independently reproducible benchmark, nor does it establish open-ended scientific discovery.
2. Terminal-Bench Science. Its status page currently shows zero tasks and marks the benchmark under construction. The contribution announcement sets 100+ tasks and a 10–20% solve rate as goals. Today it supports a task-contribution and deterministic-verification standard, not scientific leaderboard results. After release, its core claim will still be verifiable workflow completion rather than an environment-learning curve or hypothesis generation.
3. Terminal-Bench 3.0. It is also under construction. Its contribution, review, and task-format guidance define a quality bar for a future terminal benchmark; before a fixed task set and official results exist, neither previews nor target numbers are comparable capability scores.
4. Frontier Auto Research / ART. This is our proposed research scope, not a released benchmark. If it uses scientific tasks, it needs an additional research-evidence package: replayable artifacts, controls and ablations, failed attempts, a resource ledger, and transfer or replication that did not select the result. That separates “completed a workflow” or “improved along a feedback curve” from “produced a publishable empirical conclusion.”

The key question is not which task sounds more “scientific.” It is what object is held fixed, which feedback is visible, which verifier has write authority, and which release status permits an audit. See the research evidence map for sources and prohibited extrapolations.

3. SForge and Harbor Are Not Two Benchmarks

SForge is EdgeBench’s long-horizon evaluation harness. A task may have an agent-visible work image and a hidden judge image; the agent submits an archive, a Judge Server returns task-defined feedback asynchronously, and evaluation can select the best submission along a trajectory. Hidden tests, submission budgets, and the feedback protocol are part of its design.

Harbor is a more general agent harness: Dataset -> Task -> Trial -> Job. Tasks describe an instruction, environment, tests, and optionally an oracle; verifiers write reward.txt or reward.json, while agent adapters and sandboxes are replaceable. It is the official harness for Terminal-Bench 2.0, but Harbor itself makes no claim to measure “scientific ability.”

This is a protocol comparison, not a performance comparison. Without a common model, task, resources, network policy, and verifier, it is not justified to call one faster, more reliable, or “stronger.”

4. Terminal, Browser Use, and Computer Use: Interface Boundaries Also Change Measurement

Browser Use is not “a terminal with buttons.” It can retain sessions, cookies, and tabs, and can work through CDP, page inspection, JavaScript, or screenshots. Interface traces need not reveal the full business state on the server. Playwright checks that an element is visible, stable, event-receiving, and enabled before clicking; that still does not prove an order was created or an email was sent.

Computer Use has a broader boundary. With OpenAI’s computer tool, for example, the model receives screenshots, returns mouse and keyboard actions, and then observes a new screenshot. It can drive a browser, VM, or desktop-style harness. Each cycle also carries inference, rendering, screenshot-transfer, and visual-token cost. The distinction should not be reduced to “vision versus DOM”; it is primarily a general computer execution environment versus a browser runtime.

For the full comparison of task substrate, reset, interface, verifier, and comparable profiles across self-hosted web, enterprise web, live web, desktop, and mobile settings, see Web-Agent Environments. Do not pool their success rates into a single “general GUI” score.

5. World Models as Environments: From Plausible Frames to Verifiable State Transitions

When a generative world model is used to synthesize task environments, “world model” ends up naming four different objects — a predictor, a video or simulator, an embodied task environment, and internal state maintained for planning. For RSI, Auto Research, long-horizon work, RL environments, and synthetic-instance training, the important question is not how realistic a frame looks. It is which action is allowed in which state, what it changes, how failure occurs, how recovery works, and who independently checks the final state.

5.1 Separate Four Objects That Are Often Collapsed

WorldArena directly compares perceptual quality and functional interactive utility in one evaluation frame. Its follow-up, WorldArena 2.0, extends the setting toward visuotactile and interactive-RL evaluation. These preprints support a simple but important design rule: report visual quality and interactive utility separately; do not let the former vouch for the latter.

5.2 From “Does It Look Right?” to “Can It Do the Right Thing?”: Four Acceptance Layers

WorldArena organizes perceptual, functional, and action-planning evaluation for interactive embodied world models, emphasizing that visual performance and useful interaction may diverge. iWorld-Bench centers interaction and separates several task types for action-conditioned world modeling. Their shared value is not a universal ranking, but a demand that evaluators name the layer they are measuring.

For web, terminal, scientific, or computer-use environments, the last layer is often more direct than appearance: did an order actually write, is a file and its test output correct, can an experiment artifact rerun, or does a device meet its specification? Rendering can be an observation; it is not ground truth. Turning “a high visual score” into “a reliable environment” is an unsupported leap unless a verifier closes that gap.

5.3 The Contract of a Trainable Environment

A training environment should version these objects separately instead of hiding rules in a prompt, page script, or a single reward number:

TaskManifest  = goal, initial_state_digest, allowed_actions, budget, seed
Observe        = state -> observation + observation_provenance
Act            = (state, authorized_action) -> transition_event | rejected_action
Transition     = (state, action, exogenous_event) -> next_state + side_effect_digest
Reset          = task_id, seed -> initial_state + reset_evidence
Verify         = hidden_postcondition(next_state, evidence) -> outcome + diagnostics
Recover        = checkpoint, failure -> restored_state | safe_stop

This contract has seven practical consequences:

1. Initial state is data, not scenery. Record the image/database/VM digest, account or fixture, seed, and reset evidence for every run.
2. Action authority precedes the action space. A schema says what an agent can express; a capability grant says whether it may currently read, write, call an external service, or create an irreversible side effect.
3. Transitions need verifiable consequences. A successful action return does not substitute for a backend write, persisted file, changed object state, or failure branch.
4. Observation is not truth. A DOM, screen, tool response, and agent memory can be stale, injected, or incomplete; preserve provenance and visibility scope.
5. Separate reward from verifier. Reward may be a learning signal. Final acceptance still belongs to a verifier and hidden postcondition the agent cannot write.
6. Measure reset and recovery separately. Reset restores a standard initial state; recovery handles interruption, error, or partial side effect while retaining evidence. Neither is a chat-summary problem.
7. A trace is evidence, not a verdict. Log actions, interceptions, state changes, cost, checkpoints, and artifact hashes, then let an independent verifier decide the terminal state.

OSWorld combines executable computer environments, VM snapshots, and execution evaluation, an early concrete form of this contract. EnvFactory and Agentick make environment/task synthesis and verifiable task construction into systems questions. They do not make any environment inherently safe or clean, but they show that task, state, execution, and verification need to be engineered together.

5.4 A Synthetic World Is Not Synthetic Copy: Isolate the Generator Too

When synthetic instances are used for training, the most dangerous reduction is to generate only task instructions or successful trajectories. A training-useful synthetic instance needs at least:

Agent World Model proposes synthetic tool environments backed by code and databases. Its reported results occur in its own defined environments and evaluations, so it supports the claim that executable, stateful synthetic environments are a viable research object, not that automatically generated worlds naturally cover a real tool ecosystem. Agent-World, which discovers and expands tasks from database/tool environments, should likewise be read by its stated task, tool, training, and evaluation distribution.

Thus training and evaluation need at least four separations: environment, workflow/rule, generator/template family, and evaluator/security family. When a generator has seen verifier logic, successful evaluation traces, or the only state template, a final score is no longer clean transfer evidence even if task names differ. Section 8 develops instance lineage, SFT/RL controls, and the split protocol in full.

5.5 Long Horizon Is Not Longer Video: It Is Recoverable State

WorldLines constructs memory-QA and embodied-planning samples from extended household traces containing dialogue, actions, execution feedback, and object/device state changes. It exposes challenges from partial observability, overwritten state, and converting memory into action plans. LongAct studies dependencies, memory, and adaptive planning in free-form household tasks. Their direct lesson is that a long-horizon environment must confront an agent with state change, not repackage every step as an independent question.

A minimal long-horizon evaluation should report:

• State reconstruction: after interruption, can the system recover committed/uncommitted work, resources, and constraints without revealing hidden truth?
• Uncertainty and visibility: does it know that an object or state is unseen, stale, or overwritten?
• Failure recovery: after tool error, network failure, concurrent write, or partial commit, does it retry, rollback, escalate, or safely stop?
• Verified completion: does the terminal postcondition hold, rather than merely exhausting the episode or sounding confident?
• Cost of recovery: what tokens, tool calls, wall-clock time, and additional side effects did recovery require?

This is the connection between a world model and a long-horizon harness: an internal prediction or memory is useful only if it helps the system recover correctly under overwritten state, partial observation, and action feedback. See Long-Horizon Agents for the fuller checkpoint, fault-injection, and acceptance protocol, and Agent Memory for a separate protocol for context, events, retrieval, execution state, and a memory trust boundary.

5.6 Foundation World Models Is a Research Agenda, Not a Validated System Guarantee

Foundation World Models offers a useful research agenda: derive reward from specifications, check constraints with formal verification, calibrate abstractions online, and synthesize models or environments at test time. It is a strong way to enumerate variables, not a general capability or safety guarantee already established by experiments.

To turn that agenda into falsifiable experiments, separate at least these questions:

The boundary matters especially for Auto Research and RSI: a system may propose or synthesize a better research or environment artifact, but the candidate must not write acceptance, policy, or credentials. An apparently realistic world model does not replace an independent evaluator.

5.7 A Small but Sharp Evaluation Matrix

To compare static data, a visual world model, an executable environment, and agent-maintained state, hold base model, harness, action authority, total tokens, wall-clock time, training-data budget, and hidden evaluator fixed. Add these paired counterexamples:

Do not report a pass rate alone. At minimum, also report transition violations; error, refusal, and recovery categories; interception or authority violations; uncertainty calibration; trace completeness; cost per verified success; and variance across seeds and tasks. For browser/computer tasks with real side effects, explicitly name the control plane and sidecar evidence; see Agent Tool Governance.

5.8 Return to the Five Core Research Threads

The conclusion is simple but constraining: a world model should not give an environment a prettier surface. It should make state, transition, observation, authority, recovery, and acceptance definable, intervenable, and falsifiable. That is what lets it serve RL training, long-horizon execution, synthetic data, and research agents without letting “looks real” quietly replace “independently verified as correct.”

6. How We Can Differentiate: Evidence-Preserving Research Agency

The research position here is not to create one more benchmark that collapses every task into a score. It is to study evidence-preserving research agency: an agent demonstrates a level of research capability only to the extent that it produces a reusable artifact, improves it with empirical feedback, survives held-out transfer, and reproduces under a controlled rerun.

That can be an executable research protocol:

1. Use Harbor-style task, artifact, and trajectory records for replayability.
2. Start from an AutoLab-style valid baseline and report relative quality gain rather than only an absolute score.
3. Use MLS-Bench-style protected edit surfaces and held-out settings to test method generalization.
4. Record EdgeBench-style local and judge feedback timelines to show when and why meaningful improvement occurred.
5. Report a four-dimensional profile: completion rate, relative quality gain, held-out transfer, and time to first reliable improvement / rerun consistency.

This is a proposed research methodology, not a performance claim for a released system. Its value is to make “can do research” a set of falsifiable evidence rather than a vague label.

7. An Evaluation Environment Is Also a Training Substrate, but Keep Three Distributions Separate

When an environment supports synthetic instances, agentic RL, or continual adaptation, it is no longer only a one-shot evaluator; it is also a training substrate. The easiest mistake is to let the task generator, training rollouts, and final verifier share the same answer channel. Keep three distributions explicitly separate instead.

Agentick illustrates that procedurally generated tasks, a Gym-compatible interface, reference policies, and pre-built training data can share a sequential-decision framework; it does not establish that synthetic tasks are realistic enough. OSWorld illustrates how initial-state configuration and execution-based evaluation can make real computer tasks repeatable; it does not make a GUI screenshot a substitute for end-state verification. ACuRL links target-environment exploration, curriculum synthesis, and continual adaptation; its scoped result does not permit training data and the final benchmark to be mixed. Together with the detectable vulnerability opportunities in Hack-Verifiable Environments, these sources suggest a minimum boundary for a trainable environment.

“Learning” Must Name Its Update Channel

“An agent learns from an environment” is not one technical fact. It can refer to at least the four distinct updates below. A report must name the object that changed; a positive result in one channel cannot be silently promoted into a conclusion about another.

The absence of base-model updates does not make “environment learning” invalid: when the improved object is explicitly an artifact, a within-run feedback curve is still useful evidence. This taxonomy only forbids silent movement between update channels. For the proposed ClawBench V2 / WebsiteBench, state, skills, policy checkpoints, and environment artifacts may all be studied, but each must be versioned, receive isolated training/acceptance data, and be reported separately.

Accordingly, a trainable environment should version five contracts: reset, observe, act, verify, and evidence. Each synthetic instance needs its generator, initial state, execution verifier, source/license review, deduplication record, and split provenance. Accept a training result only through equal-budget SFT-only, RL-only, and SFT+RL controls on tasks held out by environment, workflow, and rule. Otherwise, “synthetic instances made a foundation model better” may only mean that it learned a shortcut near its generator.

This does not turn every benchmark into one huge training ground. It requires only that when an evaluation environment is used for training, evaluation integrity, data lineage, and anti-gaming regressions become first-class objects. As in RSI’s candidate/acceptance separation, a training agent cannot be able to write the final verifier or its evidence channel. The connected choices for memory, MCP, safety, and skills appear in the hot agent directions map; for reward, evidence, verifier, judge, acceptance, and anti-gaming regressions, see Agent Evaluation Integrity; for state transitions, visual-versus-functional evaluation, and independent terminal acceptance, see Section 5 above; for runtime authority, sidecar evidence, and adversarial acceptance over MCP and browser/computer tools, see Agent Tool Governance. The next section takes up that synthetic-instance path in detail.

8. Synthetic Instances for Agent Training: Executable, Auditable, Transferable

“Generate 2K synthetic instances” is not a training result; it is only a scale hypothesis. For agents that use tools, web pages, terminals, or GUIs, a useful instance is not a prompt-answer row. It is an executable, verifiable, traceable micro-environment: it specifies the initial state, available actions, observed trajectory, successful terminal state, and why the data did not leak the answer to final evaluation.

8.1 What a Synthetic Instance Must Contain

For an agent, the minimum training record is not a text pair but the following versioned object:

This is why “more dialogue” does not mean “more agent data.” Without initial state, action semantics, and an independent terminal state, a trajectory is hard to use as a reliable SFT demonstration or outcome-RL rollout.

8.2 Four Synthesis Routes, Four Different Risks

AgentTrek uses web tutorials as guidance, turns textual steps into GUI goals, and attempts execution and evaluation in real digital environments. It shows that guided replay can scale GUI trajectories; it does not make tutorial text automatically trainable, licensed, or separated from evaluation.

EnvFactory takes a different route: it explores and verifies stateful executable tool environments from authentic resources, then synthesizes natural multi-turn trajectories with topology-aware sampling. Its contribution is joining environment construction and trajectory synthesis; its benchmark-specific gains do not automatically transfer to web, GUI, or arbitrary tool protocols.

Agentick represents a third route: procedural tasks, a shared Gym interface, and reference policies make different agent paradigms comparable. Reinforcement Learning Foundation Models Should Already Be A Thing further proposes pretraining an RL foundation model from a synthetic MDP prior and gives a proof of concept on held-out tabular MDPs. These routes help control the generation distribution, but do not by themselves preserve the semantics, authority, or user intent of real workflows.

In coding environments, SWE-Gym packages a natural-language task, codebase, executable runtime, and unit tests into a training instance. R2E-Gym scales executable environments by constructing tests from commits and back-translating task descriptions, while analyzing the complementary strengths and limits of execution-based and execution-free verifiers. Together they show that having a runnable test does not settle every verification question: environment construction, training-data admission, and final transfer acceptance still need separate records.

8.3 Scale Is Not the Only Axis: Diversity and Executability Come Before Row Count

Beyond Quantity: Trajectory Diversity Scaling reports that, in its fixed-budget code-agent setting, raising trajectory diversity was more valuable than merely increasing count. That supports measuring coverage, long tails, and action complexity during selection; it is not a law that diversity always beats quantity in every domain.

A “2K” plan should therefore publish an instance dashboard before its count:

1. Executability: Can it replay from a frozen initial state; does its verifier pass; are failures environmental flakiness or agent behavior?
2. Structural diversity: Coverage of sites/tool graphs, goal types, initial states, authority, failure recovery, and action topology, not only embedding distance.
3. Semantic diversity: Whether intents are template rewrites, and whether they include implicit subgoals, conflicting constraints, and tasks requiring stop or refusal.
4. Integrity: Whether answer text, hidden rules, successful traces, evaluator code, or searchable near-duplicates of evaluation data appear.
5. Cost and risk: Generation, replay, judging, human review, license/privacy review, and blocked dangerous actions.

8.4 Coverage Cells Are More Auditable Than “Random Diversity”

Diversity cannot be only a claim that embedding distance is larger. EnvFactory connects environment topology to multi-turn trajectory synthesis; SWE-Gym and R2E-Gym place executable runtime, task construction, and verifier inside an instance definition. Across these different objects, the following is a sampling protocol proposed here, not a universal result claim about any paper.

CoverageCell(
  environment_family, workflow_or_rule, initial_state_class,
  action_topology, authority_class, failure_or_recovery_mode,
  verifier_family, source_lineage_cluster, split)

CoverageManifest(
  cell_quotas, minimum_tail_quota, accepted_and_rejected_counts,
  replay_and_integrity_rates, near_duplicate_policy,
  heldout_exclusion_rule, allocation_version)

For a 2K budget, first freeze the final holdout’s environment, workflow/rule, verifier, and source-exclusion axes. Then preregister a minimum tail quota for training cells instead of adding data to “effective” templates after seeing final results. Preserve accepted/rejected ratios and rejection reasons for every cell: empty cells, over-concentrated cells, and cells rejected for safety or replay failure are all data results. When a cell has no admissible instance, report uncovered rather than silently filling it with a neighboring template.

Only when accepted and rejected instances remain queryable with these measures does 2K become an auditable data target rather than a promotional number.

8.5 Admit Instances Before Accepting Training Results: Two Gates Must Not Share One Success Score

Whether a trajectory may enter a training set and whether a training run may claim transfer are different decisions. The first audits a data object; the second audits an experimental claim. A verifier-passing trace may still be templated, near-duplicated, or leak a final task, while a training run may improve only on development data. One successful trace, one reward, or one judge therefore cannot be the sole basis for both gates.

The two records should be independently queryable, replayable, and revocable:

InstanceAdmission(instance_hash, source_state, replay_result,
  outcome_evidence, integrity_result, provenance_review,
  split_label, decision)

TrainingAcceptance(run_hash, base_and_harness, method, data_manifest,
  budget, evaluator_version, holdout_suite, outcome, integrity,
  recovery, cost, transfer, decision)

Instance admission may use a training-side verifier as one piece of evidence. Training-result acceptance must occur again on a frozen, isolated final suite. This dual record makes both “why was this data included?” and “why should we believe this transfer result?” auditable, while allowing failure on either side to veto an over-broad claim.

8.6 SFT, RL, and SFT+RL: Compare Learning Signals, Not Algorithm Slogans

SFT can teach a policy to imitate verifier-passing action sequences. Outcome RL instead favors trajectories that complete an environment even when they differ from a demonstration. Both can fail: SFT inherits teacher redundancy and templates; RL can amplify verifier gaps, sparse reward, or useless exploration.

SFT Memorizes, RL Generalizes finds, in its controlled textual-rule and visual environments, that outcome-based RL generalizes better to unseen variants than SFT alone, while SFT still helps stabilize RL output format. It is an important experimental-design signal, not evidence that RL beats SFT in every agent environment.

If a comparison changes harness, available tools, browser profile, verifier, concurrency, or token budget, it no longer compares only training methods. It compares different agent systems.

8.7 Four Separations: Do Not Let Generator, Search, and Evaluator Share Answers

Training/evaluation splitting cannot be a random row split. Agent tasks need at least four separations:

Search-Time Contamination in Deep Research Agents shows that even when model weights did not contain a benchmark, test-time web retrieval can surface question context or answers and inflate a score. Synthetic agent-data generation and evaluation both need logged retrieval sources, blocked domains, and similarity audits; otherwise “unseen” can mean only a different filename.

Integrity tasks should also contain detectable reward-hacking opportunities. Hack-Verifiable Environments makes such exploitation an automatically scored outcome. Higher task success accompanied by higher integrity violations is not a training improvement.

8.8 A 2K-Instance Protocol That Can Fail

This is a research design for synthetic-instance foundation-model training, not a completed dataset or reported training result:

1. Start with a small pilot and instance admission. Execute each candidate instance from a frozen state, retaining generation, execution, verifier, and failure records. Only candidates passing provenance, replay, authority, and integrity checks enter the accepted pool.
2. Freeze distributions. Declare the environment, workflow, rule, evidence, and search split before training; the generator cannot see final tasks or an evaluator’s answer channel.
3. Sample by coverage. At fixed token and environment budget, fill long tails in action topology, recovery patterns, stopping/refusal, authority, and initial state rather than duplicate high-scoring templates.
4. Train three conditions. SFT-only, RL-only, and SFT+RL use the same base model, environment, tools, and total resource budget, retaining every checkpoint and failed rollout.
5. Then accept training results. On isolated final states, a verifier outside the agent’s write authority measures outcome, integrity violation, cost per verified success, recovery, and cross-environment transfer; a language judge’s single preference is not final ground truth.

ACuRL connects environment exploration, ability-related curriculum synthesis, and continual adaptation, showing how target-environment experience can become a data source. It also reinforces why adaptive curricula must remain separate from final evaluation: otherwise the agent keeps tracking the same test distribution.

8.9 How It Returns to the Core Five

This returns the five lines to one simple principle: the environment defines what can be learned, the verifier defines completion, and separation defines which results deserve belief. See AutoResearch for candidate freezing and independent reruns; Agent Evaluation Integrity for why reward, evidence, verifier, and acceptance cannot impersonate one another; Agentic RL for real-harness reward and trajectories; Agent Memory for stateful instances, memory operations, schema/provenance splits, and a memory trust boundary; Agent Skills for skill-aware data and controlled revision; and the hot agent directions map for adjacent choices in memory, MCP, and safety.

9. Intercepting Every Step Does Not Mean Rewarding Every Step

For the proposed self-hosted ClawBench V2 / WebsiteBench environment, “intercept every step” should mean pre-commit authority control, not an ambiguous process reward. ClawBench’s public trace bundle separately retains recording.mp4, requests.jsonl, actions.jsonl, agent-messages.jsonl, interception.json, and run metadata. This demonstrates that browser actions, network requests, agent messages, and interception decisions can be recorded separately; it does not show that those records exhaust every browser, operating-system, or server-side effect.

BrowseSafe shows that prompt injection in realistic HTML can influence a browser agent’s real actions. WASP evaluates web-agent hijacking in an isolated environment. Together they support placing injections, wrong payloads, and UI/backend mismatches in an integrity distribution, rather than folding a security screen into a final score and assuming that risk is solved.

A minimal versioned record can be:

StepRecord(run_id, step_id, pre_state_digest, observation_ref,
  proposed_action, declared_intent, authority_decision,
  interception_reason, commit_receipt, post_state_digest,
  evidence_refs, integrity_label)

RunAcceptance(run_id, task_manifest, harness_and_policy_version,
  final_outcome, integrity_violations, recovery, cost, decision)

Two anti-leakage rules matter here. First, an interceptor promises “every step” only on the plane it actually controls, such as declared browser commands, CDP actions, or outbound requests that cross a proxy. It must not claim visibility into model-internal reasoning, unknown extensions, native helpers, or sockets bypassing that plane. Second, training may use coarse allow/block safety signals as diagnostics or constraints, but final evaluation must not feed hidden rules, attack labels, or an exact safe path back to the policy. Otherwise the interceptor becomes an answer oracle and the reward contaminates evaluation.

Report reward as separate verified_outcome, proxy_reward, exploit_outcome, integrity, cost, and recovery signals: a blocked dangerous action is not success, and a legal HTTP request is not completion. Only an independent postcondition and integrity regression may accept a run. For ClawBench V2 / WebsiteBench, this is a research design and acceptance contract, not a claim of released security or RL improvement. It aligns with the reward/evidence/verifier separation in Agent Evaluation Integrity and the training/final-acceptance dual gate in Section 8 above.

Reward Hacking Benchmark (RHB) gives a concrete multi-step tool-task pattern: make shortcuts such as skipped validation, task-adjacent metadata leakage, or evaluation-relevant tampering detectable, then test independent and chained tasks separately. To report hardening_delta, hold task, policy, action surface, and budget fixed, and report legitimate-task pass rate and false blocks too; a lower exploit rate alone is not a safety proof. RHB’s model and post-training comparisons are scoped to its tasks and protocol, so they do not decide PPO, GRPO, or guard choices for future ClawBench V2 / WebsiteBench work.