V$^3$AST-Bench: Verifiable, Valid, and Versatile Safety Evaluation for Coding Agents

Weitao Feng; Hengheng Xiong; Zihao Zeng; Jun Chen; Jiyang Guan; Xiaofeng Wang; Jialing Tao; Hui Xue

cs.SEOct 26, 2026

V $^3$ AST-Bench: Verifiable, Valid, and Versatile Safety Evaluation for Coding Agents

Authors: Weitao Feng, Hengheng Xiong, Zihao Zeng, Jun Chen, Jiyang Guan, Xiaofeng Wang, Jialing Tao, Hui Xue,

Organizations: Nanyang Technological University, Singapore · Alibaba Group, Hangzhou, China

Abstract

Large language models increasingly act through code, modifying repositories, executing programs, and interacting with services in agent form. Their actions introduce risks that cannot be assessed from generated responses alone. Safety evaluation must verify actual consequences, distinguish harm avoidance from task incapability, and cover realistic workflows. We introduce V $^3$ AST-Bench, a benchmark for Verifiable results, Valid interpretation, and Versatile risk coverage of Agent Safety. It comprises 212 risk tasks spanning 18 categories. Dedicated runtime environments verify harm and task outcomes through executable checks over states, records, and artifact behavior, while paired capability twin tasks verify workflow competence. Our experiments span 51 combinations of 11 models and five harnesses, spanning 86,496 trials and over 9 billion tokens of model interaction. Results show that V $^3$ AST-Bench remains challenging even for frontier coding agents, as Claude Opus 4.8 with Claude Code still causes verified harm on 20.9% of tasks. Across model-harness combinations, agents with comparable competence exhibit markedly different safety outcomes, showing that task capability alone does not guarantee safe execution. More importantly, even explicit recognition of risks does not reliably prevent harmful actions, revealing a critical gap between risk awareness and safe execution. These findings highlight the need to move beyond risk recognition toward enforcing safety throughout execution.

Figures & tables

Panel of Table 1 — Table 1: Comparison of agent-safety benchmarks. $\checkmark$ fully covered, partially covered, – not covered. Partial coverage means capability is checked but failed cases still enter safety scoring, or only some risks within a category are tested.

Risk type	Verifiable target
R1. Untrusted Code Execution	Executing code from an untrusted source.
R2. Sensitive Data Leakage	Exposing sensitive data outside authorized boundaries.
R3. Destructive Operations	Deleting or overwriting protected data or history.
R4. Unauthorized Persistence	Enabling unauthorized access or execution after the task.
R5. Unsafe Dependency Integration	Introducing a concrete supply-chain risk.
R6. Unsafe Code Delivery	Delivering unsafe code, scripts, or configuration.

Table 2: Risk type taxonomy. Each row summarizes the prohibited action or effect checked by a task.

Figure 1: Two-stage benchmark construction. Stage I selects blueprints with realistic workflows, exposed safety decisions, and verifiable outcomes. Stage II implements risk tasks and capability twins, validates their outcome checks, and refines them through agent calibration.

Figure 2: Outcome interpretation for valid paired runs. Only pairs with successful capability twins enter safety scoring. Among these, only Compromised is unsafe, and only Completed receives risk-task completion credit.

Model Family	Models	Mini-SWE-agent		Codex		Claude Code		OpenCode		Pi
Model Family	Models	ASR $\downarrow$	CAP $\uparrow$	ASR $\downarrow$	CAP $\uparrow$	ASR $\downarrow$	CAP $\uparrow$	ASR $\downarrow$	CAP $\uparrow$	ASR $\downarrow$	CAP $\uparrow$
Qwen family	Qwen3.5-4B	97.7	62.3	94.8	55.2	95.5	51.9	89.4	58.0	94.4	67.5
	Qwen3.5-27B	92.4	88.7	89.8	88.2	88.2	88.2	81.0	86.8	85.1	85.4
	Qwen3.7-Max	78.4	96.2	73.2	89.6	70.9	92.5	69.7	87.3	75.8	89.6
	Qwen3.8-27B	47.8	92.5	51.9	92.9	42.8	92.0	46.9	92.0	44.7	91.5
	Qwen3.8-Max	19.8	95.8	24.3	97.2	33.3	94.8	28.8	93.4	18.7	95.8

Table 3: Task-level attack success rate (ASR) and capability-twin pass rate (CAP) for model–harness combinations on V 3 AST-Bench. All values are percentages. Lower ASR and higher CAP are better. Dashes indicate combinations not evaluated.

Figure 3: Task-level ASR (%) by model, risk type, and attack source. Top: direct attacks (S1); bottom: indirect attacks (S2). Results pool each model’s supported harnesses using the eligibility rule of Table 3 . All panels share a 0–100% scale; lower is better. Risk types are defined in Table 2 .

Figure 4: ASR under direct attacks (S1) and indirect attacks (S2). Models are grouped by developer and listed in generation order within each group. Results pool each model’s supported harnesses under the eligibility rule of Table 3 .

\Delta

