A safety harness that learns from an agent’s failures sounds attractive. The useful part is not the self-editing. It is the gate that decides whether an edit survives.
A new preprint called SHE treats the AI agent safety harness as a set of four editable artifacts: the system prompt, rule bank, safety memory, and tool policy. When a tool-using agent fails, the framework diagnoses the trajectory, assigns responsibility to one artifact, proposes a bounded change, and tests whether safety improves without destroying task utility.
The authors report a lower attack-success rate and better utility under attack after 20 evolution rounds. More importantly, they reserved 185 Agent-SafetyBench tasks and the entire AgentHarm benchmark for held-out evaluation. That does not prove the method is production-ready, but it makes the result more informative than optimizing and scoring on the same failure traces.
SHE edits four parts of the harness
- System Prompt: high-level role, priorities, and behavioral boundaries.
- Rule Bank: explicit rules tied to recurring risk patterns.
- Safety Memory: durable lessons for failures that remain unresolved or recur.
- Tool Policy: permissions and conditions governing tool use.
This decomposition is the core design choice. A generic prompt should not absorb every new rule, and a memory entry should not quietly grant a tool permission. By assigning each edit to the smallest responsible artifact, SHE tries to make the change attributable and reversible.
The loop runs agents under clean and adversarial conditions, diagnoses trajectory-level failures, proposes edits, and retains a candidate only after safety-utility validation. In other words, the framework treats a failure trace as a change request, not as automatic permission to rewrite production policy.
The evolution set was small; the final test was separate
The experiment starts with 200 Agent-SafetyBench tasks. The authors select a stratified 15-task evolution subset and run each task under six conditions: clean operation, context poisoning, indirect injection, tool tampering, memory injection, and a composite attack. That produces 90 task-condition instances per round. Two rollout replications produce 180 trajectories in each of 20 rounds.
The remaining 185 task IDs are reserved for final Agent-SafetyBench evaluation, and AgentHarm is held out entirely. DeepSeek-V3.2 is the base tool-using agent. GPT-5.5 generates diagnoses and edits and also judges Agent-SafetyBench trajectories. GPT-4o judges AgentHarm. All model-based decisions use temperature zero.
That design reduces direct train-test leakage, but it does not create an independent evaluation. The authors run the models, choose the protocol, and report model-judged results. The 15-task evolution set is also small enough that its risk coverage deserves scrutiny.
The reported results improve safety and utility together
| Reported metric | Seed or comparison | Evolved SHE | Direction |
|---|---|---|---|
| Average attack success rate | 8.6% | 5.5% | Lower is better |
| Clean unsafe behavior rate | 25.7% | 19.8% | Lower is better |
| Utility under attack | 33.5% | 47.6% | Higher is better |
| AgentHarm Harm Score | 19.8% | 9.8% | Lower is better |
| AgentHarm benign non-refusal | 77.9% | 77.8% | Essentially unchanged |
Against the static SafeHarness baseline, the paper reports average attack success falling from 17.1% to 5.5% and utility under attack rising from 31.6% to 47.6%. On AgentHarm, Harm Refusal rises from 78.4% to 86.4%. The benign non-refusal result matters because a harness can appear safer simply by refusing everything. Here, that measure stays almost flat.
None of these percentages should be copied into a production risk forecast. They are evidence that the method is worth reproducing, not a universal failure rate. The task distribution, base agent, tool surface, judge model, and attack design all shape the result.
The public repository is useful but not a full reproduction bundle
The authors released an Apache-2.0 repository with harness artifacts, default configuration, fixed evolution and held-out task splits, evaluation scripts, the runtime library, and smoke tests. It requires Python 3.10 or later and expects model endpoints to be supplied through environment variables.
Generated rollouts, credentials, and external benchmark packages are intentionally excluded. That is reasonable for secrets and licensed dependencies, but it means a third party must regenerate a large part of the evidence trail. A credible reproduction should retain its own model versions, prompts, judge outputs, costs, and rejected harness candidates.
A production promotion gate for an evolving harness
- Open one failure ticket. Attach the original task, attack condition, complete trajectory, tool evidence, and expected boundary.
- Name one responsible artifact. Reject a proposal that edits several harness layers without explaining why each change is necessary.
- Constrain the patch. Tool-policy changes should never broaden permissions as a side effect of fixing a refusal or memory problem.
- Run frozen held-out suites. Measure attack success, clean unsafe behavior, benign utility, task completion, and reviewer overturns on tasks excluded from evolution.
- Require human approval. A person should approve any policy promotion, especially edits affecting credentials, external communication, data movement, or destructive tools.
- Version and canary. Store the complete harness as a release artifact, deploy to a limited cohort, and keep an immediate rollback to the previous version.
This gate complements static classifiers rather than replacing them. Our review of Mistral Shieldstral explains why operators still own thresholds and appeals. Our report on PAST-Bench agent-memory evaluation makes the same point about persistence: a memory feature is not trustworthy until it beats a fresh-session baseline on a held-out task.
Do not let the safety learner approve itself
SHE uses GPT-5.5 both to generate evolution decisions and to judge Agent-SafetyBench trajectories. The paper adds other evaluation views, including AgentHarm with GPT-4o, but the shared model still creates a possible blind spot. A generator and judge can prefer the same wording, overlook the same failure, or reward a policy that optimizes the judge rather than the underlying behavior.
Production teams should separate proposal from approval. Use deterministic checks for permissions and data movement, a distinct reviewer model for semantic cases, human review for consequential changes, and periodic red-team tests that the evolution loop never sees. The Musthave.ai agent security scorecard can supply the fixed boundary questions.
My verdict: copy the release discipline before the self-editing loop
SHE is a thoughtful research direction because it makes safety-harness changes local, attributable, and testable. The held-out evaluation and nearly unchanged benign non-refusal rate are the strongest parts of the evidence. The public code and fixed splits make independent work possible.
I would not allow a production agent to rewrite its own harness continuously. I would first adopt the discipline around it: failure tickets, small artifact-specific patches, frozen safety and utility suites, human approval, canary deployment, and rollback. Once that pipeline catches regressions reliably, automated proposals can enter it. They should not own it.
Read the primary sources
- Read the SHE preprint on arXiv.
- Inspect the authors’ SHE code, configurations, data splits, and tests.
Which harness artifact in your agent stack can change today without a held-out test or rollback?
Checked August 11, 2026. Architecture, protocol, and performance figures come from the authors’ preprint and repository. The results are author-run, model-judged, and not yet independently replicated.
