Sécuriser votre serveur d'agents IA : sandboxing, pare-feu et supervision

15 min de lecture·Matthieu·monitoringlinuxfirewalldockersecurityai-agents|

Les agents IA exécutent des actions arbitraires, consomment des ressources imprévisibles et traitent des entrées non fiables par conception. Ce guide associe chaque menace à un contrôle Linux concret avec des commandes testées.

Les agents IA ne sont pas des services classiques. Un serveur web traite des requêtes HTTP prévisibles. Un agent IA exécute des appels d'outils arbitraires, lance des sous-processus, envoie des requêtes API sortantes et consomme des ressources par pics imprévisibles. Si une injection de prompt (prompt injection) réussit, l'agent devient un attaquant avec tous les privilèges que vous lui avez accordés.

Ce guide traite chaque agent IA comme du code non fiable. Chaque section commence par une menace précise, puis la relie à un contrôle Linux vérifiable. Les commandes fonctionnent sur tout VPS sous Debian 12 ou Ubuntu 22.04+, avec n'importe quel framework d'agents : OpenClaw, Claude Code, n8n, LangChain, CrewAI, ou des configurations personnalisées.

Prérequis : Un VPS avec accès root, des connaissances de base en Linux et SSH (bases de la sécurité VPS couvre le socle), et au moins un agent IA à verrouiller. Ce guide suppose que vous avez déjà effectué le durcissement initial du serveur (durcissement SSH).

Pourquoi les agents IA représentent-ils une menace différente ?

Les services traditionnels ont un ensemble de comportements borné. Un processus Nginx sert des fichiers et proxifie des requêtes. Le comportement d'un agent IA dépend de son entrée, que vous ne contrôlez pas. Trois propriétés distinguent les agents de tout ce que vous exécutez sur un serveur :

  1. Ils exécutent des actions arbitraires. Les agents avec appel d'outils (tool-calling) lancent des commandes shell, écrivent des fichiers et font des requêtes HTTP à partir de la sortie du LLM.
  2. Ils consomment des ressources imprévisibles. Une boucle de raisonnement peut faire monter le CPU à 100 % pendant plusieurs minutes. Un agent emballé peut brûler des tokens API en quelques secondes.
  3. Ils traitent des entrées non fiables par conception. L'objectif même d'un agent est d'accepter du langage naturel et d'agir en conséquence.
Menace Vecteur d'attaque Impact Contrôle
Exécution de commandes shell Injection de prompt via entrée utilisateur ou sortie d'outil Compromission totale du système Isolation utilisateur, sandbox conteneur
Exfiltration de données L'agent envoie des secrets via HTTP/DNS vers un domaine attaquant Vol d'identifiants, fuite de données Pare-feu en sortie, filtrage DNS
Épuisement des ressources Boucle de raisonnement infinie ou appels d'outils récursifs Crash du serveur, autres services indisponibles Limites CPU/mémoire cgroup
Fuite d'identifiants L'agent journalise ou mémorise des clés API depuis l'environnement Vol de clés API, mouvement latéral Injection de secrets, isolation de l'environnement
Mouvement latéral Un agent compromis pivote vers d'autres services Compromission de toute l'infrastructure Segmentation réseau, moindre privilège

Comment isoler un agent IA avec un utilisateur Linux dédié ?

Créez un utilisateur système dédié pour chaque agent, sans shell de connexion, sans accès sudo et avec un répertoire personnel restreint. C'est le contrôle le plus simple avec le plus grand impact. Si un agent est compromis, l'attaquant hérite uniquement des permissions de cet utilisateur, pas de root.

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

Verrouillez le répertoire personnel pour que les autres utilisateurs ne puissent pas lire les fichiers de l'agent :

sudo chmod 750 /home/agent-worker

Vérifiez que l'utilisateur existe et a le bon shell :

getent passwd agent-worker

Sortie attendue :

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

le shell est /usr/sbin/nologin. Personne ne peut se connecter en SSH avec cet utilisateur ni ouvrir une session interactive. Le processus de l'agent tourne sous cet utilisateur via systemd, pas via une connexion.

