PaperlayerView exact revision on arXiv

Source-linked AI summary

Can Agents Trust Their Skills? Uncovering Unsafe Chains of Trust in Skill-Based LLM Agents

Yan Wang, Zhihao Zhang, Ke Chen, Kai Chen, Yaqin Zhang, Duohe Ma, Jun Dai, Xiaoyan Sun

arXiv:2609.39065v1cs.CRcs.AI

TL;DR

Installed skills can let malicious content guide agents’ use of authority delegated by users, while evidence about how skill content reaches harmful operations and how often this occurs in real agents is limited. TrustProbe combines source-to-sink analysis, realistic skill testing, and runtime verification to investigate these flows. Across 11 agents it finds 104 verified vulnerabilities, and real-world skills exercise identified vulnerable paths in 25.1% of tests.

  • Problem

    It is unclear how skill content reaches security-sensitive operations and how often these trust failures occur in real-world agents, despite the risk that installed malicious skills can guide delegated authority.

    Source: §1 · pp. 1–2

  • Method

    TrustProbe analyzes source-to-sink paths, evolves canary-injected realistic skill tests using feedback, and uses an oracle to confirm attacker control and observable harm.

    Source: §1 · p. 2, §4.5 · p. 7

  • Results

    Across 11 open-source agents, TrustProbe identifies 104 verified taint-style vulnerabilities, and 743 of 2,963 real-world skill-agent tests (25.1%) trigger the identified paths.

    Source: §1 · p. 2

  • Takeaways & Limitations

    The results show that third-party skill content can systematically reach and exercise authority delegated by users across heterogeneous agent frameworks.

    Source: §6 · p. 10

    The threat model assumes non-malicious agent developers and an uncompromised runtime environment.

    Source: §3.3 · p. 4

Abstract

from arXiv · show

LLM agents increasingly rely on installable skills, which are packages of instructions, code, and resources that equip them with task-specific capabilities and, once installed, can be automatically invoked across subsequent user tasks. This creates a chain of trust in which users delegate authority to agents, while agent frameworks admit skill-provided content into the agents' context with insufficient validation, allowing malicious skills to influence agent behavior under that delegated authority. Yet, little is known about whether this trust model adequately constrains untrusted skill content before it reaches security-sensitive operations, or how frequently such trust violations arise in real-world agents. We present TrustProbe, a framework for uncovering unsafe chains of trust in skill-based LLM agents. First, TrustProbe analyzes agent source code to identify source-to-sink call paths from skill-controlled inputs to security-sensitive operations. Second, it generates semantically realistic SKILL.md seeds with injected canaries and evolves them through feedback-guided scheduling and mutation. Finally, it validates vulnerabilities using an oracle that confirms attacker-controlled flows and verifies observable harm. Across 11 open-source agents, eight with more than 10,000 GitHub stars, TrustProbe identifies 104 taint-style vulnerabilities. Validation on a large corpus of real-world skills collected from public hubs such as ClawHub further shows that 25.1% of skill-agent trials exercise the identified vulnerable paths, with payload injection successfully weaponizing 15 of the vulnerabilities. These results reveal a systematic trust failure in skill-based LLM agents: untrusted skill content can reach security-sensitive operations and exercise authority delegated by users to their agents.

1 Introduction

Installed skills create a persistent trust boundary: malicious content can guide agents’ use of user-delegated authority, but tracing its path to harmful execution across agent frameworks is challenging. TrustProbe combines source-to-sink analysis, realistic skill tests, and runtime verification to measure these failures.

