Moltbot и рост теневого веба: от чат-агентов к автономному выполнению задач

Open-source ИИ-агент Moltbot стал одним из самых обсуждаемых инструментов в сфере искусственного интеллекта в этом году. Изначально проект появился под названием Clawdbot, позже прошёл ребрендинг в Moltbot, а затем — в OpenClaw. Несмотря на отдельные проблемы с безопасностью, Moltbot всё равно быстро привлёк внимание пользователей и стал активно распространяться в AI-сообществе.

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

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

Постепенно главная задача инструмента сместилась от простого общения к выполнению действий. Со временем Moltbot превратился из чат-бота в полноценного AI-агента, который способен самостоятельно выполнять команды. Ранее мы также разбирали, как пользователи всё активнее внедряют AI-инструменты в повседневную работу.

Архитектурное устройство

Moltbot изначально строился по модели local-first. Проще говоря, система работает не в облаке, а прямо на компьютере пользователя. Все задачи она выполняет локально. Для части пользователей такой подход выглядит более привлекательным. Он даёт больший контроль над собственными данными, повышает скорость работы и избавляет от зависимости от чужой инфраструктуры. В local-first модели пользователь сам управляет всем: окружением, настройками и поведением системы во время работы. Ранее мы также разбирали, как децентрализованные сервисы меняют подход к конфиденциальности и хранению данных

Для сравнения, облачные ИИ-сервисы вроде OpenAI ChatGPT работают на централизованной инфраструктуре. Все процессы происходят на серверах, которыми управляет компания-разработчик. Это означает, что вопросы безопасности, мониторинга и контроля доступа находятся на стороне провайдера. Пользователь, по сути, обменивает часть контроля на стабильность и управляемость системы.

Для многих такой формат может быть удобнее, однако важно понимать, что разница между двумя подходами носит фундаментальный характер. Облачный ИИ остаётся централизованным, тогда как local-first распределяет не только контроль, но и ответственность. Теоретически локальный запуск лучше с точки зрения приватности, даже несмотря на отдельные вопросы к безопасности Moltbot. Но вместе с этим вся ответственность полностью ложится на пользователя — и в случае ошибки в настройке никакой «страховки» со стороны платформы уже нет.

Облачные ИИ-ассистенты, включая ChatGPT, работают через централизованные серверы, где провайдер отвечает за обработку данных, хранение и безопасность. Moltbot, напротив, использует local-first подход: все процессы и связанные с ними риски происходят непосредственно на устройстве пользователя. Система взаимодействует только с локальными файлами и внутренними компонентами компьютера.

Конфиденциальность оказалась под угрозой

Как уже упоминалось, Moltbot и его последующая версия OpenClaw изначально создавались как privacy-first инструменты. Предполагалось, что локальный запуск позволит не передавать пользовательские данные третьим сторонам и снизит риск их несанкционированного сбора. Однако со временем проект всё чаще стали обсуждать именно в контексте проблем безопасности.

Главная идея local-first модели заключалась в том, что вся работа происходит непосредственно на устройстве пользователя. Данные не отправляются на внешние серверы, а значит, никто со стороны не получает к ним доступ. Но на практике подобные системы всё равно требуют интеграций через API для полноценной работы.

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

В результате инструмент, который должен был защищать данные от утечек, сам стал потенциальным источником риска. Теперь злоумышленникам не нужно атаковать крупного провайдера с профессиональной защитой — достаточно найти неправильно настроенное пользовательское устройство.

Риски хранения ключей в открытом виде

OpenClaw — последняя версия Moltbot — хранит API-ключи и сервисные токены в конфигурационных файлах на устройстве пользователя. Обычно речь идет о директории ~/.clawdbot. Основная проблема заключается в том, что эти данные сохраняются без шифрования, то есть фактически в открытом виде.

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

Чем больше сервисов подключено к ИИ-агенту, тем выше потенциальный ущерб. Для атакующего такие учётные данные становятся особенно ценными, поскольку открывают доступ сразу к нескольким системам одновременно.

Проблема резервных файлов

Дополнительный риск связан с резервными файлами формата .bak. Даже если пользователь удаляет чувствительные данные из основной конфигурации, их копии могут продолжать храниться в backup-файлах.

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

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

