KI-Agent-Server absichern: Sandboxing, Firewall und Monitoring

12 Min. Lesezeit·Matthieu·monitoringlinuxfirewalldockersecurityai-agents|

KI-Agenten führen beliebige Aktionen aus, verbrauchen unvorhersehbare Ressourcen und verarbeiten nicht vertrauenswürdige Eingaben. Diese Anleitung ordnet jede Bedrohung einer konkreten Linux-Kontrolle mit getesteten Befehlen zu.

KI-Agenten sind keine gewöhnlichen Dienste. Ein Webserver verarbeitet vorhersehbare HTTP-Anfragen. Ein KI-Agent führt beliebige Tool-Aufrufe aus, startet Unterprozesse, sendet ausgehende API-Anfragen und verbraucht Ressourcen in unvorhersehbaren Spitzen. Gelingt eine Prompt Injection, wird der Agent zum Angreifer mit den Rechten, die Sie ihm gegeben haben.

Diese Anleitung behandelt jeden KI-Agenten als nicht vertrauenswürdigen Code. Jeder Abschnitt beginnt mit einer konkreten Bedrohung und ordnet ihr eine Linux-Kontrolle zu, die Sie überprüfen können. Die Befehle funktionieren auf jedem VPS mit Debian 12 oder Ubuntu 22.04+, mit jedem Agent-Framework: OpenClaw, Claude Code, n8n, LangChain, CrewAI oder eigenen Setups.

Voraussetzungen: Ein VPS mit Root-Zugang, grundlegende Linux- und SSH-Kenntnisse (VPS-Sicherheitsgrundlagen behandelt die Basis) und mindestens ein KI-Agent, den Sie absichern möchten. Diese Anleitung setzt voraus, dass Sie die initiale Serverhärtung bereits abgeschlossen haben (SSH-Härtung).

Was macht KI-Agenten zu einer besonderen Sicherheitsbedrohung?

Traditionelle Dienste haben einen begrenzten Satz an Verhaltensweisen. Ein Nginx-Prozess liefert Dateien aus und leitet Anfragen weiter. Das Verhalten eines KI-Agenten hängt von seiner Eingabe ab, die Sie nicht kontrollieren. Drei Eigenschaften unterscheiden Agenten von allem anderen auf Ihrem Server:

  1. Sie führen beliebige Aktionen aus. Agenten mit Tool-Calling führen Shell-Befehle aus, schreiben Dateien und senden HTTP-Anfragen auf Basis der LLM-Ausgabe.
  2. Sie verbrauchen unvorhersehbare Ressourcen. Eine Reasoning-Schleife kann die CPU minutenlang auf 100 % treiben. Ein außer Kontrolle geratener Agent kann API-Tokens in Sekunden verbrauchen.
  3. Sie verarbeiten nicht vertrauenswürdige Eingaben. Der gesamte Sinn eines Agenten ist es, natürliche Sprache entgegenzunehmen und darauf zu reagieren.
Bedrohung Angriffsvektor Auswirkung Kontrolle
Shell-Befehlsausführung Prompt Injection über Benutzereingabe oder Tool-Ausgabe Vollständige Systemkompromittierung Benutzerisolierung, Container-Sandbox
Datenexfiltration Agent sendet Secrets per HTTP/DNS an Angreifer-Domain Zugangsdaten-Diebstahl, Datenleck Egress-Firewall, DNS-Filterung
Ressourcenerschöpfung Endlose Reasoning-Schleife oder rekursive Tool-Aufrufe Serverabsturz, andere Dienste betroffen cgroup-CPU-/Speicherlimits
Zugangsdaten-Leak Agent loggt oder speichert API-Keys aus der Umgebung API-Key-Diebstahl, Lateral Movement Secrets-Injektion, Umgebungsisolierung
Lateral Movement Kompromittierter Agent greift auf andere Dienste über Vollständige Infrastrukturkompromittierung Netzwerksegmentierung, Least Privilege

Wie isoliere ich einen KI-Agenten mit einem dedizierten Linux-Benutzer?

