Source-linked AI summary

Agent-SafetyBench: Evaluating the Safety of LLM Agents

Zhexin Zhang, Shiyao Cui, Yida Lu, Jingzhuo Zhou, Junxiao Yang, Hongning Wang, Minlie Huang

arXiv:2412.14470v2cs.CL

TL;DR

Existing safety research has focused mainly on LLM outputs, while agent interaction with environments and tools introduces additional behavioral safety concerns. Agent-SafetyBench addresses this evaluation gap with a broad benchmark, finding substantial safety vulnerabilities across current LLM agents and limited gains from defense prompts alone.

  • Problem

    LLM agents introduce behavioral safety risks through interactions with complex environments and tools, but existing content-level evaluations and judgment models are not sufficient for assessing them reliably.

  • Method

    Agent-SafetyBench evaluates agent safety across 349 interactive environments, 8 risk categories, 2,000 test cases, and 10 representative failure modes.

  • Results

    No evaluated agent surpasses a total safety score of 60%, with analyses identifying inadequate robustness and risk awareness as fundamental safety defects.

  • Takeaways & Limitations

    Defense prompts alone have limited efficacy, indicating that agent safety cannot be fully addressed by modifying inference prompts alone.

  • Takeaways & Limitations

    Constructing diverse, high-quality agent safety test cases remains difficult because many automatically generated cases require substantial revision and expert handling.

Abstract

from arXiv · show

As large language models (LLMs) are increasingly deployed as agents, their integration into interactive environments and tool use introduce new safety challenges beyond those associated with the models themselves. However, the absence of comprehensive benchmarks for evaluating agent safety presents a significant barrier to effective assessment and further improvement. In this paper, we introduce Agent-SafetyBench, a comprehensive benchmark designed to evaluate the safety of LLM agents. Agent-SafetyBench encompasses 349 interaction environments and 2,000 test cases, evaluating 8 categories of safety risks and covering 10 common failure modes frequently encountered in unsafe interactions. Our evaluation of 16 popular LLM agents reveals a concerning result: none of the agents achieves a safety score above 60%. This highlights significant safety challenges in LLM agents and underscores the considerable need for improvement. Through failure mode and helpfulness analysis, we summarize two fundamental safety defects in current LLM agents: lack of robustness and lack of risk awareness. Furthermore, our findings suggest that reliance on defense prompts alone may be insufficient to address these safety issues, emphasizing the need for more advanced and robust strategies. To drive progress in this area, Agent-SafetyBench has been released at https://github.com/thu-coai/Agent-SafetyBench/ to facilitate further research in agent safety evaluation and improvement.

1 Introduction

Agent-SafetyBench addresses safety risks arising when LLMs operate as tool-using agents in interactive environments, beyond unsafe text generation. It provides broad coverage and reveals substantial safety weaknesses across current agents.

  • Agent safety includes behavioral risks from interactions with complex environments, such as disclosing sensitive information or modifying order quantities unintentionally.
  • Agent-SafetyBench covers 349 interactive environments, including novel environments without publicly available APIs.
  • The benchmark evaluates 8 safety-risk categories, 2,000 test cases, and 10 representative failure modes.
  • All 16 tested LLM agents achieve overall safety scores below 60%.
  • Failure-mode and helpfulness analyses identify inadequate robustness and insufficient awareness of tool-use risks as two fundamental safety defects.
  • The benchmark contributes a broader, more systematic evaluation of agent safety across environments, risks, and failure modes.

2 Related Work

Prior LLM safety benchmarks primarily assess textual outputs and jailbreak resistance, while agent safety also concerns harmful behavior during environmental interaction. Agent-SafetyBench builds on this distinction by organizing agent risks into a dedicated taxonomy.

  • Agent-SafetyBench categorizes safety risks into 8 categories that cover both content-level and behavior-level issues.
  • Existing LLM safety benchmarks use taxonomies, input instructions, multiple-choice questions, and jailbreak techniques to assess content-level safety.
  • Agent safety extends beyond unsafe content generation to potentially harmful behaviors executed in interactive environments.

3 AGENT-SAFETYBENCH Construction

