Pith. sign in

REVIEW 4 major objections 5 minor 38 references

$S^3$: Improving Agent Safety through Multi-Stage Defense

T0 review · 4 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read The paper claims that composing stage-specific safety skills under a guard agent protects LLM agents across every workflow stage at once, and backs the claim with a 0% attack success rate on all six risk types of its new benchmark.

desk verdict Useful composable abstraction for agent safety, but the near-perfect empirical results are largely built into the benchmark; the claims need to be scaled back or tested on independent risks. read the letter →

arxiv 2608.02683 v1 pith:M5VMSK5L submitted 2026-08-03 cs.CR cs.AI

Zibo Xiao , Haoyu Wang , Jun Sun This is my paper · ORCID
classification cs.CRcs.AI
keywords LLMagentsmulti-stagedefensestage-specificsafetyskillsguardagentpromptinjectionmemorypoisoningagenticworkflowbenchmark
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper claims that the right way to make LLM agents safe is to defend each workflow stage separately and then orchestrate those defenses: it introduces Stage-Specific Safety Skills, a common format that wraps any existing safety mechanism with explicit stage semantics, and S3, a framework in which an external guard agent invokes these skills at the right moments and repairs the task when a risk is found. The motivation is that risks in agent workflows arise at specific stages — input, memory, planning, tool selection, tool execution, and tool observation — and that single-stage defenses leave other stages exposed while heterogeneous designs resist integration. S3's automated transformation pipeline converts existing safety designs into these skills, and its recovery module removes the risk-inducing factor instead of aborting the task, so benign objectives survive. On the new Multi-Stage Risk Benchmark (675 tasks, six risk types injected at six stages), the complete S3 reaches a 0% attack success rate on all six risk types and 100% task safe completion on five of six (97.8% on the sixth), while every single-stage defender and both multi-stage baselines fail on at least one stage. If correct, agent safety can be assembled from existing parts rather than rewritten, and the hard problem becomes naming the risks.

What carries the argument

The Stage-Specific Safety Skill is the load-bearing abstraction: a standardized Skill.md specification that records the target workflow stage, the inspection information, the required resources (scripts and rule files), the checking procedure, and the mitigation strategy, so that any safety design can be wrapped and invoked by one orchestrator. Four mechanisms carry the argument. The guard agent — an external LLM, deliberately separate from the main agent — selects and runs skills, embodying the principle that the entity being regulated must not control its own safety enforcement. The transformation pipeline (Method Model, Skill Write, Skill Test, Skill Refine) converts existing designs into skills and iterates until generated test cases pass, which is what the fidelity results measure. The recovery module, itself a system-level skill, turns a detected risk into an actionable repair — removing malicious content from an observation, or calling tools to contain an environment incident — which is what preserves task completion and distinguishes S3 from its own no-recovery ablation. Finally, the layered trigger mechanism (stage trigger, rule-based filter, guard-agent decision) prunes unnecessary invocations and serves as the knob that trades safety coverage against runtime overhead.

What would settle it

Build an attack the MSRB taxonomy does not name but real workflows allow — for instance, a cross-stage attack that injects a malicious tool observation and simultaneously plants a poisoned memory, or a stale-validity attack where a verified plan or tool selection is swapped between the safety check and the execution (the time-of-check-to-time-of-use pattern the paper itself lists as future work). If such an attack drives S3's attack success rate well above 0% while the six MSRB risk types stay at 0%, the claim of comprehensive multi-stage protection would be bounded by the benchmark's risk coverage rather than by the defense architecture.

Watch

Extended reading notes

Core claim

The paper's central claim is that S3 provides comprehensive multi-stage protection while preserving benign task completion, consistently outperforming representative state-of-the-art baselines in both safety effectiveness and utility preservation. The underlying discovery is that safety designs with completely different mechanisms — rule-based plan checkers, reasoning-consensus memory filters, parse-and-sanitize observation guards, environment-aware incident responders — can be normalized into one executable interface, the safety skill, so that a guard agent can treat them uniformly. S3 detects risks at the stage where they emerge, before they propagate through intermediate states, and its recovery module follows each skill's stage-specific recovery message to strip injected content or repair the environment, allowing the benign part of the task to continue. The paper supports this claim with three results: on MSRB, complete S3 achieves 0% attack success across all six risk types and 100% task safe completion on five of six; the transformation pipeline reproduces original safety designs with disagreement rates below 10%; and the layered trigger mechanism plus post-recovery guidance contain the runtime cost, at the price of an explicit trade-off between safety coverage and overhead.

