Proteggere il server per agenti IA: sandboxing, firewall e monitoraggio

13 min di lettura·Matthieu·monitoringlinuxfirewalldockersecurityai-agents|

Gli agenti IA eseguono azioni arbitrarie, consumano risorse imprevedibili e elaborano input non affidabili. Questa guida associa ogni minaccia a un controllo Linux concreto con comandi testati.

Gli agenti IA non sono servizi normali. Un web server gestisce richieste HTTP prevedibili. Un agente IA esegue tool call arbitrarie, genera sottoprocessi, effettua richieste API in uscita e consuma risorse in picchi imprevedibili. Se un attacco di prompt injection riesce, l'agente diventa un attaccante con tutti i privilegi che gli hai assegnato.

Questa guida tratta ogni agente IA come codice non affidabile. Ogni sezione parte da una minaccia specifica e la associa a un controllo Linux verificabile. I comandi funzionano su qualsiasi VPS con Debian 12 o Ubuntu 22.04+, con qualsiasi framework: OpenClaw, Claude Code, n8n, LangChain, CrewAI o configurazioni personalizzate.

Prerequisiti: Un VPS con accesso root, conoscenze base di Linux e SSH (basi di sicurezza VPS copre il minimo necessario) e almeno un agente IA da proteggere. Questa guida presuppone che tu abbia già completato l'hardening iniziale del server (hardening SSH).

Perché gli agenti IA rappresentano una minaccia diversa?

I servizi tradizionali hanno un insieme limitato di comportamenti. Un processo Nginx serve file e inoltra richieste. Il comportamento di un agente IA dipende dal suo input, che tu non controlli. Tre proprietà rendono gli agenti diversi da qualsiasi altra cosa sul tuo server:

  1. Eseguono azioni arbitrarie. Gli agenti con tool-calling eseguono comandi shell, scrivono file e fanno richieste HTTP in base all'output dell'LLM.
  2. Consumano risorse imprevedibili. Un ciclo di ragionamento può portare la CPU al 100% per minuti. Un agente fuori controllo può bruciare token API in pochi secondi.
  3. Elaborano input non affidabili per progetto. Lo scopo stesso di un agente è accettare linguaggio naturale e agire di conseguenza.
Minaccia Vettore d'attacco Impatto Controllo
Esecuzione comandi shell Prompt injection tramite input utente o output del tool Compromissione totale del sistema Isolamento utente, sandbox container
Esfiltrazione dati L'agente invia segreti via HTTP/DNS a un dominio dell'attaccante Furto di credenziali, violazione dati Firewall in uscita, filtraggio DNS
Esaurimento risorse Ciclo di ragionamento infinito o tool call ricorsive Crash del server, altri servizi fuori uso Limiti cgroup su CPU/memoria
Esposizione credenziali L'agente registra nei log o memorizza chiavi API dall'ambiente Furto di chiavi API, movimento laterale Iniezione segreti, isolamento ambiente
Movimento laterale L'agente compromesso si sposta verso altri servizi Compromissione dell'intera infrastruttura Segmentazione di rete, principio del privilegio minimo

Come isolare un agente IA con un utente Linux dedicato?

Crea un utente di sistema dedicato per ogni agente, senza shell di login, senza accesso sudo e con una home directory ristretta. Questo è il controllo più semplice con il maggior impatto. Se un agente viene compromesso, l'attaccante eredita solo i permessi di quell'utente, non quelli di root.

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

Blocca la home directory in modo che gli altri utenti non possano leggere i file dell'agente:

sudo chmod 750 /home/agent-worker

Verifica che l'utente esista e abbia la shell corretta:

getent passwd agent-worker

L'output mostra un output simile a:

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

la shell è /usr/sbin/nologin. Questo significa che nessuno può accedere via SSH come questo utente o aprire una sessione interattiva. Il processo dell'agente viene eseguito come questo utente tramite systemd, non tramite login.

Se il tuo agente deve scrivere file temporanei, crea una directory dedicata:

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

Verifica i permessi:

ls -la /home/agent-worker/

Cosa fa: Anche se un attaccante ottiene l'esecuzione di codice tramite prompt injection, resta confinato in /home/agent-worker senza possibilità di leggere i file di altri utenti, scalare i privilegi a root o modificare i binari di sistema.

Come eseguire un agente IA in sandbox con Docker?

Eseguire l'agente in un container Docker aggiunge un secondo livello di isolamento. Il container ha il proprio filesystem, namespace dei processi e stack di rete. Combinato con i flag di sicurezza, limita ciò che un agente compromesso può fare, anche con esecuzione di codice.

Quali flag di sicurezza Docker usare per gli agenti IA?

Usa ogni restrizione che il tuo agente riesce a tollerare. Parti dalla configurazione più restrittiva e rilassa solo ciò che genera errori. Ecco un comando docker run di produzione per un agente 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

