Март 2026 года. Группировка TeamPCP компрометирует LiteLLM — популярную библиотеку для работы с ИИ, которую скачивают миллионы раз в сутки. В пакеты версий 1.82.7 и 1.82.8 на PyPI вшивается стилер: при установке или обновлении он тихо собирает SSH-ключи, учётные данные AWS, Azure и GCP, конфигурации Docker и всё остальное, что лежало под рукой. PyPI убрал вредоносные пакеты за несколько часов — но к тому моменту десятки организаций уже лишились доступов к своей облачной инфраструктуре.
Особенность этой атаки в том, что большинство пострадавших LiteLLM напрямую вообще не использовали. Вредонос активировался через транзитивные зависимости: dspy с пятью миллионами скачиваний в месяц, opik с тремя миллионами, crawl4ai с 1,4 миллиона. Человек ставит один пакет — получает инфостилер в нагрузку. Примерно так же работали кампании Shai-Hulud, атаковавшие разработчиков схожими методами раньше.
Почему именно рабочие машины разработчиков? Потому что они буквально переполнены учётными данными в открытом виде. Каждый активный секрет в среднем встречается на одной машине в восьми разных местах: в
ИИ-инструменты сделали ситуацию хуже. Агенты вроде OpenClaw хранят свою «память» как обычные текстовые файлы в предсказуемых местах на диске —
Первое, что стоит сделать — понять, где вообще находятся секреты на рабочих станциях. Инструмент ggshield умеет сканировать локальные репозитории, историю Git, проектные директории, дотфайлы, артефакты сборки и папки ИИ-агентов. Pre-commit хуки от ggshield перехватывают новые утечки прямо в момент коммита, не давая проблеме добраться до удалённого репозитория.
Следующий шаг — убрать секреты с машин вообще. Перенос учётных данных в централизованные хранилища (vault-инфраструктуры) позволяет управлять ротацией, следить за тем, кто и когда обращается к секрету, автоматизировать реакцию на инциденты. Параллельно нужно ввести правило для ИИ-агентов: никаких учётных данных в чатах с агентами, никакого «обучения» агента на реальных секретах, регулярное сканирование файлов памяти агентов.
Радикальнее — избавиться от целых классов секретов. WebAuthn (passkeys) убирает пароли как концепцию для пользователей. OIDC-федерация делает то же самое для CI/CD пайплайнов: вместо хранимых облачных ключей и сервисных аккаунтов пайплайн получает краткосрочный токен, привязанный к конкретному запуску. Хранить нечего — значит красть нечего.
Там, где долгоживущие ключи пока не удалось устранить, имеет смысл перейти на эфемерные учётные данные. Протокол SPIFFE выдаёт рабочим нагрузкам криптографические документы идентичности (SVID), которые ротируются автоматически. Статический API-ключ, утёкший сегодня, будет работать месяцами. SVID протухает сам.
Наконец, honeytokens — приманки — дают раннее предупреждение даже тогда, когда атака уже идёт. Ложные учётные данные, размещённые в домашних директориях разработчиков, стандартных путях конфигов и файлах памяти агентов, срабатывают в момент, когда атакующий их проверяет. Это сжимает время обнаружения с «узнали через несколько недель» до «видим прямо сейчас». Именно это отличает управляемый инцидент от тихой катастрофы.
Атака на LiteLLM показала: рабочая станция разработчика — это не периферия инфраструктуры. Это точка, где сходятся привилегии, доверие и возможность выполнения кода. Требования к её защите должны быть такими же, как к production-окружению. Пока это не так — цепочки поставок будут продолжать гореть.
Изображение носит иллюстративный характер
Особенность этой атаки в том, что большинство пострадавших LiteLLM напрямую вообще не использовали. Вредонос активировался через транзитивные зависимости: dspy с пятью миллионами скачиваний в месяц, opik с тремя миллионами, crawl4ai с 1,4 миллиона. Человек ставит один пакет — получает инфостилер в нагрузку. Примерно так же работали кампании Shai-Hulud, атаковавшие разработчиков схожими методами раньше.
Почему именно рабочие машины разработчиков? Потому что они буквально переполнены учётными данными в открытом виде. Каждый активный секрет в среднем встречается на одной машине в восьми разных местах: в
.env-файлах, которые начинались как временные, а превратились в постоянный хвост в репозитории; в ~/.aws/credentials; в ~/.config/gh/config.yml; в истории shell-сессий; в настройках IDE; в кешированных токенах и артефактах сборки. Причём 59% скомпрометированных систем в подобных атаках — это не личные ноутбуки, а CI/CD-раннеры. То есть машины, у которых прав ещё больше. ИИ-инструменты сделали ситуацию хуже. Агенты вроде OpenClaw хранят свою «память» как обычные текстовые файлы в предсказуемых местах на диске —
SOUL.md, MEMORY.md. Туда попадают учётки, токены, всё что агент видел в ходе работы. Атакующим даже искать особо не нужно: пути стандартизированы, файлы лежат там, где ожидается. Первое, что стоит сделать — понять, где вообще находятся секреты на рабочих станциях. Инструмент ggshield умеет сканировать локальные репозитории, историю Git, проектные директории, дотфайлы, артефакты сборки и папки ИИ-агентов. Pre-commit хуки от ggshield перехватывают новые утечки прямо в момент коммита, не давая проблеме добраться до удалённого репозитория.
Следующий шаг — убрать секреты с машин вообще. Перенос учётных данных в централизованные хранилища (vault-инфраструктуры) позволяет управлять ротацией, следить за тем, кто и когда обращается к секрету, автоматизировать реакцию на инциденты. Параллельно нужно ввести правило для ИИ-агентов: никаких учётных данных в чатах с агентами, никакого «обучения» агента на реальных секретах, регулярное сканирование файлов памяти агентов.
Радикальнее — избавиться от целых классов секретов. WebAuthn (passkeys) убирает пароли как концепцию для пользователей. OIDC-федерация делает то же самое для CI/CD пайплайнов: вместо хранимых облачных ключей и сервисных аккаунтов пайплайн получает краткосрочный токен, привязанный к конкретному запуску. Хранить нечего — значит красть нечего.
Там, где долгоживущие ключи пока не удалось устранить, имеет смысл перейти на эфемерные учётные данные. Протокол SPIFFE выдаёт рабочим нагрузкам криптографические документы идентичности (SVID), которые ротируются автоматически. Статический API-ключ, утёкший сегодня, будет работать месяцами. SVID протухает сам.
Наконец, honeytokens — приманки — дают раннее предупреждение даже тогда, когда атака уже идёт. Ложные учётные данные, размещённые в домашних директориях разработчиков, стандартных путях конфигов и файлах памяти агентов, срабатывают в момент, когда атакующий их проверяет. Это сжимает время обнаружения с «узнали через несколько недель» до «видим прямо сейчас». Именно это отличает управляемый инцидент от тихой катастрофы.
Атака на LiteLLM показала: рабочая станция разработчика — это не периферия инфраструктуры. Это точка, где сходятся привилегии, доверие и возможность выполнения кода. Требования к её защите должны быть такими же, как к production-окружению. Пока это не так — цепочки поставок будут продолжать гореть.