Load-bearing premise

The load-bearing premise is that the six risk types in the MSRB benchmark are representative of the risks real agent workflows face, and that the safety rules inside the strongest skills — which the paper says are tailored to the risk patterns in MSRB — stay valid outside the benchmark; if either fails, the near-perfect numbers measure something narrower than comprehensive multi-stage safety.

Editorial extensions

If this is right

  • A safety mechanism built for one workflow stage can be dropped into any agent framework that adopts the skill interface, since the transformation pipeline converts the design once and the guard agent handles the rest; the paper's implementation on DeepAgent is presented as framework-agnostic, needing only minimal changes for other agent SDKs.
  • Risks get caught where they originate, which the paper argues is why S3 preserves benign completion: later-stage interception of a propagated risk (the pattern seen with AgentSpec under observation prompt injection) blocks the unsafe action but cannot restore the disrupted benign objective.
  • The layered trigger mechanism makes safety coverage and runtime overhead an explicit configurable trade: removing the rule-based filter raises guard invocations per task from roughly 11–16 to 25–37, while dropping recovery slashes overhead but collapses task safe completion to near zero.
  • Guard-agent quality is not the binding constraint: results are consistent when the guard switches from DeepSeek-V4-Pro to the weaker DeepSeek-V4-Flash (appendix E), so deployment can choose a cheaper model.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If S3 is right, the binding constraint on agent safety shifts from defense engineering to risk enumeration: a workflow is only as protected as the set of stage–risk pairs its skill library can name, so the research frontier becomes benchmarks and rule sets for unmodeled stages, cross-stage transitions, and attacks that do not localize to a single stage.
  • The paper's appendix floats cross-stage coordination (distilling an incident detected during execution into rules that prevent it at the planning stage); carried further, this would turn S3 from a static composition into an adaptive system that learns from its own recoveries.
  • The fidelity result was demonstrated on deterministic safety designs (rules, scripts, parse logic); a natural extension is measuring whether the sub-10% disagreement holds when transforming LLM-judged, non-deterministic safety designs, where the decision behavior to preserve is itself stochastic.
  • The safety skill library plus the automated transform pipeline open a possibility the paper only gestures at: safety capability becomes portable infrastructure that can be audited and updated independently of any single agent framework.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper introduces Stage-Specific Safety Skills, a unified abstraction that represents heterogeneous safety designs as composable components with explicit workflow-stage semantics, and proposes S3, a multi-stage defense framework in which a guard agent orchestrates these skills to detect and mitigate risks across an agentic workflow. The authors additionally construct the Multi-Stage Risk Benchmark (MSRB) with six risk types targeting six workflow stages, and present experiments claiming that S3 consistently outperforms representative baselines in both safety effectiveness and utility preservation. The paper includes an automated transformation pipeline for converting existing safety designs into skills, a community-driven skill library, and an open-source implementation.

Significance. The abstraction of stage-specific safety skills is a potentially useful organizational principle for composing heterogeneous agent-safety mechanisms, and the transformation pipeline, public implementation, and reproducible benchmark construction are contributions that could support future work in this area. If the empirical claims were supported by an independent evaluation, the results would be of considerable interest to the agent-safety community. However, the current evaluation design makes the central claim of 'comprehensive multi-stage protection' and 'consistently outperforms' unsubstantiated for risks beyond the authors' own benchmark, because MSRB is co-designed with the integrated safety designs and the safety rules are explicitly tailored to MSRB's risk patterns.

