Je AI-agentserver beveiligen: sandboxing, firewall en monitoring

12 min leestijd·Matthieu·monitoringlinuxfirewalldockersecurityai-agents|

AI-agenten voeren willekeurige acties uit, verbruiken onvoorspelbare resources en verwerken onbetrouwbare invoer. Deze gids koppelt elke bedreiging aan een concrete Linux-maatregel met geteste commando's.

AI-agenten zijn geen gewone diensten. Een webserver verwerkt voorspelbare HTTP-verzoeken. Een AI-agent voert willekeurige tool-calls uit, start subprocessen, doet uitgaande API-verzoeken en verbruikt resources in onvoorspelbare pieken. Als een prompt injection slaagt, wordt de agent een aanvaller met alle rechten die je hem hebt gegeven.

Deze gids behandelt elke AI-agent als onvertrouwde code. Elke sectie begint met een specifieke bedreiging en koppelt die aan een Linux-maatregel die je kunt verifiëren. De commando's werken op elke VPS met Debian 12 of Ubuntu 22.04+, met elk agentframework: OpenClaw, Claude Code, n8n, LangChain, CrewAI of eigen setups.

Vereisten: Een VPS met root-toegang, basiskennis van Linux en SSH (VPS-beveiligingsbasis behandelt de baseline), en ten minste één AI-agent die je wilt vergrendelen. Deze gids gaat ervan uit dat je de eerste serverbeveiliging al hebt afgerond (SSH-beveiliging).

Waarom zijn AI-agenten een ander beveiligingsrisico?

Traditionele diensten hebben een begrensd gedragspatroon. Een Nginx-proces serveert bestanden en proxyt verzoeken. Het gedrag van een AI-agent hangt af van de invoer, en die beheer jij niet. Drie eigenschappen maken agenten anders dan alles wat je verder op een server draait:

  1. Ze voeren willekeurige acties uit. Tool-calling agents voeren shellcommando's uit, schrijven bestanden en doen HTTP-verzoeken op basis van LLM-output.
  2. Ze verbruiken onvoorspelbare resources. Een reasoning-loop kan de CPU minutenlang op 100% jagen. Een op hol geslagen agent verbrandt API-tokens in seconden.
  3. Ze verwerken onbetrouwbare invoer by design. Het hele doel van een agent is natuurlijke taal accepteren en erop handelen.
Bedreiging Aanvalsvector Impact Maatregel
Shellcommando-uitvoering Prompt injection via gebruikersinvoer of tool-output Volledige systeemovername Gebruikersisolatie, container-sandbox
Data-exfiltratie Agent stuurt secrets via HTTP/DNS naar aanvallersdomein Diefstal van credentials, datalek Uitgaande firewall, DNS-filtering
Resource-uitputting Oneindige reasoning-loop of recursieve tool-calls Servercrash, andere diensten plat cgroup CPU/geheugenlimieten
Credential-lekkage Agent logt of onthoudt API-keys uit environment API-key-diefstal, laterale beweging Secrets-injectie, env-isolatie
Laterale beweging Gecompromitteerde agent draait naar andere diensten Volledige infrastructuurovername Netwerksegmentatie, least privilege

Hoe isoleer ik een AI-agent met een eigen Linux-gebruiker?

Maak per agent een systeemgebruiker aan zonder loginshell, zonder sudo-toegang en met een beperkte homedirectory. Dit is de eenvoudigste maatregel met de grootste impact. Als een agent gecompromitteerd wordt, erft de aanvaller alleen de rechten van die gebruiker, niet root.

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

Vergrendel de homedirectory zodat andere gebruikers de bestanden van de agent niet kunnen lezen:

sudo chmod 750 /home/agent-worker

Controleer of de gebruiker bestaat en de juiste shell heeft:

getent passwd agent-worker

De output ziet er als volgt uit:

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

de shell is /usr/sbin/nologin. Dit betekent dat niemand als deze gebruiker kan inloggen via SSH of een interactieve sessie kan openen. Het agentproces draait als deze gebruiker via systemd, niet via login.

Als je agent tijdelijke bestanden moet schrijven, maak dan een aparte directory aan:

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