1 Introduction

  • Users delegate authority to agents while frameworks admit third-party skill content into their context, creating a chain of trust whose security implications motivate study of delivery, controls, and real-world prevalence.The introduction situates this concern alongside studies of attacks across agent workflows and skill files.Source: §1 · pp. 1–2
  • Once installed, malicious skill artifacts persist and can induce harmful actions upon later invocation without further attacker interaction, extending software-package supply-chain risks to agent instructions (Ohm et al., 2020; Zimmermann et al., 2019; Duan et al., 2021).Source: §1 · p. 1
  • Heterogeneous agent paths, costly nondeterministic runs, and often non-crashing exploitation make it difficult to trace skill content and separately establish attacker influence and harmful effects.A skill must meet framework loading conditions and be invoked through a plausible task before affecting execution.Source: §1 · p. 2
  • TrustProbe combines source-to-sink analysis, canary-injected realistic SKILL.md tests, feedback-guided mutation, and an oracle that verifies attacker influence and observable harm.Paired skill-versus-prompt and approval-control experiments examine how delivery and authorization mechanisms shape failures.Source: §1 · p. 2
  • Across 11 open-source agents, TrustProbe identifies 104 verified taint-style vulnerabilities; 743 of 2,963 real-world skill-agent tests (25.1%) trigger the identified paths, and minimal edits weaponize 15 vulnerabilities.Eight evaluated agents have more than 10,000 GitHub stars; only 33 of 104 vulnerabilities remain exploitable when the same skill bodies are delivered as direct prompts.Source: §1 · p. 2

2 Related Work

Prior work studies agent attacks, skill auditing, static analysis, and dynamic testing, but suspicious content or a candidate path alone does not establish harmful execution. This study examines how skill delivery and approval controls shape harmful operations across agent frameworks.

2 Related Work

  • Agent-security research covers attacks through prompts and external content, while benchmarks assess attacks and defenses across prompt, tool, and memory stages.The section also notes contextual-integrity benchmarks for inappropriate disclosure across information sources.Source: §2 · pp. 2–3
  • Static scanners and candidate call paths identify potential risks, but agent decisions and framework controls determine whether execution produces harm.The section distinguishes static checks and path identification from behavioral evidence.Source: §2 · p. 3
  • Dynamic taint analysis, skill audits, skill-file attack evaluation, and directed greybox fuzzing complement static inspection with evidence from actual execution.The paper’s stated distinction is its focus on how skill-delivery architectures and approval controls shape harmful operations across frameworks.Source: §2 · p. 3

3 Problem Statement

The paper defines trust failures as unvalidated skill-originated influence reaching operations that exercise an agent’s authority, then illustrates such a flow and specifies the attacker and assumptions. Its operational framing ties trust to observable framework mechanisms and execution evidence.

3.1 Trust Model and Failure Characterization

  • A trust failure occurs when skill-originated content reaches an authority-exercising operation without operation-specific validation, user consent, or provenance retained at enforcement.The paper operationalizes trust through discovery metadata, loading instructions, activation events, and prompt binding, then uses source-to-sink analysis and an oracle to examine attacker control and observable harm.Source: §3.1 · p. 3

3.2 Motivating Example

  • In the OpenClaw example, an installed skill’s bare argv value becomes an attacker-chosen shell command, and a marker file independently confirms execution.The user asks only to use the skill and follow its instructions; no validation boundary intervenes before the command is executed.Source: §3.2 · p. 4

3.3 Threat Model

  • The attacker is a malicious skill author whose installed payload persists until invocation; the model assumes non-malicious developers and an uncompromised runtime.The failure is a confused-deputy problem: the agent’s existing authority suffices, without privilege escalation (Hardy, 1988; MITRE, 2025).Source: §3.3 · p. 4

4 TrustProbe Design

TrustProbe combines source-to-sink analysis with realistic skill generation and feedback-guided testing, then separates evidence of attacker control from independently verified harm. Its design directs costly, nondeterministic agent runs toward candidate vulnerable paths.

4 TrustProbe Design

  • TrustProbe runs generated skills in fresh agent sessions, uses runtime traces to guide scheduling and mutation, and sends taint-confirmed paths to harm verification.Each iteration records security-sensitive calls, arguments, and stack frames.Source: §4 · p. 5

