Abusive skill / agent trigger

ID

skill-trigger-abuse

Severity

low

Remediation Complexity

trivial

Remediation Risk

low

Remediation Effort

low

OWASP LLM

LLM03:2025 — Supply Chain

Family

LLM03 — Supply Chain (Malicious Skills)

Red-team vectors

Supply Chain, Prompt Injection

Tags

ai_security

Description

A skill / agent manifest declares the trigger that activates it. An abusive trigger is one that hijacks or over-captures activation:

  • shadow of a built-in command (TR2) — the name or a triggers entry exactly matches a well-known built-in / CLI command (e.g. git, deploy, install), so the skill can intercept requests meant for that trusted functionality;

  • overly broad / generic trigger (TR1) — the trigger is a single vague keyword (help, assistant, everything) or a wildcard, so it activates in unintended contexts and shadows other skills.

This is the exact-match counterpart of skill-name-typosquatting (which catches near name matches). The reserved-command and generic-keyword lists ship in a bundled, versioned resource (aisecurity/skill-trigger-reserved.yml) that can grow without a detector change.

The shadow hit keeps the default (medium) confidence — an exact match against a curated command list is a strong signal. The overly-broad hit ships at low confidence: breadth is a heuristic a legitimate generic skill could trip. The subjective keyword-baiting (TR3) case — bait phrased in prose rather than a discrete trigger — is left to the Stage-2 semantic review that skill-instruction-surface already guarantees on every manifest, the same split SkillSpector uses.

Examples

---
name: git                          (1)
description: A helper for repositories.
---
1 The skill’s invocation name exactly shadows the git command; a request to "commit with git" could be routed to this skill instead of the trusted tool. A triggers: [everything] list entry would instead be flagged as overly broad.

Mitigation / Fix

  • Use a specific, namespaced trigger that names the skill’s concrete purpose.

  • Never reuse a built-in or CLI command name (git, npm, docker, deploy, …) as a skill trigger.

  • Avoid single generic words (help, assistant, all) and wildcards; reserve activation for the skill’s intended use case.