Testing AI Agent Safety Harnesses with Fresh-Context Review

An AI agent's safety harness is the software and checks around the model that constrain its actions. Those checks can pass the requests used to develop them but fail when the same harmful intent is expressed differently.

Suppose a check blocks access to a protected file by matching one spelling of its path. In a controlled test, another path to the same protected file could expose a rule that recognizes the wording rather than enforcing the access restriction. This is the practical problem with overfitting: a rule works on familiar examples but does not reliably handle variations.

The research question

EvoSafeHarness studies how to develop policies and executable safety checks for a fixed model and domain. Its Designer proposes candidates using source material, development scores, and execution records. A separate AI role, called the Criticizer, starts a fresh review context and challenges candidates with changes that preserve the request's intent, such as renaming or rephrasing.

Neither role receives held-out outcomes: results from tests withheld from candidate development. The challenge is an additional check before that evaluation, not a substitute for it. Fresh context means a separate review context; it does not by itself establish independent judgment or prove the reviewer has never seen similar examples.

The evidence

Across its five-model, three-domain comparison, the paper reports mean attack success falling from 45.6% to 10.0%, alongside a 3.3-point decrease in benign utility, its measure of performance on legitimate tasks. These are results for the overall system, not gains attributable solely to fresh-context review.

The more relevant evidence is the comparison with the Criticizer removed. Without that component, scores used to select candidates stayed the same or improved, while scores on withheld tests fell in finance, telecom, and a filesystem setting. The authors connect part of this gap to rules that depend too narrowly on particular words or identifiers.

This September 2026 preprint reports results under selected models, domains, attacks, budgets, and evaluators. Attack success remained nonzero, and the reported benefit does not establish how well the method would work in WTK.

The builder impact

For builders, the useful idea is to challenge what a rule depends on. Does it enforce a permission, or merely recognize a request from the development set? Controlled variations can help distinguish those cases, provided they preserve the intended restriction and do not change what should be allowed.

Our runtime-configuration note asks whether a running agent actually enforces its declared rules. Testing Agent Harness Changes on Held-Out Tasks explains why development and final evaluation need separate tasks. This paper adds a narrower question: can an extra challenge step identify brittle safety rules before final evaluation?

The WTK test

We propose comparing WTK's current evaluation path for one local execution environment with the same path plus a fresh-context challenge. Keep the agent package, model, compiler adapter, permissions, evaluator, test partition, and budget fixed. This uses WTK's existing package and compilation approach; it does not introduce a new runtime or catalog mechanism.

Before running, specify the permitted request variations, number of attempts, and stopping conditions. Keep final test results unavailable to both the candidate producer and the challenge reviewer. Retain every candidate, challenge, rule-check result, and final outcome, including unsuccessful runs.

Measure whether prohibited actions are blocked, legitimate tasks still complete, and challenge findings predict failures on withheld tests. Also record unnecessary blocks, cost, time, and missing evidence. Exposure of withheld outcomes, weakened checks, or lost required records would invalidate the comparison. No measurable benefit can be a valid null result; insufficient evidence should remain inconclusive.

The challenge has no permission to change access, replace qualification gates, or approve deployment. Experiment execution and any later promotion require their own authorization.

Still unknown

Would the extra review catch failures that WTK's current checks miss, or add cost without useful information? WTK has not run this comparison. Changes to the model, harness, permissions, or evaluation tasks would also require reassessing any result.

Source

Primary research: EvoSafeHarness: Evolving Model- and Domain-Specific Harnesses for Securing Agents, September 2026. WTK reviewed the complete 28-page primary PDF. This note translates an external result into a bounded question for WTK and reports no WTK experiment.