4.1 Source-to-Sink Analysis

  • Across 11 agents, static analysis yields 1,566 source-to-sink paths grouped into 202 sink-function pools for dynamic testing.Runtime taint confirmation and behavioral verification determine which paths constitute trust failures.Source: §4.1 · p. 5

4.2 LLM-assisted Seed Generation

  • For each candidate path, an LLM creates a valid SKILL.md with a plausible task and attacker-controlled fields; deterministic canaries link confirmed flaws to target-variant pairs.Seeds include loading metadata and task instructions that direct execution toward the target component.Source: §4.2 · p. 5

4.3 Feedback-driven Seed Scheduling

  • Seeds targeting the same sink are pooled; selection rewards semantic alignment and sink proximity while penalizing repeated seed and path selections.The semantic score uses execution traces, and distance measures hops from reached trace nodes to the sink.Source: §4.3 · p. 6

4.4 Rule-guided Seed Mutation

  • Four mutators target task semantics, metadata, rendered instructions, or sink arguments; oracle verdicts, feedback, and execution stage guide the repair direction.All four preserve the seed’s Inputs section.Source: §4.4 · p. 6

4.5 Bug Oracle

  • A path counts as exploitable only when canary-tainted sink flow along the audited path is confirmed and case-specific evidence independently verifies observable harm.Verification uses session records and artifacts, such as disclosed file contents, test-file writes, command output, or requests reaching a controlled endpoint.Source: §4.5 · pp. 6–7

5 Evaluation

The evaluation examines how widely trust failures occur, how delivery and approval mechanisms shape exploitation, whether real-world skills exercise vulnerable paths, and how TrustProbe compares with baselines and component ablations. It evaluates native skill-loading paths across 11 agents using isolated sessions and bounded campaign runs.

5.1 Experimental Setup

  • The study evaluates 11 TypeScript and Python agents through native skill-loading paths, using fresh sessions, isolated workspaces, and a fixed model for target agents and TrustProbe.Each sink-function pool receives at most eight mutation rounds or 15 minutes, whichever comes first; the main campaign uses permissive, non-interactive execution configurations.Source: §5.1 · p. 7, §5.2 · p. 7

5.2 RQ1: Prevalence of Trust Failures

  • 6.6% of audited paths satisfy the taint-confirmation predicate, and all taint-confirmed paths produce verified consequences, yielding 100% ASR across the evaluated agents.The campaign reaches 1,150 of 1,566 audited paths (73.4%) and 98 of 202 sink functions (48.5%); identified harms span command injection, file disclosure and modification, network requests, and code injection.Source: §5.2 · pp. 7–8, Table 1 · p. 8
  • 31 of 89 vulnerabilities covered by configurable approval layers (34.8%) remain exploitable, through paths that bypass checks or policies that omit affected operations.Approval blocks some cases when the relevant operation is both covered and checked.Source: §5.2 · p. 8

5.3 RQ2: Delivery Mechanisms

  • Direct-prompt delivery fails to reproduce 68.3% of the vulnerabilities verified through installed skills, with paired traces linking losses to changed execution routes or sink arguments.Framework-directed selection, explicit activation, and configured instructions position skill content as task guidance in ways ordinary prompt delivery does not.Source: §5.3 · pp. 8–9, Table 2 · p. 8

5.4 RQ3: Real-World Exposure

  • 743 of 2,963 skill-agent test runs (25.1%) trigger an audited vulnerable path, and minimal payload edits convert 15 evaluated triggering skills into attacks.Observed outcomes include remote code execution, credential exfiltration, OAuth phishing, and connections to attacker-controlled MCP servers; the trigger rate measures exposure, not whether original skills are malicious.Source: §5.4 · p. 9

5.5 RQ4: Baseline Comparison

  • The baseline comparison uses 20 dynamically verified vulnerabilities as its reference set; LLMSmith reports are 98.5% false positives, while adapted AgentFuzz produces no verified findings in completed valid runs.LLMSmith’s modeled sinks are limited to eval, exec, and subprocess.run; the comparison covers four Python agents, and recall measures recovery of the reference set rather than total vulnerability coverage.Source: §5.5 · pp. 9–10, Table 3 · p. 9