Erstellen Sie für jeden Agenten einen dedizierten Systembenutzer ohne Login-Shell, ohne sudo-Zugang und mit eingeschränktem Home-Verzeichnis. Das ist die einfachste Kontrolle mit der größten Wirkung. Wird ein Agent kompromittiert, erbt der Angreifer nur die Berechtigungen dieses Benutzers, nicht Root.

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

Sperren Sie das Home-Verzeichnis, damit andere Benutzer die Dateien des Agenten nicht lesen können:

sudo chmod 750 /home/agent-worker

Überprüfen Sie, ob der Benutzer existiert und die korrekte Shell hat:

getent passwd agent-worker

Die Ausgabe sollte so aussehen:

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

Beachten Sie: Die Shell ist /usr/sbin/nologin. Das bedeutet, niemand kann sich per SSH als dieser Benutzer anmelden oder eine interaktive Sitzung öffnen. Der Agent-Prozess läuft als dieser Benutzer über systemd, nicht über Login.

Falls Ihr Agent temporäre Dateien schreiben muss, erstellen Sie ein dediziertes Verzeichnis:

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

Überprüfen Sie die Berechtigungen:

ls -la /home/agent-worker/

Was das bewirkt: Selbst wenn ein Angreifer durch Prompt Injection Code ausführen kann, ist er auf /home/agent-worker beschränkt, ohne Zugriff auf Dateien anderer Benutzer, ohne Root-Eskalation und ohne Zugriff auf Systembinaries.

Wie sandboxe ich einen KI-Agenten in einem Docker-Container?

Wenn Sie Ihren Agenten in einem Docker-Container ausführen, erhalten Sie eine zweite Isolierungsebene. Der Container hat ein eigenes Dateisystem, einen eigenen Prozess-Namespace und einen eigenen Netzwerk-Stack. In Kombination mit Sicherheitsflags begrenzt er, was ein kompromittierter Agent tun kann, selbst bei Code-Ausführung.

Welche Docker-Sicherheitsflags sollte ich für KI-Agenten verwenden?

Nutzen Sie jede Einschränkung, die Ihr Agent tolerieren kann. Beginnen Sie maximal eingeschränkt und lockern Sie nur das, was nicht funktioniert. Hier ist ein produktionsreifer docker run-Befehl für einen KI-Agenten:

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

Was jedes Flag bewirkt:

Flag Zweck Warum es für Agenten wichtig ist
--user 1000:1000 Als Nicht-Root im Container ausführen Verhindert Container-Breakout über Root-Exploits
--read-only Root-Dateisystem ist schreibgeschützt Blockiert Malware-Installation, Konfigurationsmanipulation
--tmpfs /tmp:size=100M,noexec,nosuid Beschreibbares Temp ohne Ausführungsrechte Agent kann temporäre Dateien schreiben, aber keine Binaries aus /tmp ausführen
--cap-drop ALL Alle Linux-Capabilities entfernen Kein CAP_NET_RAW (Paket-Sniffing), kein CAP_SYS_ADMIN (Mount), nichts
--security-opt no-new-privileges:true Privilege Escalation via setuid verhindern Blockiert Root-Erlangung durch setuid-Binaries bei kompromittiertem Agenten
--pids-limit 100 Prozessanzahl begrenzen Stoppt Fork-Bombs eines außer Kontrolle geratenen Agenten
--memory 2g / --memory-swap 2g Harte Speicherobergrenze, kein Swap Verhindert OOM-Killing anderer Dienste
--cpus 1.5 CPU-Limit Agent kann andere Dienste nicht aushungern

Überprüfen Sie, ob der Container mit den korrekten Sicherheitseinstellungen läuft:

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

Erwartete Ausgabe:

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

Prüfen Sie, ob er als Nicht-Root läuft:

docker exec ai-agent whoami

Dies sollte den Nicht-Root-Benutzer zurückgeben, nicht root.

Benutzerdefiniertes Seccomp-Profil für KI-Agenten

