KI-Agenten absichern: Sicherheitsrisiken und Gegenmaßnahmen

KI-Agenten absichern wird in dem Moment zur Pflicht, in dem ein Agent den Sprung vom Chat-Fenster auf den Desktop schafft. Werkzeuge wie OpenClaw oder Cowork lesen Dateien, führen Shell-Kommandos aus, verschicken Nachrichten und ändern Konfigurationen. Ein Fehler des Modells ist dann kein falscher Text mehr, sondern eine falsche Aktion auf einem echten Rechner. Wie sich die beiden Plattformen im Alltag unterscheiden, steht im Vergleich OpenClaw vs. Cowork. Dieser Artikel beantwortet die Frage danach: Wie betreibt man einen solchen Agenten, ohne sich ein Sicherheitsproblem ins Haus zu holen?

Die gute Nachricht vorweg: Die wirksamen Gegenmaßnahmen sind weder teuer noch exotisch. Es sind dieselben Prinzipien, mit denen die IT seit Jahrzehnten fremden Code einhegt. Man muss sie nur konsequent auf eine neue Klasse von Software anwenden, die per Definition unvorhersehbar handelt.

Drei reale Risiken bei Desktop-Agenten

Das erste Risiko ist externe Erreichbarkeit. Desktop-Agenten werden gern über Messenger gesteuert, bei OpenClaw etwa via Telegram oder WhatsApp. Damit steuert jeder, der diesen Kanal erreicht, indirekt den Rechner. Frühe OpenClaw-Versionen hatten zusätzlich offen erreichbare Gateway-Ports und Debug-Endpunkte, über die sich Instanzen ohne Authentifizierung fanden und übernehmen ließen. Dazu kommt Prompt Injection: Liest der Agent eine Webseite oder E-Mail mit versteckten Anweisungen, kann dieser Text das Modell zu Aktionen bewegen, die niemand beauftragt hat. Eine ausführliche Analyse dieser Angriffsfläche liefert unser Artikel zu autonomen Agenten und ihren Enterprise-Risiken.

Das zweite Risiko ist banaler und trifft fast jeden früher oder später: versehentlich gelöschte oder überschriebene Daten. Ein Agent, der mit den Rechten des angemeldeten Benutzers läuft, kann alles löschen, was dieser Benutzer löschen kann. Ein falsch interpretierter Auftrag wie “räum das Projektverzeichnis auf” reicht aus. Anders als bei einem menschlichen Fehler passiert das in Sekunden und ohne Rückfrage.

Das dritte Risiko ist schleichende Selbst-Umkonfiguration. Agenten installieren Pakete, legen Cronjobs an, editieren eigene Skill-Dateien und Einstellungen. Ohne Grenzen driftet das System in einen Zustand, den niemand mehr nachvollziehen kann. Die OWASP Top 10 für LLM-Anwendungen führen dieses Muster als “Excessive Agency”: Der Agent hat mehr Befugnisse, als sein Auftrag erfordert.

Ein eigener Benutzer ohne Root-Rechte

Die wirksamste Einzelmaßnahme kostet eine halbe Stunde: Der Agent bekommt einen eigenen Betriebssystem-Benutzer ohne Administratorrechte. Damit ist der Schadensradius technisch begrenzt, egal was das Modell entscheidet. Unter Linux sieht das Grundgerüst so aus:

sudo useradd --create-home --shell /bin/bash agent
sudo passwd --lock agent
sudo chmod 750 /home/agent
sudo setfacl -m u:agent:rx /srv/projekte/website

Der Account ist für Passwort-Logins gesperrt und gehört keiner sudo-Gruppe an. Lesezugriff auf Arbeitsdaten wird gezielt per ACL vergeben, statt den Agenten im eigenen Home-Verzeichnis arbeiten zu lassen. Auf dem Mac erfüllt ein Standard-Account ohne Admin-Rechte denselben Zweck, ergänzt um einen eigenen Schlüsselbund, damit der Agent nicht an private Zugangsdaten kommt.

Dasselbe Prinzip gilt für API-Zugänge: Der Agent erhält eigene Keys mit eigenem Kostenlimit und minimalem Scope, niemals die persönlichen Zugangsdaten oder gar den Passwortmanager des Besitzers. Fällt ein Key in falsche Hände oder ruft der Agent eine Schleife lang die falsche API auf, bleibt der Schaden begrenzt und zuordenbar.

Sandbox plus schnelle Wiederherstellung

Rechtebegrenzung verhindert viel, aber nicht alles. Die zweite Verteidigungslinie besteht aus zwei Teilen: Der Agent läuft in einer Umgebung, die wenig kaputt machen kann, und das Gesamtsystem lässt sich schnell in einen bekannten Zustand zurückversetzen.

Für die Eingrenzung hat sich ein Container mit explizit gemountetem Arbeitsverzeichnis bewährt:

docker run --rm --name agent \
  --user 1001:1001 \
  --cap-drop ALL \
  --memory 4g --pids-limit 256 \
  -v /srv/agent/work:/work \
  agent-image

Sichtbar ist nur das Arbeitsverzeichnis, alle Linux-Capabilities sind entzogen, Speicher und Prozessanzahl sind gedeckelt. Den Netzwerkzugang komplett zu kappen funktioniert in der Praxis nicht, der Agent braucht seine Modell-API. Sinnvoller ist ein Egress-Proxy mit Allowlist, der nur die LLM-Endpunkte und definierte interne Dienste zulässt.