Controleer de rechten:

ls -la /home/agent-worker/

Wat dit doet: Zelfs als een aanvaller code-uitvoering bereikt via prompt injection, is hij beperkt tot /home/agent-worker zonder de mogelijkheid om bestanden van andere gebruikers te lezen, rechten te verhogen naar root of systeembinaries te wijzigen.

Hoe sandbox ik een AI-agent in een Docker-container?

Een agent in een Docker-container draaien voegt een tweede isolatielaag toe. De container heeft een eigen bestandssysteem, procesnamespace en netwerkstack. In combinatie met beveiligingsvlaggen beperkt het wat een gecompromitteerde agent kan doen, zelfs met code-uitvoering.

Welke Docker-beveiligingsvlaggen moet ik gebruiken voor AI-agenten?

Gebruik elke beperking die je agent aankan. Begin vergrendeld en versoepel alleen wat stukloopt. Hier is een productie-docker run-commando voor een AI-agent:

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

Wat elke vlag doet:

Vlag Doel Waarom dit belangrijk is voor agenten
--user 1000:1000 Draai als non-root in de container Voorkomt container-breakout via root-exploits
--read-only Root-bestandssysteem is alleen-lezen Blokkeert malware-installatie, config-manipulatie
--tmpfs /tmp:size=100M,noexec,nosuid Beschrijfbare temp zonder uitvoering Agent kan tijdelijke bestanden schrijven maar geen binaries uitvoeren vanuit /tmp
--cap-drop ALL Verwijder alle Linux-capabilities Geen CAP_NET_RAW (pakketsniffing), geen CAP_SYS_ADMIN (mount), niets
--security-opt no-new-privileges:true Voorkom privilege-escalatie via setuid Blokkeert een gecompromitteerde agent die root verkrijgt via setuid-binaries
--pids-limit 100 Maximaal aantal processen Stopt fork bombs van een op hol geslagen agent
--memory 2g / --memory-swap 2g Harde geheugengrens, geen swap Voorkomt OOM-killing van andere diensten
--cpus 1.5 CPU-limiet Agent kan andere diensten niet uithongeren

Controleer of de container draait met de juiste beveiligingsinstellingen:

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

Verwachte output:

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

Controleer of het als non-root draait:

docker exec ai-agent whoami

Dit zou de non-root-gebruiker moeten teruggeven, niet root.

Aangepast seccomp-profiel voor AI-agenten

Het standaard Docker seccomp-profiel blokkeert ongeveer 44 gevaarlijke syscalls. Voor AI-agenten kun je dit verder aanscherpen. Maak /etc/docker/seccomp-agent.json aan:

{
  "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"
    }
  ]
}

Dit profiel staat alleen de syscalls toe die nodig zijn voor een typisch Python/Node.js-agentproces. Al het andere, waaronder mount, ptrace, reboot, kexec_load en init_module, geeft een permission error.

Stel de juiste rechten in op het profiel:

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

Test of de container start met het aangepaste profiel:

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

Als je seccomp works ziet, is het profiel geldig.

Voor uitgebreidere Docker-beveiliging inclusief rootless mode, zie Docker security hardening. Voor het Docker/UFW-interactieprobleem, zie Docker UFW fix.

Hoe blokkeer ik internettoegang voor een AI-agent?

Bedreiging: Een gecompromitteerde agent exfiltreert secrets via uitgaande HTTP-verzoeken naar een server van de aanvaller, of codeert data in DNS-query's. Standaard laat UFW al het uitgaande verkeer door.

Stel een default-deny beleid in voor uitgaand verkeer en whitelist alleen de endpoints die je agent nodig heeft:

sudo ufw default deny outgoing
sudo ufw default deny incoming

Sta noodzakelijk uitgaand verkeer toe:

# 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

Sta inkomend SSH toe (zodat je jezelf niet buitensluit):

sudo ufw allow in 22/tcp

Schakel de firewall in:

sudo ufw enable

Controleer de regels:

sudo ufw status verbose

De output toont Default: deny (incoming), deny (outgoing) bovenaan moeten zien, gevolgd door je allow-regels.