AGENT-SAFETYBENCH combines eight risk categories, structured interaction environments, and annotated failure modes into a broad agent-safety benchmark. Its construction expands and refines existing data, adds diverse test cases, and applies manual, automatic, and cross-validation quality controls.

  • Risk Categories: The benchmark organizes agent safety into 8 distinct risk categories covering content-level and behavior-level safety issues.
  • Data Format and Environments: Each test case records risks, an instruction or dialog, relevant environments, and anticipated failure modes.Environment specifications include names, tools, and configurable initialization parameters.
  • Data Format and Environments: The environments use a dual-layer implementation consisting of a JSON-based tool schema and a corresponding Python class.
  • Data Augmentation: Data augmentation addresses insufficient quantity and category coverage by generating diverse cases with expected risky behaviors, yielding 1,124 new valid test cases.The augmentation process was motivated by low diversity and low quality in direct generation.
  • Quality Control: Quality control includes author review of all 2,000 test cases, automatic environment validation, and cross-validation of safety labels.
  • Scorer: A finetuned Qwen-2.5-7B-Instruct scorer reaches 91.5% accuracy on 200 Gemini-1.5-Flash interactions, compared with 75.5% for direct GPT-4o scoring.

4 Experiments

The experiments evaluate 16 tool-using LLM agents through iterative tool interaction and scorer-based safety labeling. Results show broadly low safety, especially for behavior and difficult risk categories, while defense prompts provide only limited improvements.

  • Evaluation Setup: 16 LLM agents are evaluated by iterating between agent decisions, tool execution, updated interaction history, and final responses.
  • Evaluation Setup: Safety scores are computed as the ratio of safe labels assigned by the finetuned scorer across cases.
  • Main Results: All agents score below 60% overall, with some below 20%; stronger and proprietary agents generally perform better than weaker and open-source counterparts.
  • Main Results: Behavior safety has more significant flaws than content safety, despite most behavior cases lacking explicit jailbreak attacks.
  • Main Results: 15.6% is the averaged score for the “Spread” category, which is especially challenging because agents may spread unsafe information without validation.
  • Failure Modes: Failure-mode analysis identifies lack of robustness and lack of risk awareness as two critical safety vulnerabilities.Robustness concerns tool use across scenarios, where minor inaccuracies can have disproportionately large effects.
  • Helpfulness and Safety: Agents generally show lower safety ratios on unfulfillable than fulfillable cases, indicating greater unsafe behavior when safe completion is impossible.
  • Helpfulness and Safety: Strong agents can combine high safety ratios with helpfulness on fulfillable cases by analyzing tasks and executing appropriate tool actions rather than merely refusing.

5 Conclusion

AGENT-SAFETYBENCH evaluates LLM-agent safety across diverse environments and test cases, revealing substantial vulnerabilities among representative agents. The analysis identifies robustness and risk awareness as fundamental safety defects, while prompt-only modifications show limited efficacy.

  • AGENT-SAFETYBENCH combines diverse interaction environments and test cases to evaluate the safety of LLM agents.
  • No agent surpasses a total safety score of 60%.
  • Failure-mode and helpfulness analyses identify lack of robustness and risk awareness as two fundamental safety defects.
  • Additional experiments suggest that solely modifying the inference prompt has limited efficacy in improving agent safety.

A Risk Categories

The benchmark uses a finer-grained taxonomy for behavior-level safety involving environments and tools, while retaining coarser categories for content-level safety.

  • Figures 6 and 7 define and illustrate 8 categories of safety risks using unsafe interaction records and explanations.
  • Behavior-level safety receives finer-grained treatment because it concerns interactions with environments and tools.
  • Content-level safety uses relatively coarse categories for unsafe information or misinformation and harmful or vulnerable code.

B Failure Modes

The benchmark organizes unsafe agent behavior into 10 representative failure modes, documented through definitions, examples, and explanations.

  • Figures 8, 9, and 10 present definitions and illustrative unsafe interaction records for 10 representative failure modes.
  • Figures 6 and 7 provide risk-category examples and explanations that contextualize the failure-mode taxonomy.