Cosa fa ogni flag:

Flag Scopo Perché è importante per gli agenti
--user 1000:1000 Esegue come non-root nel container Impedisce il container breakout tramite exploit root
--read-only Il filesystem root è in sola lettura Blocca installazione di malware, manomissione della configurazione
--tmpfs /tmp:size=100M,noexec,nosuid Temp scrivibile senza esecuzione L'agente può scrivere file temporanei ma non eseguire binari da /tmp
--cap-drop ALL Rimuove tutte le capability Linux Niente CAP_NET_RAW (sniffing pacchetti), niente CAP_SYS_ADMIN (mount), niente
--security-opt no-new-privileges:true Impedisce escalation dei privilegi via setuid Blocca un agente compromesso dal guadagnare root tramite binari setuid
--pids-limit 100 Tetto al numero di processi Ferma i fork bomb di un agente fuori controllo
--memory 2g / --memory-swap 2g Tetto fisso alla memoria, niente swap Impedisce all'OOM killer di terminare altri servizi
--cpus 1.5 Limite CPU L'agente non può privare di risorse gli altri servizi

Verifica che il container sia in esecuzione con le impostazioni di sicurezza corrette:

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

Output atteso:

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

Verifica che sia in esecuzione come non-root:

docker exec ai-agent whoami

Dovrebbe restituire l'utente non-root, non root.

Profilo seccomp personalizzato per agenti IA

Il profilo seccomp predefinito di Docker blocca circa 44 syscall pericolose. Per gli agenti IA, puoi restringere ulteriormente. Crea /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"
    }
  ]
}

Questo profilo consente solo le syscall necessarie per un tipico processo agente Python/Node.js. Tutto il resto, inclusi mount, ptrace, reboot, kexec_load e init_module, restituisce un errore di permesso.

Imposta i permessi corretti sul profilo:

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

Verifica che il container si avvii con il profilo personalizzato:

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

Se vedi seccomp works, il profilo è valido.

Per un hardening Docker più approfondito, incluso il rootless mode, consulta Docker security hardening. Per il problema di interazione Docker/UFW, consulta Docker UFW fix.

Come impedire a un agente IA di raggiungere internet?

Minaccia: Un agente compromesso esfiltra segreti effettuando richieste HTTP in uscita verso un server controllato dall'attaccante, o codifica dati nelle query DNS. UFW di default permette tutto il traffico in uscita.

Imposta una policy deny di default per il traffico in uscita, poi aggiungi in whitelist solo gli endpoint necessari al tuo agente:

sudo ufw default deny outgoing
sudo ufw default deny incoming

Consenti il traffico in uscita indispensabile:

# 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

Consenti SSH in ingresso (per non restare chiuso fuori):

sudo ufw allow in 22/tcp

Attiva il firewall:

sudo ufw enable

Verifica le regole:

sudo ufw status verbose

L'output mostra Default: deny (incoming), deny (outgoing) in cima, seguito dalle regole di allow.

Come autorizzare solo gli endpoint API necessari al mio agente?

Le regole sopra permettono ancora HTTPS in uscita verso qualsiasi destinazione. Per un controllo più stretto, limita il traffico in uscita a range IP specifici. Serve iptables perché UFW non supporta il filtraggio per dominio di destinazione.

Prima risolvi l'endpoint API del tuo provider IA:

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

Poi crea regole iptables per quegli IP. Crea /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

Verifica che l'utente agente non possa raggiungere host arbitrari:

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

L'output atteso è OK: egress blocked.

Nota sull'esfiltrazione DNS: Le regole sopra consentono DNS sulla porta 53. Un attaccante sofisticato può codificare dati nelle query DNS, inviando segreti come sottodomini (ad esempio sk-ant-api-key.attacker.com). Per chiudere questa falla, punta il DNS dell'agente a un resolver locale come unbound configurato con una response policy zone (RPZ) che blocca le query verso domini non in whitelist.

Installa e configura un resolver locale:

sudo apt install -y unbound

Modifica /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

Poi configura il container o il servizio systemd del tuo agente per usare 127.0.0.1 come resolver DNS al posto del default di sistema. In Docker, aggiungi --dns 127.0.0.1 al comando docker run.

Come applicare rate limiting agli endpoint API degli agenti IA?

Minaccia: Un endpoint API dell'agente esposto viene bombardato da bot o sfruttato con tentativi automatizzati di prompt injection. Senza rate limiting, ogni richiesta attiva costose chiamate API all'LLM.

Se esponi il tuo agente tramite Nginx, aggiungi il rate limiting a livello di reverse proxy. Aggiungi alla configurazione 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;
        }
    }
}

Testa la configurazione:

