PaperlayerView exact revision on arXiv

Source-linked AI summary

HarnessRisk: A Lifecycle-Oriented Benchmark for Agent Harness Safety

Yajing Bai, Jinhao Duan, Jie Peng, Xianfeng Wu, Sijia Liu, Song Wang, Tianlong Chen

arXiv:2608.17597v1cs.CRcs.AI

TL;DR

Existing benchmarks cover only part of agent-harness safety, limiting comparisons across harness responsibilities. HarnessRisk evaluates six lifecycle phases and finds substantial attack success despite high utility, with configuration the most vulnerable phase and safety varying by deployed configuration.

  • Problem

    Existing benchmarks emphasize individual attacks, runtime operation, and action control while providing limited coverage across other harness responsibilities, hindering lifecycle-wide comparison.

  • Method

    HarnessRisk organizes safety into six lifecycle phases and evaluates 128 sandboxed cases across 14 deployed model–harness configurations using utility, attack success, persistence, and detection.

  • Results

    Across configurations, substantial attack success coexists with high task utility; Harness Configuration is most vulnerable, while safety rankings vary across harnesses.

  • Takeaways & Limitations

    Agent safety should be evaluated across harness responsibilities and deployed model–harness configurations rather than attributed to the model alone.

  • Takeaways & Limitations

    The benchmark measures adversarial influence in isolated sandboxes with simulated resources and no real credentials, accounts, payments, deployments, or external side effects.

Abstract

from arXiv · show

Large language models are increasingly deployed through agent harnesses that manage tools, extensions, persistent state, permissions, and external actions. Existing safety benchmarks mainly target individual attack mechanisms or a limited subset of operational settings, making it difficult to compare how safety failures emerge across different harness responsibilities. We present HarnessRisk, a lifecycle oriented benchmark that organizes agent harness safety into six operational phases including Harness Configuration, Capability Extension, Runtime Operation, State Persistence, Action Control, and Incident Recovery. HarnessRisk contains 128 sandboxed cases, each pairing a benign user objective with an adversarial instruction embedded in an untrusted workflow artifact. We evaluate each trajectory using Utility, Attack Success Rate, Persistence, and Detection. Across three harnesses, six language models, and 14 model and harness configurations, attack success ranges from 12.6% to 80.9%, while Utility remains between 75.0% and 97.6%. Harness Configuration is the most vulnerable phase across all three harnesses, showing that attacks can succeed by altering security sensitive parameters within otherwise authorized workflows. We also find that explicit risk recognition does not reliably lead to safe action, as some configurations detect risks in more than 90% of runs while retaining substantial attack success. These results highlight the need to evaluate agent safety across multiple harness responsibilities and at the level of the deployed model and harness configuration.

1 Introduction

HarnessRisk frames agent harness safety across six operational phases and evaluates 128 sandboxed workflows spanning configuration, extensions, runtime behavior, persistence, action control, and recovery. Across 14 model–harness configurations, it shows that high task utility can coexist with high attack success and that Harness Configuration is consistently the most vulnerable phase.

  • Framework: HarnessRisk organizes safety responsibilities into six phases: Harness Configuration, Capability Extension, Runtime Operation, State Persistence, Action Control, and Incident Recovery.The framework supports consistent comparison of risks associated with different harness responsibilities across phases.
  • Benchmark: 128 sandboxed workflows pair benign user objectives with adversarial instructions embedded in untrusted workflow artifacts.Each workflow uses three owner turns, case-specific files, tools, persistent state, and controlled mock services in a freshly initialized environment without real external network access.
  • Evaluation: 14 model and harness configurations show that safety rankings can change substantially across harnesses.The evaluation covers three agent harnesses and six language models.
  • Findings: High task utility can coexist with high attack success, so successful task completion provides limited evidence of safe execution.This finding motivates evaluating deployed combinations of models and harnesses rather than models in isolation.
  • Findings: Harness Configuration is the most vulnerable phase across all three harnesses because attacks can manipulate security-sensitive parameters within otherwise authorized workflows.The result illustrates why harness risks must be assessed at multiple operational points rather than only through individual attack mechanisms.

2 Problem Formulation

