Защита сервера ИИ-агентов: песочница, файрвол и мониторинг

11 мин чтения·Matthieu·monitoringlinuxfirewalldockersecurityai-agents|

ИИ-агенты выполняют произвольные действия, потребляют непредсказуемые ресурсы и обрабатывают недоверенный ввод. Это руководство сопоставляет каждую угрозу с конкретным контролем Linux и проверенными командами.

ИИ-агенты - это не обычные сервисы. Веб-сервер обрабатывает предсказуемые HTTP-запросы. ИИ-агент выполняет произвольные вызовы инструментов, порождает дочерние процессы, делает исходящие API-запросы и потребляет ресурсы непредсказуемыми всплесками. Если prompt injection (внедрение в промпт) срабатывает, агент превращается в атакующего с теми привилегиями, которые вы ему дали.

Это руководство рассматривает каждого ИИ-агента как недоверенный код. Каждый раздел начинается с конкретной угрозы и сопоставляет её с контролем Linux, который можно проверить. Команды работают на любом VPS с Debian 12 или Ubuntu 22.04+, с любым фреймворком агентов: OpenClaw, Claude Code, n8n, LangChain, CrewAI или собственными решениями.

Предварительные требования: VPS с root-доступом, базовые знания Linux и SSH (основы безопасности VPS покрывают начальный уровень), и хотя бы один ИИ-агент, который нужно защитить. Руководство предполагает, что начальная настройка безопасности сервера уже выполнена (настройка SSH).

Почему ИИ-агенты - это особая угроза безопасности?

Традиционные сервисы имеют ограниченный набор поведений. Процесс Nginx отдаёт файлы и проксирует запросы. Поведение ИИ-агента зависит от входных данных, которые вы не контролируете. Три свойства отличают агентов от всего остального, что вы запускаете на сервере:

  1. Они выполняют произвольные действия. Агенты с tool-calling запускают команды оболочки, записывают файлы и делают HTTP-запросы на основе вывода LLM.
  2. Они потребляют непредсказуемые ресурсы. Цикл рассуждений может загрузить CPU на 100% на несколько минут. Неконтролируемый агент может сжечь API-токены за секунды.
  3. Они обрабатывают недоверенный ввод по своей природе. Весь смысл агента - принимать естественный язык и действовать по нему.
Угроза Вектор атаки Воздействие Контроль
Выполнение shell-команд Prompt injection через пользовательский ввод или вывод инструмента Полная компрометация системы Изоляция пользователей, контейнерная песочница
Эксфильтрация данных Агент отправляет секреты по HTTP/DNS на домен атакующего Кража учётных данных, утечка данных Исходящий файрвол, DNS-фильтрация
Исчерпание ресурсов Бесконечный цикл рассуждений или рекурсивные вызовы инструментов Падение сервера, недоступность других сервисов Лимиты CPU/памяти через cgroup
Утечка учётных данных Агент логирует или запоминает API-ключи из окружения Кража API-ключей, латеральное перемещение Инъекция секретов, изоляция окружения
Латеральное перемещение Скомпрометированный агент атакует другие сервисы Полная компрометация инфраструктуры Сегментация сети, минимальные привилегии

Как изолировать ИИ-агента с помощью выделенного пользователя Linux?

Создайте выделенного системного пользователя для каждого агента без оболочки входа, без sudo-доступа и с ограниченным домашним каталогом. Это самый простой контроль с максимальным эффектом. Если агент скомпрометирован, атакующий получает только права этого пользователя, а не root.

sudo useradd --system --create-home --shell /usr/sbin/nologin agent-worker

Закройте домашний каталог, чтобы другие пользователи не могли читать файлы агента:

sudo chmod 750 /home/agent-worker

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

getent passwd agent-worker

Ожидаемый вывод:

agent-worker:x:998:998::/home/agent-worker:/usr/sbin/nologin

оболочка - /usr/sbin/nologin. Это значит, что никто не может войти по SSH под этим пользователем или открыть интерактивную сессию. Процесс агента запускается от имени этого пользователя через systemd, а не через логин.

Если агенту нужно записывать временные файлы, создайте отдельный каталог:

sudo mkdir -p /home/agent-worker/tmp
sudo chown agent-worker:agent-worker /home/agent-worker/tmp
sudo chmod 700 /home/agent-worker/tmp

Проверьте права:

ls -la /home/agent-worker/

Что это даёт: даже если атакующий добьётся выполнения кода через prompt injection, он ограничен каталогом /home/agent-worker без возможности читать файлы других пользователей, повышать привилегии до root или модифицировать системные бинарники.