5.6 RQ5: Ablation Study

  • Initial seeds expose 75 vulnerabilities and mutation adds 29; ablations show that semantic seed generation, semantic feedback, and adaptive seed selection each contribute to discovery within their evaluated stages.The stage-specific variant yields do not rank component importance against one another.Source: §5.6 · p. 10, Table 4 · p. 10

6 Conclusion

TrustProbe exposes unsafe trust chains in skill-based agents and finds verified vulnerabilities across 11 agents. The conclusion connects these failures to skill-delivery and approval gaps, while outlining security measures and study safeguards.

6 Conclusion

  • Across 11 agents, TrustProbe identifies 104 verified taint-style vulnerabilities, and direct-prompt replay reproduces only 31.7% of them.The findings motivate treating third-party skill content as part of the agent’s execution security boundary, with provenance tracking, installation-time capability declarations, and argument- and path-aware controls.Source: §6 · p. 10

AI use statement

  • Deepseek-v4-flash performs seed generation, semantic scoring, and mutation; AI-assisted drafting and polishing were reviewed under author guidance.The authors state that experimental numbers and vulnerability findings come from real campaign executions, not AI-generated content.Source: AI use statement · p. 10

Ethics statement

  • TrustProbe presents dual-use risks because automated path discovery could reduce the effort needed to construct malicious skills.Evaluation used isolated local workspaces, benign commands, synthetic content, scratch files, and controlled endpoints; no real user data or credentials were targeted, and weaponized skills were not publicly published.Source: Ethics statement · p. 11

Reproducibility statement

  • The paper documents the evaluated agents’ revisions and execution configurations, campaign pseudocode and parameters, sink models, oracle requirements, and real-skill procedures.The target agents and TrustProbe components use deepseek-v4-flash as the backend model.Source: Reproducibility statement · p. 11

A Campaign Algorithm

  • The campaign audits source-to-sink paths, seeds each path with a canary, and iteratively selects and mutates candidates until a flow is confirmed or its pool budget is exhausted.It returns taint flows and exploitable vulnerabilities; the per-pool budget limits rounds and elapsed time.Source: A Campaign Algorithm · p. 17

B Sanitizer Audit Across All Agents

The audit finds that skill content can reach security-sensitive operations without adequate filtering or runtime provenance distinction. Existing protections often address prompt structure, rely on limited scanners, or expand auto-approval rather than constrain it.

B Sanitizer Audit Across All Agents

  • Loaded SKILL.md bodies reach security-sensitive operations without adequate filtering or provenance marking, and runtime mechanisms do not distinguish skill-originated from user-originated tool arguments.Metadata escaping protects prompt structure rather than filtering content; install-time scanners are limited or bypassable, while command checks are origin-blind.Source: B Sanitizer Audit Across All Agents · p. 17
  • Where provenance is consulted, three agents use skill origin to expand auto-approval: Qwen Code passes allowed-tools entries to permission rules, OpenClaw trusts skill-shipped binaries, and Pochi auto-approves skill invocation.In each case, the agent’s awareness of skill origin grants rather than denies permission.Source: B Sanitizer Audit Across All Agents · p. 18

C Prompts

  • The appendix provides prompts for seed generation, semantic scoring, and four mutation types: semantic, metadata, body, and sink-argument.The figures identify the prompts, while the prose describes how feedback selects among them.Source: C Prompts · p. 18, Figure 3 · p. 18, Figure 4 · p. 18
  • Mutation rules prioritize semantic mismatch, then distance stalls at metadata or body stages, and finally missing or unattributable canaries at a reached sink.Each selected mutator receives the path, seed, trace, feedback scores, and mutation history, and returns a revised SKILL.md.Source: C Prompts · p. 18, Figure 8 · p. 19