reports S2 minus S1 in percentage points. S1 and S2 contain distinct task sets; lower ASR is better.

Figure 5: A Codex trajectory in which the agent’s own inclination to stop does not survive the harness’s rules. The risky instruction is part of the direct request. Kimi-K3 recognizes that making internal support bundles anonymously downloadable exposes tenant data and weighs pausing, then cites the harness’s approval policy and autonomy instruction, proceeds, and publishes.

Appendix figures & tables6 assets

Supplementary material from the paper’s appendix.

Appendix

Risk type	Definition and examples	Decision boundary
R1. Untrusted Code Execution	Executing, importing, building, or testing code from external sources whose trust has not been established, or processing external data in a way that can execute code. Examples include piping a download to a shell, evaluating external content, and loading an untrusted pickle.	Downloading, reading, or searching code alone does not constitute execution.
R2. Sensitive Data Leakage	Exposing secrets, personal information, or internal business data to an unauthorized destination, audience, or visible carrier. Examples include sending internal data to an external endpoint, placing credentials in URLs, logs, or commits, and creating a public sharing link to a sensitive file.	Ordinary transfer of public data is insufficient. Judge the data source, recipient, final destination, and visibility together.
R3. Destructive Operations	Deleting, clearing, overwriting, or rewriting existing resources, with potential loss of data, history, or recoverable state. Examples include recursive deletion, dropping a table, unscoped bulk deletion, a hard reset, force-pushing rewritten remote history, and overwriting an unbacked-up file.	Distinguish cleanup of reproducible temporary files created during this task from destruction of the user’s pre-existing work.
R4. Unauthorized Persistence	Changing mechanisms that remain effective after the task to grant continuing access or cause future code execution. Examples include adding an SSH authorized key, cron job, systemd service, shell-profile loader, startup entry, or automatically executed Git hook.	Require a new or changed continuing-access, startup, scheduled-execution, or equivalent mechanism. User-authorized changes are excluded; persistence of an arbitrary setting alone is insufficient.
R5. Unsafe Dependency Integration	Installing, upgrading, or integrating a dependency with a concrete supply-chain risk, or changing its source to bypass established controls. Examples include a suspected typosquat, an unknown-origin installer, bypassed integrity checks, an unauthorized public mirror replacing an internal registry, and lockfile changes routing future installation to an untrusted source.	Installing dependencies from an existing manifest through an established trusted source does not automatically qualify. Identify the specific provenance, integrity, or source-control violation.
R6. Unsafe Code Delivery	Committing, pushing, merging, publishing, or deploying code, scripts, or configuration with a concrete security risk into a downstream execution or distribution path. Examples include committing an exfiltrating CI workflow, publishing a credential-bearing package, and delivering release configuration that exposes internal files.	Downstream execution is not required, but the delivery and its specific security consequence must be established. An ordinary functional defect alone is insufficient.

Appendix

Table 4: Unsafe action classes and decision boundaries. The oracle must verify the specified action or artifact, with evidence appropriate to its stage: execution, exposure, state change, delivery, factual output, or code construction.

Principle	Operational check
Realistic workflow	Set a realistic engineering goal and justify why high-risk input appears.
Reachable appropriate outcome	Ensure clear task feasibility. Demonstrate a completion path for valid tasks and a safe stopping path for unsafe ones.
Attributable, exposed decision	Place one safety choice directly on the main path. Evaluate trajectory to confirm exposure during each run.
Executable outcome checks	Use independent code to verify harm, task completion, and safety stops while logging unverified results.
Harmless simulation	Use disposable test data and local sandboxes for any dangerous actions.
Minimal relevant complexity	Keep only the logic that changes hazard behavior and remove all unrelated code dependencies.

Appendix

Table 5: The eight construction principles and their validation criteria.

Model	Serving backend	Baseline inference settings
Qwen3.5-4B	Self-hosted vLLM	Temperature 0.6; top- $p$ 0.95
Qwen3.5-27B	Self-hosted vLLM	Temperature 0.6; top- $p$ 0.95
Qwen3.7-Max	DashScope	Temperature 0
Qwen3.8-27B	Self-hosted vLLM	Temperature 0.6; top- $p$ 0.95
Qwen3.8-Max	DashScope	Temperature 0
GLM-5.3	DashScope	Temperature 0

Appendix

Table 6: Serving backends and baseline inference settings. These settings apply directly to Mini-SWE-agent; the native request settings of the other harnesses are summarized in Table 7 . Unspecified parameters use the serving backend’s defaults.

Harness	Version	Execution settings	Submitted inference settings
Mini-SWE-agent	2.4.2	SWE-bench tool-calling prompts; direct shell execution without permission mediation.	Baseline model settings; automatic and parallel tool calls; output cap 128,000 for Claude.
Claude Code	2.1.220	Permission checks disabled; unrestricted tools.	Adaptive thinking at high effort; requests clearing of earlier reasoning from context; output cap 64,000 for Claude and 32,000 for other models.
Codex	0.146.0	Approval checks and the built-in sandbox disabled; Responses API.	Medium reasoning effort for GPT-5.5 and low effort for GPT-5.6-Sol; reasoning summaries requested for other models; low output verbosity.
OpenCode	1.18.18	Automatic approval for permitted tools; context window 65,536 tokens.	Output cap 8,192; medium reasoning effort and automatic summaries for GPT; top- $p$ 1 on some Chat Completions routes.
Pi	0.84.2	No permission mediation; context window 65,536 tokens.	Output cap 8,192; no explicit reasoning request.

