Как защитить систему от AI: практическое руководство по sandboxing для локальных LLM

Почему ваш локальный LLM хочет удалить вашу систему (и как это предотвратить)

Вы скачали свежую модель, запустили ее с открытым шеллом для агента. Через час обнаруживаете, что домашняя директория чиста, а в крон добавлена задача на майнинг крипты. Знакомо? Это не сценарий из фантастики. В 2026 году атаки на цепочку поставок (supply chain), как та история с LiteLLM, стали обыденностью. Но теперь угроза не только в скомпрометированных пакетах. Она в самом коде, который генерирует ИИ.

Локальная LLM — не черный ящик с волшебством. Это код, исполняемый на вашей машине. Дайте агенту инструмент `subprocess.run`, и он может написать скрипт, который удалит все, до чего дотянется. Prompt injection превращает безобидный запрос в команду на форматирование диска. Звучит параноидально? Посмотрите на исследования по ИИ-рансому. Это уже реальность.

От теории к практике: три уровня изоляции для 2026 года

Sandbox — это не про "запустить в Docker и забыть". Это про слои. Как луковица. Чем больше слоев, тем больше слез у злоумышленника (или у вашего AI-агента, который решил, что `rm -rf /` — хорошее решение задачи по оптимизации места).

Уровень 1: Контейнеры (Docker, Podman) — базовый забор

Контейнеры изолируют процессы, но работают на общем ядре хоста. Уязвимость в ядре — и забор падает. В 2026 году `docker run` без флагов безопасности — это просто красивая упаковка для катастрофы.

Уровень 2: Виртуальные машины — бетонный бункер

Полная изоляция железа через гипервизор. KVM, QEMU. Это тяжело, требует ресурсов, но если агент сломает что-то внутри ВМ, хостовая система даже не чихнет. Идеально для запуска целых сред, где должен работать AI-агент с браузером или IDE. Тот самый случай "за бетонной стеной".

Уровень 3: Специализированные песочницы (gVisor, Firecracker) — умная клетка

Золотая середина. gVisor, проект от Google, реализует мусорное ядро (userspace kernel) на Go. Системные вызовы перехватываются и эмулируются — даже если агент найдет уязвимость, она будет в коде песочницы, а не в реальном ядре. Firecracker от Amazon — микро-ВМ, заточенные под быстрый запуск и минимальный оверхед. В 2026 году они стали стандартом для serverless и изоляции недоверенных рабочих нагрузок, включая AI.

Шаг за шагом: строим песочницу для AI-агента

Хватит теории. Берем популярный фреймворк для агентов (например, LangChain 1.0+ 2026 года), который умеет вызывать инструменты, и изолируем его так, чтобы даже самый креативный ИИ не навредил.

1 Готовим безопасный образ Docker

Не используйте `python:latest`. Собирайте минимальный образ с non-root пользователем. Отключайте все, что не нужно.

# Dockerfile для AI-агента (2026)
FROM python:3.12-slim-bookworm

# Создаем непривилегированного пользователя
RUN groupadd -r agent && useradd -r -g agent -m -d /home/agent agent

# Отключаем PIP cache, устанавливаем только нужное
ENV PIP_NO_CACHE_DIR=1 \
    PYTHONUNBUFFERED=1

WORKDIR /app
COPY --chown=agent:agent requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Копируем код от имени агента
COPY --chown=agent:agent . .
USER agent

# Запускаем агента
CMD ["python", "agent_main.py"]

2 Запускаем контейнер с ограничениями

Критический шаг. Без этих флагов контейнер почти бесполезен для безопасности.

docker run -d \
  --name ai-agent-sandbox \
  --read-only \  # Монтируем всю ФС только для чтения
  --tmpfs /tmp:rw,noexec,nosuid,size=1g \  # Временные файлы только в RAM
  --security-opt=no-new-privileges:true \  # Запрет повышения привилегий
  --cap-drop=ALL \  # Убираем все Linux capabilities
  --cap-add=CHOWN \  # Добавляем только минимально необходимые
  --memory=4g \  # Лимит памяти
  --cpus=2 \  # Лимит CPU
  --user agent \
  -v "$(pwd)/agent_data:/app/data:ro" \  # Данные только для чтения
  my-ai-agent:latest

3 Интегрируем с gVisor для усиленной изоляции

Если Docker с флагами — это забор, то gVisor — это забор под напряжением. Установите gVisor (runsc) и настройте Docker его использовать.

# Добавляем runsc как Docker runtime
echo '{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc"
    }
  }
}' | sudo tee /etc/docker/daemon.json
sudo systemctl restart docker

# Запускаем контейнер с gVisor
docker run --runtime=runsc \
  --name ai-agent-gvisor \
  --read-only \
  --security-opt=no-new-privileges \
  my-ai-agent:latest

Теперь системные вызовы агента проходят через песочницу. Подробнее о сравнении технологий читайте в гиде по выбору песочницы для shell-доступа.

4 Настраиваем контроль доступа к сети

Локальный LLM не должен звонить домой. Блокируем весь исходящий трафик, кроме разрешенных внутренних API.

# Создаем пользовательскую сеть Docker с ограничениями
docker network create --internal ai-internal-net

# Запускаем контейнер только во внутренней сети
docker run --network=ai-internal-net \
  --name ai-agent \
  my-ai-agent:latest

# Если нужно разрешить доступ только к определенному хосту
docker run --network=ai-internal-net \
  --add-host=allowed-api.internal:192.168.1.100 \
  --name ai-agent \
  my-ai-agent:latest

Ошибки, которые взорвут ваш sandbox (и как их избежать)

Я видел, как эти ошибки стоили людям данных и серверов.

• Доверять `--network host`. Контейнер получает полный доступ к сетевому стеку хоста. Идеально для атаки на соседние сервисы. Никогда так не делайте.
• Монтировать volumes с правами `rw`. Агент может зашифровать ваши бэкапы или подменить конфиги. Используйте `ro` (read-only) всегда, когда возможно. Для записи выделяйте изолированные `tmpfs`.
• Забыть про `--cap-add=NET_RAW`. С этой capability процесс внутри контейнера может отправлять raw-пакеты (например, для сканирования сети). Если агенту не нужно сетевое низкоуровневое взаимодействие — не давайте.
• Игнорировать обновления песочницыатаки на цепочку поставок PyPI доверяйте только образам из проверенных registry с цифровой подписью.
• Думать, что sandbox заменяет контроль за промптами. Изоляция среды выполнения не защитит от prompt injection. Это слои защиты. Нужны оба.

Что дальше? Эволюция sandboxing в 2026 году

Тенденции, которые меняют правила игры прямо сейчас:

1. Аппаратная изоляция (Intel TDX, AMD SEV)
2. eBPF для контроля поведения
3. Специализированные ОС для AI-агентов
4. Интеграция sandbox в сами фреймворки агентовLangSmith Sandboxes, предлагают встроенную изоляцию как сервис. Удобно, но вы зависите от их реализации.

Итог? Sandboxing для локальных LLM перестал быть опцией для параноиков. Это must-have, такой же, как фаервол или антивирус. Не ждите, когда ваш агент решит, что rm -rf /* — это оптимальный способ освободить место для новой модели. Изолируйте его сегодня. Начните с Docker с флагами, потом перейдите на gVisor. Спите спокойнее.

И да, если ваш агент работает с браузером, не пропустите гид по браузерным песочницам. Это отдельный ад, который стоит подготовить заранее.

Подписаться на канал