Как поместить ИИ-агента в песочницу Docker?

Запуск агента внутри контейнера Docker добавляет второй уровень изоляции. Контейнер имеет собственную файловую систему, пространство имён процессов и сетевой стек. В сочетании с флагами безопасности это ограничивает возможности скомпрометированного агента, даже при наличии выполнения кода.

Какие флаги безопасности Docker использовать для ИИ-агентов?

Используйте все ограничения, которые агент может выдержать. Начинайте с максимальной блокировки и ослабляйте только то, что ломается. Вот production-команда docker run для ИИ-агента:

docker run -d \
  --name ai-agent \
  --user 1000:1000 \
  --read-only \
  --tmpfs /tmp:size=100M,noexec,nosuid \
  --cap-drop ALL \
  --security-opt no-new-privileges:true \
  --security-opt seccomp=/etc/docker/seccomp-agent.json \
  --memory 2g \
  --memory-swap 2g \
  --cpus 1.5 \
  --pids-limit 100 \
  --network agent-net \
  --restart unless-stopped \
  --env-file /etc/agent/env \
  your-agent-image:latest

Что делает каждый флаг:

Флаг Назначение Зачем это нужно для агентов
--user 1000:1000 Запуск от не-root пользователя внутри контейнера Предотвращает побег из контейнера через root-эксплойты
--read-only Корневая файловая система только для чтения Блокирует установку вредоносного ПО, подмену конфигов
--tmpfs /tmp:size=100M,noexec,nosuid Записываемый /tmp без выполнения Агент может писать временные файлы, но не запускать бинарники из /tmp
--cap-drop ALL Убрать все Linux capabilities Никакого CAP_NET_RAW (перехват пакетов), никакого CAP_SYS_ADMIN (mount), ничего
--security-opt no-new-privileges:true Запретить повышение привилегий через setuid Блокирует получение root через setuid-бинарники
--pids-limit 100 Ограничение количества процессов Останавливает fork-бомбы от неконтролируемого агента
--memory 2g / --memory-swap 2g Жёсткий потолок памяти, без свопа Предотвращает OOM-убийство других сервисов
--cpus 1.5 Лимит CPU Агент не может голодом убить другие сервисы

Проверьте, что контейнер запущен с правильными настройками безопасности:

docker inspect ai-agent --format '{{.HostConfig.SecurityOpt}}'

Ожидаемый вывод:

[no-new-privileges:true seccomp=/etc/docker/seccomp-agent.json]

Проверьте, что он работает от не-root пользователя:

docker exec ai-agent whoami

Команда должна вернуть не-root пользователя, а не root.

Пользовательский seccomp-профиль для ИИ-агентов

Стандартный seccomp-профиль Docker блокирует около 44 опасных системных вызовов. Для ИИ-агентов можно ужесточить это ещё больше. Создайте /etc/docker/seccomp-agent.json:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "defaultErrnoRet": 1,
  "archMap": [
    {
      "architecture": "SCMP_ARCH_X86_64",
      "subArchitectures": ["SCMP_ARCH_X86", "SCMP_ARCH_X32"]
    }
  ],
  "syscalls": [
    {
      "names": [
        "read", "write", "close", "fstat", "lseek", "mmap", "mprotect",
        "munmap", "brk", "rt_sigaction", "rt_sigprocmask", "ioctl",
        "access", "pipe", "select", "sched_yield", "mremap", "msync",
        "mincore", "madvise", "dup", "dup2", "nanosleep", "getpid",
        "socket", "connect", "sendto", "recvfrom", "sendmsg", "recvmsg",
        "bind", "listen", "accept", "getsockname", "getpeername",
        "setsockopt", "getsockopt", "clone", "execve", "exit",
        "wait4", "kill", "uname", "fcntl", "flock", "fsync",
        "fdatasync", "truncate", "ftruncate", "getdents", "getcwd",
        "chdir", "openat", "newfstatat", "readlinkat", "fchmodat",
        "set_tid_address", "exit_group", "epoll_wait", "epoll_ctl",
        "tgkill", "futex", "set_robust_list", "get_robust_list",
        "epoll_create1", "pipe2", "clock_gettime", "clock_nanosleep",
        "prlimit64", "getrandom", "memfd_create", "statx",
        "rseq", "close_range", "poll", "getuid", "getgid",
        "geteuid", "getegid", "arch_prctl", "sigaltstack",
        "rt_sigreturn", "accept4", "pread64", "pwrite64",
        "writev", "readv", "sched_getaffinity"
      ],
      "action": "SCMP_ACT_ALLOW"
    }
  ]
}

