Файл llms.txt перетворюється на канал атаки: AI-агентів змусили запускати сторонній код

Дослідники компанії Pandex продемонстрували новий клас ризику для корпоративних AI-агентів: спеціально підготовлений файл llms.txt може підштовхнути систему до завантаження залежності та запуску довільного коду. За їхніми словами, експеримент спрацював у середовищах компаній зі списку Fortune 500. Йдеться не про злам самої мовної моделі, а про зловживання довірою агента до зовнішніх інструкцій і програмних ресурсів.

Формат llms.txt задуманий як зрозумілий для моделей орієнтир на сайті: він може описувати документацію, рекомендовані сторінки, інструменти та порядок роботи. За роллю це дещо нагадує README для автоматизованого помічника. Проблема виникає тоді, коли агент не просто читає пояснення, а самостійно переходить за посиланнями, встановлює пакети або виконує команди, вважаючи текст на довіреному домені безпечним.

Pandex просканувала 8565 доступних файлів llms.txt і знайшла 237 посилань на ресурси, які могли бути відсутніми, містити помилки, переїхати або залишитися без власника. Кожне таке посилання не є автоматичною вразливістю. Однак покинутий пакет чи вільний домен здатен перехопити зловмисник, а інструкція на легітимному сайті продовжить спрямовувати до нього агентів.

Це класична атака на ланцюг постачання, але з новим виконавцем. Раніше розробник мав сам прочитати команду, оцінити пакет і погодитися на встановлення. Автономний агент може пройти ці кроки за секунди й у ширшому контексті: мати доступ до репозиторію, токенів CI/CD, файлової системи або внутрішньої мережі. Тому звичайна помилка в документації отримує наслідки, які раніше вимагали активної участі людини.

Важливий висновок полягає у зближенні даних і коду. Для чат-бота текст був переважно інформацією, а для агента він стає планом дій. Якщо система здатна запускати оболонку, редагувати файли та підключати інструменти, зовнішня сторінка фактично впливає на виконання програми. Відповідно, її треба перевіряти так само суворо, як скрипт, залежність або оновлення.

Захист починається з мінімальних привілеїв. Агентові не слід передавати універсальний токен або повний доступ до робочої станції лише заради читання документації. Встановлення залежностей, виконання невідомих бінарних файлів, зміна конфігурації та вихід у мережу мають проходити через окремі дозволи. Контейнери, одноразові середовища, списки дозволених доменів і пакетів обмежують шкоду навіть тоді, коли інструкцію вже підмінили.

Другий рівень — перевірка походження. Назва пакета недостатня: потрібно фіксувати версію та контрольну суму, стежити за зміною власника, перевіряти цифровий підпис і репутацію репозиторію. Для доменів важливі дата реєстрації, редиректи й відповідність організації. Якщо агент отримав рекомендацію із зовнішнього тексту, він має показати людині точну команду та джерело перед виконанням ризикової дії.

Власникам сайтів варто регулярно перевіряти llms.txt та іншу машинно-читану документацію на биті посилання. Покинутий приклад коду, старий домен або назва пакета з друкарською помилкою можуть роками залишатися непомітними для людей, але масово використовуватися автоматизованими системами. Корисними будуть автоматичні перевірки посилань і сповіщення про зміну доступності рекомендованих ресурсів.

Демонстрація не доводить, що кожен AI-агент уразливий однаково: усе залежить від його політик, доступних інструментів і середовища. Водночас вона показує небезпечну зміну моделі загроз. Компаніям недостатньо фільтрувати лише запити користувача. Треба контролювати всі матеріали, які агент читає під час роботи, і вважати зовнішні інструкції недовіреними, доки їх не перевірено та не обмежено політикою виконання.