Протоколы «теневого веба»

Проблемы безопасности Moltbot привели к ещё одному эффекту: многие local-first ИИ-агенты начали случайно открывать пользовательские интерфейсы в публичный доступ. Когда автономные AI-агенты стали быстро набирать популярность, разработчики и пользователи часто ставили скорость запуска выше безопасности. О развитии AI-агентов в криптоиндустрии и Web3 мы рассказывали тут.

В итоге reverse proxy-сервисы начали публиковать веб-интерфейсы, удалённые shell-доступы и даже административные панели в открытый интернет. В какой-то момент было обнаружено более 1200 публично доступных интерфейсов, связанных с Moltbot и OpenClaw.

Так постепенно появился термин Shadow Web. Речь идёт не о даркнете или теневых маркетплейсах, а об обычных HTTP-интерфейсах, которые случайно оказались доступны извне. Формально они находились вне корпоративной инфраструктуры, однако при этом управляли ИИ-агентами с расширенными правами на локальных устройствах пользователей.

Чаще всего причиной становились ошибки в настройке reverse proxy. Некоторые tunneling-сервисы перенаправляли трафик с публичных URL на локальные порты AI-агентов. Если система аутентификации отсутствовала или была настроена неправильно, proxy продолжал пересылать запросы без проверки личности пользователя.

В результате интерфейсы оказывались открытыми для всех желающих и при этом сохраняли полный функционал.

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

Supply chain и эпоха vibe-coding

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

Для крупных open-source проектов без строгой координации это довольно типичная проблема. Не все изменения проходят полноценный аудит безопасности, а приоритет часто отдаётся скорости разработки, а не глубокой проверке системы.

В AI-среде такой подход всё чаще называют vibe-coding. Речь идёт о ситуации, когда разработчики добавляют функции просто потому, что они «работают», а не потому, что их успели полноценно протестировать и обезопасить.

В подобных условиях новые возможности появляются очень быстро, но вместе с этим растёт и вероятность появления уязвимостей.

Как сейчас пытаются снижать риски

Если local-first AI-агенты получают доступ к системе и способны выполнять действия от имени пользователя, их необходимо изолировать от основной среды. Иначе любой сбой или компрометация агента могут превратиться в полноценную угрозу безопасности.

Одним из главных способов защиты остаётся использование виртуальных машин. Запуск Moltbot или OpenClaw внутри VM позволяет ограничить потенциальный ущерб. Даже если агент окажется скомпрометирован, злоумышленник не получит прямой доступ к основной операционной системе.

Дополнительным уровнем защиты считается настройка firewall. Интерфейсы AI-агентов не должны быть публично доступны. Локальные порты рекомендуется ограничивать только внутренним трафиком, а внешние API — разрешать лишь для заранее известных адресов.

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

В случаях, когда удалённый доступ всё же необходим, специалисты рекомендуют использовать IP allow-listing. Это механизм, который ограничивает доступ только доверенными IP-адресами вместо того, чтобы оставлять интерфейс открытым для всего интернета.

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

Насколько Moltbot готов для корпоративного использования в 2026 году

Технически компании уже могут использовать Moltbot в 2026 году, однако инструмент всё ещё нельзя назвать готовым корпоративным решением «из коробки».

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

Заключение

Moltbot и OpenClaw быстро стали популярными на фоне роста рынка AI-агентов, поскольку предлагают то, чего не дают классические облачные сервисы: полный локальный запуск и больший контроль над системой.

Такой подход действительно способен повысить приватность и ускорить выполнение задач, поскольку все процессы происходят непосредственно на устройстве пользователя.

Но вместе со свободой пользователь получает и полную ответственность за безопасность. Именно поэтому при работе с Moltbot и OpenClaw важно понимать существующие риски и заранее устранять потенциальные уязвимости.

Незашифрованные API-ключи, старые backup-файлы, публичные административные панели и другие подобные проблемы необходимо закрывать ещё до запуска системы в рабочей среде.

При правильной настройке local-first AI действительно может стать мощным инструментом. Но для этого пользователю придётся самостоятельно выстраивать защиту и контролировать инфраструктуру.