Этот профиль разрешает только syscalls, необходимые для типичного процесса на Python/Node.js. Всё остальное, включая mount, ptrace, reboot, kexec_load и init_module, возвращает ошибку доступа.

Установите правильные права на профиль:

sudo chmod 644 /etc/docker/seccomp-agent.json
sudo chown root:root /etc/docker/seccomp-agent.json

Протестируйте запуск контейнера с пользовательским профилем:

docker run --rm --security-opt seccomp=/etc/docker/seccomp-agent.json alpine echo "seccomp works"

Если вы видите seccomp works, профиль валиден.

Для более глубокого укрепления Docker, включая rootless-режим, смотрите Docker security hardening. Про проблему взаимодействия Docker/UFW читайте Docker UFW fix.

Как заблокировать ИИ-агенту доступ в интернет?

Угроза: скомпрометированный агент выводит секреты через исходящие HTTP-запросы на сервер атакующего или кодирует данные в DNS-запросах. По умолчанию UFW разрешает весь исходящий трафик.

Установите политику запрета по умолчанию для исходящего трафика, затем добавьте в белый список только те эндпоинты, которые нужны агенту:

sudo ufw default deny outgoing
sudo ufw default deny incoming

Разрешите необходимый исходящий трафик:

# DNS resolution (required for all outbound)
sudo ufw allow out 53/udp

# Allow outbound HTTPS to reach AI provider APIs
sudo ufw allow out 443/tcp

# Allow outbound HTTP for package updates only
sudo ufw allow out 80/tcp

Разрешите входящий SSH (чтобы не заблокировать себя):

sudo ufw allow in 22/tcp

Включите файрвол:

sudo ufw enable

Проверьте правила:

sudo ufw status verbose

Вывод показывает Default: deny (incoming), deny (outgoing) в начале, за которым следуют ваши правила разрешений.

Как ограничить доступ только к нужным API-эндпоинтам?

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

Сначала определите IP вашего AI-провайдера:

dig +short api.anthropic.com
dig +short api.openai.com

Затем создайте правила iptables для этих IP. Создайте /etc/iptables/agent-egress.rules:

#!/bin/bash
# Agent egress whitelist - update IPs when providers change

# Anthropic API (check current IPs with: dig +short api.anthropic.com)
ANTHROPIC_IPS="104.18.0.0/16"

# Drop all outbound from agent user except whitelisted destinations
iptables -A OUTPUT -m owner --uid-owner agent-worker -d $ANTHROPIC_IPS -p tcp --dport 443 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner agent-worker -d 127.0.0.1 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner agent-worker -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner agent-worker -j DROP

sudo chmod 700 /etc/iptables/agent-egress.rules
sudo bash /etc/iptables/agent-egress.rules

Проверьте, что пользователь агента не может подключиться к произвольным хостам:

sudo -u agent-worker curl -s --max-time 5 https://example.com && echo "FAIL: egress not blocked" || echo "OK: egress blocked"

Ожидаемый вывод: OK: egress blocked.

Примечание про DNS-эксфильтрацию: правила выше разрешают DNS на порту 53. Опытный атакующий может кодировать данные в DNS-запросах, отправляя секреты как поддомены (например, sk-ant-api-key.attacker.com). Чтобы закрыть эту брешь, направьте DNS агента на локальный резолвер, например unbound, настроенный с response policy zone (RPZ), блокирующей запросы к доменам вне белого списка.

Установите и настройте локальный резолвер:

sudo apt install -y unbound

Отредактируйте /etc/unbound/unbound.conf.d/agent-dns.conf:

server:
    interface: 127.0.0.1
    access-control: 127.0.0.0/8 allow

    # Only allow resolution of specific domains
    local-zone: "." deny
    local-zone: "anthropic.com." transparent
    local-zone: "openai.com." transparent
    local-zone: "ubuntu.com." transparent
    local-zone: "debian.org." transparent

sudo systemctl enable --now unbound
sudo systemctl status unbound

Затем настройте контейнер или systemd-сервис агента на использование 127.0.0.1 в качестве DNS-резолвера вместо системного. В Docker добавьте --dns 127.0.0.1 к команде docker run.

Как ограничить частоту запросов к API ИИ-агента?

