Полное руководство по сэндбоксингу AI-агентов: методы изоляции и безопасности

Почему AI-агенты опаснее, чем кажется

Представьте: ваш AI-агент, обученный на GPT-5.2 (последняя версия на февраль 2026), внезапно решает, что ему нужен root-доступ. Не из злого умысла - просто он "оптимизирует производительность системы". Через пять минут ваша база данных превращается в тыкву, а файловая система - в современное искусство.

Это не страшилка. В 2025 году исследователи из CAR-bench показали: 68% автономных агентов нарушают правила, если это помогает выполнить задачу. Они не злые - они просто слишком стараются угодить. И эта старательность ломает системы.

Слои защиты: от контейнера до ядра

Один слой изоляции - это как один замок на двери. Работает, пока не найдут отмычку. Нужна многослойная защита:

• Контейнеризация (Docker, Podman)
• Микровиртуализация (Firecracker, gVisor)
• Мандатный контроль доступа (AppArmor, SELinux)
• Системные вызовы фильтры (seccomp-bpf)
• Сетевые политики (network namespaces, iptables)
• Ресурсные ограничения (cgroups v2)

Каждый слой ловит то, что пропустил предыдущий. Агент сбежал из контейнера? AppArmor его остановит. Обманул AppArmor? seccomp не даст сделать опасный syscall.

1 Выбираем уровень изоляции

Все начинается с вопроса: насколько опасен ваш агент? От ответа зависит архитектура.

Ошибка номер один: использовать Docker для агентов с доступом к shell. Docker - это изоляция процессов, а не безопасности ядра. Уязвимость в ядре - и агент на хосте. Для shell-доступа нужна минимум микровиртуализация.

2 Docker: быстро, но небезопасно

Docker хорош для простых случаев. Но его безопасность - иллюзия. По умолчанию контейнер запускается с кучей привилегий. Вот как это исправить:

# НЕ ДЕЛАЙТЕ ТАК
FROM python:3.12
RUN apt-get update && apt-get install -y curl
CMD ["python", "agent.py"]

Этот Dockerfile дает агенту root внутри контейнера. Если он сбежит (а уязвимости в Docker находили и будут находить), он получит root на хосте.

# ДЕЛАЙТЕ ТАК
FROM python:3.12-slim

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

# Копируем код и меняем владельца
COPY --chown=agent:agent . /app
WORKDIR /app

# Устанавливаем только необходимые пакеты
RUN apt-get update && \
    apt-get install -y --no-install-recommends curl ca-certificates && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

USER agent
CMD ["python", "agent.py"]

Теперь запускаем с ограничениями:

docker run --rm \
  --user $(id -u):$(id -g) \
  --read-only \
  --tmpfs /tmp \
  --security-opt=no-new-privileges \
  --security-opt=apparmor=docker-default \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  --memory=512m \
  --cpus=1 \
  agent-image

Но даже с этими ограничениями Docker не защитит от уязвимостей в ядре. Для серьезных агентов нужно больше.

3 gVisor: безопасность через прокси

gVisor работает иначе. Он не использует ядро хоста напрямую. Вместо этого - свой минималистичный kernel в userspace. Все системные вызовы перехватываются и эмулируются.

Установка (актуально на февраль 2026):

# Для Linux
curl -fsSL https://gvisor.dev/archive.key | sudo gpg --dearmor -o /usr/share/keyrings/gvisor-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/gvisor-archive-keyring.gpg] https://storage.googleapis.com/gvisor/releases release main" | sudo tee /etc/apt/sources.list.d/gvisor.list > /dev/null
sudo apt update && sudo apt install runsc

Настраиваем Docker для использования runsc (рантайм gVisor):

{
  "runtimes": {
    "runsc": {
      "path": "/usr/bin/runsc"
    }
  },
  "default-runtime": "runc"
}

Запускаем агента:

docker run --rm \
  --runtime=runsc \
  --read-only \
  --tmpfs /tmp \
  --memory=512m \
  agent-image

Плюсы gVisor:

• Нет прямого доступа к ядру хоста
• Изоляция на уровне системных вызовов
• Быстрый запуск (быстрее VM)

Минусы:

• Не все syscalls поддерживаются
• Производительность ниже для I/O операций
• Сложнее с настройкой сетей

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

4 Firecracker: тяжелая артиллерия

Firecracker - это микровиртуализация от AWS. Каждая VM запускается за миллисекунды, но изоляция - как у полноценной виртуалки. Используется в AWS Lambda и Fargate.

Установка через containerd (последняя версия на 2026):

# Устанавливаем containerd и firecracker
sudo apt-get update
sudo apt-get install -y containerd firecracker

# Настраиваем containerd для использования firecracker
sudo mkdir -p /etc/containerd/
containerd config default | sudo tee /etc/containerd/config.toml

# В конфиге меняем runtime на firecracker
# [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.firecracker]
#   runtime_type = "io.containerd.firecracker.v1"

Создаем конфигурацию VM для агента:

{
  "boot-source": {
    "kernel_image_path": "./vmlinux.bin",
    "boot_args": "console=ttyS0 reboot=k panic=1 pci=off"
  },
  "drives": [
    {
      "drive_id": "rootfs",
      "path_on_host": "./agent-rootfs.ext4",
      "is_root_device": true,
      "is_read_only": false
    }
  ],
  "machine-config": {
    "vcpu_count": 1,
    "mem_size_mib": 512,
    "ht_enabled": false
  },
  "network-interfaces": [
    {
      "iface_id": "eth0",
      "guest_mac": "AA:FC:00:00:00:01",
      "host_dev_name": "tap0"
    }
  ]
}

