pith. sign in

arxiv: 2605.12015 · v2 · pith:H3N5XNZ5new · submitted 2026-05-12 · 💻 cs.CR · cs.AI· cs.CL· cs.LG· cs.MA

SkillSafetyBench: Evaluating Agent Safety under Skill-Facing Attack Surfaces

Pith reviewed 2026-05-13 05:04 UTC · model grok-4.3

classification 💻 cs.CR cs.AIcs.CLcs.LGcs.MA
keywords LLM agentsskill safetyadversarial evaluationsafety benchmarkreusable skillsagent attacksrisk domains
0
0 comments X

The pith

SkillSafetyBench shows that attacks on reusable skills can induce unsafe actions in LLM agents even from benign user requests.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper presents SkillSafetyBench as a way to test how modular skills in LLM agents create new safety problems that standard evaluations overlook. Reusable skills give agents access to tools and contexts that can be poisoned with adversarial material, leading agents to perform harmful actions without the user asking for them. Through 155 test cases in various risk areas, the authors demonstrate that these attacks work reliably on different agents and models, revealing unique failure types for each combination. This matters because as agents rely more on shared skills, their safety becomes tied to how they process and trust those skills in real execution environments, beyond just the underlying model's training.

Core claim

SkillSafetyBench includes 155 adversarial cases across 47 tasks, 6 risk domains, and 30 safety categories, each with a case-specific rule-based verifier. Experiments with multiple CLI agents and model backends show that localized non-user attacks can consistently induce unsafe behavior, with distinct failure patterns across domains, attack methods, and scaffold-model pairings. The findings indicate that agent safety depends not only on model-level alignment, but also on how agents interpret skills, trust workflow context, and act through executable environments.

What carries the argument

SkillSafetyBench, a runnable benchmark for evaluating skill-mediated safety failures using adversarial cases and rule-based verifiers.

If this is right

  • Agent safety evaluations need to include tests for skill-facing attacks in addition to direct user prompts.
  • Distinct failure patterns suggest that safety improvements must be tailored to specific agent scaffolds and model backends.
  • Trust in workflow context from skills can be exploited to bypass safety measures in executable environments.
  • Reusable skills should be designed with safeguards against local adversarial artifacts to maintain agent safety.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Extending the benchmark to include more diverse agent types beyond CLI could reveal additional vulnerabilities in deployed systems.
  • Skill providers might need to incorporate validation mechanisms for skill content to reduce attack surfaces.
  • The results imply that future agent designs could benefit from isolated execution environments for skills to limit the impact of compromised context.

Load-bearing premise

The constructed adversarial cases and rule-based verifiers in SkillSafetyBench correctly identify and measure real-world skill-mediated safety failures without missing important cases or introducing errors in verification.

What would settle it

Re-running the experiments on the 155 cases with new agent-model combinations and observing that no or very few unsafe behaviors are triggered according to the verifiers would challenge the claim of consistent induction of unsafe behavior.

Figures

Figures reproduced from arXiv: 2605.12015 by An Wang, Biaojie Zeng, Chang Jin, Chao Yang, Jingjing Qu, Kai Wang, Qiaosheng Zhang, Xia Hu, Xingcheng Xu, Zeming Wei.