Hoe whitelist ik alleen de API-endpoints die mijn agent nodig heeft?

De regels hierboven staan nog steeds uitgaand HTTPS naar elke bestemming toe. Voor striktere controle beperk je uitgaand verkeer tot specifieke IP-ranges. Dit vereist iptables omdat UFW geen bestemmingsfiltering op domeinnaam ondersteunt.

Los eerst het API-endpoint van je AI-provider op:

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

Maak vervolgens iptables-regels voor die IP's. Maak /etc/iptables/agent-egress.rules aan:

#!/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

Controleer of de agentgebruiker geen willekeurige hosts kan bereiken:

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

De verwachte output is OK: egress blocked.

Opmerking over DNS-exfiltratie: De regels hierboven staan DNS op poort 53 toe. Een geavanceerde aanvaller kan data coderen in DNS-query's door secrets als subdomeinen te versturen (bijv. sk-ant-api-key.attacker.com). Om dit gat te dichten, verwijs je de DNS van de agent naar een lokale resolver zoals unbound, geconfigureerd met een response policy zone (RPZ) die query's naar niet-gewhiteliste domeinen blokkeert.

Installeer en configureer een lokale resolver:

sudo apt install -y unbound

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

Configureer vervolgens de container of systemd-service van je agent om 127.0.0.1 als DNS-resolver te gebruiken in plaats van de systeemstandaard. Voeg in Docker --dns 127.0.0.1 toe aan je docker run-commando.

Hoe beperk ik de rate van AI-agent API-endpoints?

Bedreiging: Een blootgesteld agent-API-endpoint wordt bestookt door bots of misbruikt via geautomatiseerde prompt-injection-pogingen. Zonder rate limiting triggert elk verzoek dure LLM-API-aanroepen.

Als je je agent via Nginx beschikbaar stelt, voeg dan rate limiting toe op de reverse-proxylaag. Voeg toe aan je Nginx-configuratie:

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;
        }
    }
}

Test de configuratie:

sudo nginx -t && sudo systemctl reload nginx

Controleer of rate limiting actief is door snel achter elkaar verzoeken te sturen:

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

De output toont 200-responses moeten zien gevolgd door 429-responses zodra de limiet bereikt is.

Hoe beperk ik CPU- en geheugengebruik van een AI-agent?

Bedreiging: Een reasoning-loop of recursieve tool-call jaagt de CPU minutenlang naar 100%. Zonder limieten hongert de agent SSH, monitoring en andere diensten uit. Op een gedeelde VPS kan dit provider-throttling of automatische schorsing veroorzaken.

Docker-resourcelimieten

Als je agent in Docker draait, regelen de --memory- en --cpus-vlaggen uit de containersectie hierboven dit. Controleer of de limieten worden afgedwongen:

docker stats ai-agent --no-stream

Controleer of MEM USAGE onder MEM LIMIT blijft en CPU % onder je toegewezen cores.

Systemd cgroup-limieten voor niet-gecontaineriseerde agenten

Als je agent direct op de host draait (niet in Docker), gebruik dan systemd om cgroup v2-limieten af te dwingen. Maak een systemd-service met resource-controls:

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 is een harde bovengrens. De OOM killer beëindigt de agent als hij dit overschrijdt. MemoryHigh=1536M is een zachte limiet: de kernel reclaimt agressief geheugen boven deze drempel, waardoor de agent vertraagt voordat hij de harde limiet raakt. CPUQuota=150% staat 1,5 CPU-cores toe. TasksMax=100 voorkomt fork bombs.

Schakel de service in en start hem:

sudo systemctl enable --now ai-agent.service

enable zorgt dat hij reboots overleeft. --now start hem direct.

Controleer of de service draait en de limieten zijn toegepast:

sudo systemctl status ai-agent.service

Controleer de cgroup-limieten:

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

Verwachte output:

MemoryMax=2147483648
CPUQuota=150%
TasksMax=100

Hoe beheer ik secrets voor AI-agenten zonder ze te lekken?