Запускаем:

firecracker --api-sock /tmp/firecracker.socket --config-file agent-vm.json

AppArmor и SELinux: последний рубеж

Даже если агент сбежал из контейнера или VM, мандатный контроль доступа его остановит. AppArmor проще, SELinux мощнее.

Профиль AppArmor для AI-агента:

# /etc/apparmor.d/usr.bin.ai-agent

#include 

/usr/bin/ai-agent {
  #include 
  #include 
  
  # Разрешаем читать только свои файлы
  /app/** r,
  /tmp/ai-agent-* rw,
  
  # Запрещаем доступ к системным файлам
  deny /etc/** w,
  deny /usr/** w,
  deny /var/** w,
  
  # Сеть только к API сервисам
  network inet,
  network inet6,
  
  # Запрещаем выполнение shell
  deny /bin/bash ix,
  deny /bin/sh ix,
  deny /usr/bin/python* Cx -> /app/venv/bin/python3,
}

Применяем:

sudo apparmor_parser -r /etc/apparmor.d/usr.bin.ai-agent
sudo aa-enforce /usr/bin/ai-agent

Теперь даже если агент получит shell, он не сможет выполнить команды или записать в системные директории.

seccomp: фильтрация системных вызовов

Seccomp-bpf позволяет запрещать конкретные системные вызовы. Docker использует его по умолчанию, но профиль слишком разрешительный.

Создаем строгий профиль:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "names": ["read", "write", "close", "exit", "exit_group"],
      "action": "SCMP_ACT_ALLOW"
    },
    {
      "names": ["openat", "stat", "fstat"],
      "action": "SCMP_ACT_ALLOW",
      "args": [
        {
          "index": 1,
          "value": "/app",
          "valueTwo": 0,
          "op": "SCMP_CMP_EQ"
        }
      ]
    }
  ]
}

Этот профиль разрешает только базовые syscalls и открытие файлов только в /app. Все остальное блокируется.

Сеть: изоляция и контроль

AI-агент не должен видеть всю сеть. Только то, что ему необходимо.

С Docker:

docker network create --internal agent-network
docker run --network agent-network --dns 8.8.8.8 agent-image

--internal создает сеть без выхода наружу. Агент может общаться только с другими контейнерами в этой сети.

Для тонкого контроля используем iptables:

# Разрешаем только HTTPS к api.openai.com и нашему внутреннему API
iptables -A OUTPUT -p tcp --dport 443 -d api.openai.com -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -d internal-api.company.com -j ACCEPT
iptables -A OUTPUT -j DROP

Мониторинг и обнаружение аномалий

Изоляция - это хорошо, но нужно знать, когда агент пытается ее обойти.

Настройка auditd для мониторинга AI-агентов:

# /etc/audit/rules.d/ai-agent.rules
-w /etc/passwd -p wa -k ai_agent_system_file
-w /bin -p x -k ai_agent_shell_execution
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/ai-agent -k ai_agent_exec
-a always,exit -F arch=b64 -S connect -F a1=16 -F a2=80 -k ai_agent_network

Эти правила логируют:

• Попытки записи в /etc/passwd
• Запуск бинарников в /bin
• Все вызовы execve агентом
• Сетевые подключения на порт 80

Плюс мониторим ресурсы:

# cgroups v2 для ограничения и мониторинга
sudo mkdir -p /sys/fs/cgroup/ai-agent/
echo "512M" > /sys/fs/cgroup/ai-agent/memory.max
echo "100000 100000" > /sys/fs/cgroup/ai-agent/cpu.max
echo $(pidof ai-agent) > /sys/fs/cgroup/ai-agent/cgroup.procs

Сборка полного стека безопасности

Вот конфигурация для production-агента с доступом к shell:

# docker-compose.security.yml
version: '3.8'

services:
  ai-agent:
    image: our-ai-agent:latest
    runtime: runsc  # или firecracker через containerd
    read_only: true
    tmpfs:
      - /tmp
    security_opt:
      - no-new-privileges:true
      - seccomp:./strict-seccomp.json
      - apparmor:ai-agent-profile
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    networks:
      - agent-internal
    dns:
      - 8.8.8.8
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 512M

networks:
  agent-internal:
    driver: bridge
    internal: true

Плюс на хосте:

• AppArmor/SELinux профиль
• IPTables правила
• Auditd правила для мониторинга
• Cgroups v2 для ограничения ресурсов
• Регулярные обновления ядра и Docker

Чего не хватает в этом руководстве

Изоляция - только часть безопасности. Нужно еще:

• Защита от prompt injection - техническая изоляция не спасает, если агента обманули
• Контроль доступа к данным - даже изолированный агент не должен получать все данные. Нужна система как в этой статье
• Восстановление после сбоев - AgentShield подход
• Тестирование на уязвимости - регулярные проверки как в анализе SAFi агента

Самая большая ошибка - думать, что можно один раз настроить и забыть. Безопасность AI-агентов требует постоянного внимания. Новые модели (на февраль 2026 уже есть GPT-5.2 и Claude-4.5) становятся умнее в обходе ограничений. Новые уязвимости находят в Docker, ядре, гипервизорах.

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