major comments (4)
  1. [§5.1, Table 1, §4.1] The evaluation is circular in a load-bearing way: Table 1 maps each of the six MSRB risk types to exactly one of the six safety designs that S3 composes (LC-GuardRail, A-MemGuard, AgentSpec*/AgentSpec, AIR, ParseData), and S3 is the composition of those six designs. With this one-to-one benchmark-to-skill alignment, near-perfect ASR and TSR on MSRB are forced by construction and provide no evidence about protection for risks outside this tailored taxonomy. To support the 'comprehensive' claim, the authors need to evaluate on an independent, pre-existing benchmark or on a held-out set of risk types not aligned with the integrated skills.
  2. [§5.2] The manuscript concedes that the rule-based components achieve strong results 'in light of the high-quality safety rules tailored to the risk patterns in MSRB.' This admission directly undermines the claim that S3 'consistently outperforms representative state-of-the-art baselines' in a general sense, because on a different risk distribution the rules would likely offer far less coverage. The evaluation should include experiments with non-tailored rules or a sensitivity analysis showing how S3's performance degrades as rule coverage is reduced.
  3. [§4.2, Algorithm 1, §5.3] The fidelity check for the transformation pipeline (RQ2) does not break the circularity: the Skill Test step generates test inputs and expected binary results from the Skill.md specification produced by the same transform agent, and the Skill Refine step then iterates until those self-generated tests pass. The Disagreement Rate therefore measures consistency between the transformed skill and its own generation process, not fidelity to the original safety design. The authors should validate transformed skills against independently annotated test cases or against decision traces from the original safety design executed on inputs not seen during refinement.
  4. [§5.1, §5.4, Tables 2–4] No error bars, confidence intervals, significance tests, or per-risk-type instance counts are reported anywhere. Many comparisons in Tables 2 and 4 involve differences of a few percentage points (e.g., 97.8% vs. 100%), which, given 675 total task instances, could easily reflect one or two task outcomes rather than a meaningful superiority. The claim that S3 'consistently outperforms' baselines requires statistical support, and the authors should either report variance across repeated runs or apply appropriate significance tests.
minor comments (5)
  1. [Throughout] The capitalization of the framework name is inconsistent: the title uses '$S^3$', while the body alternates between 'S3' and 'S 3' (e.g., 'we propose S3' in the abstract vs. 'we propose S 3' in Section 1). Please standardize.
  2. [§3] The problem statement explicitly excludes risks at the output stage, yet the abstract and conclusion claim 'comprehensive' protection over the workflow. The exclusion of output-stage risks should be stated in the abstract or conclusions, or 'comprehensive' should be qualified.
  3. [§5.1] The text states that MSRB contains 675 task instances across nine task categories and three hazard categories, but Table 5 lists only a few example categories. Please provide a complete breakdown of the nine categories and the distribution of instances per risk type.
  4. [Appendix B.1] The mapping of AgentSpec to the tool-selection stage is explained, but the original AgentSpec formulation treats planning and tool selection as a single stage. This stage-splitting choice affects the interpretation of the 'stage-specific' coverage in Table 8 and should be justified more explicitly.
  5. [§5.3, Table 3] The Fidelity results report Block Rates and Disagreement Rates as percentages without indicating the number of hazardous and benign instances per stage. Since the benchmark is imbalanced across risk types, instance counts are needed to interpret the reported rates.

Circularity Check

2 steps flagged · score 6.0 of 10