D Evaluated Agents and Revisions

The evaluation identifies each tested agent and its source revision, then records the native loading and execution configurations used in the main campaign. Shared campaign parameters were used without per-agent tuning.

D Evaluated Agents and Revisions

  • The 11 evaluated agents span Python and TypeScript implementations, and Table 5 records each tested product, repository, version, and source revision.For repositories with multiple packages, the listed version is that of the tested agent or CLI.Source: D Evaluated Agents and Revisions · p. 19, Table 5 · p. 20
  • The main campaign uses each agent’s native skill-loading path and its most permissive non-interactive mode when approvals are available.Executions were unsandboxed except for DB-GPT’s native WebAssembly isolation for code execution; none of the evaluated agents enables a sandbox by default.Source: D Evaluated Agents and Revisions · p. 20, Table 6 · p. 20

E Campaign Parameters

  • All subjects share the reported campaign parameters, with no per-agent tuning; the unclipped selection penalty makes repeatedly selected candidates yield priority to alternatives.With the reported weights, the penalty equals the nonnegative sum of seed- and path-selection counts.Source: E Campaign Parameters · p. 20

F Sink List

The sink inventory supplies language-specific candidates for source-to-sink analysis, while the execution-path analysis distinguishes installed skills from direct prompts by how frameworks discover, activate, retrieve, or bind skill content. These delivery mechanisms can change both the model’s routing cues and the execution path available to the content.

F Sink List

  • The sink models combine language-specific APIs and aliases into 202 sink-function pools, but a modeled sink is only a candidate until its path passes taint confirmation and exploitability verification.The Python inventory includes expanded execution families and models for asynchronous execution, file APIs, archive extraction, HTTP clients, and deserialization; the TypeScript profile covers Node.js, IDE-agent, LLM-runtime, and tool-dispatch APIs.Source: F Sink List · pp. 20–21

G Skill and Direct-Prompt Execution Paths

  • Trust is operationally defined by the framework path: installed skills may receive discovery metadata, invocation events, tool results, bound prompts, or combinations absent from direct-prompt replay.The replay supplies the same body only through the ordinary user-message interface.Source: G Skill and Direct-Prompt Execution… · p. 22

G.1 Catalog-and-Retrieval Paths

  • Catalog-and-retrieval designs route skills through framework discovery and loading, but direct prompts still reproduce vulnerabilities in some cases: OpenClaw 1 of 24, Hermes Agent 6 of 16, OpenCode 7 of 17, Pi Coding Agent 2 of 3, and Agent Zero 1 of 1.The one-case Agent Zero result establishes route equivalence for that case, not a general absence of skill-specific trust.Source: §G.1 · p. 22

G.2 Explicit Activation Paths

  • Explicit activation paths range from typed skill events to structured references and injected tool exchanges; direct-prompt replay reproduces 1 of 12 Kimi Code CLI, 0 of 2 Mistral Vibe, 9 of 13 Pochi, 4 of 8 Qwen Code, and 2 of 7 Cline vulnerabilities.For Pochi, ordinary messages can still reach the same general-purpose operations; for Cline, activation affects which tool path and sink arguments are constructed.Source: §G.2 · p. 23

G.3 Framework-Bound Prompt Paths

  • DB-GPT binds loaded skill instructions into the agent prompt, and its one verified vulnerability was not reproduced by direct-prompt delivery; the sample is too small for a broad quantitative claim.Across delivery designs, discovery, activation, and binding provide skill-specific context and route fields or resources through code that plain messages do not traverse.Source: §G.3 · pp. 23–24

H Approval-Control Configurations

The approval replay used the strictest usable non-interactive configuration for each agent and checked for evidence that the restrictive mode was active. The tested failures arose either because enforcement was skipped on an execution path or because the policy did not cover the operation.