sudo nginx -t && sudo systemctl reload nginx

Verifica che il rate limiting sia attivo inviando richieste rapide:

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

L'output mostra risposte 200 seguite da risposte 429 una volta raggiunto il limite.

Come limitare CPU e memoria per un agente IA?

Minaccia: Un ciclo di ragionamento o una tool call ricorsiva porta la CPU al 100% per minuti. Senza limiti, l'agente affama SSH, il monitoraggio e gli altri servizi. Su un VPS condiviso, questo può attivare il throttling del provider o la sospensione automatica.

Limiti risorse Docker

Se il tuo agente gira in Docker, i flag --memory e --cpus dalla sezione container gestiscono questo aspetto. Verifica che i limiti siano applicati:

docker stats ai-agent --no-stream

Controlla che MEM USAGE resti sotto MEM LIMIT e che CPU % resti sotto i core allocati.

Limiti cgroup con systemd per agenti senza container

Se il tuo agente gira direttamente sull'host (non in Docker), usa systemd per applicare limiti cgroup v2. Crea un servizio systemd con controlli sulle risorse:

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 è un tetto fisso. L'OOM killer termina l'agente se supera questo valore. MemoryHigh=1536M è un limite soft. Il kernel recupera aggressivamente memoria sopra questa soglia, rallentando l'agente prima che raggiunga il tetto fisso. CPUQuota=150% consente 1,5 core CPU. TasksMax=100 previene i fork bomb.

Attiva e avvia il servizio:

sudo systemctl enable --now ai-agent.service

enable lo rende persistente ai riavvii. --now lo avvia subito.

Verifica che il servizio sia in esecuzione e i limiti siano applicati:

sudo systemctl status ai-agent.service

Controlla i limiti cgroup:

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

Output atteso:

MemoryMax=2147483648
CPUQuota=150%
TasksMax=100

Come gestire i segreti degli agenti IA senza esporli?

Minaccia: Un agente registra nei log le variabili d'ambiente (molti framework lo fanno in modalità debug), include chiavi API nel contesto dell'LLM o scrive credenziali in un file temporaneo. Un attaccante con accesso in lettura alla memoria o ai log dell'agente ottiene ogni segreto.

Non inserire mai segreti nel file di configurazione dell'agente, nel Dockerfile o negli argomenti della riga di comando. Usa un file di ambiente con permessi restrittivi.

Crea il file dei segreti:

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

Aggiungi i tuoi segreti:

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

Genera password forti invece di inventarle:

openssl rand -base64 32

Il servizio systemd referenzia questo file con EnvironmentFile=/etc/agent/env. Il processo dell'agente riceve le variabili ma non può leggere il file stesso (proprietario root, permessi 600). Systemd legge il file e passa le variabili al processo.

Verifica i permessi del file:

ls -la /etc/agent/env

Atteso: -rw------- 1 root root. Solo root può leggerlo.

Rotazione: Quando ruoti un segreto, aggiorna /etc/agent/env e riavvia il servizio:

sudo systemctl restart ai-agent.service

L'agente acquisisce i nuovi valori senza modifiche ai file di configurazione.

Come monitorare l'attività degli agenti IA su un server Linux?

Minaccia: Un agente compromesso o malfunzionante opera silenziosamente. Senza monitoraggio, scopri il problema quando arriva la fattura delle API o il server viene segnalato per abuso.

Monitoraggio risorse in tempo reale

Osserva l'uso delle risorse in tempo reale:

journalctl -u ai-agent.service -f

Questo trasmette lo stdout/stderr dell'agente in tempo reale. Premi Ctrl+C per fermare.

Per i container Docker:

docker logs -f ai-agent

Monitora CPU e memoria in tempo reale:

docker stats ai-agent

Quali regole auditd impostare per i processi degli agenti IA?

Installa auditd:

sudo apt update && sudo apt install -y auditd

Crea regole di audit specifiche per l'agente. Aggiungi a /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

Sostituisci uid=998 con l'UID effettivo del tuo utente agente. Trovalo con:

id -u agent-worker

Carica le nuove regole:

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

Verifica che le regole siano attive:

sudo auditctl -l | grep agent

L'output mostra le quattro regole elencate.

Cerca eventi di esecuzione dell'agente:

sudo ausearch -k agent-exec --start recent

Alerting automatizzato

Per la produzione, configura un semplice watchdog che avvisa in caso di uso elevato delle risorse. Crea /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

Eseguilo ogni minuto tramite cron o un timer systemd. Gli alert compaiono nel syslog, che puoi inoltrare al tuo stack di monitoraggio.

Come aggiornare il software degli agenti IA in sicurezza?

Minaccia: Software non aggiornato contiene vulnerabilità note. Ma aggiornare durante una sessione attiva può corrompere lo stato o interrompere workflow in esecuzione.