Bedreiging: Een agent logt zijn environment-variabelen (veel frameworks doen dit in debug-modus), neemt API-keys op in LLM-context, of schrijft credentials naar een tijdelijk bestand. Een aanvaller met leestoegang tot het geheugen of de logs van de agent krijgt elk secret te pakken.

Zet secrets nooit in het configuratiebestand van de agent, de Dockerfile of command-line-argumenten. Gebruik een environment-bestand met beperkte rechten.

Maak het secrets-bestand aan:

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

Voeg je secrets toe:

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

Genereer sterke wachtwoorden in plaats van ze zelf te verzinnen:

openssl rand -base64 32

De systemd-service verwijst naar dit bestand met EnvironmentFile=/etc/agent/env. Het agentproces ontvangt de variabelen maar kan het bestand zelf niet lezen (eigendom van root, mode 600). Systemd leest het bestand en geeft de variabelen door aan het proces.

Controleer de bestandsrechten:

ls -la /etc/agent/env

Verwacht: -rw------- 1 root root. Alleen root kan het lezen.

Rotatie: Wanneer je een secret roteert, werk /etc/agent/env bij en herstart de service:

sudo systemctl restart ai-agent.service

De agent pikt de nieuwe waarden op zonder wijzigingen in configuratiebestanden.

Hoe monitor ik AI-agentactiviteit op een Linux-server?

Bedreiging: Een gecompromitteerde of defecte agent draait stil door. Zonder monitoring ontdek je het probleem pas wanneer je API-factuur binnenkomt of je server wordt gemarkeerd voor misbruik.

Realtime resource-monitoring

Bekijk resourcegebruik live:

journalctl -u ai-agent.service -f

Dit streamt de stdout/stderr van de agent in realtime. Druk op Ctrl+C om te stoppen.

Voor Docker-containers:

docker logs -f ai-agent

Monitor CPU en geheugen in realtime:

docker stats ai-agent

Welke auditd-regels moet ik instellen voor AI-agentprocessen?

Installeer auditd:

sudo apt update && sudo apt install -y auditd

Maak agentspecifieke auditregels aan. Voeg toe aan /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

Vervang uid=998 door de werkelijke UID van je agentgebruiker. Vind deze met:

id -u agent-worker

Laad de nieuwe regels:

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

Controleer of de regels actief zijn:

sudo auditctl -l | grep agent

De output toont je vier regels moeten zien.

Zoek naar agent-uitvoeringsgebeurtenissen:

sudo ausearch -k agent-exec --start recent

Geautomatiseerde waarschuwingen

Stel voor productie een eenvoudige watchdog in die waarschuwt bij hoog resourcegebruik. Maak /usr/local/bin/agent-watchdog.sh aan:

#!/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

Draai het elke minuut via cron of een systemd-timer. De waarschuwingen verschijnen in syslog, dat je kunt doorsturen naar je monitoringstack.

Hoe houd ik AI-agentsoftware veilig bijgewerkt?

Bedreiging: Niet-gepatchte agentsoftware bevat bekende kwetsbaarheden. Maar updaten midden in een sessie kan de status beschadigen of draaiende workflows breken.

Voor Docker-gebaseerde agenten is het updateproces atomair:

# 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

Voor niet-gecontaineriseerde agenten:

# 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

Productietip: Draai twee agent-instanties achter een load balancer. Werk er één tegelijk bij. Als de bijgewerkte instantie de health checks niet haalt, val terug naar de vorige versie.

Houd het host-OS apart gepatcht:

sudo apt update && sudo apt upgrade -y

Schakel automatische beveiligingsupdates in:

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

Voor en na: wat een aanvaller ziet

Op een ongeharde server waar de agent als root draait zonder container en zonder firewall:

  • Volledige bestandssysteemtoegang: /etc/shadow, SSH-keys, data van andere gebruikers lezen
  • Onbeperkt uitgaand verkeer: data exfiltreren naar elke bestemming
  • Alle syscalls beschikbaar: bestandssystemen mounten, kernelmodules laden, netwerkverkeer sniffen
  • Onbeperkte resources: de server crashen met een fork bomb of geheugenlek
  • Persistente toegang: een backdoor installeren, SSH-keys toevoegen, nieuwe gebruikers aanmaken

