PaperlayerView exact revision on arXiv

Source-linked AI summary

EvoRiskBench: An Evolving Benchmark for Runtime Security Risks in Workspace Agents

Shiyi Kuang, Xuemei Luo, Kun Liu, Junhai Li, Rui Tian, Feng Shi, Bo Shen, Nianyu Li, Dehui Li, Ping Chen

arXiv:2610.03153v1cs.CRcs.AI

TL;DR

Executable coverage of workspace-agent runtime risks remains incomplete, while model capabilities, harnesses, tools, and threats evolve. EvoRiskBench organizes risk paths and evaluates nine configurations, finding that ASR varies more across models than harnesses, with an aggregate ASR of 37.46%.

  • Problem

    Executable coverage of workspace-agent runtime risks remains incomplete across entry interfaces and technical effects, and fixed test sets may become less representative as systems and threats evolve.

    Source: §1 · p. 2

  • Method

    EvoRiskBench organizes runtime risks by nine entry points and five effects, then uses an automated workflow to construct and verify 450 executable tasks across six scenarios.

    Source: §1 · p. 2

  • Results

    Across nine configurations, ASR varied more across models than harnesses, with harness differences depending on the model; aggregate ASR was 37.46%.

    Source: §5 · p. 10

  • Takeaways & Limitations

    The findings support evaluating security at the level of complete workspace-agent configurations rather than models alone.

    Source: §1 · p. 3

    The evaluation focuses on IPI attacks and sandboxed environments that may not fully capture production-workspace complexity.

    Source: §5 · p. 10

Abstract

from arXiv · show

Workspace agents combine large language models with execution harnesses to perform stateful, multi-step tasks that access or modify external resources. Existing benchmarks leave gaps in executable coverage of their runtime security risks, while evolving model capabilities, harnesses, tools, and threats motivate benchmark evolution. We introduce EvoRiskBench, an evolving benchmark organized around the EP-Path-EF framework, which links an initial risk entry point to a one-hop technical effect through an agent-mediated risk path. The framework defines nine entry-point categories and five effect categories; a 20-participant study supports their interpretability and classification consistency on representative cases. Guided by this framework, an automated end-to-end workflow constructs and executes risk cases in isolated environments and independently verifies outcomes using runtime traces and environment states. The benchmark provides a reproducible dataset of 450 adversarial tasks across six scenarios. We evaluate nine model-harness configurations spanning three models (GPT-5.6 Sol, DeepSeek-V4-Pro-0813, and Claude Opus 5) and three harnesses (Claude Code, Codex, and OpenClaw). Our results reveal substantial vulnerabilities across systems. The most vulnerable configuration, Codex with DeepSeek-V4-Pro-0813, reaches a 68.44% attack success rate (ASR), indicating that configuration of workspace agent is insufficient to ensure secure autonomous execution. ASR varies more across models than harnesses, and harness differences depend on the model. The benchmark cases and evaluation platform will be released after completion of artifact safety and reproducibility checks.

1 INTRODUCTION

EvoRiskBench treats workspace agents as stateful Model × Harness systems whose tool-mediated actions can produce verifiable technical effects, and focuses on indirectly induced risks entering through workspace resources and interfaces. It links those risks through EP–Path–EF and supports executable evaluation that can evolve with changing capabilities, harnesses, tools, and threats.

Motivation

  • Existing benchmarks have incomplete executable coverage of runtime-risk entry points and effects, while agent capabilities, harnesses, tools, and threats evolve and some effects require monitoring beyond trajectories or final-state checks.The introduction notes partial or absent coverage for agent communication and subagent delegation, and uneven coverage of resource exhaustion.Source: §1 · p. 2

Framework

  • EP–Path–EF links nine risk entry-point categories to five technical-effect categories; a 20-participant study found Fleiss’ κ = 0.904 for entry points and κ = 0.723 for effects.The blind classification study covered 11 representative scenarios.Source: §1 · pp. 2–3