Das Standard-Docker-Seccomp-Profil blockiert etwa 44 gefährliche Syscalls. Für KI-Agenten können Sie dies weiter verschärfen. Erstellen Sie /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"
    }
  ]
}

Dieses Profil erlaubt nur die Syscalls, die ein typischer Python-/Node.js-Agent-Prozess benötigt. Alles andere, einschließlich mount, ptrace, reboot, kexec_load und init_module, gibt einen Berechtigungsfehler zurück.

Setzen Sie die richtigen Berechtigungen für das Profil:

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

Testen Sie, ob der Container mit dem benutzerdefinierten Profil startet:

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

Wenn Sie seccomp works sehen, ist das Profil gültig.

Für weitergehende Docker-Härtung einschließlich Rootless-Modus siehe Docker Security Hardening. Für das Docker/UFW-Interaktionsproblem siehe Docker UFW Fix.

Wie blockiere ich den Internetzugang eines KI-Agenten?

Bedrohung: Ein kompromittierter Agent exfiltriert Secrets durch ausgehende HTTP-Anfragen an einen vom Angreifer kontrollierten Server oder kodiert Daten in DNS-Anfragen. Standard-UFW erlaubt allen ausgehenden Verkehr.

Setzen Sie eine Default-Deny-Richtlinie für ausgehenden Verkehr und geben Sie nur die Endpunkte frei, die Ihr Agent benötigt:

sudo ufw default deny outgoing
sudo ufw default deny incoming

Erlauben Sie notwendigen ausgehenden Verkehr:

# 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

Erlauben Sie eingehenden SSH-Zugang (damit Sie sich nicht aussperren):

sudo ufw allow in 22/tcp

Aktivieren Sie die Firewall:

sudo ufw enable

Überprüfen Sie die Regeln:

sudo ufw status verbose

Die Ausgabe zeigt oben Default: deny (incoming), deny (outgoing) sehen, gefolgt von Ihren Erlaubnisregeln.

Wie beschränke ich den Zugang auf die API-Endpunkte, die mein Agent benötigt?

Die obigen Regeln erlauben weiterhin ausgehendes HTTPS zu jedem Ziel. Für strengere Kontrolle beschränken Sie den ausgehenden Verkehr auf bestimmte IP-Bereiche. Das erfordert iptables, da UFW keine Zielfilterung nach Domain unterstützt.

Lösen Sie zunächst den API-Endpunkt Ihres KI-Anbieters auf:

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

Erstellen Sie dann iptables-Regeln für diese IPs. Erstellen Sie /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

Überprüfen Sie, ob der Agent-Benutzer keine beliebigen Hosts erreichen kann:

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

Die erwartete Ausgabe ist OK: egress blocked.

Hinweis zur DNS-Exfiltration: Die obigen Regeln erlauben DNS auf Port 53. Ein erfahrener Angreifer kann Daten in DNS-Anfragen kodieren und Secrets als Subdomains senden (z. B. sk-ant-api-key.attacker.com). Um diese Lücke zu schließen, richten Sie den DNS des Agenten auf einen lokalen Resolver wie unbound ein, der mit einer Response Policy Zone (RPZ) konfiguriert ist und Anfragen an nicht freigegebene Domains blockiert.

Installieren und konfigurieren Sie einen lokalen Resolver:

sudo apt install -y unbound

Bearbeiten Sie /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

Konfigurieren Sie dann den Container oder systemd-Dienst Ihres Agenten so, dass er 127.0.0.1 als DNS-Resolver verwendet statt den Systemstandard. In Docker fügen Sie --dns 127.0.0.1 zu Ihrem docker run-Befehl hinzu.

Wie begrenze ich die Rate von KI-Agent-API-Endpunkten?

Bedrohung: Ein exponierter Agent-API-Endpunkt wird von Bots bombardiert oder durch automatisierte Prompt-Injection-Versuche missbraucht. Ohne Rate Limiting löst jede Anfrage teure LLM-API-Aufrufe aus.

Wenn Sie Ihren Agenten über Nginx exponieren, fügen Sie Rate Limiting auf der Reverse-Proxy-Ebene hinzu. Ergänzen Sie Ihre Nginx-Konfiguration:

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