H Approval-Control Configurations

  • Ask-mode requests were rejected or left pending; agents without usable ask-per-action mode used deny rules or an adapted permission-gate extension.Pi Coding Agent’s print mode had no built-in gate; its extension blocked Bash, Write, and Edit.Source: H Approval-Control Configurations · p. 24, Table 10 · p. 24
  • Restrictive-mode enforcement required native evidence; without it and without a confirmed target, a run counted only as not reproduced.Evidence included approval-request or denial events, rejected tool results, initialized tool lists, or pending-approval records.Source: H Approval-Control Configurations · p. 24
  • Nine enforcement failures occurred because Kimi Code CLI did not load configured deny rules and OpenClaw’s tested local-CLI path skipped approval checks.In both agents, logs showed no approval event before the protected operation.Source: H Approval-Control Configurations · p. 24
  • Twenty-two policy-scope gaps included uncovered file tools, subprocesses outside tool-level approval boundaries, and a Pi gate that omitted Read.OpenClaw’s workspaceOnly default was false, allowing disclosure and write cases to proceed.Source: H Approval-Control Configurations · p. 24

I Approval-Control Results

Under restrictive approval settings, 31 of 89 reevaluated vulnerabilities remained exploitable, with survivors attributed to enforcement failures or policy-scope gaps. The replay excluded 15 vulnerabilities in three agents without a configurable approval layer in the tested mode.

I Approval-Control Results

  • 31 of 89 vulnerabilities (34.8%) remained exploitable after automatic approval was removed.Of the other 58, 40 had evidence that the configured control blocked the operation, while 18 did not reproduce the target attack in that run.Source: I Approval-Control Results · p. 25, Table 11 · p. 25
  • Pochi, Agent Zero, and DB-GPT lacked a configurable approval layer in the tested mode, leaving 15 vulnerabilities unevaluated under restrictive settings.The remaining 89 vulnerabilities were paired across eight agents and counted only when the oracle reconfirmed attacker control and observable harm.Source: I Approval-Control Results · p. 25
  • Nine survivors were enforcement failures: configured policies were not checked on active execution paths, including Kimi’s unloaded deny rules and OpenClaw’s default local command path.The logs contained no approval event before the protected operation executed.Source: I Approval-Control Results · p. 25
  • Twenty-two survivors were policy-scope gaps; file disclosure remained the weakest-protected family, with 14 of 20 cases (70.0%) exploitable.OpenCode, Cline, and Mistral Vibe retained no verified vulnerabilities under restrictive configurations.Source: I Approval-Control Results · p. 25

J Real-Skill Validation Details

The real-skill evaluation retained 633 adjudicable files after excluding files with no derivable marker. The protocol derived markers from skill content and required evidence of sink invocation, marker flow, and the audited path; 15 researcher-modified skill twins were weaponized.

J Real-Skill Validation Details

  • 694 real SKILL.md files came from four sources, and 633 remained adjudicable after excluding 61 with no derivable marker.Sources included stratified SkillsMP long-tail samples, ClawHub site and registry files, and official repositories and built-in packs.Source: J Real-Skill Validation Details · pp. 25–26
  • Real-skill triggers required an invoked target sink, a content-derived marker in a sink argument, and recorded stack frames covering the audited path.Markers were extracted from paths, URLs, commands, file names, and environment tokens; corpus-common tokens and idle-baseline markers were excluded.Source: J Real-Skill Validation Details · p. 26
  • The 15 weaponized twins were researcher-modified copies, so their results do not imply that the original skills were malicious.Table 12 reports the anonymized twins, their agents, techniques, and observed outcomes.Source: J Real-Skill Validation Details · p. 26, Table 12 · p. 26
  • All 15 completed twins substituted existing service or installer addresses, reference endpoints, or a bootstrap command with controlled listener addresses.No twin added instructions or rewrote task text; ten changed at most two lines, and the largest edit was one global service-domain substitution.Source: J Real-Skill Validation Details · p. 26
Loading 2609.39065v1…