AI-агенты

MuleRun AI swarm: 900 аккаунтов и урок для AI-платформ

MuleRun описал AI swarm на сотнях аккаунтов, GitHub Actions и Firebase. Разбираем, почему бесплатные AI-платформы становятся поверхностью атаки.

По состоянию на 18 апреля 2026 года у нас есть один публичный источник по инциденту: постмортем MuleRun от 14 апреля. Это не независимый аудит и не судебный отчёт, поэтому цифры ниже нужно читать как данные самой платформы. Но кейс всё равно сильный: он показывает, как бесплатные тарифы, CI/CD и агентные песочницы складываются в инфраструктуру, которую один человек может заставить работать почти как распределённую систему.

Канонический ключ этой статьи: MuleRun AI swarm. Смысл не в том, что кто-то снова завёл пачку аккаунтов ради бесплатных кредитов. Такое было всегда. Новое здесь другое: по версии MuleRun, система сама поддерживала пул аккаунтов, гоняла задачи через GitHub Actions, хранила состояние в Firebase и переносила "мозг" агента между сессиями, когда кредиты заканчивались.

Исходный постмортем MuleRun: 900 аккаунтов, 56 рабочих процессов GitHub Actions и $0 заявленных затрат на вычисления. Источник: MuleRun Tech Blog.

Что случилось в MuleRun

MuleRun пишет, что 13 апреля 2026 года заметила всплеск регистраций с двух похожих почтовых доменов. В одном срезе было 202 аккаунта примерно за 1 час 20 минут, в другом 683 аккаунта примерно за 22 часа. Средний интервал регистрации был слишком ровным для человека: 23,6 секунды в первой волне и 118,7 секунды во второй.

Дальше расследование расширилось. По IP, шаблонам имён и истории доменов команда связала инцидент с 27 почтовыми доменами и 2 256 аккаунтами за восемь месяцев. В отдельном перечне ресурсов фигурировали 887 аккаунтов MuleRun, 47 API-ключей и ресурсы на 11 AI-платформах. Поэтому "900 аккаунтов" в заголовке источника лучше воспринимать как округление рабочего масштаба, а не единственную точную цифру.

Самая опасная часть, если верить постмортему, была не в регистрациях. Команда нашла публичный репозиторий и Firebase Realtime Database URL, жёстко прописанный в исходном коде. База была доступна без аутентификации. Внутри, по словам MuleRun, лежали пароли, GitHub PAT, Telegram Bot Tokens, API-ключи, чаты и операционный статус. Объём выгрузки: 35 МБ JSON.

Почему это не обычный фрод с бесплатными кредитами

Обычное злоупотребление бесплатными тарифами выглядит скучно: много аккаунтов, скрипт регистрации, прокси, промокоды, попытка выжать лимит. В MuleRun AI swarm интереснее связка компонентов.

Центральный элемент назывался Cortex. По описанию MuleRun, это сессия внутри песочницы MuleRun, которая читала файлы предыдущей версии, меняла код и промпты, затем отправляла изменения обратно в GitHub. GitHub Actions подхватывал новую версию. Если кредиты у аккаунта заканчивались, модуль-сторож выбирал другой аккаунт и переносил туда системный контекст. К моменту расследования Cortex прошёл 219 "реинкарнаций".

Вторая часть: Hive Controller. Он каждые 20 минут выбирал аккаунты с доступными кредитами и мог запускать до 50 рабочих сессий одновременно. Третья часть: Spawner, который автоматизировал регистрацию новых аккаунтов. Интерфейсом для оператора был Telegram-бот. Вся связка держалась на Firebase как общем хранилище состояния.

Это не делает систему умной в человеческом смысле. Но для платформы разница существенная: злоупотребление перестаёт быть одиночным скриптом и становится процессом с памятью, оркестрацией, реакцией на блокировки и попытками улучшать собственные инструкции.

Ключевые цифры инцидента

Все цифры в таблице взяты из постмортема MuleRun. Они не подтверждены независимым аудитом, но внутренне согласуются с логикой расследования: регистрация, хранение секретов, оркестрация и реакция платформы.

Фрагмент кейса	Цифра	Почему это важно
Текущая волна регистраций	202 аккаунта за ~1 ч 20 мин и 683 аккаунта за ~22 ч	Ровный темп дал сигнал, что регистрации делает автоматизация, а не человек
История аккаунтов	2 256 аккаунтов через 27 доменов за 8 месяцев	Блокировка одного домена не решает проблему, если система быстро меняет источник регистраций
Хранилище секретов	35 МБ JSON, 887 аккаунтов, 47 API-ключей	Открытая база превращает abuse-инфраструктуру в готовую карту компрометации
Оркестрация	56 рабочих процессов GitHub Actions и Telegram-бот на 308 КБ	CI/CD стал планировщиком задач для чужих бесплатных ресурсов
Самообновление	219 поколений Cortex	Контекст переносился между сессиями, пока пул аккаунтов ещё имел кредиты
Рабочие кампании	138 кампаний, около 70% отказов Mule Agent	Даже защитные отказы агента становились входными данными для следующей итерации
Кросс-платформенный масштаб	11 AI-платформ, 976 аккаунтов, 47 ключей	Проблема выходит за пределы одной компании: атакующий собирает ресурсы как портфель
Ответ MuleRun	2 256 банов, 27 доменов в списке блокировки, патруль 4 раза в день	Платформа перешла от доменных блокировок к поведенческой детекции