Testen Sie die Konfiguration:

sudo nginx -t && sudo systemctl reload nginx

Überprüfen Sie, ob das Rate Limiting aktiv ist, indem Sie schnelle Anfragen senden:

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

Die Ausgabe zeigt 200-Antworten sehen, gefolgt von 429-Antworten, sobald das Limit erreicht ist.

Wie begrenze ich CPU- und Speicherverbrauch eines KI-Agenten?

Bedrohung: Eine Reasoning-Schleife oder ein rekursiver Tool-Aufruf treibt die CPU minutenlang auf 100 %. Ohne Limits hungert der Agent SSH, Monitoring und andere Dienste aus. Auf einem Shared VPS kann dies Provider-Throttling oder eine automatische Sperrung auslösen.

Docker-Ressourcenlimits

Wenn Ihr Agent in Docker läuft, übernehmen die Flags --memory und --cpus aus dem Container-Abschnitt oben diese Aufgabe. Überprüfen Sie, ob die Limits durchgesetzt werden:

docker stats ai-agent --no-stream

Prüfen Sie, dass MEM USAGE unter MEM LIMIT bleibt und CPU % unter Ihren zugewiesenen Kernen.

Systemd-cgroup-Limits für nicht containerisierte Agenten

Wenn Ihr Agent direkt auf dem Host läuft (nicht in Docker), verwenden Sie systemd zur Durchsetzung von cgroup-v2-Limits. Erstellen Sie einen systemd-Dienst mit Ressourcenkontrollen:

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 ist eine harte Obergrenze. Der OOM-Killer beendet den Agenten, wenn er diesen Wert überschreitet. MemoryHigh=1536M ist ein weiches Limit. Der Kernel fordert Speicher über diesem Schwellenwert aggressiv zurück und verlangsamt den Agenten, bevor er die harte Grenze erreicht. CPUQuota=150% erlaubt 1,5 CPU-Kerne. TasksMax=100 verhindert Fork-Bombs.

Aktivieren und starten Sie den Dienst:

sudo systemctl enable --now ai-agent.service

enable sorgt dafür, dass er Neustarts übersteht. --now startet ihn sofort.

Überprüfen Sie, ob der Dienst läuft und die Limits angewendet werden:

sudo systemctl status ai-agent.service

Prüfen Sie die cgroup-Limits:

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

Erwartete Ausgabe:

MemoryMax=2147483648
CPUQuota=150%
TasksMax=100

Wie verwalte ich Secrets für KI-Agenten ohne Leaks?

Bedrohung: Ein Agent loggt seine Umgebungsvariablen (viele Frameworks tun dies im Debug-Modus), nimmt API-Keys in den LLM-Kontext auf oder schreibt Zugangsdaten in eine temporäre Datei. Ein Angreifer mit Lesezugriff auf den Speicher oder die Logs des Agenten erhält jedes Secret.

Speichern Sie Secrets niemals in der Konfigurationsdatei des Agenten, im Dockerfile oder in Kommandozeilenargumenten. Verwenden Sie eine Environment-Datei mit eingeschränkten Berechtigungen.

Erstellen Sie die Secrets-Datei:

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

Fügen Sie Ihre Secrets hinzu:

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

Generieren Sie starke Passwörter statt sie zu erfinden:

openssl rand -base64 32

Der systemd-Dienst referenziert diese Datei mit EnvironmentFile=/etc/agent/env. Der Agent-Prozess empfängt die Variablen, kann die Datei selbst aber nicht lesen (gehört Root, Modus 600). Systemd liest die Datei und übergibt die Variablen an den Prozess.

Überprüfen Sie die Dateiberechtigungen:

ls -la /etc/agent/env

Erwartet: -rw------- 1 root root. Nur Root kann sie lesen.

Rotation: Wenn Sie ein Secret rotieren, aktualisieren Sie /etc/agent/env und starten den Dienst neu:

sudo systemctl restart ai-agent.service

Der Agent übernimmt die neuen Werte ohne Änderungen an Konfigurationsdateien.