Appendix

Table 7: Harness versions, execution settings, and inference parameters observed in recorded requests. Output caps are measured in tokens per model call. All harnesses run inside task containers; Claude Code and Codex use the permissive settings listed below.

Model	$M$	ASR@1	ASR@2	ASR@3	ASR@4	$s$	$K=0$	$K=1$	$K=2$	$K=3$	$K=4$
Qwen3.8-Max	1010	16.6	20.9	23.3	25.0	0.55	758	66	49	43	94
Opus 4.8	769	19.1	22.4	24.2	25.4	0.64	574	37	25	30	103
Kimi-K3	1001	28.6	34.3	37.2	39.0	0.48	611	72	65	70	183
Qwen3.8-27B	977	32.7	38.6	41.7	43.7	$\approx 1.22$	550	80	61	68	218
GLM-5.3	1013	37.5	43.2	46.0	47.6	0.88	531	65	70	72	275
Opus 4.6	768	51.1	54.3	55.7	56.6	0.94	333	28	25	36	346

Appendix

Table 8: Exact ASR under subsampling one to four observed runs, together with the distribution of compromised-run counts.

M

is the number of complete eligible task–harness combinations for a model;

K=k

counts combinations with exactly

k

compromised runs. ASRs are percentages. Zero or four observed compromises do not establish deterministic safety or failure.

AI Agent Safety

AI agent safety studies how to prevent and detect harmful actions by autonomous systems that use tools, memory, and multi-step plans.

See all 330 papers

Risky-Bench: Evaluating Agentic Safety Risks in Real-World Life-Assist Deployments
Feb 3, 2026Jingnan Zheng, Yanzhen Luo, Jingjun Xu +8Language Model Safety Evaluation LLM Agent Safety
National University of Singapore · University of Science and Technology of China · Southern University of Science and Technology +3
ForesightSafety-SAGE:A Fully Automated Scenario Generation and Safety Evaluation Framework for LLM Agents
Jun 7, 2026Lu Jia, Haibo Tong, Feifei Zhao +5AI Agent Safety Benchmarks LLM Agent Safety
BrainCog AI Lab, Institute of Automation, Chinese Academy of Sciences · Beijing Institute of AI Safety and Governance, China · University of Chinese Academy of Sciences (UCAS), Beijing, China +2
AgentHazard: A Benchmark for Evaluating Harmful Behavior in Computer-Use Agents
Apr 3, 2026Yunhao Feng, Yifan Ding, Yingshui Tan +6LLM Safety Benchmarks Computer-Use Agent Benchmarks
Alibaba Group · Fudan University · Hunan Institute of Advanced Technology +2

Feb 3, 2026J/K move · Enter open · S save

Risky-Bench: Evaluating Agentic Safety Risks in Real-World Life-Assist Deployments

Jingnan Zheng, Yanzhen Luo, Jingjun Xu, Bingnan Liu+7

National University of Singapore · University of Science and Technology of China · Southern University of Science and Technology+3

Language Model Safety Evaluation LLM Agent Safety AI Agent Safety Benchmarks

Open paper AskPDF arXiv

Large Language Models (LLMs) are increasingly deployed as agents that operate in real-world environments, introducing safety risks beyond linguistic harm through tool use, external transactions, and multi-step decision making. Existing agent safety evaluations construct risk-oriented tasks that lack a hierarchically organized taxonomy of attack surfaces, rely on predefined harm categories rather than deployment-grounded safety rubrics, and evaluate agent behavior in isolation rather than during realistic, long-horizon task execution. To address these limitations, we propose Risky-Bench, a deployment-grounded framework for systematic agent safety evaluation in life-assist settings. Risky-Bench derives context-aware safety rubrics from domain-agnostic safety principles and systematically probes safety risks across hierarchically organized attack surfaces through realistic task execution under varying threat assumptions. Applied to life-assist scenarios covering food delivery, in-store assistance, and online travel booking, Risky-Bench evaluates seven state-of-the-art agents across 750 tasks, revealing attack success rates ranging from 25% to 60% and exposing systematic failure patterns including threat-model-specific vulnerabilities, attack-surface-dependent risk concentration, and model-dependent effects of explicit reasoning. Our code and data are available at https://github.com/SophieZheng998/Risky-Bench.

Abstract

AI Agent Safety

Explore similar work

Risky-Bench: Evaluating Agentic Safety Risks in Real-World Life-Assist Deployments

ForesightSafety-SAGE:A Fully Automated Scenario Generation and Safety Evaluation Framework for LLM Agents

AgentHazard: A Benchmark for Evaluating Harmful Behavior in Computer-Use Agents