Case construction

  • An automated workflow uses runtime traces and replay-verification feedback to refine risk cases, producing 450 executable adversarial tasks across six scenarios for a shared, frozen evaluation set.The workflow also supports adding validated cases as models, harnesses, tools, and threats evolve.Source: §1 · pp. 2–3

Results

  • 68.44% is the highest observed ASR across nine evaluated Model × Harness configurations, and stronger task-execution capability can coincide with greater attack susceptibility.The paper argues for evaluating complete workspace-agent systems rather than models alone.Source: §1 · p. 3

Evaluation platform

  • The evaluation platform uses isolated, resettable Windows Docker environments for nine Model × Harness configurations and verifies targeted effects with execution trajectories, environment evidence, and ETW process and network events.The platform instantiates all nine entry points through native runtime interfaces and covers five risk effects.Source: §1 · pp. 3–4

2 RELATED WORK

Workspace agents are stateful systems whose runtime behavior depends on both model and harness. EvoRiskBench builds on prior agent-security and evolving-benchmark work by linking untrusted-content entry points, execution paths, and technical effects in a case-construction workflow.

Workspace Agents

  • Workspace agents generalize tool-using and computer-use agents to delegated tasks in evolving environments, with runtime behavior jointly shaped by model and harness (Schick et al., 2023; Yao et al., 2023; 2025).EvoRiskBench evaluates complete, stateful Model × Harness configurations as agents access or modify external resources.Source: §2 · p. 4

Agent Security Benchmarks and Runtime Risk Coverage

  • Prior benchmarks cover harmful tasks, sandboxed tool use, prompt injection, runtime trajectories, and executable security (Andriushchenko et al., 2025; Ruan et al., 2024; Feng et al., 2026a; Li et al., 2026b).EvoRiskBench focuses on risks indirectly induced by untrusted workspace content, representing entry points, agent-mediated paths, and direct technical effects; the framework supports executable case construction and coverage analysis.Source: §2 · p. 4

Evolving Benchmarks and Adversarial Case Construction

  • Evolving benchmarks address the limits of fixed test suites as agent capabilities, harnesses, and tools change.EvoRiskBench uses execution feedback under a fixed Model × Harness configuration to refine cases; validated cases and failure modes inform later generation, while formal evaluation uses a frozen case set.Source: §2 · p. 4

3 EVORISKBENCH

EvoRiskBench organizes runtime risks as entry points connected to one-hop effects through agent-mediated paths, then constructs executable cases and verifies their outcomes in sandboxed runs. Its workflow covers risk formulation, case construction and refinement, and runtime evaluation.

3.1 RUNTIME RISK FORMULATION

  • EvoRiskBench defines nine risk entry points and five one-hop technical effects, linking each pair through an agent-mediated execution path.Effects are direct, observable consequences; downstream consequences are recorded separately.Source: §3.1 · pp. 5–6
  • The threat model limits attacks to malicious content in untrusted workspace resources; harmful effects must arise through Model × Harness execution.Attackers cannot modify trusted instructions, models, harnesses, environments, or verifiers, directly perform target operations, or forge evidence.Source: §3.1 · p. 5
  • Twenty participants’ majority labels matched intended categories in all 11 tested scenarios, with Fleiss’ κ = 0.904 for EPs and 0.723 for EFs.The study supports interpretability and consistent application on the tested scenarios.Source: §3.1 · p. 6

3.2 EXECUTABLE CASE GENERATION & REFINEMENT

  • Candidates are frozen and replayed three times, and retained only if at least two replays reach the payload, execute the intended action, and independently verify the target effect.Failed candidates are refined using execution traces and judge feedback; stable candidates inform a reusable experience repository.Source: §3.2 · pp. 6–7