Wie überwache ich KI-Agent-Aktivität auf einem Linux-Server?

Bedrohung: Ein kompromittierter oder fehlerhafter Agent läuft lautlos. Ohne Monitoring entdecken Sie das Problem erst, wenn die API-Rechnung kommt oder Ihr Server wegen Missbrauchs gemeldet wird.

Echtzeit-Ressourcenüberwachung

Beobachten Sie die Ressourcennutzung live:

journalctl -u ai-agent.service -f

Dies streamt stdout/stderr des Agenten in Echtzeit. Drücken Sie Ctrl+C zum Beenden.

Für Docker-Container:

docker logs -f ai-agent

Überwachen Sie CPU und Speicher in Echtzeit:

docker stats ai-agent

Welche auditd-Regeln sollte ich für KI-Agent-Prozesse setzen?

Installieren Sie auditd:

sudo apt update && sudo apt install -y auditd

Erstellen Sie agentspezifische Audit-Regeln. Fügen Sie diese in /etc/audit/rules.d/agent.rules ein:

# 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

Ersetzen Sie uid=998 durch die tatsächliche UID Ihres Agent-Benutzers. Ermitteln Sie sie mit:

id -u agent-worker

Laden Sie die neuen Regeln:

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

Überprüfen Sie, ob die Regeln aktiv sind:

sudo auditctl -l | grep agent

Die Ausgabe zeigt Ihre vier Regeln aufgelistet sehen.

Suchen Sie nach Agent-Ausführungsereignissen:

sudo ausearch -k agent-exec --start recent

Automatische Alarmierung

Richten Sie für den Produktionsbetrieb einen einfachen Watchdog ein, der bei hohem Ressourcenverbrauch alarmiert. Erstellen Sie /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

Führen Sie ihn jede Minute per Cron oder systemd-Timer aus. Die Alarme erscheinen im Syslog, das Sie an Ihren Monitoring-Stack weiterleiten können.

Wie halte ich KI-Agent-Software sicher aktuell?

Bedrohung: Ungepatchte Agent-Software enthält bekannte Schwachstellen. Aber ein Update während einer laufenden Sitzung kann den Zustand beschädigen oder laufende Workflows unterbrechen.

Für Docker-basierte Agenten ist der Update-Prozess atomar:

# 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

Für nicht containerisierte 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

Produktionstipp: Betreiben Sie zwei Agent-Instanzen hinter einem Load Balancer. Aktualisieren Sie eine nach der anderen. Wenn die aktualisierte Instanz die Health Checks nicht besteht, kehren Sie zur vorherigen Version zurück.

Halten Sie das Host-Betriebssystem separat gepatcht:

sudo apt update && sudo apt upgrade -y

Aktivieren Sie automatische Sicherheitsupdates:

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

Vorher und nachher: Was ein Angreifer sieht

Auf einem nicht gehärteten Server, auf dem der Agent als Root ohne Container und ohne Firewall läuft:

  • Voller Dateisystemzugriff: /etc/shadow, SSH-Keys, Daten anderer Benutzer lesen
  • Uneingeschränkter ausgehender Verkehr: Daten an jedes Ziel exfiltrieren
  • Alle Syscalls verfügbar: Dateisysteme mounten, Kernelmodule laden, Netzwerkverkehr mitlesen
  • Keine Ressourcenlimits: Server mit Fork-Bomb oder Memory-Leak zum Absturz bringen
  • Dauerhafter Zugang: Backdoor installieren, SSH-Keys hinzufügen, neue Benutzer anlegen

Nach Anwendung aller Kontrollen aus dieser Anleitung:

  • Eingesperrt in /home/agent-worker ohne Zugriff auf Systemdateien
  • Ausgehendes HTTPS nur zu freigegebenen API-Endpunkten
  • ~80 Syscalls verfügbar (statt 300+), kein mount/ptrace/reboot
  • Harte Obergrenze von 2 GB RAM und 1,5 CPU-Kernen, 100-Prozesse-Limit
  • Schreibgeschütztes Dateisystem, keine Möglichkeit Software zu installieren oder Änderungen zu persistieren
  • Jeder Befehl wird von auditd mit durchsuchbarem Audit-Trail protokolliert

