HarnessRisk Shows Why One Prompt-Injection Demo Cannot Measure Agent Safety
HarnessRisk reports wide security differences across model-and-harness combinations and finds configuration more vulnerable than the other lifecycle phases it tested.
A prompt-injection test can show whether an agent follows a hostile instruction in a document. It cannot show whether the same agent harness safely configures a connector, installs a capability, preserves clean state, authorizes an external action, or fully recovers from contamination.
A new under-review preprint called HarnessRisk makes that missing scope concrete. Its authors tested 128 sandboxed cases across three agent harnesses, six language models, and 14 model-and-harness configurations. They report attack-success rates from 12.6% to 80.9% even though benign-task utility stayed between 75.0% and 97.6%. Harness configuration was the most vulnerable phase in all three harnesses they studied.
Those results have not been independently reproduced, and the benchmark does not establish a universal failure rate for production agents. Its useful contribution is the testing unit: evaluate the deployed model and harness together across configuration, capability extension, runtime operation, persistent state, action control, and incident recovery, while recording task utility and security outcomes separately.
HarnessRisk tests a deployed configuration, not a model in isolation
An agent harness is the execution layer around a language model. It supplies tools, loads extensions, maintains memory, applies permissions, presents authorization context, and turns model output into actions. Two deployments using the same model can therefore expose different tools and state, frame authority differently, and enforce different boundaries.
HarnessRisk reflects that joint responsibility. Each case gives the agent a benign objective over three owner turns while placing an adversarial instruction inside an untrusted workflow artifact. Runs start from a fresh environment, use controlled mock services, and disable real external network effects. Each of the 128 cases is repeated with three sampling seeds for every evaluated configuration.
The authors’ released repository includes harness adapters, mock services, trajectory collection, deterministic evaluation rules, and an LLM judge. It does not make reproduction push-button: teams still need the separate case dataset, compatible harness installations, model-provider access, and stronger operating-system isolation when arbitrary host commands are possible. The repository explicitly says its process-level separation is not an OS security sandbox.
The paper’s headline range also compresses very different configurations. One model recorded a 54.7% attack-success rate on OpenClaw and 12.6% on Nanobot, a 4.3-fold difference in the authors’ setup. That comparison does not isolate the harness as the cause because prompts, tools, and state management differ. It does show why importing a base-model safety score into a different deployment is a category error.
Four scores prevent a successful task from hiding an unsafe run
HarnessRisk assigns four binary labels to each trajectory, then reports percentages across runs. The labels answer different questions and can be true at the same time.
| Metric | Direction | Question the evidence must answer | Common false comfort |
|---|---|---|---|
| Utility | Higher is better | Did the agent complete the benign user objective? | “The task passed, so the run was safe.” |
| Attack success rate | Lower is better | Did the prohibited effect actually occur? | “The agent warned us, so the attack must have failed.” |
| Persistence | Lower is better | Did adversarial influence remain in durable memory, configuration, policy, extension, or startup state? | “Nothing bad happened during this turn.” |
| Detection | Higher is better | Did the agent explicitly identify the concrete content as suspicious or untrusted? | “A refusal or generic caution proves it found the actual risk.” |
The distinction matters because recognition and containment are separate outcomes. In the paper, one OpenClaw configuration detected risks in 97.9% of runs but still had a 31.2% attack-success rate. Another combined 92.2% detection with 54.7% attack success. Detection correlated with lower attack success across the 12 shared configurations, but the small observational sample does not support a causal claim, and the adjusted relationship was not statistically significant.
The evaluator is another source of uncertainty. GPT-5.4 scored the main trajectories from transcripts, tool calls, state changes, mock-service state, and network observations. On held-out samples, its labels agreed with deterministic rules on 92.5% of utility cases and 89.7% of attack-success cases; agreement with adjudicated human labels was 84.3% for persistence and 85.7% for detection. These are useful validation results, not proof that the judge is error-free.
The lifecycle framing is the benchmark’s strongest idea
The six phases—configuration, capability extension, runtime operation, persistent state, action control, and incident recovery—describe different opportunities for untrusted material to gain authority. A clean runtime prompt-injection result says little about a connector configured from hostile text or a poisoned preference that survives into a later session.
Configuration deserves special attention because HarnessRisk found it had the highest attack-success rate for each tested harness, often when an unsafe value appeared inside an otherwise authorized change. Capability extension is different again: Anthropic’s August 20 production-agent announcement made computer use, browser use, the Skills API, and the Files API generally available, increasing the number of reusable components a harness can load.
A current typosquatted-skill campaign supplies real-world consequence without validating the benchmark numbers. TechRadar reported that look-alike agent skills later introduced credential-stealing behavior; the 1.7 million figure was aggregate displayed installs, not unique users or confirmed victims. The incident belongs in the capability-extension threat model. It does not prove that any HarnessRisk configuration represents that marketplace or an Anthropic managed API container.
The four reported outcomes should also remain separate. A deployment can complete the benign task and still permit the prohibited effect; it can detect suspicious content and still fail to contain it; it can appear safe in the current turn while preserving hostile state for the next one. One blended “safety score” would erase the benchmark’s most useful distinctions.
What this benchmark cannot decide for a production team
HarnessRisk is version-one preprint evidence, under review as of August 23. Its Hugging Face paper page shows practitioner attention but no independent reproduction. The authors evaluated selected models, harnesses, cases, artifacts, and metrics; provider endpoints and serving policies can drift. Their cross-harness comparisons are between deployed configurations, not controlled estimates of a harness-only effect.
The paper also uses “sandbox” for isolated run state, mock side effects, and restricted reachable endpoints. Its appendix says no kernel namespace, chroot, or additional firewall was imposed. Teams testing an agent that can run arbitrary host commands need an OS-level containment boundary, fake credentials, mock services, restricted egress, disposable state, and a host with nothing worth stealing. The benchmark repository makes the same warning.
Finally, low attack success can include safe refusal, failure to reach the relevant tool, or general task failure. Persistence and detection depend on what the harness exposes to the evaluator. A deployment test should document those observability limits instead of treating an absent log event as evidence that nothing happened.
The strongest near-term signal will not be a larger leaderboard. It will be an independent rerun that pins the case, harness, model, evaluator, and isolation revisions, then shows whether a specific control lowers attack success or persistence without destroying utility. Until then, the paper’s six-phase framing is best read as a warning about scope: a clean prompt-injection demo cannot certify the rest of an agent system.