Si votre agent a besoin d'écrire des fichiers temporaires, créez un répertoire dédié :

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

Vérifiez les permissions :

ls -la /home/agent-worker/

Ce que ça fait : Même si un attaquant obtient une exécution de code par injection de prompt, il est confiné à /home/agent-worker sans pouvoir lire les fichiers des autres utilisateurs, escalader vers root ou modifier les binaires système.

Comment sandboxer un agent IA dans un conteneur Docker ?

Exécuter votre agent dans un conteneur Docker ajoute une seconde barrière d'isolation. Le conteneur dispose de son propre système de fichiers, espace de noms de processus et pile réseau. Combiné aux options de sécurité, il limite ce qu'un agent compromis peut faire, même avec une exécution de code.

Quels flags de sécurité Docker utiliser pour les agents IA ?

Utilisez toutes les restrictions que votre agent peut tolérer. Commencez verrouillé et ne relâchez que ce qui bloque. Voici une commande docker run de production pour un agent IA :

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

Ce que chaque flag fait :

Flag Fonction Pourquoi c'est important pour les agents
--user 1000:1000 Exécuter en non-root dans le conteneur Empêche l'évasion du conteneur via des exploits root
--read-only Système de fichiers racine en lecture seule Bloque l'installation de malware, la modification de configuration
--tmpfs /tmp:size=100M,noexec,nosuid Temp inscriptible sans exécution L'agent peut écrire des fichiers temp mais pas exécuter de binaires depuis /tmp
--cap-drop ALL Supprime toutes les capabilities Linux Pas de CAP_NET_RAW (capture réseau), pas de CAP_SYS_ADMIN (montage), rien
--security-opt no-new-privileges:true Empêche l'escalade de privilèges via setuid Bloque un agent compromis qui tenterait d'obtenir root via des binaires setuid
--pids-limit 100 Plafond du nombre de processus Arrête les fork bombs d'un agent emballé
--memory 2g / --memory-swap 2g Plafond mémoire strict, pas de swap Empêche le OOM killer de tuer les autres services
--cpus 1.5 Limite CPU L'agent ne peut pas affamer les autres services

Vérifiez que le conteneur tourne avec les bons paramètres de sécurité :

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

Sortie attendue :

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

Vérifiez qu'il tourne en non-root :

docker exec ai-agent whoami

Cela devrait retourner l'utilisateur non-root, pas root.

Profil seccomp personnalisé pour les agents IA

Le profil seccomp par défaut de Docker bloque environ 44 appels système dangereux. Pour les agents IA, vous pouvez aller plus loin. Créez /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"
    }
  ]
}

Ce profil autorise uniquement les appels système nécessaires à un processus d'agent Python/Node.js typique. Tout le reste, y compris mount, ptrace, reboot, kexec_load et init_module, retourne une erreur de permission.

Définissez les permissions correctes sur le profil :

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

Testez que le conteneur démarre avec le profil personnalisé :

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

Si vous voyez seccomp works, le profil est valide.

Pour un durcissement Docker plus poussé incluant le mode rootless, voir Docker security hardening. Pour le piège d'interaction Docker/UFW, voir Docker UFW fix.

Comment empêcher un agent IA d'accéder à Internet ?

Menace : Un agent compromis exfiltre des secrets en envoyant des requêtes HTTP sortantes vers un serveur contrôlé par l'attaquant, ou encode des données dans des requêtes DNS. Par défaut, UFW autorise tout le trafic sortant.

Définissez une politique de refus par défaut pour le trafic sortant, puis autorisez uniquement les points de terminaison dont votre agent a besoin :

sudo ufw default deny outgoing
sudo ufw default deny incoming

Autorisez le trafic sortant indispensable :

# 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

Autorisez le SSH entrant (pour ne pas vous verrouiller dehors) :

sudo ufw allow in 22/tcp

Activez le pare-feu :

sudo ufw enable

Vérifiez les règles :

sudo ufw status verbose

La sortie affiche Default: deny (incoming), deny (outgoing) en haut, suivi de vos règles d'autorisation.

