Как не нарваться на prompt-injection или зачем нам проверять скиллы?

В прошлой статье говорили про использования LLM хакерами, и обещал как раз продолжение, как защищить свое рабочее пространство, ну в общем, к делу :)

Когда последний раз вы проверяли библиотеку на уязвимости? Или софт, что вы ставите и используете – проверяли? Ну, вот и я также – почти что никогда (раньше)

Суть вот в чем, мы в одной из прошлых статей то и обсуждали, что разработка своих скиллов – это естественная история, но и использование oss скилов – аналогично, особенно когда эти скиллы не просто MD файл, а полноценный инструмент взаимодействия

Но, проблема в том, что скилл это не конфиг и не просто “промпт” в SKILL.md – это буквально может быть и исполняемым кодом и самое важное – с твоими правами :)

Меня зовут Эдгар Сипки. Я инженер и более 10 лет работаю с backend-системами, AI / LLM-инструментами. Выступаю на AI Conf, TeamLead Conf, HighLoad, отбираю доклады на Golang Conf в программном комитете.
А в своём тг-канале делюсь прикладными AI-инструментами и подходами для разработки – подписывайтесь :)

Но, зачем мне боятся то скиллов?

Есть исследование на 42 447 скиллов с маркетплейсов, и в итоге 26.1% содержат уязвимости, 5.2% – скорее всего вредоносные. Но и это еще не все, каждый четвёртый – с дырой, f каждый двадцатый – закладка, к примеру промпт-инъекции, сбор env-переменных с твоими ключами, отправка контекста наружу, в общем полный набор

А, кстати, еще :)

Скиллы с исполняемыми скриптами уязвимы в 2.12 раза чаще, лежит в скилле .py или .sh – проверять обязательно стоит

Но, как говорится

Как защититься?

NVIDIA выкатили SkillSpector – сканер скиллов ДО установки, а ставится одной строкой:

uv tool install git+https://github.com/NVIDIA/skillspector.git
# альтернативы: сборка из исходников (git clone + make install) или Docker - см. README проекта
# (в PyPI пакета skillspector нет, pip/pipx install skillspector не сработает)

И дальше просто:

skillspector scan <https://github.com/owner/repo> --format terminal

Что умеет:

• на вход – git-URL, zip, директория или одиночный SKILL.md;

• 64+ паттерна в 16+ категориях (в новых релизах уже 68/17): инъекции, эксфильтрация, тайпсквоттинг, MCP tool poisoning и пр.;

• два этапа: быстрая статика (regex/AST/YARA/OSV.dev), а поверх – опциональный LLM-анализ для оценки намерения;

• на выходе – risk_score 0-100, вердикт SAFE / CAUTION / DO_NOT_INSTALL и отчёт в terminal / json / markdown / sarif.

А сам-то сканер не словит инъекцию?

И вот тут у меня прокрались сомнения как раз таки, ведь в чем суть, сам сканер работает не просто проверяя по ключевым словам (но да, это конечно тоже) но и проверяет же также через llm, то первое о чем я задумался: если внутри скилла лежит злая инструкция, а SkillSpector скармливает его LLM – не уговорит ли скилл сканер сказать “всё чисто”? Короткий ответ – “нет”, и вот почему

1. Статика идёт первой и она детерминированная. Regex/AST/YARA/проверка зависимостей не “читают” инструкции – они матчат паттерны. Уговорить regex невозможно.

2. LLM здесь – классификатор, а не агент. У него нет инструментов, файловой системы и сети. Его единственный выход – структурный вердикт (JSON), он физически ничего не может “сделать” по просьбе скилла.

3. В промпте анти-джейлбрейк. Стадия намеренно защищена от “проигнорируй прошлые инструкции”.

4. Сама попытка инъекции – это улика. Текст вида “ignore previous instructions” триггерит паттерны Instruction Override / Hidden Instructions. То есть инъекция не прячется от сканера, а наоборот подсвечивает скилл.

SkillSpector обрабатывает содержимое скилла как данные для анализа, а не как команды к исполнению. Ровно этого не хватает уязвимым агентам – они принимают чужой текст за свои инструкции :)

P.S. Да, поэтому явно точно не стоит проверять скиллы своим же кодинг агентом

Короче говоря: сканер сдвигает шансы в твою пользу, но думать всё равно тебе :)

Автоматизация, автоматизация и снова автоматизация :)

Главная боль из исследования – не “нет инструмента”, а “я забываю им пользоваться”. Поэтому делаем так, чтобы проверка происходила сама, я рекомендую создать алиас который резолвит репо, прогоняет SkillSpector и ставит скилл, только если он прошёл:

# ~/.zshrc | ~/.bashrc
# deps: Node (npx) + uv (uv tool install git+https://github.com/NVIDIA/skillspector.git)
safeskill() {
  local repo="$1"
  [ -z "$repo" ] && { echo "usage: safeskill <owner/repo>"; return 2; }

  echo "🔍 SkillSpector проверяет $repo ..."
  skillspector scan "<https://github.com/$repo>" --format terminal
  local scan_exit=$?

  case "$scan_exit" in
    0)
      echo "✅ risk_score <= 50 - ставлю скилл"
      npx skills add "$repo"
      ;;
    1)
      echo "⚠️  risk_score > 50 (DO_NOT_INSTALL) - смотри находки выше."
      printf "Всё равно установить %s? [y/N] " "$repo"
      read -r REPLY
      case "$REPLY" in
        [yY]|[yY][eE][sS])
          echo "⚠️  ставлю несмотря на предупреждение скана"
          npx skills add "$repo"
          ;;
        *)
          echo "Отменено."
          return 1
          ;;
      esac
      ;;
    *)
      echo "⛔ скан упал (exit=$scan_exit)"
      return 2
      ;;
  esac
}

Теперь вместо npx skills add owner/repo ты пишешь safeskill owner/repo – и в итоге тебе явно тяжелее продолбаться с этой историей

А если скан ругается, но ты всё равно хочешь поставить – алиас спросит подтверждение [y/N], так что финальное решение остаётся за тобой.

Алиас – это для рук. Но в эпоху antigravity, cursor agent mode, vs code agent и так далее, где ты уже даже прямого доступа к терминалу не имеешь – я сделал скилл, который заставит агента сам проверять новый скилл перед установкой :)

Что в итоге

Короче, скиллы – это суперсила, и отказываться от них глупо. А самая важная мысль, ребята, “разделяте данные и инструкции” ведь ровно это нехватает нам.

И самое важное, не забываете что скиллы и агенты часто работают имея полностью вшаи же права, так что не забывайте проверять.

Пусть агент остаётся 🐢, который думает, а не ⚡, который слепо исполняет :)