C Details for Implementing Environments

The environments use standardized tool schemas paired with executable Python implementations, while augmentation prompts generate diverse, risk-focused test cases and scenarios.

  • Environment implementation: Each environment combines a JSON-based tool schema with a corresponding Python class.
  • Environment implementation: JSON schemas specify tool names, descriptions, and parameters, while Python classes implement tool functionality and customizable initialization.
  • Environment implementation: The tool schema follows mainstream standards used by systems such as OpenAI and Claude for API-based agent integration.
  • Data augmentation: In-context learning with GPT-4o generates potential risky behaviors and uses completed risky behaviors as examples for new test cases.
  • Data augmentation: Test-case prompts divide risks into 8 categories and require cases to specifically reveal the selected risk type.
  • Data augmentation: Augmentation prompts generate distinct cases across scenarios, topics, and expected risky actions while avoiding explicitly malicious user intent.

F Details for Data Cross-Validation

Cross-validation found that most sampled test cases and safety labels were judged reasonable, supporting the quality and reliability of the benchmark annotations.

  • 98% of 200 randomly sampled test cases were deemed reasonable during cross-validation by different authors.The review assessed test-case reasonability, including risk categorization and failure-mode design.
  • 97.5% of 200 randomly sampled interaction-record safety labels were deemed reasonable by different authors.The cross-validation evaluated the reliability of safety annotations.
  • The authors conclude that the constructed test cases and assigned safety labels have a high degree of quality and reliability.

G Scorer Details

The scorer model is fine-tuned on author-labeled interaction records and prompted to assess both textual responses and tool-use behaviors for safety. Its fine-tuning configuration is documented separately.

  • 4,000 annotated interaction records were used to fine-tune the scorer, including 2,186 unsafe and 1,814 safe instances.The scorer was initialized from Qwen2.5-7B-Chat and trained on records produced by GPT-4o-mini and Claude-3.5-Sonnet.
  • Scorer inputs include environment information, the dialogue, and the assistant’s tool-use actions.
  • The scorer evaluates assistant responses and behaviors by considering textual content and safety implications of tool execution within an environment.
  • The scorer prompt requires a safety label of safe or unsafe together with a detailed analysis.
  • The paper provides hyperparameters for fine-tuning the scorer model in Table 9.

H Experimental Details

The experiments standardize decoding, agent tool-calling behavior, helpfulness judgments, defense prompts, and supporting datasets and model licenses. The setup includes safeguards for invalid outputs and explicit criteria for helpfulness.

  • Decoding Parameters: Sampling temperature is 0 by default, with temperature 1 used for fewer than 1% of invalid-output cases; generation is capped at 2,048 new tokens per turn.
  • Agent Prompts: Agents receive one task description, choose actions stepwise, invoke one tool at a time, and wait for each result before continuing.
  • Helpfulness Evaluation: Helpfulness is judged by whether the assistant attempts to address or advance the user’s goal, regardless of whether its behavior is safe.
  • Defense Prompts: The defense prompts instruct agents to avoid harmful content, incomplete or incorrect tool calls, ignored constraints, and unvalidated tool results.
  • Licenses: The experiments use cited open-source datasets and models, while AGENT-SAFETYBENCH and its evaluation code are distributed under the MIT license.

J Limitations

The benchmark primarily tests commonsense safety rather than advanced domain-specific knowledge, and its automatically generated cases require substantial manual revision. The authors also note possible misuse risks and describe extensibility through configurable environments.

  • Most non-code test cases rely primarily on commonsense reasoning, leaving scenarios requiring advanced domain-specific knowledge for future work.
  • A large proportion of automatically generated test cases still requires substantial revision to meet suitable agent-safety standards.
  • The authors report that general crowdworkers could not reliably revise cases, evaluate interaction safety, or annotate failure modes, so these tasks were performed by the authors.
  • Benchmark test cases might inadvertently inspire adversarial attackers, although the sandbox design makes direct application to production scenarios non-trivial.
  • Practitioners can configure existing environments or define new ones using a Python class and JSON-based tool descriptions.
Loading 2412.14470v2…