Markdown, который получает права пользователя
Обычный Markdown ничего не исполняет. Файл SKILL.md - исключение. Он меняет поведение агента, у которого есть командная строка, доступ к файлам, токен GitHub и иногда права на рабочую инфраструктуру.
Фраза "перед началом запусти проверочный сценарий" выглядит как документация. Для агента это команда. Сценарий будет запущен с теми же правами, которые получил сам агент.
Поэтому такой файл трудно проверять привычными средствами. В одном пакете могут лежать текстовые указания, команды, вспомогательные сценарии и правила выбора инструментов. Сканер кода изучает исполняемые файлы. Защита от внедрения инструкций читает текст. Ни один из этих методов по отдельности не отвечает на главный вопрос: что агент сделает, когда соединит текст, код, задачу пользователя и свои реальные права.
В июне авторы MalSkillBench собрали 3 944 вредоносных навыка и запускали их в Docker под наблюдением системных вызовов. Лучший специализированный детектор находил 98,4% атак, спрятанных в коде, но заметно хуже справлялся с атаками через текстовые инструкции и контур управления агентом. Два защитных слоя видели разные части одного объекта.
SKILL.md нельзя считать обычной документацией. Его нужно проверять как программу, часть которой написана на естественном языке.
Правдоподобная процедура не выглядит атакой
Работа Towards a Risk Assessment of Malicious Skill Files in Coding Agents проверяет не команды вроде "укради ключ SSH", а инструкции, похожие на нормальную подготовку проекта.
Исследователи взяли 471 команду, превратили их с помощью шести моделей в 2 826 правдоподобных файлов навыков и распределили по 11 тактикам MITRE ATT&CK. Затем они провели 5 629 завершенных запусков. Gemini CLI дошел до вредоносного действия в 95,5-96,1% случаев, Qwen Code - в 71,6-74,0%. Агенты явно распознали угрозу только в 1,99% запусков. Код и шаблоны опубликованы в AgentJailbreak.
У этих чисел есть ограничение: команды подтверждались автоматически. Эксперимент показывает поведение автономного агента, а не вероятность того, что человек вручную одобрит ту же операцию.
Ручное подтверждение снижает риск, но не устраняет его. Пользователь видит команду внутри объяснения, которое уже подготовил вредоносный файл: "обязательная диагностика", "проверка окружения" или "настройка набора разработчика". После десятков нормальных действий очередное подтверждение легко нажать по привычке.
Агент тоже не выбирает между очевидно безопасной и очевидно опасной командой. Он выполняет связную процедуру, которую принял за часть проекта.
Вредоносные навыки уже попадали в общие каталоги
Это не только лабораторный сценарий. Авторы исследования Do Not Mention This to the User, принятого на USENIX Security 2026, проверили 98 380 навыков из двух каталогов. Они подтвердили вредоносное поведение у 157 пакетов и нашли в них 632 уязвимости, относящиеся к 13 техникам атак.
В среднем один вредоносный пакет содержал 4,03 уязвимости и проходил несколько стадий атаки. Чаще всего авторы крали учетные данные через удаленное исполнение или управляли решениями агента с помощью инструкций в документации. Более половины найденных пакетов принадлежали одному автору, который создавал поддельные бренды по одному шаблону.
После раскрытия каталоги удалили все 157 пакетов. Однако их нашли уже после публикации. До удаления они распространялись через канал, где установка расширения воспринимается как обычная настройка рабочего инструмента.
Для программных пакетов давно существуют фиксированные версии, списки компонентов, базы уязвимостей и подписи выпусков. Каталоги навыков часто предлагают одну команду установки и Markdown, который выглядит безобидно при беглом просмотре.
Статический сканер видит форму, а не поведение
Первый защитный слой очевиден: искать опасные команды, обращения к учетным данным, подозрительные адреса и просьбы скрыть действие от пользователя. Такой фильтр полезен, но его нельзя считать границей безопасности.
В работе Cloak and Detonate исследователи взяли 1 613 вредоносных навыков и атаковали восемь сканеров. Самораспаковывающаяся упаковка скрывала части программы во время установки и восстанавливала их при запуске. Этот прием обходил каждый сканер более чем в 90% случаев. Изменение структуры файлов обходило большинство статических систем более чем в 80% случаев.
Смысл атаки оставался прежним. Менялся только вид, который получал сканер.
Авторы добавили динамическую проверку SkillDetonate. Навык запускается в изолированной среде, а проверяющая система следит за процессами, файлами, сетью и перемещением подставных секретов. В экспериментах она обнаружила 97% атак при 2% ложных срабатываний. На навыках из реальных каталогов показатель обнаружения составил 87%.
Это результат одной исследовательской работы, а не гарантия для рабочей системы. Вредоносная часть может ждать конкретный репозиторий, дату, домен или настоящий секрет. Динамическая проверка также дороже простого чтения файлов. Зато она наблюдает действие, а не обещание в документации.
Как принимать навыки во внутренний каталог
Сначала нужно зафиксировать происхождение пакета: источник, автора, лицензию, точную версию Git и контрольные суммы файлов. Любое обновление считается новой зависимостью и проходит проверку заново. Автоматически загружать последнюю версию нельзя, если поведение агента должно воспроизводиться.
Затем статическая проверка извлекает команды, сетевые адреса, пути к файлам, обращения к учетным данным и попытки менять настройки агента. Найденные возможности сравниваются с назначением пакета. Средству форматирования Python не нужны сеть и чтение ~/.ssh.
Следующий этап - пробный запуск в одноразовой изолированной среде. В нее помещают подставные секреты и включают наблюдение за операционной системой. Сеть закрыта по умолчанию. Разрешенные адреса перечисляются явно. Чтение секрета, закрепление в системе, изменение настроек агента и отправка данных превращаются в проверяемые события.
Даже прошедший проверку навык не должен получать все права пользователя. Среда выполнения выдает минимальные разрешения для конкретной задачи. Операции чтения отделяются от изменений внешнего состояния. Публикация в GitHub, работа с облаком, загрузка пакета и изменение рабочей системы требуют отдельного подтверждения с понятными аргументами и ожидаемым результатом.
Журнал выполнения должен показывать источник каждого действия: запрос пользователя, базовое правило, конкретную версию SKILL.md или промежуточный план агента. Иначе расследование оставит набор команд без ответа, почему они вообще были запущены.
Где можно упростить защиту
Не каждый файл требует полного контура. Статический Markdown без сценариев и перехватчиков, запущенный агентом без командной строки, сети, секретов и права записи, способен причинить меньше вреда. Обязательное подтверждение тоже помогает, если человек видит всю команду, настоящие аргументы и источник инструкции.
Глубина проверки должна зависеть от прав агента. Для рабочего агента-разработчика с автоматическим подтверждением установка неизвестного SKILL.md почти равна запуску чужого установочного сценария.
Разница лишь в первом впечатлении: сценарий сразу выглядит исполняемым, а Markdown сначала притворяется текстом.