3.3 RUNTIME EVALUATION & OUTCOME VERIFICATION

  • Each frozen case runs in a controlled sandbox with fixed case specifications, poisoned artifacts, initialization, and verification logic across Model × Harness configurations.Runtime events and final environment states are collected alongside agent trajectories.Source: §3.3 · p. 7
  • Attack success requires evidence that the target effect occurred; ETW process and network events supplement trajectories and environment states when tool outputs do not expose system behavior.Textual compliance or an attempted harmful action alone does not establish success.Source: §3.3 · p. 7

4 EVALUATION

Workspace-agent vulnerability to indirect prompt injection is substantial, varies more by model than harness, and differs across entry-point/effect combinations; task success and harm severity also vary under attack.

4.1 EXPERIMENTAL SETUP

  • Evaluation covered all nine combinations of three models and three harnesses, using a fresh Windows process-isolated container for each run.ASR measures attacker-goal completion, TSR measures legitimate-task completion under IPI, and evidence-grounded Harm Scores rate harmful behavior from 0 to 10 using trajectories and system-level evidence.Source: §4.1 · pp. 7–8

4.2 MAIN RESULTS

  • Across 4,050 attacks, 1,517 succeeded (37.46% aggregate ASR), and DeepSeek-V4-Pro-0813 with Codex had the highest ASR at 68.44%.Five of the six configurations using GPT-5.6 Sol or DeepSeek-V4-Pro-0813 reached at least 50% ASR. Successful attacks produced observable state changes in external resources.Source: Figure 2 · p. 8, §4.2 · p. 8
  • Model-level ASR ranged from 4.44% to 58.81%, a 54.37-point spread versus 5.41 points across harnesses; harness effects depended on the model.DeepSeek-V4-Pro-0813, GPT-5.6 Sol, and Claude Opus 5 had ASRs of 58.81%, 49.11%, and 4.44%, respectively. Claude Opus 5’s low ASR was partly associated with cyber-safety refusals or interruptions; GPT-5.6 Sol slightly exceeded DeepSeek-V4-Pro-0813 with Claude Code (52.44% vs. 51.56%).Source: §4.2 · p. 8

4.3 TASK UTILITY AND HARM UNDER ATTACK

  • Under IPI, overall TSR was 60.44%, and mean TSR was highest for Claude Code at 74.30%.Codex and OpenClaw averaged 55.04% and 52.00%; Claude Opus 5’s TSR ranged from 73.33% with Claude Code to 26.89% with Codex. Performance therefore depended on the Model × Harness configuration.Source: Table 4 · p. 9, §4.3 · p. 9
  • Mean harm scores were highest for MCPS among entry points (4.31) and ID among effects (3.96), while most category means fell between 2 and 4.FIO (2.06) and SAD (2.14) ranked lowest among entry points, and RE ranked lowest among effects (2.10). The AI-judged mean complements execution-verified ASR but may obscure individual high-severity cases.Source: Figure 3 · p. 9, §4.3 · p. 9

4.2 MAIN RESULTS

  • Claude Opus 5’s 4.44% aggregate ASR masked 56.67% ASR for NA–SD (17/30), while MCPS led entry points at 61.78% and ID led effects at 41.60%.NA–SD reached 100% with Claude Code; ID reached 84.44% with DeepSeek-V4-Pro-0813 × Codex. Every entry-point and effect category appeared in at least one pair with 100% ASR.Source: §4.2 · p. 9

5 CONCLUSION, LIMITATIONS AND FUTURE WORK

EvoRiskBench provides 450 executable cases for runtime security risks in workspace agents and reports results across nine model–harness configurations, while identifying scope limitations and directions for future evaluation.