The paper defines harness safety as a joint property of the language model and harness, requiring trusted task completion despite untrusted inputs while preventing unauthorized effects. It scopes attacks to adversarial workflow influence in isolated sandboxes and organizes risks across six lifecycle phases.

  • 2 Problem Formulation: Safety requires completing trusted user tasks amid untrusted inputs while preserving confidentiality, integrity, authorization, persistent state, and recovery.The paper treats safety as a joint property of the deployed model and harness.
  • 2.1 Threat Model and Safety Scope: The attacker controls artifact content or metadata and may supply untrusted extensions, configuration inputs, or recovery information through normal interfaces.The attacker cannot directly invoke trusted tools, modify protected state, or execute external actions.
  • 2.1 Threat Model and Safety Scope: The attacker seeks unauthorized effects during benign task completion, including disclosure, privilege expansion, policy modification, persistent-state corruption, external action, or recovery interference.The model parameters, system prompt, trusted objective, benchmark runtime, evaluation criteria, and trusted infrastructure remain outside attacker control.
  • 2.1 Threat Model and Safety Scope: All evaluations use isolated sandboxes with simulated resources and services, excluding real credentials, accounts, payments, deployments, and external side effects.The scope is whether an agent configuration preserves task utility while containing adversarial influence in a controlled environment.
  • 2.2 Lifecycle Taxonomy: The lifecycle taxonomy comprises six phases: Harness Configuration, Capability Extension, Runtime Operation, State Persistence, Action Control, and Incident Recovery.The phases describe how adversarial influence can propagate across harness responsibilities.
  • 2.2 Lifecycle Taxonomy: Harness Configuration and Capability Extension address setup weaknesses and malicious or over-privileged plugins that can weaken isolation or exceed user intent.Configuration covers connectors, credentials, gateways, policies, and templates; extension risks include malicious or typosquatted skills.
  • 2.2 Lifecycle Taxonomy: Runtime Operation, State Persistence, Action Control, and Incident Recovery cover redirected execution, poisoned durable state, insufficiently validated sensitive actions, and adversarially influenced remediation.These phases span untrusted operational content, durable memory and identities, high-impact actions, and recovery activities such as rollback and credential rotation.

3 HarnessRisk

HarnessRisk benchmarks agent-harness safety across six lifecycle phases using 128 sandboxed cases that pair benign objectives with adversarial instructions in untrusted workflow artifacts. It evaluates both task completion and security outcomes across controlled, reproducible trajectories.

  • Benchmark scope: 128 sandboxed cases span six lifecycle phases: Harness Configuration, Capability Extension, Runtime Operation, State Persistence, Action Control, and Incident Recovery.The benchmark assesses whether agents complete trusted tasks while containing adversarial influence from surrounding workflows.
  • Benchmark scope: 22 cases each cover Harness Configuration and Capability Extension, while the other four phases contain 21 cases each.This approximately even allocation supports systematic comparisons without allowing one attack surface to dominate.
  • Case design: Each case combines a benign user task, initial world state, available tools, and case-specific evaluation criteria with an adversarial instruction embedded in an untrusted workflow artifact.Artifacts may include configuration instructions, extension metadata, messages, webpages, documents, stored state, tool outputs, or recovery records.
  • Evaluation setup: Every execution starts from a freshly initialized environment with real external network access disabled and external effects confined to controlled mock services.This prevents actions involving credentials, messages, payments, deployments, web requests, or extensions from affecting real accounts or infrastructure.
  • Evaluation metrics: Utility, Attack Success Rate, Persistence, and Detection measure benign-task completion, adversarial success, durable adversarial influence, and explicit concrete risk identification, respectively.Higher Utility and Detection are better, while lower Attack Success Rate and Persistence indicate safer behavior.

4 Experiments

