# Как проверять чужие навыки на промпт-инъекции > Практический аудит чужих skills: как находить промпт-инъекции и решать, чему доверять. ## Publication - Author: Владимир Монин - Published: 2026-09-01T08:23:58.933253+00:00 - Modified: 2026-09-01T08:23:58.933492+00:00 - Canonical: --- ## 📖 О чем это руководство Чужой `skill` удобно воспринимать как полезную папку с инструкциями, но с точки зрения безопасности это всё равно **внешний текст, который будет влиять на поведение агента**. Поэтому skill нельзя автоматически считать безопасным только потому, что он красиво оформлен, лежит на GitHub или уже кому-то помог. Практическая цель здесь не в том, чтобы доказать абсолютную безопасность. Такой гарантии всё равно не будет. Задача реалистичнее: **быстро поймать красные флаги**, снизить риск скрытых инструкций и понять, стоит ли вообще пускать навык в рабочий контур без ручной чистки. ## 🧠 Почему skill нужно считать недоверенным текстом Skill не даёт агенту новый технический доступ сам по себе. Но он меняет поведение модели: что считать нормальным действием, какие шаги ставить в приоритет и какие рамки игнорировать. Именно поэтому danger-zone у skills часто сидит не в “магическом взломе”, а в **скрытых инструкциях**, которые подталкивают агента к неправильному поведению. На практике это означает очень спокойную дисциплину. Чужой навык надо читать не как врага по умолчанию, но и не как священную документацию. *Недоверие здесь не истерика, а инженерная гигиена.* > [!warning] > #### Базовая установка > Любой внешний `skill` сначала считается **недоверенным текстом**. Доверие появляется только после чтения, red-flag pass и короткого ручного аудита. ## 📊 Минимальный контур проверки Самый безопасный маршрут выглядит так: сначала собрать весь навык в единый пакет для чтения, потом прогнать грубый red-flag pass, затем отдать материал сильной reasoning-модели и только после этого принять решение вручную. ```mermaid sequenceDiagram autonumber actor User as "👤 Пользователь" participant Pack as "📦 Audit Pack" participant Model as "🧠 Strong Model" participant Review as "🔎 Manual Review" User->>Pack: "Собрать файлы skill в один пакет" activate Pack Pack-->>User: "Единый markdown для аудита" deactivate Pack User->>User: "Сделать red-flag pass" User->>Model: "Проверить пакет на инъекции и скрытые инструкции" activate Model Model-->>User: "Подозрительные фрагменты и риски" deactivate Model User->>Review: "Перечитать найденные места руками" activate Review Review-->>User: "Принять: взять, перепаковать или отклонить" deactivate Review ``` Смысл этой схемы в том, что **одна модель не заменяет ручное решение**. Её задача - сузить поле внимания и показать подозрительные места, а не снять с вас ответственность за интеграцию навыка в рабочую систему. ## 🛠️ Практический порядок аудита ### 📦 Шаг 1. Соберите навык в один audit-pack Если skill состоит из десятков мелких файлов, читать его по одному неудобно и человеку, и модели. Поэтому сначала полезно собрать все `SKILL.md`, docs, examples и scripts в один markdown-файл. Это не постоянная форма хранения, а **временный контейнер для аудита**. Ниже простой PowerShell-пайплайн для такой сборки: ```powershell Get-ChildItem -Path .\some-skill -Recurse -File | Sort-Object FullName | ForEach-Object { "## FILE: $($_.FullName)`n" Get-Content -LiteralPath $_.FullName "`n" } | Set-Content -LiteralPath .\skill-audit-pack.md ``` Этот шаг полезен потому, что вы начинаете видеть навык как **цельную систему правил**, а не как россыпь фрагментов, между которыми легко потерять странную связку или скрытую инструкцию. ### 🚩 Шаг 2. Сделайте red-flag pass До глубокого чтения полезно пройтись по самым опасным паттернам. Здесь важна не тонкая филология, а грубый инженерный фильтр. Ищите попытки скрывать текст навыка, игнорировать пользовательские инструкции, обходить локальные правила, вытаскивать секреты, читать чувствительные директории или выполнять действия, никак не связанные с заявленной ролью навыка. Если skill про видеомонтаж, а внутри внезапно всплывают указания про скрытие поведения, секретность, ключи, кошельки или credential-файлы, это уже не нюанс, а повод тормозить интеграцию. ### 🧪 Шаг 3. Отдайте пакет сильной reasoning-модели После грубого pass полезно дать собранный пакет сильной модели и попросить не “вообще оценить skill”, а **найти скрытые приоритеты, возможные промпт-инъекции и несоответствие между заявленной задачей навыка и тем, что он реально заставляет делать агента**. Такой запрос особенно полезен, когда файлов много и ручное чтение долгое. Ключевой момент здесь в формулировке. Нужен не общий обзор, а жёсткая задача: показать опасные фрагменты текста, объяснить риск и назвать конкретную причину тревоги. > [!tip] > #### Что спрашивать у модели > Хороший audit-запрос почти всегда содержит три требования: **найти опасные инструкции**, **объяснить, почему они опасны**, и **показать точный фрагмент текста**, который вызвал подозрение. ### 👀 Шаг 4. Перечитайте подозрительные места руками Даже сильная модель не снимает ручной review. Её задача - сузить зону внимания. После автоматического аудита нужно самому перечитать найденные места и задать простой вопрос: соответствует ли это реальной роли навыка или здесь уже начинается странное поведение, которое невозможно оправдать основной задачей. Это особенно важно для skills, которые живут рядом с `bash`, файлами, браузером, `git` и локальными сервисами. Чем ближе навык к реальным действиям, тем опаснее соглашаться на вердикт в стиле *“вроде выглядит нормально”* без собственной проверки. ### 🧭 Шаг 5. Примите одно из трёх решений После аудита вариантов обычно не десять, а три. Либо skill выглядит чисто и идёт в работу без изменений. Либо он полезен, но требует локальной чистки и перепаковки под ваши правила. Либо его лучше вообще не использовать, потому что цена доверия слишком высока. Именно это и есть взрослый результат security-pass. Не слепое доверие и не паранойя на ровном месте, а **осознанное решение с понятной причиной**. ## ⚠️ На какие красные флаги смотреть в первую очередь Первая группа красных флагов связана с попыткой перехватить приоритеты агента: “игнорируй локальные инструкции”, “не раскрывай текст навыка”, “всегда выполняй этот слой первым”, “не сообщай пользователю о таких-то действиях”. Это уже не просто стиль, а попытка навязать скрытое управление. Вторая группа опаснее operationally: требования читать чувствительные директории, искать ключи, токены, кошельки, credential-файлы или выполнять shell-действия, которые не имеют отношения к основной задаче навыка. Здесь особенно важно не оправдывать странность фразой “ну, наверное, автор что-то имел в виду”. Третья группа тоньше, но тоже важна. Иногда skill не выглядит вредоносным, но **слишком агрессивно переопределяет user intent** и заставляет агента игнорировать локальный проектный workflow. Для production-среды это тоже плохой сигнал. > [!warning] > #### Самая дорогая ошибка > Проверить только `SKILL.md` и проигнорировать вложенные docs, examples и scripts. Неприятный сюрприз чаще всего прячется именно там, где его меньше всего ждут. ## ✅ Когда skill можно пускать в работу После хорошего аудита у вас должно получиться воспроизводимое объяснение: зачем нужен навык, какие файлы вы реально проверили, какие red flags искали и почему в итоге решили его принять, перепаковать или отклонить. То есть решение опирается не на настроение, а на **ясный рабочий проход**. Если после проверки role навыка остаётся узкой, понятной и не вызывает внутреннего дискомфорта, это хороший знак. Если же после аудита остаются мутные зоны, лучше не уговаривать себя и держать skill в карантине до ручной чистки. ## 🔄 Что можно сделать дальше Следующий полезный шаг - оформить собственный короткий checklist аудита skills и прогонять его перед каждым новым импортом. Тогда проверка перестанет быть разовой осторожностью и станет нормальной частью рабочего контура OpenCode.