Comment n'autoriser que les points de terminaison API nécessaires à mon agent ?

Les règles ci-dessus autorisent encore le HTTPS sortant vers n'importe quelle destination. Pour un contrôle plus fin, restreignez le trafic sortant à des plages IP spécifiques. Cela nécessite iptables car UFW ne prend pas en charge le filtrage par destination sur le nom de domaine.

D'abord, résolvez le point de terminaison API de votre fournisseur IA :

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

Puis créez des règles iptables pour ces IP. Créez /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

Vérifiez que l'utilisateur de l'agent ne peut pas atteindre des hôtes arbitraires :

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

La sortie attendue est OK: egress blocked.

Note sur l'exfiltration DNS : Les règles ci-dessus autorisent le DNS sur le port 53. Un attaquant sophistiqué peut encoder des données dans des requêtes DNS, envoyant des secrets sous forme de sous-domaines (par exemple sk-ant-api-key.attacker.com). Pour combler cette faille, faites pointer le DNS de l'agent vers un résolveur local comme unbound configuré avec une zone de politique de réponse (RPZ) qui bloque les requêtes vers les domaines non autorisés.

Installez et configurez un résolveur local :

sudo apt install -y unbound

Éditez /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

Ensuite, configurez le conteneur Docker ou le service systemd de votre agent pour utiliser 127.0.0.1 comme résolveur DNS au lieu du défaut système. Dans Docker, ajoutez --dns 127.0.0.1 à votre commande docker run.

Comment limiter le débit des points de terminaison API d'un agent IA ?

Menace : Un point de terminaison API d'agent exposé se fait marteler par des bots ou est exploité via des tentatives automatisées d'injection de prompt. Sans limitation de débit, chaque requête déclenche des appels LLM coûteux.

Si vous exposez votre agent via Nginx, ajoutez une limitation de débit au niveau du reverse proxy. Ajoutez à votre configuration 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;
        }
    }
}

Testez la configuration :

sudo nginx -t && sudo systemctl reload nginx

Vérifiez que la limitation de débit est active en envoyant des requêtes rapides :

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

La sortie affiche des réponses 200 suivies de réponses 429 une fois la limite atteinte.

Comment limiter l'utilisation CPU et mémoire d'un agent IA ?

Menace : Une boucle de raisonnement ou un appel d'outil récursif fait monter le CPU à 100 % pendant plusieurs minutes. Sans limites, l'agent prive SSH, le monitoring et les autres services de ressources. Sur un VPS mutualisé, cela peut déclencher un throttling ou une suspension automatique par le fournisseur.

Limites de ressources Docker

Si votre agent tourne dans Docker, les flags --memory et --cpus de la section conteneur ci-dessus gèrent ce point. Vérifiez que les limites sont appliquées :

docker stats ai-agent --no-stream

Vérifiez que MEM USAGE reste sous MEM LIMIT et que CPU % reste sous vos cœurs alloués.

Limites cgroup systemd pour les agents non conteneurisés

Si votre agent tourne directement sur l'hôte (pas dans Docker), utilisez systemd pour appliquer des limites cgroup v2. Créez un service systemd avec des contrôles de ressources :

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 est un plafond strict. Le OOM killer termine l'agent s'il dépasse cette valeur. MemoryHigh=1536M est une limite souple. Le noyau récupère agressivement la mémoire au-dessus de ce seuil, ralentissant l'agent avant qu'il atteigne le plafond strict. CPUQuota=150% autorise 1,5 cœur CPU. TasksMax=100 empêche les fork bombs.

Activez et démarrez le service :

sudo systemctl enable --now ai-agent.service

enable le fait survivre aux redémarrages. --now le démarre immédiatement.

Vérifiez que le service tourne et que les limites sont appliquées :

sudo systemctl status ai-agent.service

Vérifiez les limites cgroup :

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

Sortie attendue :

MemoryMax=2147483648
CPUQuota=150%
TasksMax=100

Comment gérer les secrets des agents IA sans les exposer ?