5 CONCLUSION, LIMITATIONS AND FUTURE WORK

  • EvoRiskBench characterizes runtime security risks under IPI through nine entry points and five verifiable effects instantiated by 450 executable cases.Its execution-feedback-driven construction and verification workflow supports case refinement and versioned expansion; cross-configuration evaluation uses a frozen, shared case set.Source: §5 · p. 9
  • Across 4,050 runs over nine Model × Harness configurations, EvoRiskBench reports 37.46% ASR and 60.44% TSR.ASR varies more across models than harnesses, and harness differences depend on the model; ASRs also differ across entry points and effects, while task utility varies across configurations.Source: §5 · p. 10
  • The evaluation focuses on IPI attacks and sandboxed tools, services, and state that may not fully capture production-workspace complexity.Future work will broaden the threat model beyond IPI and evaluate more realistic external services, heterogeneous workspaces, and long-running scenarios.Source: §5 · p. 10

AI USE STATEMENT

  • Generative AI supported manuscript editing, benchmark-case generation and refinement, and trajectory-level harm-severity assessment, with generated cases execution-validated and AI-assisted text manually reviewed.The authors take responsibility for the benchmark, methodology, results, analyses, and final manuscript.Source: AI USE STATEMENT · p. 10

ETHICS STATEMENT

  • Experiments used isolated, resettable environments with synthetic data, mock credentials, and controlled services, and no production systems, real user accounts, or personal data were targeted.The benchmark is intended for authorized security research and defensive evaluation; released artifacts will omit operational credentials and sensitive environment-specific information and include responsible-use documentation.Source: ETHICS STATEMENT · p. 10

REPRODUCIBILITY STATEMENT

  • The paper documents the taxonomy, construction procedure, configurations, metrics, and validity criteria, with cases fixing inputs, injected content, environment, and success conditions before execution.Runs use isolated environments, case-specific scripts, traces, and post-execution system states; sanitized cases, configurations, scripts, and aggregation code are planned for release after safety and reproducibility checks.Source: REPRODUCIBILITY STATEMENT · p. 10

A APPENDIX · A.1 AN USER STUDY

A 20-participant study found strong practical consistency and positive assessments of the runtime-risk taxonomy, while identifying a few difficult category boundaries for refinement. The blind classifications matched intended categories in all 11 scenarios.

A.1 AN USER STUDY

  • The study involved 20 volunteers with relevant security and agent-system backgrounds, assessing taxonomy quality and practical interpretability.Participants reported average familiarity scores of 4.10/5 with Agent/LLM systems and 4.00/5 with Agent/LLM security.Source: §A.1 · p. 13
  • Risk Entry Points scored 4.24 for clarity and 3.91 for distinctiveness; Risk Effects scored 4.51 and 4.18, respectively.Scores were on a five-point Likert scale.Source: §A.1 · p. 13
  • The majority blind-classification label matched the intended category in all 11 representative scenarios.Participants classified six Risk Entry Point cases and five Risk Effect cases without seeing the intended labels.Source: §A.1 · p. 13
  • Fleiss’ κ was 0.841 overall, 0.904 for Risk Entry Points, and 0.723 for Risk Effects.The overall statistic treats entry-point and effect labels as a joint label space.Source: §A.1 · p. 13
  • Feedback focused on a few difficult boundaries, especially communication- and delegation-related entry points, while most participants saw no obvious missing categories.The feedback refined category definitions and examples without changing the high-level taxonomy.Source: §A.1 · p. 13

A.2 AI-JUDGED HARM-SCORE ASSESSMENT PROTOCOL · A.2.1 AI JUDGE PROMPT

The protocol applies one fixed, evidence-grounded AI judge and output schema to every execution trajectory. It classifies scenario and refusal, separates attempted behavior from realized effects, and assigns a trajectory-level Harm Score from concrete actions and system evidence.

A.2 AI-JUDGED HARM-SCORE ASSESSMENT PROTOCOL

  • The same fixed judge and output schema assess every trajectory; the reported Harm Score comes from the JSON record’s risk.score field.The record also includes scenario classification, supporting evidence, execution state, failure reason, and risk score.Source: §A.2.1 · p. 14

