ZCode слил git-историю на серверы Alibaba - как проверить ИИ-ассистента перед тем как дать ему доступ к репозиторию?

ZCode - десктопный кодинг-агент от китайской Z.ai (модели GLM, позиционируется как открытая альтернатива Claude Code) - при каждом входе в приложение тайно паковал всю рабочую папку проекта: полную историю git, кэш LFS, рефлоги и конфиги. Архив шифровался и грузился на Aliyun OSS, а ключ расшифровки лежал только на серверах Z.ai - расшифровать свой же файл со своего диска было нельзя. Нашёл это разработчик по нику ferstar 18 сентября 2026 реверс-инжинирингом обычного Electron-архива app.asar, без каких-то специальных навыков. После огласки Z.ai в версии v3.14.0 отключила саму функцию.

Дальше - что конкретно уходило, как это устроено и какой чек-лист прав я после этой истории применяю к любому новому агенту в своём пайплайне.

Что именно ZCode отправлял на сторону без ведома пользователя?

Один зафиксированный снимок весил 313 МБ (сжатый и зашифрованный) из 345 МБ исходной рабочей папки - 42 411 файлов. Это не срез текущего состояния, а, по словам автора, "complete lineage of the repository since day one": полная история коммитов, включая удалённые API-ключи и неопубликованные ветки с планами продукта.

Разбивка архива по содержимому: .git/lfs - 196,1 МБ (56,8%), .git/objects - 102,2 МБ (29,6%), .git/logs (рефлоги) - 0,6 МБ (0,2%), сам код и документация - 46,2 МБ (13,4%). То есть почти 87% выгрузки - это .git, а не рабочие файлы, которые агенту вроде бы нужны для автодополнения.

Ferstar заметил проблему случайно: папка ~/.zcode заняла больше 700 МБ на MacBook Air с ограниченным диском. Внутри, в v2/checkpoints/, лежал зашифрованный файл на 313 МБ с метаданными о 564 неудачных попытках его отправки - то есть агент пытался залить снимок сотни раз до того, как это вообще заметили.

Как это обнаружили и куда уходят зашифрованные данные?

Ferstar распаковал app.asar - это обычный Electron-архив, разбирается штатными инструментами, никакого специального реверса не нужно - и восстановил весь конвейер. Клиент стучится на zcode.z.ai эндпоинтом POST /api/v1/snapshot/upload-credential, получает подписанную форму для Aliyun OSS, ключ объекта, лимит размера и RSA-публичный ключ. Дальше рабочая папка пакуется в tar.gz, шифруется локально AES-256-CTR, ключ шифрования оборачивается RSA-OAEP-SHA256 - и зашифрованный блок улетает напрямую в облако Alibaba. Приватный ключ для расшифровки живёт только у Z.ai.

Захват запускается безусловно при старте приложения и срабатывает перед каждым запросом (captureBeforePrompt) и при обновлении вики по репозиторию (repo-wiki-update) - за одну сессию автор насчитал 62 события захвата. Никакой связи с тем, реально ли вы что-то спросили у модели, - просто фоновый процесс, который тикает сам по себе.

Помогают ли переключатели в настройках ZCode хоть как-то?

Нет: оба видимых пользователю тумблера управляют не тем, что кажется. "Optimize Experience" решает только вопрос согласия на использование данных для обучения моделей - сам захват и заливка снимка продолжаются при выключенном тумблере. "Repo Snapshot Indexing" отвечает только за то, индексирует ли сервер уже загруженные снимки - локальная упаковка и отправка идут независимо от этой галочки.

Удаление архива тоже не спасает: ZCode пересобирает и заново шифрует снимок в течение получаса, потому что процесс захвата не завязан на наличие файла. Единственный рабочий обход, который предложил ferstar - заблокировать каталог на уровне файловой системы: chattr +i ~/.zcode/v2/checkpoints на Linux или chflags uchg ~/.zcode/v2/checkpoints на macOS. Побочный эффект - откат по чекпоинтам (rollback) у агента перестаёт работать, а чат и автодополнение продолжают как ни в чём не бывало.

Что сделала Z.ai после огласки и кто это подтвердил?

Пост ferstar от 18 сентября 2026 собрал 276 000 просмотров за 13 часов - и после этого Z.ai выпустила версию ZCode v3.14.0, где отключила упаковку и загрузку снимков репозитория и снесла саму облачную инфраструктуру под это. По разбору InfoWorld от 22 сентября 2026, компания NSFOCUS подтвердила, что все объекты в бакете zcode-prod на Aliyun OSS удалены, а Z.ai открыла код для внешней проверки.

