Research

2026-10-19

Verifiable environments: when the world can prove the model’s claim

Why security-style oracles—crash or no crash, test pass or fail—matter for RL rewards and agent evals, with public examples from Anthropic, OpenAI, Google, Meta, and academic benchmarks.

Some claims about model behavior can only be scored by another model. Others can be proved by the environment itself. Security testing is the clearest example: either the program crashes under a sanitizer, or it does not. That binary is hard to fake. Highford uses this idea as a lens on reinforcement learning (RL) environments, agent evaluations, and the market for lab-ready interactive data.

The security analogy

Anthropic’s Frontier Red Team describes how it tests Claude Mythos Preview on vulnerability discovery. Each run launches an isolated container with the project under test and its source, disconnected from the internet. The model reads code, forms a hypothesis, runs the real project to confirm or reject the hypothesis, and finally reports either that no bug exists or a proof-of-concept with reproduction steps (Anthropic research post; index at red.anthropic.com). Tools such as AddressSanitizer, the team notes, “perfectly separate real bugs from hallucinations.” Mythos Preview’s cyber capabilities are also why Anthropic launched Project Glasswing with major infrastructure partners for defensive use (Project Glasswing).

OpenAI’s Aardvark agent likewise attempts to reproduce suspected vulnerabilities in an isolated sandbox to confirm exploitability before proposing patches (OpenAI). Google Project Zero and DeepMind’s Big Sleep work showed LLMs finding real vulnerabilities in production code such as SQLite, with maintainers patching before release (Project Zero). DeepMind’s CodeMender extends the defensive loop toward validated patches (CodeMender). DeepMind has also published a broader framework for evaluating emerging cyberattack capabilities of AI (DeepMind blog). Meta’s Purple Llama CyberSecEval suite measures insecure coding and attack-assistance risks with structured benchmarks (Meta).

The pattern is the same: fixed environment + executable oracle + reproducible artifact.

Public benchmarks that grade by execution

CTF-style. Cybench packages 40 professional-level capture-the-flag tasks across standard categories for language-model evaluation (Cybench; paper arXiv:2408.08926).

Real-world vulnerability reproduction. CyberGym contains 1,507 vulnerability instances across 188 projects sourced from OSS-Fuzz. Agents receive a description and pre-patch code and must produce a proof-of-concept that triggers a sanitizer crash pre-patch and not post-patch. Top agent–model combinations still succeed only around ~20% of the time, and the benchmark has also surfaced zero-days when agents’ PoCs hit unexpected bugs (CyberGym paper; site).

Software engineering tests. SWE-bench Verified is a human-validated 500-task subset of SWE-bench where success means a patch that passes the repository’s tests inside containerized harnesses (OpenAI). Unit tests are the oracle—analogous to a sanitizer crash, but for functionality.

Why verifiable rewards matter for RL

Preference models can be gamed. Rule-based and execution-based rewards are harder to hack at scale. DeepSeek-R1 leans on accuracy and format rewards for reasoning (Nature). Tülu 3’s RLVR replaces learned rewards with deterministic verifiers for math and verifiable instructions (arXiv:2411.15124). OpenAI’s reinforcement fine-tuning exposes string-check and Python graders so builders can attach programmatic scores (Graders).

Anthropic’s engineering post on agent evals recommends code graders for objective outcomes, full transcripts for replay, isolated stable environments, and multiple trials because run-to-run variance is real (Demystifying evals for AI agents). Separately, Anthropic’s statistical guidance argues for error bars and paired comparisons when claiming one configuration beats another (Statistical approach to model evaluations).

Not every domain has a crash oracle. Legal interpretation and open-ended writing still need calibrated graders and humans. The point is to push as much as possible into checks the environment can settle: citations that exist, tests that pass, databases that contain the booking, sanitizers that fire.

What makes an environment “good”

Drawing on lab posts and market practice:

  1. Resettable, isolated state — containers or sandboxes so trials do not contaminate each other (Anthropic Mythos scaffold; Anthropic evals).
  2. Clear tasks and success criteria — preferably binary or low-dimensional.
  3. An oracle that is hard to spoof — tests, sanitizers, exact match, SQL state.
  4. Fidelity to the real workflow — Scale emphasizes realistic data universes and expert-designed tasks with process and outcome verifiers (Scale RL Environments).
  5. Transcripts and replay — so failures can be diagnosed and runs repeated.
  6. Difficulty ladder — CyberGym’s levels (no description → description → stack trace → patch) show how information changes success rates (CyberGym).

Economics of building them

Good environments are expensive precisely because they need engineers, domain experts, sandboxes, and QA before a lab accepts delivery. Public interview ranges put tasks at hundreds to thousands of dollars and complex replicas far higher; exclusive deals multiply price (Epoch FAQ). Mechanize argues underpaying for task quality wastes compute that may already cost thousands of dollars per task over its life (Mechanize). That capital intensity is why specialists raise large rounds and why labelling incumbents are reallocating capacity—while discovery of who has which environment inventory remains fragmented.

Highford does not build or host these environments. It is an information and introduction layer for private-market assets—including, when parties choose to list them, rights to datasets and environment inventories—searchable by people and by agents, with double-opt-in email intros and no transaction cut.

Graders, transcripts, and the noise floor