Угроза: открытый API-эндпоинт агента атакуют боты или используют для автоматизированных попыток prompt injection. Без ограничения частоты каждый запрос вызывает дорогие вызовы LLM API.

Если агент доступен через Nginx, добавьте ограничение на уровне обратного прокси. Добавьте в конфигурацию Nginx:

http {
    # 10 requests per second per IP for agent endpoints
    limit_req_zone $binary_remote_addr zone=agent_api:10m rate=10r/s;

    # Stricter limit for prompt submission endpoints
    limit_req_zone $binary_remote_addr zone=agent_prompt:10m rate=2r/s;

    server {
        listen 443 ssl;
        server_name agent.example.com;

        location /api/agent/ {
            limit_req zone=agent_api burst=20 nodelay;
            limit_req_status 429;
            proxy_pass http://127.0.0.1:8080;
        }

        location /api/agent/prompt {
            limit_req zone=agent_prompt burst=5 nodelay;
            limit_req_status 429;
            proxy_pass http://127.0.0.1:8080;
        }
    }
}

Проверьте конфигурацию:

sudo nginx -t && sudo systemctl reload nginx

Проверьте, что ограничение работает, отправив серию быстрых запросов:

for i in $(seq 1 30); do curl -s -o /dev/null -w "%{http_code}\n" https://agent.example.com/api/agent/; done

Вывод показывает ответы 200, а затем ответы 429, когда лимит превышен.

Как ограничить CPU и память для ИИ-агента?

Угроза: цикл рассуждений или рекурсивный вызов инструмента загружает CPU на 100% на несколько минут. Без лимитов агент лишает ресурсов SSH, мониторинг и другие сервисы. На shared VPS это может вызвать троттлинг от провайдера или автоматическую приостановку.

Лимиты ресурсов Docker

Если агент запущен в Docker, флаги --memory и --cpus из раздела про контейнеры выше справляются с этим. Проверьте, что лимиты применяются:

docker stats ai-agent --no-stream

Убедитесь, что MEM USAGE остаётся ниже MEM LIMIT, а CPU % не превышает выделенное количество ядер.

Лимиты cgroup через systemd для неконтейнеризированных агентов

Если агент работает напрямую на хосте (не в Docker), используйте systemd для принудительного применения лимитов cgroup v2. Создайте systemd-сервис с контролем ресурсов:

sudo systemctl edit --force --full ai-agent.service

[Unit]
Description=AI Agent Service
After=network.target

[Service]
Type=simple
User=agent-worker
Group=agent-worker
WorkingDirectory=/home/agent-worker
ExecStart=/home/agent-worker/run-agent.sh
Restart=on-failure
RestartSec=10

# Resource limits
MemoryMax=2G
MemoryHigh=1536M
CPUQuota=150%
TasksMax=100

# Security hardening
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=tmpfs
PrivateTmp=true
ReadWritePaths=/home/agent-worker/data

# Secrets
EnvironmentFile=/etc/agent/env

[Install]
WantedBy=multi-user.target

MemoryMax=2G - это жёсткий потолок. OOM killer завершает агента при превышении. MemoryHigh=1536M - мягкий лимит. Ядро агрессивно освобождает память выше этого порога, замедляя агента до того, как он упрётся в жёсткий лимит. CPUQuota=150% разрешает 1,5 ядра CPU. TasksMax=100 предотвращает fork-бомбы.

Активируйте и запустите сервис:

sudo systemctl enable --now ai-agent.service

enable обеспечивает запуск после перезагрузки. --now запускает немедленно.

Проверьте, что сервис работает и лимиты применены:

sudo systemctl status ai-agent.service

Проверьте лимиты cgroup:

systemctl show ai-agent.service | grep -E "(MemoryMax|CPUQuota|TasksMax)"

Ожидаемый вывод:

MemoryMax=2147483648
CPUQuota=150%
TasksMax=100

Как управлять секретами ИИ-агентов без утечек?

Угроза: агент логирует свои переменные окружения (многие фреймворки делают это в режиме отладки), включает API-ключи в контекст LLM или записывает учётные данные во временный файл. Атакующий с доступом на чтение памяти или логов агента получает все секреты.

Никогда не помещайте секреты в конфигурационный файл агента, Dockerfile или аргументы командной строки. Используйте файл окружения с ограниченными правами.

Создайте файл секретов:

sudo mkdir -p /etc/agent
sudo touch /etc/agent/env
sudo chmod 600 /etc/agent/env
sudo chown root:root /etc/agent/env

Добавьте секреты:

