Как защитить ИИ-агента от утечек через пакеты, хранилища и внешние сервисы

Почему агентная система уязвимее обычного приложения

ИИ-агент обычно соединяет несколько доверенных на вид компонентов: модель, оркестратор, память, базы данных, инструменты, облачные API и пакеты из внешних репозиториев. Секрет может утечь на любом из этих уровней. Модель не обязана быть взломана: достаточно ошибки в проверке пространства имён, вредоносного обновления зависимости или чрезмерно широких полномочий интеграции.

Практический вывод: защищать нужно не только промпт и модель, а весь путь от входного запроса до внешнего действия. Особенно опасны компоненты, которые одновременно видят пользовательские данные и ключи доступа.

Что показали недавние инциденты

Факт: в экосистеме LangGraph была исправлена уязвимость в хранилищах контрольных точек для PostgreSQL и SQLite. В затронутых версиях пространство имён собиралось из частей через точку. Из-за этого последовательности `(tenant, bob)` и `(tenant.bob,)` преобразовывались в одинаковое значение. Проверка выполнялась при записи, но отсутствовала в операциях чтения, поиска, удаления, перечисления и некоторых пакетных вызовах. Если недоверенный ввод мог задавать метку пространства имён, он потенциально позволял прочитать, изменить или удалить данные другого арендатора. Исправления выпущены в версиях `langgraph-checkpoint-postgres` 3.1.3 и `langgraph-checkpoint-sqlite` 3.1.2.

Факт: компрометированная версия LiteLLM 1.107.0 попала в PyPI и официальные контейнерные образы. По анализу Microsoft, файлы `cook.pth`, `cook.py` и `sitecustomize.py` могли запускать вредоносный код при обычной инициализации Python, даже без импорта LiteLLM. Потенциально затронуты были не только шлюзы моделей, но и рабочие станции разработчиков, CI/CD-агенты, тестовые среды и контейнеры. Сборщик был рассчитан на поиск ключей разработчиков и ИИ-приложений, облачных учётных данных, данных браузеров, SSH-материалов, переменных окружения и конфигурации прокси.

Заявление разработчиков LiteLLM: версия 1.107.0 была опубликована примерно на два часа, а часть Docker-тегов указывала на скомпрометированные образы несколько часов. Команда рекомендовала считать затронутые среды скомпрометированными и ротировать доступные им секреты. Это заявление описывает позицию поставщика и рекомендации по реагированию; оно не доказывает, что каждый установленный экземпляр действительно передал данные злоумышленнику.

Факт: Andromeda сообщила о несанкционированном доступе к учётным данным в своей среде. Компания заявила, что инцидент затронул ограниченное число клиентских аккаунтов, а скомпрометированные аккаунты были отключены в день обнаружения. При этом первопричина атаки оставалась не установленной, а компания не сообщала о доступе к клиентским моделям, наборам данных или обучающим данным.

Какие меры дают наибольший эффект

Первый слой — инвентаризация секретов и минимальные полномочия. У агента должны быть отдельные ключи для отдельных задач, арендаторов и окружений. Ключ, который нужен для чтения одной базы, не должен одновременно позволять удалять записи, вызывать произвольные инструменты или получать данные другого клиента. Секреты лучше выдавать краткоживущими и ограничивать по ресурсам, операциям и сетевому направлению.

Второй слой — изоляция зависимостей. Фиксируйте версии пакетов и контейнеров, проверяйте хэши артефактов и не полагайтесь на плавающие теги вроде `latest`. Обновление должно проходить через отдельное тестовое окружение, проверку происхождения сборки и контроль изменений. Для критических библиотек полезно иметь внутреннее зеркало или кэш, где можно зафиксировать проверенный артефакт и быстро заблокировать подозрительную версию.

Однако подпись или хэш не доказывают безопасность самого кода. Они помогают убедиться, что установлен именно проверенный артефакт, но не отвечают на вопрос, был ли скомпрометирован процесс сборки или доверенный релиз. Поэтому контроль происхождения нужно сочетать с анализом изменений, ограничением исходящих соединений и наблюдением за поведением процесса.

Третий слой — строгая валидация границ арендаторов. Идентификатор клиента нельзя без проверки превращать в часть ключа, пути, SQL-выражения или составного пространства имён. Проверки должны применяться одинаково к чтению, записи, удалению, поиску и пакетным операциям. Ошибка LangGraph показывает, почему проверки только на пути `put` недостаточно: обходной сценарий может появиться в другой операции.

Практическое правило: канонизируйте идентификатор один раз, храните его в структурированном виде и запрещайте неоднозначные разделители. Дополнительно тестируйте коллизии, необычные Unicode-символы, пустые значения и различия между синхронными и асинхронными API. Тест должен проверять не только отказ в доступе, но и невозможность чтения, перезаписи и удаления чужого объекта.

Четвёртый слой — ограничение инструментов агента. Модель не должна самостоятельно выбирать произвольный URL, SQL-запрос, путь к файлу или набор заголовков авторизации. Для каждого инструмента задайте разрешённые операции, домены, параметры и максимальный объём данных. Действия с необратимыми последствиями — удаление, публикация, перевод денег, изменение прав — должны требовать отдельного подтверждения или проходить через детерминированную политику.

Как строить обнаружение и реагирование

Логи должны позволять связать запрос пользователя, идентификатор арендатора, вызванный инструмент, версию зависимости и исходящий запрос. Секреты при этом нельзя записывать в логи целиком. Нужны события для необычного чтения данных, массового перечисления пространств имён, неожиданных обращений к метаданным и вызовов из нового окружения.

Если зависимость оказалась скомпрометирована, простого удаления пакета недостаточно. Нужно изолировать среду, сохранить признаки компрометации, проверить процессы и сетевые соединения, пересоздать виртуальное окружение или образ из проверенных исходников и ротировать все секреты, до которых мог дотянуться процесс. Запускать Python или `pip` внутри подозрительной среды следует с осторожностью: в случае LiteLLM сама инициализация Python могла активировать вредоносные файлы.

Что остаётся неизвестным

Наличие уязвимой версии не доказывает факт утечки, а отсутствие найденного файла или маркера не доказывает чистоту системы. По предоставленным данным нельзя установить полный масштаб компрометации LiteLLM или Andromeda, а также определить, использовалась ли уязвимость LangGraph против конкретных арендаторов. Поэтому оценка должна опираться на фактические версии, журналы, сетевые события и доступные процессу права.

Вывод редакции: основной риск для ИИ-агента возникает на стыках компонентов. Надёжная защита — это сочетание минимальных полномочий, структурированной изоляции арендаторов, воспроизводимых зависимостей, ограниченных инструментов и заранее подготовленного плана ротации секретов. Ни одна из этих мер не заменяет остальные: безопасная модель не компенсирует вредоносный пакет, а проверенный пакет не исправляет ошибочную авторизацию в хранилище.