В начале февраля 2026 года GitGuardian опубликовал отчёт, который должен был встревожить каждого разработчика, использующего персонального AI-ассистента. Их инфраструктура сканирования секретов обнаружила более 200 утечек учётных данных, напрямую связанных с развёртываниями OpenClaw — API-ключи, пароли от баз данных, OAuth-токены и учётные данные облачных провайдеров, разбросанные по публичным репозиториям, лог-файлам и отчётам об ошибках. Некоторые принадлежали медицинским компаниям. Другие — финтех-стартапам. Все они были действующими.
Несколькими днями позже Northeastern University опубликовал статью с заголовком, который бил сильнее любого CVE: «Почему AI-ассистент OpenClaw — это "кошмар приватности"». Исследователи сосредоточились не на отдельной уязвимости. Они сосредоточились на самой архитектуре — на том, как OpenClaw обрабатывает данные, хранит учётные данные и раскрывает пользовательскую информацию by design, а не по случайности.
Это были не единичные инциденты, вызванные невнимательными пользователями. Это был предсказуемый результат запуска AI-агентов в средах, где секреты, пользовательские данные и код агента делят одно адресное пространство без какой-либо изоляции.
Как секреты оказываются не там, где нужно
Типичная установка OpenClaw выглядит так: вы устанавливаете его на свою машину, настраиваете API-ключи в переменных окружения и начинаете общаться. Процесс агента работает от вашего пользователя, с вашими правами, читая ваши переменные окружения. Каждый установленный скилл работает в том же процессе, с тем же доступом.
Это означает, что когда вы просите AI-ассистента помочь отладить скрипт деплоя, агент видит ваши AWS-учётные данные. Когда скилл обрабатывает вашу почту, он может прочитать пароль от базы данных. Когда возникает ошибка и стек-трейс попадает в лог, эти переменные окружения могут оказаться в лог-файле. А когда этот лог-файл коммитится в репозиторий, загружается в баг-репорт или синхронизируется с облачным сервисом — ваши секреты становятся публичными.
200+ утечек секретов, обнаруженных GitGuardian, были результатом не 200 отдельных ошибок. Они были результатом одной архитектурной ошибки, повторённой 200 раз: размещения секретов в process.env, где их может прочитать любой код в процессе.
Проблема усугубляется со скиллами и плагинами. Система скиллов OpenClaw запускает сторонний код в том же процессе, что и ядро агента. Вредоносному скиллу не нужен эксплойт для кражи ваших учётных данных — он просто читает process.env. Плохо написанному скиллу не нужно намеренно сливать ваши данные — он просто включает контекст окружения в отчёт об ошибке. Поверхность атаки — это не уязвимость, которую можно пропатчить. Это сама архитектура.
В чём Northeastern был прав
Исследователи из Northeastern выявили то, вокруг чего сообщество безопасности ходило кругами: проблема приватности AI-ассистентов — не в шифровании и не в аутентификации. Она в фундаментальном вопросе: к чему агент имеет доступ и какие границы существуют между миром агента и вашим.
Когда AI-агент работает от вашего пользователя, с вашими правами, на вашей машине, границы нет. Агент может читать ваши файлы, учётные данные, историю браузера, SSH-ключи. Он может получить доступ ко всему, к чему можете вы. Единственное, что мешает ему сделать что-то вредоносное, — это промпт, а атаки prompt injection неоднократно демонстрировали, что промпты — не граница безопасности.
Именно это Northeastern имел в виду под «кошмаром приватности». Не то, что OpenClaw намеренно крал данные, а то, что архитектура делала невозможной гарантию того, что данные не утекут. Доступ агента ограничивался только правами пользователя ОС, то есть, по сути, не ограничивался вообще.
Как контейнерная изоляция NanoClaw меняет расклад
NanoClaw использует принципиально иной подход. Каждый агент работает внутри собственного Linux-контейнера — Apple Container на macOS, Docker на macOS и Linux. Контейнер — это не удобная фича и не опция деплоя. Это модель безопасности.
Когда вы отправляете сообщение в NanoClaw, хост-процесс не запускает Claude напрямую. Он создаёт контейнер, монтирует только те директории, к которым агенту нужен доступ, и передаёт контекст разговора внутрь. Агент работает внутри контейнера со своей файловой системой, своим пространством процессов и своим сетевым стеком. Когда он заканчивает, контейнер уничтожается.
Вот где обработка секретов становится интересной. NanoClaw никогда не загружает ваш ANTHROPIC_API_KEY в process.env. Вместо этого он считывает ключ из .env во время выполнения и передаёт его процессу контейнера через stdin в виде JSON-пакета. Внутри контейнера agent-runner получает ключ, использует его для API-вызовов и никогда не записывает на диск и не экспортирует в переменные окружения.
Это означает, что даже если вредоносный промпт обманом заставит агента выполнить `printenv` или `cat /proc/self/environ`, API-ключа там нет. Он существует только в памяти процесса agent-runner, на протяжении одного хода разговора. Скомпрометированный контейнер не может слить то, к чему у него нет доступа.
Система монтирования добавляет ещё один уровень защиты. NanoClaw ведёт белый список директорий, которые можно монтировать в контейнеры, хранящийся за пределами корня проекта. Каждая группа получает свою изолированную файловую систему — свой файл памяти CLAUDE.md, своё записываемое рабочее пространство. Белый список включает обнаружение escape-ов через символические ссылки, чтобы подготовленная символическая ссылка не могла обмануть систему монтирования и открыть директории за пределами разрешённого набора.
Контейнеры также работают от непривилегированного пользователя, с исходным кодом проекта, смонтированным только для чтения. Агент может читать кодовую базу для понимания контекста, но не может изменять файлы хоста. Записываемые пути ограничены группой и очищаются при завершении контейнера.
Модель изоляции по группам
Изоляция NanoClaw выходит за рамки простого разделения агента и хоста. Каждая группа WhatsApp получает свой контейнер, свою память и свою файловую систему. Группа A не может видеть разговоры, файлы или память CLAUDE.md группы B — не из-за контроля доступа на уровне приложения, а потому что они работают в физически отдельных контейнерах с отдельными точками монтирования.
Это важно для сценария, который большинство AI-ассистентов полностью игнорируют: общие устройства и многопользовательские конфигурации. Если вы используете NanoClaw с семьёй, разговоры и файлы вашей рабочей группы изолированы от разговоров и файлов семейной группы на уровне контейнера. Нет бага приложения, который мог бы привести к утечке данных между группами, потому что изоляция обеспечивается средой выполнения контейнера, а не приложением.
Ваш основной канал WhatsApp — личная переписка с ассистентом — служит интерфейсом администратора. Это единственный канал, который может управлять запланированными задачами, изменять конфигурацию и получать доступ к межгрупповому состоянию. Групповые каналы по умолчанию ограничены своей песочницей.
Какой урок должна извлечь индустрия
Отчёт GitGuardian и анализ Northeastern указывают на один и тот же вывод: AI-агенты — это инфраструктура, а инфраструктура требует безопасности инфраструктурного уровня. Запускать AI-агента в том же процессе, что и ваши учётные данные, с теми же правами, что и ваш пользовательский аккаунт, — это эквивалент запуска веб-сервера от root без файрвола. Работает, пока не перестаёт, а когда перестаёт — радиус поражения охватывает всё.
Контейнерная изоляция — не новая идея. Индустрия веб-хостинга разобралась с этим два десятилетия назад — нельзя запускать код нескольких клиентов в одном процессе. Индустрия баз данных разобралась ещё раньше — нельзя давать каждому запросу доступ к каждой таблице. Но экосистема AI-агентов всё ещё находится в фазе «запускаем всё от root», и утечки секретов и кошмары приватности — предсказуемый результат.
Подход NanoClaw — не единственный способ решить эту проблему, но он демонстрирует, что проблема решаема без потери функциональности. Агенты, работающие внутри контейнеров, по-прежнему могут искать в интернете, просматривать страницы, читать и записывать файлы и выполнять shell-команды. Они просто делают это внутри песочницы, где радиус поражения любого сбоя — будь то баг, prompt injection или вредоносный скилл — ограничен областью одного контейнера.
200 утечек секретов, обнаруженных GitGuardian, не должны были произойти. Они произошли, потому что архитектура сделала их неизбежными. Решение — не в обучении пользователей и не в более аккуратном управлении учётными данными. Решение — в архитектуре, где секреты не могут утечь, потому что они никогда не находятся в месте, откуда утечка возможна.