A Safe Target Has to Survive Its Own History

A governed agent can look safe in a static test and fail once persistent state changes accumulate. A passing test tells us how it behaved in one moment. It says much less about the same agent, operating under the same declared authority, after its environment develops a history.

The signal

OpenART: Scaling Agent Red Teaming via Open-Ended Environment Evolution makes that gap uncomfortable. The authors hold task objectives fixed while evolving only the persistent environment state. Their arena contains more than 10,000 validated stateful scenarios in 50 domains, drawn from a pool of more than 500,000 tools and skills, with a median of 97 tool calls per task across 75 agent-model configurations.

The sharp contradiction is that the goal did not need to change for the safety outcome to change. OpenART reports a pooled 85.0% attack success rate for its Evolutionary Markov Hypergraph Attack, a black-box environment-evolution policy. Its advantage over instruction-only evolution grew from about 2% in simpler environments to more than 17% in the most complex ones.

The evidence

The paper argues that early changes to shared state can shape later decisions in long-running workflows. It also reports that the specific runtime implementation explained a significant part of safety variation beyond the underlying model. That is a useful warning against treating a model label, a package definition, or one target smoke test as the whole safety story.

For WTK, the point is not that every stateful workflow is unsafe. It is that a portable package still needs target-specific qualification, and a static fixture may not be enough evidence for a claim about a deployed, stateful harness. The executable target has a history, not just an input.

The boundary

This is an external red-teaming arena, not a WTK result or a production incident rate. Its 85.0% figure is pooled across the authors' environments and attack policy. It does not tell us the rate for WTK packages, establish a causal breakdown for each runtime, or show which control would eliminate the reported failures.

It also does not authorize importing the paper's tools, scenarios, attacks, or environment policy. More state evolution is not automatically a better test. The test must remain bounded, declared, and safe to run.

The builder impact

Our take: test the history that matters, not every possible history. When an agent keeps working against a changing environment, define a small sequence of allowed state transitions before the run. Keep the goal, authority, and tool declarations fixed, then ask whether the target still obeys the same boundaries after each step.

That separates a reassuring answer from a supported one. A target that passes when the state is fresh but quietly broadens, leaks, or bypasses a required control after the declared state changes has not earned a broad safety claim.

The WTK test

WTK can compare a fixed-state fixture with a short, predeclared state-transition sequence for the same package and compiled target. For every step, it should retain the state transition, tool receipt, requested action, gate result, denial or degraded outcome, and terminal result. The comparison needs an explicit stop condition and no hidden retries.

The useful result would be narrow: whether the target maintains its declared controls across that particular state path. It would not prove long-horizon safety, runtime parity everywhere, or a general defense against red teaming. That restraint is the feature, because it makes the next failing state observable instead of folding it into one optimistic score.

Still unknown

We do not yet know which small state paths are representative of real governed work, how those paths vary across targets, or whether the paper's complexity effect appears under WTK conditions. The next move is a bounded comparison with complete receipts and an explicit human review point, not a maturity promotion based on external research.