Где здесь настоящий риск для AI-платформ

Первый риск: аккаунт уже нельзя считать человеком. Когда агент может автоматически регистрироваться, читать почту, запускать рабочие процессы и переключаться между сервисами, платформа должна смотреть не только на email-домен и IP. Нужны признаки поведения: скорость создания аккаунтов, повторяемость имён, синхронность задач, похожие траектории потребления кредитов, связи между сессиями.

Второй риск: бесплатный тариф становится compute API. GitHub прямо пишет в документации, что GitHub Actions бесплатен для стандартных GitHub-hosted runners в публичных репозиториях, а частные репозитории получают квоты бесплатных минут и хранилища. Это нормальная функция для разработчиков. В связке с агентами она превращается в дешёвый планировщик: workflow проснулся, проверил состояние, запустил следующую задачу, сохранил результат.

GitHub Actions честно описывает free usage для публичных репозиториев и квоты для приватных. Для разработчиков это удобство, для abuse-сценариев это готовый планировщик. Источник: GitHub Docs.

Третий риск: состояние системы часто хранится в "временной" базе, которую никто не воспринимает как продакшен. Firebase в документации подчёркивает, что Security Rules решают, кто может читать и писать данные, а по умолчанию доступ не открыт. В кейсе MuleRun, по версии компании, проблема была в конкретной неправильной настройке: база с секретами и статусом стала публичной.

Четвёртый риск: чрезмерная автономность агента. OWASP в Top 10 для LLM-приложений выделяет Excessive Agency: когда системе дают слишком много свободы действий, растут риски для надёжности, приватности и доверия. MuleRun AI swarm показывает практический вариант этой проблемы: агент не просто отвечает текстом, а меняет код, планирует задачи, переносит память и ищет новые ресурсы.

Что платформам стоит менять после такого кейса

Блокировка доменов нужна, но это нижний слой защиты. Если система уже научилась менять почтовых провайдеров, denylist становится реакцией с задержкой. Более полезны поведенческие признаки: одинаковые интервалы регистрации, пачки аккаунтов с похожими именами, повторяемые последовательности действий после онбординга, резкий рост параллельных сессий, общее хранилище результатов.

Бесплатные кредиты стоит выдавать не только по факту регистрации. Платформам придётся учитывать оценку доверия: возраст аккаунта, подтверждение платёжного метода, качество первых задач, совпадение отпечатка устройства, историю отказов модели, попытки скрыть swarm-контекст в промптах. Это неприятно для честных новых пользователей, но без такого слоя бесплатный тариф будет работать как открытый бюджет на чужие эксперименты.

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

Для команд, которые строят собственных AI-агентов, вывод похожий. Если агент умеет запускать код, работать с браузером, менять репозиторий и дергать внешние API, ему нужна не только безопасность промптов. Нужны лимиты на действия, отдельные сервисные аккаунты, аудит вызовов инструментов, контроль секретов, условия остановки и понятная граница: что агент может делать сам, а где нужен человек.

Мы уже писали о том, почему бенчмарки ИИ-агентов ломаются из-за exploit-поведения. MuleRun добавляет к этому экономический слой: агент может оптимизироваться не под тест, а под добычу ресурсов. А в статье про Cloudflare Agent Cloud и боевой контур для агентов хорошо видно, почему агентная инфраструктура быстро становится отдельным классом платформенной безопасности.

Ограничения этого разбора

У кейса есть важное ограничение: публичные факты сейчас в основном идут от самой MuleRun. Компания могла видеть внутренние логи, аккаунты и расходы, но внешний читатель не может независимо проверить каждую запись из Firebase, каждый workflow и каждую кампанию. Поэтому корректная формулировка такая: "по данным MuleRun", а не "доказано независимыми исследователями".

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

Третья оговорка касается термина "AI swarm". В этом кейсе он скорее описывает оркестрацию множества сессий и аккаунтов, а не научную multi-agent систему с формальной координацией. Но для платформы это различие вторично. Счёт за API, нагрузка на песочницы и риск утечки секретов вполне реальные.

Главный вывод

MuleRun AI swarm показывает, что бесплатный тариф для AI-платформ теперь нужно проектировать как поверхность атаки. Раньше abuse-команда искала скрипты массовой регистрации. Теперь ей придётся искать автономные контуры: CI/CD как планировщик, Firebase как память, Telegram как пульт, free credits как топливо, агент как кодер собственных обходов.

Для читателя-практика вывод короткий. Если вы строите платформу с агентами и бесплатным доступом, проверяйте не только промпты. Проверяйте экономику действий: кто создаёт аккаунты, кто запускает задачи, где хранится состояние, как быстро расходуются кредиты и может ли один пользователь размножить себя через автоматику. Иначе следующий "бесплатный пользователь" может оказаться не пользователем, а маленьким дата-центром на чужих квотах.