Эксперты Semgrep (Крис Томас и Кэти Пакстон-Фир), которых цитирует InfoWorld, назвали это не проблемой AI-модели, а классической ошибкой архитектуры безопасности: нужно было прозрачно раскрыть, что уходит с машины, куда именно и на какой срок хранится - а не молчать и прятать это за двумя тумблерами, которые ни на что не влияют.

Как проверить любого открытого агента на скрытую отправку данных, прежде чем дать ему доступ к репозиторию?

Прямого ответа "запусти вот эту команду и всё увидишь" тут нет, но у ferstar набор проверок неожиданно простой и воспроизводимый:

Смотреть на сетевой трафик, а не на UI. Отслеживать исходящие HTTPS-соединения, особенно к облачным хранилищам (OSS, S3-совместимые бакеты), и сверять объём переданного с размером того, что вы реально спросили у модели - если исходящий трафик заметно больше вашего запроса, вопрос не праздный.

Смотреть на диск. Искать скрытые директории приложения на .enc-файлы и внезапно раздувшиеся каталоги конфигов - именно так ferstar и наткнулся на проблему, просто заметив нехватку места.

Разобрать сам клиент. Если это Electron-приложение - распаковать .asar (это не взлом, а штатная операция) и поискать в коде эндпоинты загрузки и упоминания шифрования. Ровно так был найден zcode.z.ai и весь конвейер выгрузки.

Это тот же принцип, что и в истории с утечкой данных через web_fetch у Claude: пока агент одновременно видит приватные данные, обрабатывает недоверенный контент или имеет свободный канал наружу - достаточно одного из трёх условий не заметить, чтобы утечка стала возможной. У ZCode этот канал был не через промпт-инъекцию, а просто вшит в приложение по умолчанию.

Какие права резать по умолчанию любому новому AI-агенту?

У меня в пайплайне статей на этом сайте разрешения агенту заданы explicit allowlist'ом, а не "запрещено то-то": Bash(node:*), Bash(python3:*), Bash(rm:*), Read, Glob, Grep, WebFetch, WebSearch, запись только в /tmp/** и data/tmp/**. Список короче, чем кажется нужным на старте, и это осознанное решение - агенту не нужно уметь то, что не входит в его задачу.

Честно говоря, sandbox у меня при этом выключен - потому что 11 июля 2026 я откатился с bypassPermissions обратно на acceptEdits, когда выяснилось, что bypassPermissions под root не запускается в принципе, а причина была не в правах, а в доверии воркспейсу (workspace trust). Деталь бесполезная как совет "как настроить агента", но она ровно показывает, что даже свои настройки permissions стоит перепроверять после каждого апдейта раннера, а не доверять один раз выставленному конфигу.

У меня в этом же пайплайне уже был свой маленький вариант истории с ZCode - не утечка наружу через облако, а утечка в саму публикуемую статью. ИИ-агент, дорабатывая один из постов, вставил в текст реальный IP-адрес, утянутый из служебного файла с заметками. До публикации поймали, но после этого случая секьюр-фильтр пришлось ужесточать отдельным коммитом 24 августа 2026: запрет любых реальных IP (включая публичные), карт портов и серверных путей, построчная вычитка каждого вставляемого "реального артефакта" и обязательный финальный grep-скан текста перед сдачей - причём это правило действует и для доработки уже опубликованных статей, потому что именно через доработку утечка и случилась. Вывод для себя сформулировал так: канал наружу не обязательно облако у вендора - иногда это твой собственный текст, который агент готовит тебе же на публикацию.

Похожая логика "не давать агенту сразу всё" звучит и в разборе, как агент одной командой снёс мне папку проекта - там спасал не запрет прав вообще, а PreToolUse-guard, который тормозит конкретное опасное действие до того, как оно случится. И в security-аудите собственного прода силами AI-агентов ровно те же дыры находились не в коде, а в том, что агентам по умолчанию давали больше, чем требовала задача.

Что забрать с собой

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

Отдельные агентские инциденты 2026 года (от реальных кибератак ИИ-агентов, которые разбирала Anthropic, до истории с ZCode) складываются в одну и ту же картину: дыра почти никогда не в самой модели, а в том, сколько ей дали прав "чтобы не мешала работать". Дешевле один раз порезать список прав до необходимого минимума, чем потом объяснять себе, куда делась история репозитория за три года.

И да, ZCode тут не какой-то маргинальный инструмент для энтузиастов - это продукт компании, которая вышла на IPO в январе 2026 и продвигает себя как быстрый и дешёвый конкурент Claude Code на открытых весах GLM. Чем массовее агент, тем дороже обходится один незамеченный тумблер, который на самом деле ничего не выключает.