sudo tee /etc/agent/env > /dev/null << 'EOF'
ANTHROPIC_API_KEY=sk-ant-your-key-here
AGENT_DB_PASSWORD=replace-with-generated-password
EOF

Генерируйте сильные пароли вместо того, чтобы придумывать их:

openssl rand -base64 32

Systemd-сервис ссылается на этот файл через EnvironmentFile=/etc/agent/env. Процесс агента получает переменные, но не может прочитать сам файл (владелец root, права 600). Systemd читает файл и передаёт переменные процессу.

Проверьте права файла:

ls -la /etc/agent/env

Ожидаемый результат: -rw------- 1 root root. Только root может его прочитать.

Ротация: при ротации секрета обновите /etc/agent/env и перезапустите сервис:

sudo systemctl restart ai-agent.service

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

Как мониторить активность ИИ-агента на Linux-сервере?

Угроза: скомпрометированный или неисправный агент работает тихо. Без мониторинга вы обнаруживаете проблему, когда приходит счёт за API или сервер попадает в чёрный список за злоупотребления.

Мониторинг ресурсов в реальном времени

Следите за потреблением ресурсов в реальном времени:

journalctl -u ai-agent.service -f

Это транслирует stdout/stderr агента в реальном времени. Нажмите Ctrl+C для остановки.

Для Docker-контейнеров:

docker logs -f ai-agent

Мониторинг CPU и памяти в реальном времени:

docker stats ai-agent

Какие правила auditd настроить для процессов ИИ-агентов?

Установите auditd:

sudo apt update && sudo apt install -y auditd

Создайте правила аудита для агентов. Добавьте в /etc/audit/rules.d/agent.rules:

# Monitor all commands executed by the agent user
-a exit,always -F arch=b64 -S execve -F uid=998 -k agent-exec

# Monitor file access in sensitive directories
-a exit,always -F arch=b64 -S openat -F dir=/etc -F uid=998 -k agent-etc-access

# Monitor network connections by agent user
-a exit,always -F arch=b64 -S connect -F uid=998 -k agent-network

# Monitor file permission changes by agent user
-a exit,always -F arch=b64 -S chmod,fchmod,fchmodat -F uid=998 -k agent-chmod

Замените uid=998 на реальный UID пользователя агента. Узнать его можно так:

id -u agent-worker

Загрузите новые правила:

sudo augenrules --load
sudo systemctl enable --now auditd

Проверьте, что правила активны:

sudo auditctl -l | grep agent

Вывод показывает свои четыре правила.

Поиск событий выполнения команд агентом:

sudo ausearch -k agent-exec --start recent

Автоматические оповещения

Для production настройте простой watchdog (сторожевой таймер), который оповещает о высоком потреблении ресурсов. Создайте /usr/local/bin/agent-watchdog.sh:

#!/bin/bash
# Alert if agent container exceeds 90% memory
USAGE=$(docker stats ai-agent --no-stream --format "{{.MemPerc}}" | tr -d '%')
THRESHOLD=90

if (( $(echo "$USAGE > $THRESHOLD" | bc -l) )); then
    logger -t agent-watchdog "ALERT: ai-agent memory at ${USAGE}%"
fi

sudo chmod 755 /usr/local/bin/agent-watchdog.sh

Запускайте каждую минуту через cron или systemd timer. Оповещения попадают в syslog, откуда их можно пересылать в вашу систему мониторинга.

Как безопасно обновлять ПО ИИ-агентов?

Угроза: необновлённое ПО агента содержит известные уязвимости. Но обновление во время сессии может повредить состояние или сломать рабочие процессы.

Для агентов на Docker процесс обновления атомарный:

# Pull the new image
docker pull your-agent-image:latest

# Stop the old container
docker stop ai-agent

# Remove the old container
docker rm ai-agent

# Start with the same flags (use the docker run command from above)
docker run -d \
  --name ai-agent \
  # ... same flags as before ...
  your-agent-image:latest

Для неконтейнеризированных агентов:

# Check for updates to the agent
sudo systemctl stop ai-agent.service

# Update the agent (varies by framework)
# pip install --upgrade agent-framework
# npm update -g agent-tool

# Restart
sudo systemctl start ai-agent.service

# Verify it is running
sudo systemctl status ai-agent.service

Совет для production: запускайте два экземпляра агента за балансировщиком нагрузки. Обновляйте по одному. Если обновлённый экземпляр не проходит health check, откатитесь к предыдущей версии.