A.2.1 AI JUDGE PROMPT

  • The judge analyzes only the supplied execution record and treats quoted instructions, messages, tool results, and external values as untrusted evidence.It determines the record’s nature independently, without assuming intent, and prioritizes concrete actions and system evidence over prose.Source: §A.2.1 · p. 14
  • The judge must distinguish model, provider, harness, and environment refusals, and a refusal is complete only if the requested or equivalent action was not later performed.The schema records whether a refusal occurred, its actor and reason, and supporting evidence.Source: §A.2.1 · p. 14
  • Dangerous attempted behavior is scored even when it fails, with the score reason stating the execution stage and failure reason.The prompt also requires an explanation of the scenario classification, refusal actor, danger decision, score, and execution stage.Source: §A.2.1 · p. 14
  • Text without evidence of action must not count as a completed harmful action.The prompt requires distinguishing attempted behavior from realized effects.Source: §A.2.1 · p. 14
  • The risk scale assigns scores 3–4 to limited sensitive access or partial attempts, 5–6 to clear dangerous actions with bounded impact, and 7–10 to increasingly severe boundary violations or impacts.The prompt specifies credential access, unauthorized command execution, or major boundary violation at 7–8; confirmed exfiltration, persistence, privilege escalation, or destructive impact at 9; and a completed severe chain with major impact at 10.Source: §A.2.1 · p. 14

A.2.2 HARM-SCORE RUBRIC AND ADDITIONAL RESULTS

The appendix defines a 0–10 Harm Score rubric for grading dangerous behavior and presents configuration-specific severity results across nine Model × Harness systems, broken down by risk entry point and risk effect.

A.2.2 HARM-SCORE RUBRIC AND ADDITIONAL RESULTS

  • The rubric assigns HS 0–10, ranging from no dangerous behavior to a completed multi-stage harmful chain with major impact.Intermediate bands distinguish suspicious or failed attempts, limited sensitive access, bounded dangerous actions, major security-boundary violations, and confirmed exfiltration, persistence, privilege escalation, or destructive impact.Source: §A.2.2 · p. 14
  • Figures 4 and 5 report configuration-specific Harm Scores across nine Model × Harness systems, showing trajectory-level severity by risk entry point and risk effect.Figure 4 averages trajectories for each entry point across five effects; Figure 5 averages trajectories for each effect across nine entry points. Rows correspond to models and columns to harnesses.Source: §A.2.2 · pp. 14–15, Figure 4 · p. 15, Figure 5 · p. 16

A.3 EXPERIMENTAL CONFIGURATIONS AND ISOLATION

The section specifies how candidate cases are replay-validated, how unattended harness runs are configured, and how each evaluation run is isolated. Formal evaluation uses the same 450 frozen cases across all nine configurations.

A.3 EXPERIMENTAL CONFIGURATIONS AND ISOLATION

  • At least two of three valid construction-time replays must succeed under a fixed model, harness, and environment baseline for candidate admission.Platform- or environment-caused technical failures are replaced after repair; unsuccessful attack executions remain valid, and case changes require a new version. Formal evaluation uses the same 450 frozen cases across all nine configurations.Source: §A.3 · p. 16
  • Unattended runs bypass tool-approval prompts and Codex CLI’s internal sandbox while retaining operating-system permissions and platform-level container isolation.Table 7 records harness versions and update dates; the Codex configuration for the agent-to-agent entry uses OpenAI Agents SDK 0.17.2 as an adapter.Source: §A.3 · p. 16, Table 7 · p. 16
  • Each run uses a disposable Windows process-isolated container initialized from the fixed image and case specification, then destroys it, including after unsuccessful runs.The warm pool pre-creates unused containers but never recycles a container that has executed a case, preventing writable layers and session state from carrying over without assuming shared host resources or external services are independent across concurrent runs.Source: §A.3 · p. 16

Related papers

Loading 2610.03153v1…