Na het toepassen van elke maatregel in deze gids:

  • Beperkt tot /home/agent-worker zonder toegang tot systeembestanden
  • Uitgaand HTTPS beperkt tot alleen gewhiteliste API-endpoints
  • Ongeveer 80 syscalls beschikbaar (van 300+), geen mount/ptrace/reboot
  • Harde bovengrens van 2 GB RAM en 1,5 CPU-cores, limiet van 100 processen
  • Alleen-lezen bestandssysteem, geen mogelijkheid om software te installeren of wijzigingen te persisteren
  • Elk commando gelogd door auditd met doorzoekbare audit trail

De agent werkt nog steeds. Hij kan LLM-API's aanroepen, invoer verwerken en output teruggeven. Maar een gecompromitteerde agent kan niet uit zijn box ontsnappen.

Gaat er iets mis?

Symptoom Waarschijnlijke oorzaak Oplossing
Container stopt direct Seccomp-profiel te beperkend Draai tijdelijk met --security-opt seccomp=unconfined, controleer dmesg voor geblokkeerde syscalls, voeg ze toe aan je profiel
Agent kan API niet bereiken Uitgaande firewall blokkeert verkeer Controleer sudo ufw status, verifieer dat het bestemmings-IP is toegestaan
Agent gedood door OOM Geheugenlimiet te laag Verhoog MemoryMax of --memory, controleer het werkelijke piekgebruik van de agent met docker stats
auditd logt niet Regels niet geladen of verkeerde UID Draai sudo auditctl -l om te verifiëren, controleer of de UID overeenkomt met de agentgebruiker
429-fouten van Nginx Rate limit te streng Verhoog de burst-waarde, controleer of legitieme verkeerspieken verwacht worden
Agent kan geen tijdelijke bestanden schrijven --read-only zonder --tmpfs Voeg --tmpfs /tmp:size=100M toe aan je Docker run-commando

Controleer eerst de agentlogs:

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

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

Controleer auditlogs voor geblokkeerde acties:

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

FAQ

Kan ik AI-agenten veilig als root draaien?

Nee. Agenten als root draaien betekent dat elke prompt injection de aanvaller volledige systeemcontrole geeft. Er is geen compenserende maatregel die draaien als root acceptabel maakt. Gebruik altijd een aparte non-root-gebruiker.

Heb ik Docker nodig om een AI-agent te beveiligen?

Nee. Linux-gebruikersisolatie, systemd-beveiligingsrichtlijnen (ProtectSystem, NoNewPrivileges, PrivateTmp) en cgroup-limieten bieden sterke isolatie zonder Docker. Docker voegt een containergrens toe, wat waardevolle defense in depth is. Gebruik het als je kunt, maar gebruikersisolatie alleen stopt de meeste prompt-injection-naar-root-shell-aanvallen al.

Hoeveel CPU moet ik toewijzen aan een AI-agent?

Begin met 1-2 CPU-cores (CPUQuota=150% in systemd of --cpus 1.5 in Docker) en 2 GB RAM op een 8 GB VPS. Monitor het werkelijke gebruik met docker stats of systemctl status gedurende een week en pas dan aan. Agenten zijn bursty: ze staan stil tussen verzoeken en pieken tijdens reasoning. De limieten voorkomen dat pieken andere diensten beïnvloeden.

Hoe beveilig ik meerdere agenten op dezelfde server?

Maak per agent een aparte Linux-gebruiker en container aan. Elk krijgt eigen cgroup-limieten, egress-regels en audit trail. Gebruik Docker-netwerken om inter-agentverkeer te isoleren. Deel nooit secrets tussen agenten.

Copyright 2026 Virtua.Cloud. Alle rechten voorbehouden. Deze inhoud is een origineel werk van het Virtua.Cloud-team. Reproductie, herpublicatie of herdistributie zonder schriftelijke toestemming is verboden.

Klaar om het zelf te proberen?

Draai AI-agents veilig op uw eigen VPS.

Bekijk VPS-aanbod