Menace : Un agent journalise ses variables d'environnement (beaucoup de frameworks le font en mode debug), inclut des clés API dans le contexte du LLM, ou écrit des identifiants dans un fichier temporaire. Un attaquant avec accès en lecture à la mémoire ou aux journaux de l'agent récupère tous les secrets.

Ne mettez jamais les secrets dans le fichier de configuration de l'agent, le Dockerfile ou les arguments de la ligne de commande. Utilisez un fichier d'environnement avec des permissions restreintes.

Créez le fichier de secrets :

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

Ajoutez vos secrets :

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

Générez des mots de passe forts au lieu de les inventer :

openssl rand -base64 32

Le service systemd référence ce fichier avec EnvironmentFile=/etc/agent/env. Le processus de l'agent reçoit les variables mais ne peut pas lire le fichier lui-même (propriétaire root, mode 600). Systemd lit le fichier et transmet les variables au processus.

Vérifiez les permissions du fichier :

ls -la /etc/agent/env

Attendu : -rw------- 1 root root. Seul root peut le lire.

Rotation : Quand vous changez un secret, mettez à jour /etc/agent/env et redémarrez le service :

sudo systemctl restart ai-agent.service

L'agent récupère les nouvelles valeurs sans modification de fichier de configuration.

Comment superviser l'activité d'un agent IA sur un serveur Linux ?

Menace : Un agent compromis ou défaillant s'exécute silencieusement. Sans supervision, vous découvrez le problème quand votre facture API arrive ou que votre serveur est signalé pour abus.

Supervision en temps réel des ressources

Suivez l'utilisation des ressources en direct :

journalctl -u ai-agent.service -f

Cela diffuse la sortie stdout/stderr de l'agent en temps réel. Appuyez sur Ctrl+C pour arrêter.

Pour les conteneurs Docker :

docker logs -f ai-agent

Surveillez le CPU et la mémoire en temps réel :

docker stats ai-agent

Quelles règles auditd définir pour les processus d'agents IA ?

Installez auditd :

sudo apt update && sudo apt install -y auditd

Créez des règles d'audit spécifiques à l'agent. Ajoutez dans /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

Remplacez uid=998 par l'UID réel de votre utilisateur agent. Trouvez-le avec :

id -u agent-worker

Chargez les nouvelles règles :

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

Vérifiez que les règles sont actives :

sudo auditctl -l | grep agent

La sortie affiche vos quatre règles listées.

Recherchez les événements d'exécution de l'agent :

sudo ausearch -k agent-exec --start recent

Alertes automatisées

En production, mettez en place un watchdog simple qui alerte en cas d'utilisation élevée des ressources. Créez /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

Exécutez-le chaque minute via cron ou un timer systemd. Les alertes apparaissent dans syslog, que vous pouvez rediriger vers votre pile de monitoring.

Comment mettre à jour le logiciel d'un agent IA en toute sécurité ?

Menace : Un logiciel d'agent non patché contient des vulnérabilités connues. Mais une mise à jour en pleine session peut corrompre l'état ou casser des workflows en cours.

Pour les agents Docker, le processus de mise à jour est atomique :

# 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

Pour les agents non conteneurisés :

# 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

Astuce production : Exécutez deux instances d'agent derrière un répartiteur de charge. Mettez à jour une à la fois. Si l'instance mise à jour échoue aux vérifications de santé, revenez à la version précédente.

Maintenez le système hôte à jour séparément :

sudo apt update && sudo apt upgrade -y

Activez les mises à jour de sécurité automatiques :

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

Avant et après : ce que voit un attaquant

Sur un serveur non durci où l'agent tourne en root sans conteneur et sans pare-feu :

  • Accès complet au système de fichiers : lecture de /etc/shadow, clés SSH, données des autres utilisateurs
  • Sortie non restreinte : exfiltration de données vers n'importe quelle destination
  • Tous les appels système disponibles : montage de systèmes de fichiers, chargement de modules noyau, capture du trafic réseau
  • Ressources illimitées : crash du serveur avec un fork bomb ou une fuite mémoire
  • Accès persistant : installation d'une porte dérobée, ajout de clés SSH, création de nouveaux utilisateurs

