Как разделить рабочие и личные данные ИИ-помощника

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

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

Начните с требования, которое можно проверить. «Не путать задачи» означает одно, а «рабочий помощник не должен прочитать личные документы» — другое. В первом случае помогают организация контекста и отдельная память. Во втором нужна принудительная граница доступа.

Под «отдельной средой» здесь понимается технически ограниченное место исполнения — например, правильно настроенный контейнер, виртуальная машина или отдельная учётная запись с проверенными правами. Выбор зависит от угроз и эксплуатации. Имя среды, число профилей или инструкция модели сами по себе не доказывают изоляцию.

Опишите источники и операции

Перечислите частные документы, общие справочники, память, историю, внешние сервисы и резервные копии. Для каждого источника укажите владельца и допустимые операции. «Доступ есть» недостаточно: чтение и изменение должны быть разделены.

Условная матрица для рабочего и личного помощников может выглядеть так. Запреты в ней — требования, которые ещё нужно реализовать и испытать.

Разведите состояния и подключения

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

В Hermes для этого проверяют отдельный профиль и его локальную/внешнюю память; в OpenClaw — состояние агента, рабочую папку и правила маршрутизации; в Codex — каталог состояния и подключения, а не только профиль конфигурации. Смысл этих различий описан в документации Hermes ↗, OpenClaw ↗ и Codex ↗.

Отдельно откройте настройки сервиса памяти, браузера и API. Проверьте аккаунт, пространство данных, разрешённые объекты и действия. Две локальные папки могут обращаться к одному облачному хранилищу. Два браузерных окна могут использовать одну авторизованную сессию. Общая учётная запись допустима только там, где общие права действительно разрешены.

Подключите общий справочник отдельно

Назначьте владельца справочника и выдайте обоим помощникам только чтение. Не монтируйте родительский каталог со всеми частными папками ради одного общего файла. Не передавайте в среду Docker-сокет или административные ключи: такой доступ способен обойти выбранную файловую границу.

Пример выполняется в Bash на Linux с уже установленным Docker Engine и доступом к локальному сервису Docker (daemon). Он создаёт только новые учебные папки. Нужны интернет для первой загрузки образа и Python 3 в контейнере. Не запускайте команды в терминале действующего агента с неизвестным рабочим каталогом.

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

docker context show
docker info --format '{{.OSType}}'
docker context inspect --format '{{.Endpoints.docker.Host}}'
docker pull python:3.12-slim
lab_dir=$(mktemp -d "$HOME/agent-separation-demo.XXXXXX")
mkdir -p "$lab_dir/work" "$lab_dir/personal" "$lab_dir/reference"
printf 'Work example only\n' > "$lab_dir/work/notes.txt"
printf 'Personal example only\n' > "$lab_dir/personal/notes.txt"
printf 'Shared reference only\n' > "$lab_dir/reference/guide.txt"
printf 'Учебная папка: %s\n' "$lab_dir"

Ожидаемый тип операционной системы — linux, адрес выбранного контекста — локальный Unix-сокет. Если соединение переопределено через DOCKER_HOST или DOCKER_CONTEXT, сначала уточните фактический хост: один лишь вывод настроек контекста не подтверждает, куда ушёл запрос. Сохраните выведенный путь: переменная lab_dir нужна в следующих командах того же терминала. Если вы открыли новый терминал, задайте ей именно этот путь, не угадывайте каталог по похожему имени.

Проверьте доступ рабочего исполнителя

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

docker run --rm -i --network none --read-only \
  --user "$(id -u):$(id -g)" \
  --cap-drop ALL --security-opt no-new-privileges \
  --mount "type=bind,src=$lab_dir/work,dst=/work" \
  --mount "type=bind,src=$lab_dir/reference,dst=/reference,readonly" \
  -e "OTHER_HOST_PATH=$lab_dir/personal/notes.txt" \
  python:3.12-slim python - <<'PY'
import errno
import os
from pathlib import Path

assert Path('/work/notes.txt').read_text() == 'Work example only\n'
assert Path('/reference/guide.txt').read_text() == 'Shared reference only\n'
Path('/work/result.txt').write_text('Allowed write\n')

try:
    Path('/reference/guide.txt').write_text('Unexpected change\n')
except OSError as error:
    assert error.errno in {errno.EROFS, errno.EACCES, errno.EPERM}
    print('Reference write denied:', error.__class__.__name__)
else:
    raise RuntimeError('Reference must be read-only')

try:
    Path(os.environ['OTHER_HOST_PATH']).read_text()
except OSError as error:
    assert error.errno in {errno.ENOENT, errno.EACCES, errno.EPERM}
    print('Other private file unavailable:', error.__class__.__name__)
else:
    raise RuntimeError('Other private file must be unavailable')

print('Filesystem checks passed')
PY

Успешный результат — две строки об отказе и Filesystem checks passed. Если разрешённое чтение не сработало, исправьте настройку или права и повторите опыт. Если запрещённая операция удалась, не подключайте реальные данные: проверьте дополнительные монтирования и место исполнения.

Для проверки личного исполнителя повторите команду, заменив монтирование src=$lab_dir/work,dst=/work на src=$lab_dir/personal,dst=/work, значение OTHER_HOST_PATH на $lab_dir/work/notes.txt и ожидаемый текст Work example only на Personal example only. Остальные ограничения сохраняются. Проверьте и этот запуск, а не делайте вывод по симметрии.

На хосте убедитесь, что обе разрешённые записи появились, а справочник не изменился:

cat "$lab_dir/work/result.txt"
cat "$lab_dir/personal/result.txt"
cat "$lab_dir/reference/guide.txt"

Ожидаются две строки Allowed write и одна Shared reference only. После завершения учебные папки можно удалить вручную по сохранённому пути. Команда удаления намеренно не нужна для подтверждения результата.

Механизм подключения папки только для чтения описан в документации Docker bind mounts ↗. Здесь проверена конкретная файловая конфигурация. Агент с терминалом на хосте, внешним браузером или API может иметь другой доступ. Чтобы применить результат к нему, поместите нужный исполнитель в выбранную среду и отдельно испытайте каждый обходной канал. Контейнер также не заменяет оценку угроз общей операционной системы.

Используйте заранее созданные безобидные контрольные файлы и факты. Для API подготовьте тестовые объекты, на которые вы вправе проверять доступ. В протоколе достаточно указать действие, результат, среду и дату; содержимое частных документов и секреты в отчёт не включают.

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

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

Видит ли второй профиль частные файлы первого

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

Разделяет ли новый профиль внешнюю память и входы

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

Можно ли оставить один общий справочник

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

Что произойдёт после удаления помощника

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