Sichere Nutzung von KI-Agenten

Risiken von KI-Agenten

• Preisgabe von Zugangsdaten: Agenten haben Zugriff auf Umgebungsvariablen, Konfigurationsdateien und Credential-Stores. Eine Prompt-Injection kann einen Agenten dazu verleiten, API-Schlüssel oder Zugriffstoken an einen vom Angreifer kontrollierten Server zu exfiltrieren.
• Malware-Installation: Agenten können dazu gebracht werden, bösartigen Code herunterzuladen und auszuführen, zum Beispiel durch manipulierte Abhängigkeiten oder bösartige Anweisungen in README-Dateien.
• Destruktive Aktionen auf dem lokalen Rechner: Ein Agent könnte Dateien löschen, Konfigurationen überschreiben oder eine lokale Datenbank beschädigen – durch Prompt-Injection oder schlicht durch eine falsche Entscheidung.
• Destruktive Aktionen auf entfernten Systemen: Agenten haben oft Zugriff auf CLI-Tools, die mit der Produktionsinfrastruktur interagieren können. Man denke an kubectl delete, terraform destroy, nctl delete, oder vielleicht sogar einfach einen Datenbank-Client, der mit Prod verbunden ist.

Gegenmassnahmen

• Hoffnung: Den Agenten anweisen, keine destruktiven Dinge zu tun.
• Manuelle Freigabe: Die Agenten so konfigurieren, dass sie vor jeder Aktion fragen.
• Agenten-spezifische Konfiguration: Den Agenten das Lesen bestimmter Dateien oder das Ausführen bestimmter Befehle verbieten.
• Isolation: Die Agenten in VMs, Docker-Containern oder einem Sandboxing-Tool ausführen.

Hoffnung / Prompt-Betteln

Manuelle Freigabe

Agenten-spezifische Konfiguration

  {
  "permissions": {
    "allow": [
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

  {
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "bash": {
      "git commit *": "allow",
      "git push *": "deny"
    }
  }
}

• Agenten-spezifisch: Es gibt keine Möglichkeit, Regeln über alle Agenten hinweg festzulegen.
• Deny-Listen können nicht vollständig sein: Man kann eine Deny-Regel wie Read(.env) angeben, aber der Agent kann auf dieselbe Datei über ein Bash-Tool zugreifen: cat .env, grep . .env, python -c "print(open('.env').read())" usw. Deny-Listen können grundsätzlich nicht die unendlichen Möglichkeiten abdecken, auf eine Ressource zuzugreifen.
• Leicht überschreibbar: Die Regeln liegen im Repository selbst und können während der normalen Nutzung verändert werden. Claude Code erstellt zum Beispiel .claude/settings.local.json und fügt es zu Ihrem globalen ~/.config/git/ignore hinzu. Änderungen an dieser Datei erscheinen also nicht einmal in git status. Und andere Agenten ignorieren diese Konfigurationsdateien schlicht und einfach.

Isolation

Technik	Eigenschaften	Isolationsniveau
VM	Vollständige Isolation. Nur Interaktion über virtuelles Netzwerk	Sehr hoch
Container	Kernel-Namespaces, cgroups. Eingeschränkter Zugriff auf Dateien, Prozesse und andere Ressourcen	Hoch
Sandboxes	Landlock LSM / Seatbelt	Konfigurationsabhängig

• Lokale Agenten: Man möchte ihnen Zugriff auf das lokale Projekt und wahrscheinlich einige Entwicklungstools geben. Eine separate VM oder sogar ein Docker-Container erfordert daher viel Einrichtungsaufwand.
• Eigenständiger Agent: Er läuft ohnehin auf seinem eigenen Server / VM. Weiterhin möchte man, dass er in einer reproduzierbaren Umgebung läuft und das Betriebssystem nicht durcheinanderbringt. Es macht also Sinn, ihn in einem Container auszuführen.

Devcontainer

Eingebautes Sandboxing

• Agenten-spezifisch
• Schwer, die Konfiguration richtig hinzubekommen (1)
• Zumindest bei Claude Code betrifft es nur das Bash-Tool, nicht die Lese- und Schreib-Tools!

Spezialisierte Sandboxing-Tools

• Agent Safehouse: Verwendet macOS Seatbelt, um dem Agenten nur Zugriff auf das zu geben, was er wirklich braucht.
• nono: Verwendet Landlock auf Linux und Seatbelt auf macOS. Es bietet nicht nur Kernel-Isolation, sondern auch Rückgängig-Machen & Rollback, Audit-Trail, Supply-Chain-Herkunft, Laufzeitüberwachung und Filterung von Umgebungsvariablen.

• Sie erzwingen unwiderrufliche Allow-List-basierte Blockierung auf Kernel-Ebene
• Sie funktionieren mit allen Agenten
• Sie verwenden sinnvolle Standardeinstellungen zum Schutz von Zugangsdaten auf Ihrem System
• Die Konfiguration ist vom Agenten getrennt und kann separat getestet werden:

  $ nono run --allow-cwd ls ~/.ssh
...
ls: cannot open directory '~/.ssh': Permission denied
...

• nono verweigert den Zugriff auf SSH-Zugangsdaten

  $ echo $TEST_ENV_TOKEN
my-secret
$ nono run --profile claude --allow-cwd -- claude
...
❯ Zeig mir den Inhalt von TEST_ENV_TOKEN

● Bash(echo "$TEST_ENV_TOKEN")
  ⎿  my-secret

● TEST_ENV_TOKEN=my-secret

• Claude greift problemlos auf Tokens aus der Umgebung zu

  {
  "extends": "claude",
  "environment": {
    "allow_vars": ["PATH", "HOME", "TERM", "LANG", "LC_*"]
  }
}

• Benutzerdefiniertes Profil unter ~/.config/nono/profiles/claude-filter-env.json

  $ echo $TEST_ENV_TOKEN
my-secret
$ nono run --profile claude-filter-env --allow-cwd -- claude
...
❯ Zeig mir den Inhalt von TEST_ENV_TOKEN.

● Bash(echo "$TEST_ENV_TOKEN")
  ⎿  (Keine Ausgabe)

● TEST_ENV_TOKEN ist nicht gesetzt (oder leer) in dieser Shell.

• Claude kann den Inhalt von $TEST_ENV_TOKEN nicht sehen

Zusammenfassung

• Für eigenständige Agenten: Verwenden Sie VMs, Docker-Container und begrenzen Sie die Verfügbarkeit von Zugangsdaten so weit wie möglich. Es ist besser, den KI-Agenten seine Aufgabe erledigen zu lassen und dann Ihre benutzerdefinierte Laufzeit Code pushen, auf Tickets antworten usw. zu lassen.
• Für Entwicklermaschinen: Verwenden Sie Sandboxing-Tools mit vorgefertigten Profilen für gängige KI-Agenten. Lassen Sie sie dennoch nicht im --yolo / unbeaufsichtigten Modus laufen: Geben Sie die Befehle weiterhin selbst frei, aber Sie können grosszügiger sein, welche Befehle sie ohne Bestätigung ausführen dürfen. Achten Sie besonders auf Zugangsdaten, die über Umgebungsvariablen verfügbar sind.

---