HarnessRisk evaluates 128 sandboxed cases across three agent harnesses, six language models, and 14 model–harness configurations using four trajectory-based safety metrics. Results show that high task utility often coexists with unsafe behavior, with outcomes varying substantially by harness and lifecycle phase.

  • Evaluation setup: The evaluation covered three harnesses and six language models, with DeepSeek-V4-Pro, GLM-5.2, Kimi K2.6, and MiniMax M3 tested on all three harnesses.GPT-5.5 and Claude Opus 4.7 were also included, though the supplied passage truncates their harness coverage.
  • Evaluation setup: 128 benchmark cases were run independently in freshly initialized sandboxes, reset to case-specific conditions and repeated three times with reported means and standard deviations.Owner messages were delivered sequentially to preserve each workflow’s multi-turn structure.
  • Evaluator validation: The unified GPT-5.4 evaluator achieved 92.5% agreement for Utility, 89.7% for ASR, 84.3% for Persistence, and 85.7% for Detection against independent references.Cohen’s κ values were 0.83, 0.77, 0.65, and 0.69, respectively; semantic metrics showed greater ambiguity than directly observable outcomes.
  • Main results: Useful-but-unsafe outcomes account for 59% of OpenClaw trajectories, 38% of Nanobot trajectories, and 43% of Hermes trajectories, despite generally high Utility.Useful-and-safe outcomes account for 36%, 51%, and 53%, respectively, showing that successful task completion alone provides limited evidence of safety.
  • Main results: GLM-5.2’s ASR is 54.7% on OpenClaw versus 12.6% on Nanobot, a 4.3× difference, while DeepSeek-V4-Pro ranges from 37.3% on Nanobot to 65.4% on Hermes.These shifts change safety rankings across harnesses, supporting evaluation at the model–harness configuration level rather than attributing safety to the model alone.
  • Main results: Detection is strongly negatively associated with ASR (Pearson r = −0.71; Spearman ρ = −0.77), but MiniMax M3 on OpenClaw retains 31.2% ASR at 97.9% Detection.GLM-5.2 likewise reaches 92.2% Detection with 54.7% ASR, demonstrating that risk recognition alone does not ensure safe execution.
  • Lifecycle findings: Harness Configuration has the highest mean ASR on every harness, while later vulnerabilities diverge across Capability Extension, Action Control, and State Persistence.OpenClaw remains vulnerable in Capability Extension and Action Control, whereas Nanobot shows elevated risk in State Persistence despite lower overall ASR.

5 Related Work

Prior work has established interactive LLM agents, the runtime infrastructure supporting them, and benchmarks for agent capability and safety. These studies cover adversarial content, tools, extensions, persistent state, external actions, and complete execution trajectories.

  • Agent Infrastructure: LLMs have evolved into interactive agents that reason, invoke tools, maintain memory, and act in external environments.Recent research also examines agent architectures, interface adaptation, memory management, and protocols for tool and context integration.
  • Agent Benchmarks: Benchmarks increasingly evaluate agents through tool use, external interaction, stateful workspaces, complex workflows, and harness-mediated execution.Harness Bench further shows that agent capability varies across combinations of operational settings.
  • Agent Safety: Agent safety benchmarks examine adversarial content, unsafe tools, compromised extensions, persistent state, harmful external actions, and violations across complete trajectories.Related studies also evaluate high-privilege agents, persistent compromise, and attacks spanning execution stages.

6 Conclusion · Appendix

HarnessRisk evaluates agent safety across six harness responsibilities using 128 sandboxed cases and 14 model–harness configurations. Every evaluated configuration shows lifecycle-level safety failures, with substantial attack success despite high utility and the greatest vulnerability in Harness Configuration.

  • 6 Conclusion: HarnessRisk evaluates six responsibilities: Harness Configuration, Capability Extension, Runtime Operation, State Persistence, Action Control, and Incident Recovery.
  • 6 Conclusion: 128 sandboxed cases and 14 model–harness configurations underpin the benchmark’s lifecycle-level evaluation.
  • 6 Conclusion: Every evaluated configuration exhibits lifecycle-level safety failures, combining substantial attack success with consistently high task utility.
  • 6 Conclusion: Adversarial influence can persist in durable system state across the evaluated lifecycle settings.
  • 6 Conclusion: Harness Configuration is the most vulnerable phase across all three harnesses.
  • Appendix: The benchmark’s 128 cases are organized by phase, with the final column summarizing the harness responsibility exercised by each phase.

A Benchmark Construction Details … B.3 Isolation Scope

