Когда документация вооружается: скрытые угрозы в файлах для ИИ
Тихая опасность у всех на виду
Вы наверняка слышали про prompt injection, отравление моделей и атаки на данные для обучения. Но есть одна угроза, которой уделяют слишком мало внимания: устаревшая документация как вектор атаки.
Исследователи недавно обнаружили кое-что тревожное. Они изучили файлы llms.txt и llms-full.txt — форматы документации в машинном виде, которые помогают AI-системам понимать устройство сайтов. Результаты впечатляют. Среди тысяч доменов оборонных подрядчиков, компаний из Fortune 500 и технологических гигантов они нашли 120 файлов со ссылками на названия пакетов или доменов, которые давно не существуют.
Концепция атаки элегантна в своей простоте. Злоумышленнику не нужно взламывать систему. Достаточно просто подождать.
Как это работает на практике
Представьте такую ситуацию: разработчик использует AI-ассистента для настройки проекта. Ассистент читает llms.txt компании, находит ссылку на зависимость под названием cool-utils-lib, и — потому что у ассистента есть разрешение на выполнение команд менеджера пакетов — устанавливает её.
Проблема в том, что этот пакет никогда не был зарегистрирован. До тех пор, пока его не зарегистрировал атакующий.
В контролируемом эксперименте исследователи сделали именно это. Они забрали себе несколько заброшенных названий, загрузили безобидные пакеты с функцией логирования (только чтобы зафиксировать обращения) и стали ждать. Результаты поразительны: менее чем через час после публикации один из пакетов уже установила компания из Fortune 500. За следующие дни «с десяток других» организаций тоже подключились.
Это была не настоящая атака — пакеты были безопасными, никакие production-системы не пострадали. Но достижимость доказана. Поверхность для атаки реальна.
Почему AI-ассистенты делают всё хуже
Вот что делает это особенно опасным: традиционная безопасность предполагает, что решения принимают люди. Если дать человеку документ с неверными инструкциями, он может их выполнить. Но люди часто замечают явные ошибки, задают уточняющие вопросы или чувствуют, когда что-то не так.
AI-ассистенты работают иначе. Они воспринимают документацию как исполняемую истину. Если в llms.txt написано «запусти npm install legacy-widget», ассистент часто просто делает это — не задумываясь, существует ли ещё этот пакет, кто им владеет и тот ли это пакет.
Исследователи тестировали разные ассистенты — Claude, OpenAI Codex, Nous Research Hermes — и все они следовали проблемным ссылкам. Это не баг конкретного вендора. Это системная проблема, возникающая из комбинации:
- Неактуализированной документации, которая устаревает
- AI-ассистентов с правами на выполнение действий, которые доверяют документации безоговорочно
- Возможности занять заброшенные названия пакетов в публичных реестрах
Что с этим делать
Рекомендации исследователей практичны и применимы:
1. Регулярно проверяйте свои llms.txt
Если ваша организация публикует AI-читаемую документацию, относитесь к ссылкам на пакеты так же серьёзно, как к зависимостям в коде. Убедитесь, что каждый упомянутый пакет, домен или команда действительно ведёт на легитимный актуальный ресурс. Простая опечатка в документации может стать регистрируемой инфраструктурой.
2. Внедрите этапы согласования для действий ассистентов
Не позволяйте AI-ассистентам автоматически выполнять shell-команды или устанавливать зависимости. Требуйте явного подтверждения на каждом шаге. Документация должна быть справочным материалом, а не руководством к действию.
3. Следите за реестрами пакетов на предмет похожих названий
Настройте оповещения для имён пакетов, похожих на ваши внутренние зависимости. Раннее обнаружение даёт вам окно возможностей занять название до того, как это сделает кто-то другой.
Общая картина
Это исследование подсвечивает важную вещь в переходе к AI-ассистированной разработке: модель доверия изменилась, а наши практики пока не успели за ней.
Когда разработчики работали в одиночку, документация была指南. Когда рядом с разработчиками работают AI-ассистенты, документация становится API. И как любой API, она требует валидации, версионирования и проверки безопасности.
Хорошая новость? Эта проблема решаема. В отличие от многих уязвимостей, исправления здесь просты — документируйте лучше, доверяйте меньше, проверяйте чаще. Сложность в том, чтобы выработать привычку относиться к AI-читаемой документации с той же строгостью, что и к продакшен-коду.
По мере того как AI-ассистенты будут всё глубже встраиваться в процессы разработки, ожидайте появления подобных исследований. Атаки идут не за вашими моделями или данными напрямую. Иногда они терпеливо ждут в вашей документации — терпеливо, как опечатка.