S3's central effectiveness claim is substantially forced by benchmark construction: MSRB's six risk types are one-to-one with the six composed safety skills, §5.2 admits rules are tailored to MSRB, and the Skill Test step validates skills against labels generated from the same Skill.md.

  1. fitted input called prediction [Section 5.1 (Benchmark and Safety Designs), Table 1; Section 5.2 (Effectiveness Analysis)]
    "As shown in Table 1, we select six representative safety designs covering different stages of the agentic workflow. ... Their effectiveness, however, should be interpreted in light of the high-quality safety rules tailored to the risk patterns in MSRB."

    The benchmark's six risk types are paired one-to-one with the six safety designs that S3 integrates: Table 1 maps Direct Prompt Injection to Input and LC-GuardRail, Memory Poisoning to Memory and A-MemGuard, Backdoor PoT to Planning and AgentSpec*, Selection Perturbation to Tool Selection and AgentSpec, Environment Perturbation to Tool Execution and AIR, and Observation Prompt Injection to Tool Observation and ParseData. S3's evaluated configuration is the union of these same designs, and Section 5.2 explicitly admits that the rule-based designs perform well because their rules are tailored to MSRB's risk patterns.

  2. self definitional [Section 4.2 (Safety Skill Transformation, Step 3 'Skill Test'); Algorithm 1]
    "Each test case is represented as a tuple (Resources,Test Input,Expected Result), where the test input corresponds to the target stage ... and the expected result is a binary label (i.e., safe or unsafe). The test input and resources are provided to the guard agent equipped with the generated safety skill, and its output is compared with the expected result to determine whether the skill preserves the decision behavior of the original safety design."

    The expected result is generated from the same Skill.md specification that is under test, and any mismatch triggers refinement of that specification (Algorithm 1, lines 15-16). This loop can only establish that the transformed skill agrees with its own LLM-generated specification, not that it agrees with the original safety design's decisions. The claim that the Skill Test checks preservation of the original decision behavior is therefore not supported by this step; the separate RQ2 comparison in Section 5.3 does provide genuine evidence, which is why this is a partial rather than total circularity.

full rationale

The S3 abstraction itself has independent content: composing heterogeneous external safety designs under a guard agent with a recovery module is not inherently circular, and I found no problematic self-citation chain or imported uniqueness theorem. However, the headline empirical claim that S3 'consistently outperforms' and provides 'comprehensive multi-stage protection' is evaluated on MSRB, a benchmark constructed by the same authors whose six risk types are one-to-one with the six safety designs integrated into S3. Section 5.2 explicitly admits the rules are 'tailored to the risk patterns in MSRB,' so the near-perfect ASR/TSR results are largely the expected consequence of testing the union of the six stage-specific defenses on a benchmark that enumerates exactly those stages; this is a benchmark-to-defense alignment that reduces the central empirical 'prediction' by construction. Separately, the Skill Test step in the transformation pipeline derives expected labels from the Skill.md specification under test, making its internal fidelity check self-referential; the later RQ2 comparison to original designs provides real evidence and prevents the fidelity claim from collapsing entirely, which keeps the score at 6 rather than higher. The paper's engineering contributions remain meaningful, but the published evaluation does not yet independently establish comprehensive protection beyond the tailored risk taxonomy.

Assumptions & free parameters 4 free parameters · 5 assumptions · 6 invented entities

The central claims rest on a fixed workflow decomposition, stage-local risk detectability, the independence of the guard agent, the faithfulness of the LLM transform agent, and the cooperation of the main agent with recovery guidance. The hand-chosen safety rules and prompt wording are tuned to the authors' benchmark and directly influence the reported results.

free parameters (4)
  • AgentSpec/AIR safety rule sets = not published; JSON rule files referenced
    Hand-crafted rules such as unsafe_item_in_heat_appliance_hazard encode the specific hazardous actions in MSRB (e.g., putting a fork or credit card in a microwave); these rules are integrated into S3 and are explicitly acknowledged as tailored to the benchmark.
  • Post-recovery guidance prompt wording = exact text in Listing 2
    The instruction telling the main agent to 'skip' the hazardous subtask and continue only the benign task is hand-written and is directly responsible for the high TSR/TCR numbers.
  • Stage-mapping of safety designs = AgentSpec mapped to tool selection, AgentSpec* to planning, etc.
    The decision to split the original AgentSpec planning+selection into two stages and to map each design to one stage is a modeling choice that makes the stage-specific composition align with the risk types.
  • Rule-based filter conditions = not specified in detail
    The layered trigger mechanism's second layer relies on 'lightweight predefined conditions' whose exact content is not described; these conditions affect which safety checks run and thus the measured overhead.