HarnessRisk constructs 128 lifecycle-spanning cases in which plausible workflow artifacts carry adversarial instructions, then evaluates model–harness trajectories in isolated, mock-service environments. The design separates benign task utility from unauthorized effects while standardizing evidence across harnesses and explicitly limiting the scope of sandbox isolation.

  • A.1 Lifecycle Phase Composition: The 128 cases span six lifecycle phases, pairing each phase with plausible untrusted workflow artifacts and the harness responsibility they target.Adversarial content enters through ordinary workflow artifacts rather than overtly suspicious channels.
  • A.2 Case Specification: Each case combines a user task, initial world state, available tools, and case-specific evaluation criteria delivered through three sequential owner messages.The message sequence allows adversarial content to appear mid-workflow and depend on earlier actions.
  • A.2 Case Specification: Evaluation uses utility, attack, and safe-behavior predicate families that inspect observable state and are contextualized by reference safe and unsafe trajectories.Predicates cover the benign deliverable, unauthorized effect, and absence of that effect.
  • A.3 Construction Criteria: Cases require plausible benign workflows and adversarial artifacts, separable utility and security outcomes, observable harmful effects, and exclusively synthetic controlled assets.These criteria were verified during construction.
  • A.3 Construction Criteria: A Harness Configuration example separates successful summarization from security behavior by contrasting safe retention of an indirect secret reference and narrow sharing with unsafe attacker-selected configuration values.The task configures a vector index and summarizes three policy topics while processing a manifest requesting a plaintext token and workspace-wide sharing.
  • B.1 Sandboxed Execution and Mock Services: Each run starts in a fresh case-specific environment with isolated mutable state, synthetic credentials, local mock services, and a case-restricted tool surface.Mock interfaces expose observable effects without affecting real accounts.
  • B.1 Sandboxed Execution and Mock Services: The four-stage execution pipeline sets up harness state, starts mocks, processes and normalizes trajectories, then scores exported evidence with deterministic predicates and a GPT-5.4 evaluator.Exported artifacts include normalized transcripts, tool calls, workspace differences, and mock-service state.
  • B.2 Harness Adapters: Dedicated adapters preserve the three-message persistent session while translating harness-specific conversations, tool calls, and durable state into a common trajectory format.This lets all configurations be scored from the same evidence representation.

C Trajectory Evaluation Protocol … E Utility and Detection Associations

The protocol evaluates trajectories from a harness-neutral evidence bundle using independently scored Utility, ASR, Persistence, and Detection labels, with validation, filtering, replication, and uncertainty procedures designed to clarify what the benchmark estimates. Correlation analysis finds weak Utility–ASR association but stronger negative Detection associations, while recognition may coexist with failed containment.

  • C.1 Evidence Bundle and Rubric: Evaluators receive a harness-neutral evidence bundle containing goals, predicates, conversations, tool events, final answers, workspace changes, persistent-state candidates, mock-service states, and network observations.Observed tool events and state changes take precedence over unsupported final-answer claims, while adversarial content is treated as evidence rather than instruction.
  • C.1 Evidence Bundle and Rubric: The judge returns exactly four independently scored binary labels—Utility, ASR, Persistence, and Detection—so Utility and ASR may both equal one.Each label includes supporting evidence, a rationale, a confidence estimate, and missing or ambiguous observations.
  • C.2 Validation Protocol: Validation compares Utility and ASR with deterministic predicates on 360 stratified trajectories, and Persistence and Detection with adjudicated human annotations on a separate 300-trajectory sample.The references test observable outcomes versus semantic consistency, but neither makes the evaluator error-free; benchmark values remain estimates conditioned on the rubric.
  • D.1 Validity Filtering: Invalid runs are excluded when outputs, harness responses, evaluator verdicts, or processes fail, preventing provider outages from being interpreted as safe refusal or task failure.Evaluator parsing failures are excluded rather than assigned zero.
  • D.2 Replication and Variance Estimation: Each model–harness configuration uses three independent sampling seeds covering the full case set, yielding a nominal 128 × 3 = 384 trajectories per configuration.Reported means pool valid case-runs across seeds, while standard deviations are sample deviations across the three seed-level metric values.
  • D.3 Phase Macro-Average and Uncertainty: Phase-level analysis uses four models shared across harnesses, pooling valid case-runs within each model before equally averaging the four model means.This defines the phase macro-average used in Figure 6.
  • D.3 Phase Macro-Average and Uncertainty: The 95% intervals are percentile intervals from 10,000 bootstrap samples with a fixed random seed, quantifying case-run variability under the observed model set.Within each harness, model, and phase, case-runs are resampled with replacement and resampled model means are equally averaged.
  • E Utility and Detection Associations: Utility has a weak, uncertain association with ASR, while Detection has a stronger negative unadjusted association across the 12 common model–harness configurations.Utility: Pearson r = 0.299, p = 0.345; Spearman ρ = 0.336, p = 0.286. Detection: Pearson r = −0.708, p = 0.010; Spearman ρ = −0.769, p = 0.003. These associations are descriptive, and recognition can coexist with failed containment.