Für die Wiederherstellung zählt eine einzige Kennzahl: Wie lange dauert es, bis das System nach einem Agenten-Fehler wieder arbeitsfähig ist? Dateisystem-Snapshots mit Btrfs oder ZFS, Time Machine auf dem Mac oder ein goldenes VM-Image bringen diese Zeit unter 15 Minuten. Wer die Agenten-Umgebung von vornherein als Wegwerf-Artefakt behandelt, das jederzeit neu aufgesetzt werden kann, nimmt dem Fehlerfall den Schrecken und dem Betreiber die Angst vor Experimenten.

Freigabe-Schritte für kritische Aktionen

Technische Isolation beantwortet nicht die Frage, welche Aktionen der Agent überhaupt eigenständig ausführen darf. Dafür braucht es eine Policy mit Freigabe-Schritten, also menschlicher Bestätigung an den Stellen, wo ein Fehler teuer wird. Als Kategorien-Modell statt Einzelfall-Entscheidung:

policies:
  file_read: allow
  file_write: allow_workdir
  file_delete: require_approval
  shell_command: require_approval
  message_send: require_approval
  system_config: deny
  default: deny

Lesen ist frei, Schreiben nur im Arbeitsverzeichnis, Löschen und ausgehende Nachrichten erfordern einen Klick vom Menschen, Systemkonfiguration ist tabu. Entscheidend ist der Default: Alles, was keiner Kategorie zugeordnet ist, wird verweigert. Cowork und Claude Code setzen dieses Muster mit Berechtigungsdialogen um, OpenClaw lässt sich über Konfiguration ähnlich zähmen.

Zwei Fallstricke verdienen Beachtung. Erstens Freigabe-Müdigkeit: Fragt das System bei jeder Kleinigkeit nach, klickt der Mensch nach einer Woche alles blind weg. Freigaben gehören deshalb nur an wirklich kritische Aktionen. Zweitens endet die Policy nicht am Agenten selbst. Jedes angebundene Tool braucht dieselbe Disziplin auf Server-Seite, mit minimalen Rechten pro Werkzeug.

Fazit

Vier Maßnahmen machen aus einem riskanten Experiment einen kalkulierbaren Betrieb: ein eigener Benutzer ohne Root-Rechte, eine Sandbox mit begrenztem Dateisystem- und Netzwerkzugriff, ein in Minuten wiederherstellbares System und Freigabe-Schritte für destruktive Aktionen. Die sinnvolle Reihenfolge: erst Rechte begrenzen, dann Wiederherstellung testen, zuletzt die Policies verfeinern. Wer das vor dem ersten produktiven Einsatz erledigt, muss KI-Agenten nicht fürchten, sondern kann ihren Nutzen ausschöpfen.

EverBright betreibt eigene Desktop-Agenten produktiv nach genau diesem Muster und unterstützt Unternehmen beim sicheren Setup, von der Risikoanalyse bis zur Umsetzung. Mehr dazu unter KI-Beratung und Umsetzung.

Jetzt Beratungsgespräch vereinbaren →

Häufige Fragen

Wie sichert man einen KI-Agenten auf dem Desktop ab?

Vier Maßnahmen greifen ineinander: ein eigener Betriebssystem-Benutzer ohne Administratorrechte, eine Sandbox mit gezielt gemountetem Arbeitsverzeichnis und begrenztem Netzwerkzugang, Snapshots für schnelle Wiederherstellung sowie Freigabe-Schritte für destruktive Aktionen wie Löschen oder das Versenden von Nachrichten. Zusammen begrenzen sie den Schaden, egal welche Entscheidung das Modell trifft.

Warum sollte ein KI-Agent keine Root-Rechte haben?

Ein Agent handelt nicht-deterministisch und kann durch Prompt Injection oder Fehlinterpretation falsche Aktionen ausführen. Mit Root-Rechten betrifft das im schlimmsten Fall das gesamte System, inklusive anderer Benutzer und Systemdienste. Ein unprivilegierter Account begrenzt den Schadensradius technisch, unabhängig davon, was das Modell entscheidet oder welcher Angriff gelingt.

Welche Aktionen eines KI-Agenten brauchen eine manuelle Freigabe?

Alle Aktionen, die schwer rückgängig zu machen sind oder nach außen wirken: Dateien löschen, Shell-Kommandos außerhalb der Sandbox, Nachrichten oder E-Mails versenden, Geld bewegen und Systemkonfiguration ändern. Reines Lesen und Schreiben im definierten Arbeitsverzeichnis kann frei bleiben, sonst entsteht Freigabe-Müdigkeit und der Schutz verliert seine Wirkung.

Wie schnell lässt sich ein System nach einem Agenten-Fehler wiederherstellen?

Mit Dateisystem-Snapshots über Btrfs oder ZFS, Time Machine auf dem Mac oder einem vorbereiteten VM-Image liegt die Wiederherstellungszeit realistisch unter 15 Minuten. Wichtig ist, den Ernstfall einmal zu proben, bevor der Agent produktiv läuft. Eine Umgebung, die als Wegwerf-Artefakt konzipiert ist, macht Fehler des Agenten beherrschbar.