assumptions (5)
  • domain assumption The agentic workflow is fixed as input, memory, planning, tool selection, tool execution, tool observation, output.
    Section 3 and Figure 1; the entire stage-specific framework depends on this fixed stage decomposition, which may not hold for other agent architectures (e.g., hierarchical agents, recursive skills).
  • domain assumption Risks arise from stage-specific information and can be detected at the stage where they emerge.
    Section 4.1; S3's design assumes each risk is tied to a single workflow stage and can be identified from that stage's information, ignoring cross-stage or transition risks acknowledged as future work in Appendix D.
  • domain assumption The guard agent is independent of the main agent and cannot be manipulated by it.
    Section 4.1 states the entity being regulated should not control safety enforcement, but the paper provides no mechanism or test preventing the main agent from influencing the guard agent through tool observations or prompts.
  • domain assumption The LLM transform agent can faithfully abstract and refine safety designs from source materials.
    Section 4.2 and Algorithm 1; the transformation pipeline assumes the transform agent (DeepSeek-V4-Pro) correctly extracts core safety logic and that generated test cases with expected labels are sufficient to validate fidelity.
  • domain assumption The main agent follows the recovery module's post-recovery guidance.
    Section 4.3 and Listing 2; the utility preservation result assumes the main agent skips the hazardous subtask and continues the benign task when instructed, rather than retrying, rephrasing, or ignoring the guidance.
invented entities (6)
  • Stage-Specific Safety Skill
    purpose: A standardized Skill.md abstraction representing a safety capability tied to one workflow stage, enabling composition and orchestration.
    The abstraction exists only inside the paper's framework and repo; no external standard or independent use is demonstrated, and the fidelity of skills is validated only against the authors' own test cases.
  • Guard Agent
    purpose: An external LLM agent that invokes safety skills at the appropriate stages and coordinates recovery.
    It is a software component within S3; no independent falsifiable prediction outside the paper's benchmark is provided.
  • Transform Agent
    purpose: An LLM that converts existing safety designs into safety skills through a four-step pipeline.
    Its output is evaluated only on the authors' test cases and MSRB-derived instances.
  • Recovery Module
    purpose: A component that removes or mitigates risk-inducing factors to preserve benign task completion after a risk is detected.
    Its behavior is demonstrated only in the paper's simulated embodied tasks (e.g., spilling water on appliances).
  • Layered Trigger Mechanism
    purpose: Filters candidate safety skills via stage trigger, rule-based filter, and guard-agent decision to reduce invocation overhead.
    Internal optimization; efficiency is measured only by the authors' GIC/RSC metrics.
  • Multi-Stage Risk Benchmark (MSRB) independent evidence
    purpose: A benchmark of 675 task instances across six risk types and nine task categories for evaluating stage-specific agent defenses.
    If released, the benchmark serves as an external artifact other researchers can run against, giving a falsifiable handle outside the paper's own evaluation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of $S^3$: Improving Agent Safety through Multi-Stage Defense." pith.science (2026). https://pith.science/paper/M5VMSK5L

@misc{pith2026260802683,
  author       = {Pith},
  title        = {Pith review of: $S^3$: Improving Agent Safety through Multi-Stage Defense},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/M5VMSK5L}},
  note         = {Machine review of arXiv:2608.02683}
}
abstract

Large Language Model (LLM) agents rely on multi-stage agentic workflows, with stages such as memory, planning, and tool execution, to accomplish complex tasks. However, risks may emerge at different stages, propagate across steps, and become difficult to detect and mitigate. Existing safety methods protect only isolated stages and are difficult to integrate, leaving agents without comprehensive protection throughout the workflow. To address these limitations, we introduce Stage-Specific Safety Skills, a unified abstraction that represents heterogeneous safety designs as reusable and composable components with explicit stage semantics. We further develop an automated transformation pipeline that converts existing safety designs into reusable safety skills and establish a community-driven safety skill library. Building on this abstraction, we propose $S^3$, a multi-stage defense framework in which a guard agent orchestrates stage-specific safety skills for risk detection and mitigation throughout the agentic workflow. We also construct the Multi-Stage Risk Benchmark (MSRB) to evaluate representative risks across workflow stages. Experimental results show that $S^3$ consistently outperforms representative state-of-the-art baselines in both safety effectiveness and utility preservation. These results demonstrate the potential of stage-specific safety skills as a scalable and composable foundation for building resilient and trustworthy agent systems.