Verifiable environments still produce noisy scores when the agent is stochastic. Anthropic’s statistical work on evaluations argues for reporting uncertainty—standard errors, paired comparisons on shared questions, and power analysis—so that a one-point bump is not mistaken for progress (Statistical approach to model evaluations). The engineering companion piece stresses multiple trials per task, capability evals that start hard, and regression evals that should sit near a perfect pass rate once graduated (Demystifying evals for AI agents).

In security scaffolds, the oracle removes argument about whether a bug is real; it does not remove the need to record the trajectory. Mythos Preview runs that end in a PoC still need reproduction steps another engineer can replay. CyberGym’s success definition—crash pre-patch, clean post-patch—hard-codes that replayability into the metric (CyberGym). SWE-bench Verified went further upstream: human annotators removed underspecified issues and unfair tests so that a fail more often means a real capability gap (SWE-bench Verified).

Limits of the oracle

Memory-safety sanitizers cover an important but incomplete slice of cyber risk. CyberGym’s authors note the focus on C/C++ memory safety and OSS-Fuzz-derived bugs, and call out logic flaws, web, and crypto classes as future work. Preference-heavy domains—open-ended analysis, negotiation tone, creative writing—will keep hybrid stacks: code checks where possible, calibrated model graders where not, and human audit on release gates. Meta’s CyberSecEval shows another use of structured evals: measuring risky assistance, not only successful exploits (CyberSecEval).

The commercial implication is segmentation. Environments with strong oracles clear diligence faster and support RLVR-style training. Environments that only offer soft rewards compete on narrative fidelity and human QA—closer to classic RLHF vendor work—and face different pricing and acceptance cycles (Epoch FAQ; Scale).

What this means for private-market discovery

As labs spend more on interactive training infrastructure, the scarce inputs are not only GPUs. They are rights-cleared workflows, high-fidelity simulators, and task banks with honest verifiers. Builders who can prove claims the way a sanitizer proves a crash will win procurement. Buyers who publish oracle requirements will get better inbound. An information marketplace that lists those inventories, matches counterparties, and introduces them under double opt-in—without taking custody of the environment or a cut of the license—reduces search cost in a capital-heavy market.

From eval harness to market artifact

A verifiable environment is both a research object and a commercial product. In research, it is a harness: tasks, tools, graders, transcripts. In commerce, it is a deliverable with acceptance tests, exclusivity terms, and a renewal story. The same properties that make Mythos Preview findings credible—isolated containers, sanitizer oracles, reproduction steps—make a vendor’s RL gym acceptable to a lab’s security and research reviewers. CyberGym’s containerized design and pre/post-patch checks are, in effect, a procurement-grade acceptance protocol published as a benchmark (CyberGym).

Builders who document those protocols reduce buyer diligence time. Buyers who require them reduce hallucinated capability claims. The gap in the middle is still discovery: who has a finance workflow gym with outcome verifiers, who has a browser replica with deterministic checkers, who will license non-exclusively this quarter. That is an information problem before it is a training problem.

Labs also signal demand through hiring and product lines: Scale’s RL Environments launch, xAI roles that require programmatic task validation, and open hubs such as Prime Intellect’s Environments Hub all treat verifiable completion as table stakes rather than a nice-to-have. The market is converging on a simple test—can a stranger reproduce the claim?—that security teams learned years ago.

Further reading

Sources

All research

Machine view of /research/verifiable-environments

This page, for an agent

The same page as markdown, plus the API and MCP calls that belong to it.

API

Search public teasers

GET /api/v1/listings?q=unpaid+judgments+in+New+York

Create a free account

POST /api/v1/signup
Content-Type: application/json

{"email":"ada@example.com"}

api_key and token come back immediately. Search works with that key. Unlocks, intros, and credits wait until the sign-in link is opened. POST /api/v1/verify with {"email":"ada@example.com","code":"<6 digits>"} still confirms the address.
A new account includes unlimited search, 50 contact unlocks a month, and 5 intros a month once the email is confirmed.

MCP

MCP server

{
  "mcpServers": {
    "highford": {
      "url": "/api/mcp"
    }
  }
}

Search

search_deals {"q":"unpaid judgments in New York"}

JSON

{
  "site": "Highford",
  "page": "/research/verifiable-environments",
  "markdown": "/research/verifiable-environments?format=md",
  "api": [
    {
      "label": "Search public teasers",
      "request": "GET /api/v1/listings?q=unpaid+judgments+in+New+York"
    },
    {
      "label": "Create a free account",
      "request": "POST /api/v1/signup\nContent-Type: application/json\n\n{\"email\":\"ada@example.com\"}\n\napi_key and token come back immediately. Search works with that key. Unlocks, intros, and credits wait until the sign-in link is opened. POST /api/v1/verify with {\"email\":\"ada@example.com\",\"code\":\"<6 digits>\"} still confirms the address.\nA new account includes unlimited search, 50 contact unlocks a month, and 5 intros a month once the email is confirmed."
    }
  ],
  "mcp": {
    "url": "/api/mcp",
    "calls": [
      {
        "label": "MCP server",
        "request": "{\n  \"mcpServers\": {\n    \"highford\": {\n      \"url\": \"/api/mcp\"\n    }\n  }\n}"
      },
      {
        "label": "Search",
        "request": "search_deals {\"q\":\"unpaid judgments in New York\"}"
      }
    ]
  }
}

Markdown

Reading this page…