Безопасность ИИ-агентов: Защита ваших активов в эпоху автономного ИИ

TL;DR

• ИИ-агенты теперь хранят ключи кошельков, учетные данные API и системные разрешения — одна неверная конфигурация может быть необратимой.
• Поверхность атаки теперь практична: непроверенные навыки агентов, скомпрометированные зависимости и внедренные в запросы действия кошелька могут превратить разрешения агента в реальные потери.
• Дисциплина та же, что и при любом другом операционном риске: ограничьте радиус поражения, прежде чем предоставлять возможности.

Что такое ИИ-агенты — и почему профиль риска только что изменился

ИИ-агенты — это программы на базе LLM, которые выполняют реальные действия от вашего имени — совершают сделки, управляют кошельками, запускают код и вызывают API. Фреймворки, такие как OpenClaw и Hermes, популяризировали стеки с открытым исходным кодом; крупные биржи запустили экосистемы «Навыков», которые предоставляют агентам прямой доступ к учетным записям пользователей и операциям в сети. Рост подпитывается *vibe coding* (подсказки на естественном языке, которые генерируют код) и очень низкими барьерами для входа. Обратная сторона: когда агент хранит ваши ключи и системные разрешения, одна неправильная конфигурация может означать безвозвратную потерю, а скорость разработки регулярно опережает проверку безопасности.

Агенты с открытым исходным кодом: свобода сопряжена с риском цепочки поставок

ClawHavoc: вредоносные навыки в экосистеме OpenClaw

ClawHub — это сторонний рынок навыков OpenClaw; ClawHavoc — это кампания атак на ClawHub, раскрытая Koi Security в начале 2026 года. Первоначальный аудит выявил 341 вредоносный навык из 2857 — ~12% экосистемы — а более поздние отчеты отслеживали не менее 1184. Замаскированные под трекеры кошельков Solana, интеграции с Twitter и аналогичные инструменты, навыки использовали поддельные разделы «Предварительные условия» в `SKILL.md`, чтобы обманом заставить пользователей вставлять команды `curl` и `bash`.

Компрометация LiteLLM PyPI

24 марта 2026 года группа TeamPCP выпустила вредоносные версии `litellm` (1.82.7, 1.82.8) в PyPI, скомпрометировав CI/CD проекта: отравленный Trivy GitHub Action украл Токен `PYPI_PUBLISH` и опубликовал версии с бэкдором напрямую. Полезная нагрузка включала кражу учетных данных, горизонтальное перемещение Kubernetes и постоянный бэкдор systemd. LiteLLM широко используется в стеках ИИ-приложений, поэтому даже короткое окно воздействия PyPI создало значительный риск для последующих систем. Та же кампания затронула Telnyx — скомпрометированный вышестоящий CI/CD теперь является активным вектором для зависимостей агентов.

Как оставаться в безопасности

• Проверяйте перед установкой. Никогда не запускайте `curl | sh` или установщики в один клик, не прочитав скрипты установки, точки входа и сетевой код. Если вы не можете прочитать это, дождитесь аудита сообщества.
• Оцените зрелость проекта. Количество участников, время ответа на проблемы, независимые аудиты.
• Запускайте в песочницах. Docker или виртуальные машины защищают хост-файлы, кошельки и учетные данные от вредоносного кода.
• Закрепляйте версии зависимостей. Точные закрепления в `package-lock.json` или `requirements.txt` — плавающие версии позволяют скомпрометированным вышестоящим пакетам незаметно достигать вас.

Изоляция кошелька: давайте своему агенту только то, что ему нужно

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

Инцидент с Токеном DRB: когда вывод ИИ стал командой кошелька