Figures

Figures reproduced from arXiv: 2608.02683 by the authors.

Figure 1
Figure 1. Overview of S 3 . skill invocation may compromise explicit stage alignment, leading to ambiguous or inconsistent invocation decisions. (2) The entity being regulated should not control its own safety enforcement. Accordingly, the main agent focuses on task execution, while the guard agent performs risk detection and mitigation. Stage-Specific Design. Unlike conventional agent skills, each safety skill is explicitly … view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 13 canonical work pages

  1. [1]

    arXiv preprint arXiv:2511.21990 , year=

    A Safety and Security Framework for Real-World Agentic Systems , author=. arXiv preprint arXiv:2511.21990 , year=

    arXiv

  2. [2]

    arXiv preprint arXiv:2510.02373 , year=

    A-memguard: A proactive defense framework for llm-based agent memory , author=. arXiv preprint arXiv:2510.02373 , year=

    arXiv

  3. [3]

    , author=

    AgentSpec: Customizable runtime enforcement for safe and reliable LLM agents. , author=. Proceedings of the IEEE/ACM International Conference on Software Engineering, ICSE , pages=

    work page

  4. [4]

    arXiv preprint arXiv:2602.11749 , year=

    AIR: Improving agent safety through incident response , author=. arXiv preprint arXiv:2602.11749 , year=

    arXiv

  5. [5]

    Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers) , pages=

    PIGuard: Prompt injection guardrail via mitigating overdefense for free , author=. Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers) , pages=

  6. [6]

    2025 , howpublished =

    Agent Skills: A Simple, Open Format for Giving Agents New Capabilities , author =. 2025 , howpublished =

    work page 2025

  7. [7]

    2024 , howpublished =

    Model Context Protocol , author =. 2024 , howpublished =

    work page 2024

  8. [8]

    2022 , note =

    Harrison Chase , title =. 2022 , note =

    work page 2022