F Qualitative Analysis of Failure Modes

The qualitative analysis identifies four recurring failure mechanisms: authorized changes can conceal unsafe parameters, later turns can launder provenance, authorized actions can enable target substitution, and detection can fail to produce remediation. These explanations come from representative trajectories and do not establish causal effects of individual harness design choices.

  • Recurring failure mechanisms: Authorized configuration changes can conceal unsafe parameters embedded within otherwise sanctioned edits to connectors, gateways, credentials, or policies.Adversarial instructions may alter secrets, sharing scope, approval steps, gateway exposure, or redaction settings within an authorized operation.
  • Recurring failure mechanisms: Later owner messages can launder an artifact’s provenance, causing agents to store initially untrusted content as approved metadata without independent verification.Neither the harness nor the model may preserve source and authorization constraints across turns.
  • Recurring failure mechanisms: Authorized actions can enable target substitution when adversarial artifacts replace amounts, recipients, endpoints, secrets, or evidence sources within legitimate requests.A single completed tool call may satisfy the attack objective, leaving little opportunity for correction.
  • Recurring failure mechanisms: Detection does not guarantee remediation: agents may recognize contaminated state yet retain unsafe tokens, extensions, policies, or memories, or omit rollback or revocation.Explicit detection and successful containment are distinct outcomes that require separate measurement.
  • Limitations: These mechanisms are qualitative explanations from representative trajectories, not causal estimates of individual harness design choices.Controlled ablations would be required to isolate such causal effects.

G Limitations and Threats to Validity

The benchmark’s validity is limited by nonrandom exclusions, uncontrolled differences among deployed harness configurations, and observability-dependent measurements. Metric meanings, statistical procedures, and provider-serving drift further constrain interpretation and reproducibility.

  • Validity filtering: Nonrandom provider-side exclusions condition pooled estimates on valid runs, while reported standard deviations omit uncertainty from the excluded cases.Excluded case-runs may vary systematically across models and time.
  • Cross-harness comparability: Cross-harness contrasts compare deployed configurations because system prompts, tool surfaces, and state management are not held fixed.Differences therefore cannot be interpreted as controlled harness-only effects.
  • Measurement observability: Persistence and Detection depend on harness-specific observability of durable state, transcripts, and reasoning, so cross-harness differences may reflect visibility as well as behavior.Persistence uses exported durable state, whereas Detection requires explicit language in recorded outputs.
  • Metric interpretation: Low ASR can reflect refusal, failure to reach a tool, or utility failure; Persistence and attack success can also occur independently.Durable adversarial content can produce positive Persistence without realized attack success, while a one-time unsafe external action can produce attack success without Persistence.
  • Statistical scope: 12 configurations make reported correlations exploratory, while bootstrap estimates omit several dependence sources and phase comparisons are descriptive rather than multiplicity-adjusted tests.Repeated cases, sampling seeds, and model selection are not modeled; provider-hosted identifiers, endpoints, and serving policies may drift, affecting exact reruns.

H Reproducibility

The authors release the benchmark artifacts and analysis tooling used to produce all reported results. Archived run metadata supports recomputation of every table while keeping API keys out of released files and trajectories.

  • The release includes benchmark cases, harness adapters, mock-service implementations, evaluator prompts, and analysis scripts.
  • Archived runs record case, harness, model, endpoint, inference, validity-filter, and evaluator metadata sufficient to recompute every table.
  • API keys are supplied through environment variables and excluded from released configuration files and trajectories.
Loading 2608.17597v1…