4 мая 2026 года кастодиальный кошелек, предоставленный Bankr и связанный с учетной записью Grok в X, перевел около 3 миллиардов Токенов DebtReliefBot (DRB) на Base, с заявленной стоимостью около 155–200 тысяч долларов США. Цепочка атаки не была кражей приватного ключа, и сам Grok не контролировал кошелек. Злоумышленник сначала активировал разрешения Bankr для этого кошелька, затем использовал запрос на перевод в азбуке Морзе, чтобы Grok опубликовал инструкцию в стиле перевода, помечающую Bankrbot. Bankrbot обработал этот публичный вывод ИИ как исполняемую команду и инициировал перевод. Большая часть стоимости, как сообщается, была позже возвращена в ETH и USDC, но основная ошибка осталась: вывод ИИ на естественном языке был расценен как финансовое разрешение, а высокорискованные действия с кошельком не имели строгих ограничений или подтверждения человеком.

Многоуровневая стратегия кошелька и активов

• Разделите основной и операционный кошелек. Основное хранилище никогда не подключается к какому-либо агенту, API или третьей стороне. Перемещайте только то, что требуется для задачи, на выделенный операционный кошелек; остальное возвращайте после.
• Минимизируйте разрешения ключей API. Только для чтения, если это возможно; никогда не включайте *вывод* или *перевод*, если это не требуется строго. Большинство потерь происходит из-за ключей с избыточными разрешениями, а не из-за вредоносных агентов.
• Белый список IP + лимиты транзакций. Свяжите ключи с известными IP-адресами, установите лимиты на транзакцию и ежедневные лимиты, чтобы любой отдельный эксплойт был ограничен.
• Меняйте ключи каждые 30–90 дней. Почти нулевая стоимость, значительно меньшее окно воздействия.

Системная изоляция: принцип наименьших привилегий

• Современные фреймворки агентов по умолчанию имеют *полный контроль над стеком* — файлы, оболочка, браузер, системные настройки. Мощно, но опасно, если не контролировать.
• Используйте отдельную машину, если это возможно. Самая простая изоляция — это выделенный ноутбук, мини-ПК или VPS для рабочих нагрузок агентов, без доступа к личным файлам, хранилищам ключей, профилям браузера или приложениям кошельков. Если вы должны использовать свой основной компьютер, по крайней мере, создайте отдельного пользователя ОС.
• Ограничения на уровне ОС. Запускайте как стандартный пользователь, никогда не как root. Используйте `sandbox-exec` на macOS, AppArmor или SELinux на Linux. Отключите ненужный sudo.
• Сетевая изоляция. Брандмауэр агентов только для тех конечных точек, которые им нужны; привяжите локальные службы (базы данных, узлы блокчейна) к `localhost`.
• Безопасное управление учетными данными. Никогда не прописывайте ключи в файлах конфигурации. Используйте менеджер секретов (1Password CLI, HashiCorp Vault) или связку ключей ОС; избегайте долгоживущих переменных среды в открытом виде, где это возможно — они были основной добычей в нескольких из вышеупомянутых инцидентов.
• Журналы и мониторинг. Просматривайте журналы активности. Неизвестные сетевые адреса или доступ к файлам вне области действия → приостановите и расследуйте.

Новые угрозы: внедрение запросов и ползучее расширение разрешений

Самая быстрорастущая поверхность атаки — это внедрение запросов — скрытые инструкции, встроенные в контент, который обрабатывают агенты. Полезные нагрузки могут скрываться в GitHub Issues, README, веб-страницах, даже изображениях. Недавние инциденты с инструментами агентского кодирования и утилитами разработчика MCP показывают ту же схему: как только агент может читать недоверенный контент, получать доступ к секретам и вызывать внешние инструменты, умный запрос может стать реальным эксплойтом. Рассматривайте любого агента с такой комбинацией как высокорискованного.

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

Заключение: четыре основных принципа

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

1. Никогда не доверяйте, всегда проверяйте. Проверяйте проекты с открытым исходным кодом перед установкой.

2. Изолируйте свои активы. Разделите основной кошелек и операционный кошелек; минимизируйте разрешения ключей API.

3. Применяйте принцип наименьших привилегий. Изоляция на системном уровне, чтобы агенты касались только того, что им необходимо.

4. Постоянно отслеживайте. Проверяйте журналы, меняйте ключи, немедленно реагируйте на аномалии.