Après avoir appliqué chaque contrôle de ce guide :

  • Confiné à /home/agent-worker sans accès aux fichiers système
  • HTTPS sortant restreint aux points de terminaison API autorisés uniquement
  • Environ 80 appels système disponibles (contre 300+), pas de mount/ptrace/reboot
  • Plafond strict de 2 Go de RAM et 1,5 cœur CPU, limite de 100 processus
  • Système de fichiers en lecture seule, aucune possibilité d'installer un logiciel ou de persister des modifications
  • Chaque commande journalisée par auditd avec piste d'audit interrogeable

L'agent fonctionne toujours. Il peut appeler les API LLM, traiter des entrées et retourner des sorties. Mais un agent compromis ne peut pas s'échapper de sa boîte.

Quelque chose ne fonctionne pas ?

Symptôme Cause probable Solution
Le conteneur s'arrête immédiatement Profil seccomp trop restrictif Lancez avec --security-opt seccomp=unconfined temporairement, vérifiez dmesg pour les appels système bloqués, ajoutez-les à votre profil
L'agent ne peut pas atteindre l'API Pare-feu en sortie bloquant le trafic Vérifiez sudo ufw status, confirmez que l'IP de destination est autorisée
L'agent est tué par le OOM killer Limite mémoire trop basse Augmentez MemoryMax ou --memory, vérifiez l'utilisation réelle avec docker stats
auditd ne journalise pas Règles non chargées ou mauvais UID Lancez sudo auditctl -l pour vérifier, contrôlez que l'UID correspond à l'utilisateur agent
Erreurs 429 depuis Nginx Limite de débit trop stricte Augmentez la valeur burst, vérifiez si des pics de trafic légitime sont attendus
L'agent ne peut pas écrire de fichiers temp --read-only sans --tmpfs Ajoutez --tmpfs /tmp:size=100M à votre commande Docker run

Vérifiez les journaux de l'agent en premier :

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

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

Vérifiez les journaux d'audit pour les actions bloquées :

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

FAQ

Puis-je exécuter des agents IA en tant que root en toute sécurité ?

Non. Exécuter des agents en root signifie que toute injection de prompt donne à l'attaquant le contrôle total du système. Il n'existe aucun contrôle compensatoire qui rende acceptable l'exécution en root. Utilisez toujours un utilisateur non-root dédié.

Ai-je besoin de Docker pour sécuriser un agent IA ?

Non. L'isolation utilisateur Linux, les directives de sécurité systemd (ProtectSystem, NoNewPrivileges, PrivateTmp) et les limites cgroup fournissent une isolation solide sans Docker. Docker ajoute une frontière de conteneur, ce qui constitue une défense en profondeur précieuse. Utilisez-le si vous le pouvez, mais l'isolation utilisateur seule arrête la plupart des attaques de type injection-de-prompt-vers-shell-root.

Combien de CPU dois-je allouer à un agent IA ?

Commencez avec 1 à 2 cœurs CPU (CPUQuota=150% dans systemd ou --cpus 1.5 dans Docker) et 2 Go de RAM sur un VPS de 8 Go. Surveillez l'utilisation réelle avec docker stats ou systemctl status pendant une semaine, puis ajustez. Les agents fonctionnent par rafales : ils sont inactifs entre les requêtes et montent en charge pendant le raisonnement. Les limites empêchent les pics d'affecter les autres services.

Comment sécuriser plusieurs agents sur le même serveur ?

Créez un utilisateur Linux et un conteneur distincts pour chaque agent. Chacun reçoit ses propres limites cgroup, règles de sortie et piste d'audit. Utilisez les réseaux Docker pour isoler le trafic inter-agents. Ne partagez jamais les secrets entre agents.

Copyright 2026 Virtua.Cloud. Tous droits réservés. Ce contenu est une création originale de l'équipe Virtua.Cloud. Toute reproduction, republication ou redistribution sans autorisation écrite est interdite.

Prêt à essayer ?

Exécutez des agents IA en toute sécurité sur votre VPS.

Voir les offres VPS