Per gli agenti basati su Docker, il processo di aggiornamento è atomico:

# 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

Per gli agenti senza container:

# 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

Suggerimento per la produzione: Esegui due istanze dell'agente dietro un load balancer. Aggiorna una alla volta. Se l'istanza aggiornata non passa gli health check, torna alla versione precedente.

Mantieni aggiornato separatamente il sistema operativo dell'host:

sudo apt update && sudo apt upgrade -y

Abilita gli aggiornamenti automatici di sicurezza:

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

Prima e dopo: cosa vede un attaccante

Su un server non protetto dove l'agente gira come root senza container e senza firewall:

  • Accesso completo al filesystem: lettura di /etc/shadow, chiavi SSH, dati di altri utenti
  • Uscita senza restrizioni: esfiltrazione dati verso qualsiasi destinazione
  • Tutte le syscall disponibili: montare filesystem, caricare moduli kernel, intercettare traffico di rete
  • Risorse illimitate: crash del server con un fork bomb o memory leak
  • Accesso persistente: installare una backdoor, aggiungere chiavi SSH, creare nuovi utenti

Dopo aver applicato ogni controllo di questa guida:

  • Confinato in /home/agent-worker senza accesso ai file di sistema
  • HTTPS in uscita limitato ai soli endpoint API in whitelist
  • ~80 syscall disponibili (da 300+), niente mount/ptrace/reboot
  • Tetto fisso di 2 GB RAM e 1,5 core CPU, limite di 100 processi
  • Filesystem in sola lettura, nessuna possibilità di installare software o persistere modifiche
  • Ogni comando registrato da auditd con audit trail consultabile

L'agente continua a funzionare. Può chiamare API LLM, elaborare input e restituire output. Ma un agente compromesso non può uscire dalla sua gabbia.

Qualcosa non funziona?

Sintomo Causa probabile Soluzione
Il container si chiude subito Profilo seccomp troppo restrittivo Avvia con --security-opt seccomp=unconfined temporaneamente, controlla dmesg per le syscall bloccate, aggiungile al profilo
L'agente non raggiunge l'API Firewall in uscita che blocca il traffico Controlla sudo ufw status, verifica che l'IP di destinazione sia autorizzato
L'agente viene terminato dall'OOM Limite di memoria troppo basso Aumenta MemoryMax o --memory, controlla il picco effettivo con docker stats
auditd non registra Regole non caricate o UID errato Esegui sudo auditctl -l per verificare, controlla che l'UID corrisponda all'utente agente
Errori 429 da Nginx Rate limit troppo stretto Aumenta il valore burst, verifica se sono previsti picchi di traffico legittimo
L'agente non può scrivere file temporanei --read-only senza --tmpfs Aggiungi --tmpfs /tmp:size=100M al comando Docker run

Controlla prima i log dell'agente:

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

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

Controlla i log di audit per le azioni bloccate:

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

FAQ

Posso eseguire agenti IA come root in sicurezza?

No. Eseguire agenti come root significa che qualsiasi prompt injection dà all'attaccante il controllo totale del sistema. Non esiste un controllo compensativo che renda accettabile l'esecuzione come root. Usa sempre un utente non-root dedicato.

Serve Docker per proteggere un agente IA?

No. L'isolamento utente Linux, le direttive di sicurezza systemd (ProtectSystem, NoNewPrivileges, PrivateTmp) e i limiti cgroup forniscono un forte isolamento senza Docker. Docker aggiunge un confine container, che è un valido livello di difesa in profondità (defense in depth). Usalo se puoi, ma il solo isolamento utente blocca la maggior parte degli attacchi prompt-injection-to-root-shell.

Quanta CPU devo allocare a un agente IA?

Parti con 1-2 core CPU (CPUQuota=150% in systemd o --cpus 1.5 in Docker) e 2 GB di RAM su un VPS da 8 GB. Monitora l'uso effettivo con docker stats o systemctl status per una settimana, poi regola. Gli agenti lavorano a picchi: restano inattivi tra le richieste e salgono durante il ragionamento. I limiti impediscono ai picchi di influenzare gli altri servizi.

Come proteggere più agenti sullo stesso server?

Crea un utente Linux e un container separati per ogni agente. Ciascuno riceve i propri limiti cgroup, regole di uscita e audit trail. Usa le reti Docker per isolare il traffico tra agenti. Non condividere mai i segreti tra agenti.

Copyright 2026 Virtua.Cloud. Tutti i diritti riservati. Questo contenuto è un'opera originale del team Virtua.Cloud. La riproduzione, ripubblicazione o redistribuzione senza autorizzazione scritta è vietata.

Pronto a provare?

Esegui agenti IA in sicurezza sul tuo VPS.

Vedi piani VPS