Show all 38 references
  1. [9]

    Proceedings of the 36th annual acm symposium on user interface software and technology , pages=

    Generative agents: Interactive simulacra of human behavior , author=. Proceedings of the 36th annual acm symposium on user interface software and technology , pages=

  2. [10]

    2025 , howpublished =

    Peter Steinberger , title =. 2025 , howpublished =

    2025

  3. [11]

    Hermes Agent: A Self-Evolving Open-Source AI Agent with Closed-Loop Skill Learning , year =

  4. [12]

    Operator: An AI Agent for Web Automation , year =

  5. [13]

    arXiv preprint arXiv:2312.06674 , year=

    Llama guard: Llm-based input-output safeguard for human-ai conversations , author=. arXiv preprint arXiv:2312.06674 , year=

    arXiv

  6. [14]

    arXiv preprint arXiv:2309.07875 , year=

    Safety-tuned llamas: Lessons from improving the safety of large language models that follow instructions , author=. arXiv preprint arXiv:2309.07875 , year=

    arXiv

  7. [15]

    arXiv preprint arXiv:2505.23020 , year=

    Agentalign: Navigating safety alignment in the shift from informative to agentic large language models , author=. arXiv preprint arXiv:2505.23020 , year=

    arXiv

  8. [16]

    arXiv preprint arXiv:2507.08270 , year=

    Agent Safety Alignment via Reinforcement Learning , author=. arXiv preprint arXiv:2507.08270 , year=

    arXiv

  9. [17]

    2025 , note =

    OpenAI Agents SDK (Python) , howpublished =. 2025 , note =

    2025

  10. [18]

    arXiv preprint arXiv:2601.05504 , year=

    Memory poisoning attack and defense on memory based llm-agents , author=. arXiv preprint arXiv:2601.05504 , year=

  11. [19]

    arXiv preprint arXiv:2509.08646 , year=

    Architecting resilient llm agents: A guide to secure plan-then-execute implementations , author=. arXiv preprint arXiv:2509.08646 , year=

    arXiv

  12. [20]

    arXiv preprint arXiv:2601.10156 , year=

    ToolSafe: Enhancing Tool Invocation Safety of LLM-based agents via Proactive Step-level Guardrail and Feedback , author=. arXiv preprint arXiv:2601.10156 , year=

  13. [21]

    arXiv preprint arXiv:2602.14281 , year=

    MCPShield: A security cognition layer for adaptive trust calibration in Model Context Protocol agents , author=. arXiv preprint arXiv:2602.14281 , year=

  14. [22]

    arXiv preprint arXiv:2601.04795 , year=

    Defense Against Indirect Prompt Injection via Tool Result Parsing , author=. arXiv preprint arXiv:2601.04795 , year=

  15. [23]

    arXiv preprint arXiv:2601.18491 , year=

    AgentDoG: A Diagnostic Guardrail Framework for AI Agent Safety and Security , author=. arXiv preprint arXiv:2601.18491 , year=

    arXiv

  16. [24]

    arXiv preprint arXiv:2508.00500 , year=

    Pro2Guard: Proactive Runtime Enforcement of LLM Agent Safety via Probabilistic Model Checking , author=. arXiv preprint arXiv:2508.00500 , year=

    arXiv

  17. [25]

    arXiv preprint arXiv:2604.02022 , year=

    ATBench: A Diverse and Realistic Trajectory Benchmark for Long-Horizon Agent Safety , author=. arXiv preprint arXiv:2604.02022 , year=

    arXiv

  18. [26]

    arXiv preprint arXiv:2603.28807 , year=

    SafeClaw-R: Towards Safe and Secure Multi-Agent Personal Assistants , author=. arXiv preprint arXiv:2603.28807 , year=

  19. [27]

    arXiv preprint arXiv:2601.10338 , year=

    Agent Skills in the Wild: An Empirical Study of Security Vulnerabilities at Scale , author=. arXiv preprint arXiv:2601.10338 , year=

    arXiv

  20. [28]

    arXiv preprint arXiv:2604.02837 , year=

    Towards Secure Agent Skills: Architecture, Threat Taxonomy, and Security Analysis , author=. arXiv preprint arXiv:2604.02837 , year=

    arXiv

  21. [29]

    arXiv preprint arXiv:2604.13630 , year=

    SafeHarness: Lifecycle-Integrated Security Architecture for LLM-based Agent Deployment , author=. arXiv preprint arXiv:2604.13630 , year=

    arXiv

  22. [30]

    2026 , eprint=

    Defense Against Indirect Prompt Injection via Tool Result Parsing , author=. 2026 , eprint=

    2026

  23. [31]

    The eleventh international conference on learning representations , year=

    React: Synergizing reasoning and acting in language models , author=. The eleventh international conference on learning representations , year=

  24. [32]

    International Conference on Learning Representations , volume=

    Agent security bench (asb): Formalizing and benchmarking attacks and defenses in llm-based agents , author=. International Conference on Learning Representations , volume=

  25. [33]

    2025 , howpublished =

    LangChain , title =. 2025 , howpublished =

    2025

  26. [34]

    arXiv preprint arXiv:2505.03574 , year=

    Llamafirewall: An open source guardrail system for building secure ai agents , author=. arXiv preprint arXiv:2505.03574 , year=

    arXiv

  27. [35]

    2026 , url =

    Anonymous , title =. 2026 , url =

    2026

  28. [36]

    arXiv preprint arXiv:2412.13178 , year=

    Safeagentbench: A benchmark for safe task planning of embodied llm agents , author=. arXiv preprint arXiv:2412.13178 , year=

  29. [37]

    IEEE Access , year=

    Agentic AI security: Threats, defenses, evaluation, and open challenges , author=. IEEE Access , year=

  30. [38]

    2025 , eprint=

    Agent Security Bench (ASB): Formalizing and Benchmarking Attacks and Defenses in LLM-based Agents , author=. 2025 , eprint=

    2025

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.