Der Agent funktioniert weiterhin. Er kann LLM-APIs aufrufen, Eingaben verarbeiten und Ausgaben zurückgeben. Aber ein kompromittierter Agent kann seine Box nicht verlassen.

Etwas hat nicht funktioniert?

Symptom Wahrscheinliche Ursache Lösung
Container beendet sich sofort Seccomp-Profil zu restriktiv Temporär mit --security-opt seccomp=unconfined starten, dmesg auf blockierte Syscalls prüfen, diese zum Profil hinzufügen
Agent kann API nicht erreichen Egress-Firewall blockiert ausgehenden Verkehr sudo ufw status prüfen, Ziel-IP verifizieren
Agent wird durch OOM gekillt Speicherlimit zu niedrig MemoryMax oder --memory erhöhen, tatsächlichen Spitzenverbrauch mit docker stats prüfen
auditd protokolliert nicht Regeln nicht geladen oder falsche UID sudo auditctl -l zur Überprüfung ausführen, UID des Agent-Benutzers prüfen
429-Fehler von Nginx Rate Limit zu streng burst-Wert erhöhen, prüfen ob legitime Verkehrsspitzen erwartet werden
Agent kann keine temporären Dateien schreiben --read-only ohne --tmpfs --tmpfs /tmp:size=100M zum Docker-Run-Befehl hinzufügen

Prüfen Sie zuerst die Agent-Logs:

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

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

Prüfen Sie die Audit-Logs auf blockierte Aktionen:

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

FAQ

Kann ich KI-Agenten sicher als Root ausführen?

Nein. Agenten als Root auszuführen bedeutet, dass jede Prompt Injection dem Angreifer volle Systemkontrolle gibt. Es gibt keine kompensierende Kontrolle, die das Ausführen als Root akzeptabel macht. Verwenden Sie immer einen dedizierten Nicht-Root-Benutzer.

Brauche ich Docker, um einen KI-Agenten abzusichern?

Nein. Linux-Benutzerisolierung, systemd-Sicherheitsdirektiven (ProtectSystem, NoNewPrivileges, PrivateTmp) und cgroup-Limits bieten starke Isolierung ohne Docker. Docker fügt eine Container-Grenze hinzu, die als Defense in Depth wertvoll ist. Nutzen Sie es, wenn möglich, aber Benutzerisolierung allein stoppt die meisten Prompt-Injection-zu-Root-Shell-Angriffe.

Wie viel CPU sollte ich einem KI-Agenten zuweisen?

Beginnen Sie mit 1-2 CPU-Kernen (CPUQuota=150% in systemd oder --cpus 1.5 in Docker) und 2 GB RAM auf einem 8-GB-VPS. Überwachen Sie den tatsächlichen Verbrauch eine Woche lang mit docker stats oder systemctl status und passen Sie dann an. Agenten sind sprunghaft: Sie idlen zwischen Anfragen und spiken während des Reasonings. Die Limits verhindern, dass Spitzen andere Dienste beeinträchtigen.

Wie sichere ich mehrere Agenten auf demselben Server ab?

Erstellen Sie für jeden Agenten einen separaten Linux-Benutzer und Container. Jeder erhält eigene cgroup-Limits, Egress-Regeln und einen eigenen Audit-Trail. Verwenden Sie Docker-Netzwerke, um den Verkehr zwischen Agenten zu isolieren. Teilen Sie niemals Secrets zwischen Agenten.

Copyright 2026 Virtua.Cloud. Alle Rechte vorbehalten. Dieser Inhalt ist ein Originalwerk des Virtua.Cloud-Teams. Vervielfältigung, Wiederveröffentlichung oder Weiterverbreitung ohne schriftliche Genehmigung ist untersagt.

Bereit, es selbst auszuprobieren?

Betreiben Sie KI-Agenten sicher auf Ihrem eigenen VPS.

VPS-Angebote ansehen