The next safety contest for artificial intelligence may be decided outside the model. Three new research papers submitted on August 10 examine different parts of the systems that surround AI agents: the rules they receive, the permissions their tools enforce, the memory that carries past failures, and the validation that decides whether an apparent success is real.
Read together, the papers point to a broader change in engineering priorities. Improving a model’s judgment remains important, but an agent can still fail when its surrounding software trusts the wrong state, keeps stale safety instructions, or uses the same score to guide a search and certify its result.
Rules can fail when authority gets lost
The clearest controlled evidence comes from a 5,280-episode study by the POLIS Research Programme at Project AWARE. It tested agents that had to route restricted material among internal and external specialists under different governance systems.
A detailed constitutional prompt produced no realized violations in 384 main episodes. A guard that checked immutable provenance also produced none, although it blocked 51 prohibited attempts. Forty-four of those blocked episodes later finished safely through another path.
The important comparison involved a weaker guard that trusted the policy currently visible in the workflow. When an ordinary transformation made that local policy appear permissive while the original restriction remained unchanged, the local guard admitted violations in 22 of 96 matched cases. The provenance-aware guard admitted none.
The researchers caution that this does not create a universal ranking of prompts and code-based guardrails. Their treatments combined multiple design choices, and the tasks were structured simulations. The result is narrower: enforcement can be mechanically consistent and still wrong if it consults an authority record that a workflow can accidentally rewrite.
A safety harness that learns from trajectories
A second team from Shanghai Artificial Intelligence Laboratory, Fudan University, Shanghai Jiao Tong University, and the Hong Kong University of Science and Technology focuses on the agent harness itself. Its Safety Harness Evolution framework separates four components: the system prompt, rule bank, safety memory, and tool policy.
Instead of treating those components as fixed deployment files, the framework analyzes failed trajectories, assigns responsibility to a component, proposes a localized change, and tests the revised harness for safety and usefulness. On Agent-SafetyBench, the researchers report a 3.1-fold reduction in attack success rate compared with a static SafeHarness baseline. They also report transfer to the held-out AgentHarm benchmark and across agent models without another evolution cycle.
Those are preprint results, not a guarantee that an evolving harness will remain stable in production. The evolution used a small stratified task subset, and model-based judges remained part of the evaluation. Still, the decomposition makes an operational question visible: when a failure occurs, teams need to know whether the prompt, memory, permission boundary, or tool policy should change.
TENS Analysis: safety is becoming a systems discipline
The shared lesson is that agent safety is moving from a model property to a systems property. A capable model can make a prohibited proposal, yet a provenance-aware guard can contain it and preserve a route to useful completion. Conversely, a reasonable guard can enforce the wrong answer when the authority state beneath it has drifted.
That distinction separates three jobs often collapsed into one safety score: prevent a bad proposal, block a bad action, and recover the legitimate task afterward. Two systems can record zero final violations while reaching that number through very different mechanisms. Deployment reviews should therefore count attempted violations, interventions, safe recoveries, and unnecessary blocks—not only final outcomes.
A third August 10 paper extends the same argument to automated research. Its authors compare research agents with software fuzzers: both propose candidates, execute them, observe feedback, and decide what to try next. They argue that a cheap measure of partial progress should steer the search, while protected evidence that never guides the search should decide whether a discovery is valid.
This creates a useful design matrix. Prompts communicate policy; executable guards contain actions; provenance preserves authority; safety memory carries lessons forward; and protected validators prevent the search process from grading its own homework. None substitutes for the others, and each creates a different failure surface that can be tested independently.
What builders should test next
The three papers do not establish a finished safety architecture. One is a position paper proposing falsifiable tests rather than reporting a new agent experiment. The empirical studies use benchmarks and structured environments that cannot reproduce every ambiguity, tool failure, or adversarial behavior in live organizations.
They do, however, sharpen what evidence should look like. Teams can test whether transformations preserve original permissions, whether a denied action leaves a safe fallback, whether harness updates generalize to unseen risks, and whether final validation is isolated from the feedback used during search.
The future of safer agents may depend less on finding one perfect instruction and more on building an accountable surrounding institution: one that knows where authority came from, records why controls changed, blocks actions at the right boundary, and keeps success claims separate from the signals used to pursue them.
Sources: Multi-Agent AI Safety as an Institutional Design Problem; SHE: Trajectory-driven Safety Harness Evolution for LLM Agents; Agentic Auto-Research is Fuzz Testing.
Featured image: The Columbia supercomputer at NASA’s Advanced Supercomputing Facility. Photo: Trower, NASA via Wikimedia Commons. Public domain, United States government work. Center-cropped from 2,100 × 1,524 pixels to 16:9 and resized to 1,920 × 1,080 pixels; no generative or substantive alteration.