Figure 1
Figure 1. Figure 1: Problem-to-benchmark overview of SkillSafetyBench. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: The construction pipeline of a specific case under the taxonomy of SkillSafetyBench. [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: An example case in RD3 from SkillSafetyBench. [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Attack success versus task success across evaluated agent systems. Each point represents one CLI agent system–model backend pairing. The x-axis reports the task success rate, while the y-axis reports the overall attack success rate (ASR) on SkillSafetyBench. Dashed lines show the median task success rate (37.4%) and median ASR (41.8%) across evaluated systems. 5.4 Main Results Agent CLI and Model Compariso… view at source ↗
Figure 6
Figure 6. Figure 6: Average ASR by risk domain. Bars show the mean attack success rate (ASR) across completed agent￾model runs for each risk domain, and error bars indicate standard deviation across systems. Risk domains are sorted by mean ASR in descending order. 21 [PITH_FULL_IMAGE:figures/full_fig_p021_6.png] view at source ↗
read the original abstract

Reusable skills are becoming a common interface for extending large language model agents, packaging procedural guidance with access to files, tools, memory, and execution environments. However, this modularity introduces attack surfaces that are largely missed by existing safety evaluations: even when the user request is benign, unsafe influence may reside in skill guidance, local artifacts, or execution-environment files that steer the agent toward unsafe actions. We present SkillSafetyBench, a runnable benchmark for evaluating such skill-mediated safety failures. SkillSafetyBench includes 155 adversarial cases across 47 tasks, 6 risk domains, and 30 safety categories, each evaluated with a case-specific rule-based verifier. Experiments with multiple CLI agents and model backends show that non-user attacks can consistently induce unsafe behavior, with distinct failure patterns across domains, attack methods, and scaffold-model pairings. Our findings suggest that agent safety depends not only on model-level alignment, but also on how agents interpret skills, trust workflow context, and act through executable environments.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The manuscript introduces SkillSafetyBench, a runnable benchmark for evaluating safety failures in LLM agents induced by reusable skills that grant access to files, tools, memory, and execution environments. It comprises 155 adversarial cases across 47 tasks, 6 risk domains, and 30 safety categories, each paired with a case-specific rule-based verifier. Experiments with multiple CLI agents and model backends demonstrate that localized non-user attacks can consistently induce unsafe behavior, with distinct failure patterns varying by domain, attack method, and scaffold-model pairing. The authors argue that agent safety requires attention to skill interpretation, workflow context, and executable environments beyond model-level alignment.

Significance. If the benchmark's cases and verifiers hold up under validation, the work is significant for identifying an overlooked attack surface in modular LLM agents. It supplies empirical evidence of how benign user requests combined with adversarial skill materials can steer agents toward unsafe actions, highlighting the need for skill-aware safety mechanisms. The runnable design and multi-domain coverage are strengths that could aid reproducibility and future extensions.

major comments (2)
  1. [Benchmark Design] Benchmark Design section (around the description of the 155 cases and verifiers): The central claim of consistent unsafe behavior induction depends on the case-specific rule-based verifiers correctly identifying safety failures. However, no details are provided on rule development, validation against human judgments, inter-rater agreement, or checks that rules capture intent/context rather than surface keywords (e.g., file writes or tool calls). This is load-bearing, as overfitting or misclassification could artifactually generate the reported distinct failure patterns across domains and scaffolds.
  2. [Experimental Results] Experimental Results section (around the experiments with CLI agents and model backends): The abstract reports consistent induction of unsafe behavior but omits information on case construction (e.g., independence from tested agents' failure modes), statistical significance, controls for prompt sensitivity, or confounding factors. Without these, the generalizability of the distinct failure patterns across domains, attack methods, and pairings cannot be assessed reliably.
minor comments (2)
  1. [Abstract] The abstract would be clearer if it specified the exact number and identities of CLI agents and model backends tested.
  2. [Benchmark Design] Consider adding a summary table or figure showing the distribution of the 155 cases across the 6 risk domains and 30 safety categories to aid reader comprehension.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their constructive and detailed review of our manuscript introducing SkillSafetyBench. The comments identify areas where additional methodological transparency will strengthen the presentation of the benchmark and results. We address each major comment below and will incorporate the suggested clarifications in a revised version.

read point-by-point responses
  1. Referee: [Benchmark Design] Benchmark Design section (around the description of the 155 cases and verifiers): The central claim of consistent unsafe behavior induction depends on the case-specific rule-based verifiers correctly identifying safety failures. However, no details are provided on rule development, validation against human judgments, inter-rater agreement, or checks that rules capture intent/context rather than surface keywords (e.g., file writes or tool calls). This is load-bearing, as overfitting or misclassification could artifactually generate the reported distinct failure patterns across domains and scaffolds.

    Authors: We agree that greater detail on verifier construction is warranted to support the central claims. The case-specific rules were authored to detect observable violations of the safety categories within each task's defined context, rather than relying on isolated keywords; for example, a rule for unauthorized file access checks both the target path and the absence of required permissions given the workflow state. In the revision we will add a dedicated subsection describing the rule development process, including how rules were derived from the 30 safety categories and 47 tasks. We will also report results from a human validation study on a representative subset of cases, including inter-annotator agreement metrics and alignment between automated verdicts and expert judgments. These additions will directly address concerns about potential misclassification and allow readers to assess the reliability of the observed failure patterns. revision: yes

  2. Referee: [Experimental Results] Experimental Results section (around the experiments with CLI agents and model backends): The abstract reports consistent induction of unsafe behavior but omits information on case construction (e.g., independence from tested agents' failure modes), statistical significance, controls for prompt sensitivity, or confounding factors. Without these, the generalizability of the distinct failure patterns across domains, attack methods, and pairings cannot be assessed reliably.

    Authors: We acknowledge the value of these additional details for evaluating generalizability. The 155 cases were constructed from domain-specific risk scenarios and common agent workflow patterns prior to selecting the evaluation scaffolds, ensuring independence from any particular agent's failure modes. In the revised manuscript we will expand the experimental section to include: (1) a description of the case construction methodology and its separation from the tested CLI agents and model backends; (2) statistical significance testing and confidence intervals for the reported unsafe behavior rates; and (3) discussion of controls for prompt sensitivity (e.g., template variations) and other potential confounders such as environment initialization and temperature settings. These changes will provide a clearer basis for interpreting the distinct failure patterns across domains, attack methods, and scaffold-model pairings. revision: yes

Circularity Check

0 steps flagged

No circularity in derivation chain

full rationale

The paper presents SkillSafetyBench as an empirical benchmark consisting of 155 adversarial cases across tasks, domains, and categories, each paired with a case-specific rule-based verifier. It reports experimental outcomes from running multiple CLI agents and model backends under localized non-user attacks. No mathematical derivations, equations, fitted parameters, predictions, or self-citations appear in the abstract or described structure. The central claim—that such attacks induce unsafe behavior with distinct patterns—is a direct reporting of benchmark results rather than any reduction to inputs by construction, self-definition, or load-bearing self-citation. The evaluation is self-contained as an observational study of agent behavior.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

The central claim depends on the assumption that the constructed adversarial cases and rule-based verifiers faithfully represent skill-facing attack surfaces; no free parameters, axioms, or invented entities are invoked in the abstract.

pith-pipeline@v0.9.0 · 5499 in / 1155 out tokens · 39925 ms · 2026-05-13T05:04:22.667508+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.