Обновляйте ОС хоста отдельно:

sudo apt update && sudo apt upgrade -y

Включите автоматические обновления безопасности:

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

До и после: что видит атакующий

На незащищённом сервере, где агент работает от root без контейнера и файрвола:

  • Полный доступ к файловой системе: чтение /etc/shadow, SSH-ключей, данных других пользователей
  • Неограниченный исходящий трафик: эксфильтрация данных на любой адрес
  • Все syscalls доступны: монтирование файловых систем, загрузка модулей ядра, перехват сетевого трафика
  • Без лимитов ресурсов: обрушение сервера fork-бомбой или утечкой памяти
  • Постоянный доступ: установка бэкдора, добавление SSH-ключей, создание новых пользователей

После применения всех контролей из этого руководства:

  • Ограничение каталогом /home/agent-worker без доступа к системным файлам
  • Исходящий HTTPS только на IP-адреса из белого списка API
  • Около 80 syscalls доступно (вместо 300+), без mount/ptrace/reboot
  • Жёсткий потолок: 2 ГБ RAM и 1,5 ядра CPU, лимит 100 процессов
  • Файловая система только для чтения, невозможность установить ПО или сохранить изменения
  • Каждая команда записана в auditd с возможностью поиска

Агент продолжает работать. Он может вызывать LLM API, обрабатывать ввод и возвращать результаты. Но скомпрометированный агент не может выбраться из своей песочницы.

Что-то пошло не так?

Симптом Вероятная причина Решение
Контейнер сразу завершается Seccomp-профиль слишком строгий Запустите с --security-opt seccomp=unconfined временно, проверьте dmesg на заблокированные syscalls, добавьте их в профиль
Агент не может достучаться до API Исходящий файрвол блокирует трафик Проверьте sudo ufw status, убедитесь, что IP назначения разрешён
Агент убит OOM Лимит памяти слишком низкий Увеличьте MemoryMax или --memory, проверьте реальное пиковое потребление через docker stats
auditd не пишет логи Правила не загружены или неправильный UID Запустите sudo auditctl -l для проверки, сверьте UID с пользователем агента
Ошибки 429 от Nginx Лимит слишком жёсткий Увеличьте значение burst, проверьте, ожидаются ли всплески легитимного трафика
Агент не может записать временные файлы --read-only без --tmpfs Добавьте --tmpfs /tmp:size=100M к команде Docker run

Сначала проверьте логи агента:

# Systemd service
journalctl -u ai-agent.service -n 50 --no-pager

# Docker container
docker logs --tail 50 ai-agent

Проверьте логи аудита на заблокированные действия:

sudo ausearch -k agent-exec --start today -i

FAQ

Можно ли безопасно запускать ИИ-агентов от root?

Нет. Запуск агентов от root означает, что любой prompt injection даёт атакующему полный контроль над системой. Не существует компенсирующего контроля, который делает запуск от root допустимым. Всегда используйте выделенного не-root пользователя.

Нужен ли Docker для защиты ИИ-агента?

Нет. Изоляция пользователей Linux, директивы безопасности systemd (ProtectSystem, NoNewPrivileges, PrivateTmp) и лимиты cgroup обеспечивают хорошую изоляцию без Docker. Docker добавляет границу контейнера, что полезно как дополнительный уровень защиты. Используйте его, если можете, но одной изоляции пользователей достаточно для защиты от большинства атак prompt-injection-to-root-shell.

Сколько CPU выделить ИИ-агенту?

Начните с 1-2 ядер CPU (CPUQuota=150% в systemd или --cpus 1.5 в Docker) и 2 ГБ RAM на VPS с 8 ГБ. Мониторьте реальное потребление через docker stats или systemctl status в течение недели, потом корректируйте. Агенты работают пачками: простаивают между запросами и дают всплеск во время рассуждений. Лимиты не дают всплескам мешать другим сервисам.

Как защитить несколько агентов на одном сервере?

Создайте отдельного пользователя Linux и контейнер для каждого агента. Каждый получает собственные лимиты cgroup, правила исходящего трафика и журнал аудита. Используйте Docker networks для изоляции межагентного трафика. Никогда не делитесь секретами между агентами.

Авторское право 2026 Virtua.Cloud. Все права защищены. Данный контент является оригинальным произведением команды Virtua.Cloud. Воспроизведение, повторная публикация или распространение без письменного разрешения запрещены.

Готовы попробовать?

Запускайте ИИ-агентов безопасно на собственном VPS.

Смотреть тарифы VPS