Sicherheit (persönlicher) KI-Agenten

Dieser Artikel ist Teil der XPRT. Magazin Nr. 21

Seit ich Ende letzten Jahres begonnen habe, mit KI-Agenten wie Claude Code und den neueren Modellen wie Opus 4.5 zu arbeiten, und festgestellt habe, wie sehr sie sich verbessert haben, geht mir eine Frage nicht mehr aus dem Kopf: Gibt es eine Möglichkeit, dass mir ein Agent dabei hilft, mein Privat- und Berufsleben zu organisieren? Als Vater von fünf Kindern, der 36 Stunden pro Woche arbeitet und über 40 Jahre alt ist, stelle ich oft fest, dass ich Unterstützung gebrauchen könnte, um sicherzustellen, dass ich nichts vergesse. Außerdem fällt mir regelmäßig erst dann ein, etwas zu erledigen, wenn ich bereits nichts mehr daran ändern kann. Sollte ich einfach besser darin werden, mir Dinge zu merken, oder gibt es etwas, das mir helfen könnte? Wäre es nicht großartig, wenn jeder einen solchen „Executive Assistant“ (EA) hätte, wie ihn die Führungskräfte in Fernsehserien offenbar haben? Einen EA, der nichts vergisst und dafür sorgt, dass man auf alles gut vorbereitet ist?

Dann kam vor einigen Monaten OpenClaw auf den Markt, und zum ersten Mal dachte ich: „Wow, das könnte genau das sein, was ich brauche. OpenClaw könnte mein persönlicher Assistent sein!“ Doch immer wieder stieß ich auf Artikel über Sicherheitsbedenken. Diese Sicherheitsbedenken haben mich bisher davon abgehalten, das Programm tatsächlich zu nutzen.

Also fragte ich mich: Wie gehen die anderen Agenten das Thema Sicherheit an? Was ist mir wichtig? Halte ich OpenClaw tatsächlich für unsicher, und könnte ich etwas dagegen unternehmen?

In diesem Artikel werde ich die verfügbaren Optionen untersuchen und erläutern, wie diese auf (persönliche) KI-Agenten angewendet werden könnten.

Sicherheitsaspekte im Zusammenhang mit KI-Agenten

Um feststellen zu können, welche zusätzlichen Sicherheitsmaßnahmen ergriffen werden könnten, müssen wir zunächst die Risiken betrachten, die mit der Nutzung von LLMs und den Agenten-Harnesses (ohne jegliche Schutzmaßnahmen) verbunden sind:

Sofortige Injektion. Ein Agent, der nicht vertrauenswürdige Inhalte verarbeitet – sei es eine Webseite, eine E-Mail oder ein Dokument, das Ihnen jemand gesendet hat –, kann durch in diesen Inhalten eingebettete Anweisungen manipuliert werden. Das LLM kann nicht zuverlässig zwischen „Anweisungen des Benutzers“ und „Anweisungen, die in dem enthalten sind, was ich gerade lese“ unterscheiden. Eine bösartige Seite kann Ihrem Agenten befehlen, Ihre Notizen zu entwenden oder Dateien zu löschen, und wenn der Agent dazu in der Lage ist und es keine Ebene unterhalb des Modells gibt, die ihn daran hindert, wird er dies tun.

Unkontrollierter Explosionsradius. Ein Agent übernimmt die Berechtigungen Ihres Benutzers. Das bedeutet, dass er Ihre SSH-Schlüssel lesen, in Ihr Home-Verzeichnis schreiben, Dateien löschen, in Ihrem Namen E-Mails versenden und mit jedem lokalen Dienst interagieren kann, auf den Ihr Benutzerkonto Zugriff hat. Der Agent ist nicht böswillig, kann jedoch Fehler machen, Anweisungen falsch verstehen oder manipuliert werden. Alles, was er tut, ist so, als hätten Sie es selbst getan.

Datenexfiltration. Ein Agent mit Lesezugriff auf Ihre Dateien und uneingeschränktem Netzwerkzugang hat grundsätzlich die Möglichkeit, Ihre Dateien an jeden beliebigen Ort zu senden. Hier treffen zwei Funktionen aufeinander, die in Standardkonfigurationen von Agenten häufig gemeinsam vorkommen: umfassender Lesezugriff (der Agent muss Ihre Dateien einsehen können, um Ihnen dabei zu helfen) und uneingeschränkter ausgehender Datenverkehr (der Agent muss APIs aufrufen).

Offenlegung von Anmeldedaten. In den meisten Entwicklerumgebungen sammeln sich im Laufe der Zeit Anmeldedaten an: API-Schlüssel in Shell-Profilen, Cloud-Anmeldedaten in „ ~/.azure “, SSH-Schlüssel sowie „ .env “-Dateien, die über die Projektverzeichnisse verstreut sind. Ein in Ihrer Shell ausgeführter Agent-Prozess übernimmt all diese Daten. Wird der Agent kompromittiert oder verhält er sich fehlerhaft, sind diese Anmeldedaten gefährdet. Den meisten Entwicklern sind nicht alle vertraulichen Daten bewusst, die sich in ihrer Umgebung befinden.

Unumkehrbarkeit. Wenn ein Agent eine Datei mithilfe seiner integrierten Werkzeuge ändert oder löscht, wird diese Änderung sofort in Ihrem tatsächlichen Dateisystem übernommen. Es gibt keinen Rückgängig-Puffer, keinen Vorschau-Schritt und keinen Papierkorb. Eine falsch verstandene Anweisung oder eine fehlerhafte Modellausgabe führt zu einem tatsächlichen Datenverlust. Für ein Tool, das über eine lange Sitzung hinweg autonom in Ihrem Auftrag arbeitet, ist dies von größerer Bedeutung als für ein Tool, das jeweils nur eine Änderung vornimmt, während Sie den Vorgang im Blick behalten.

Diese Risiken treten nicht isoliert auf. Eine sofortige Injektion ist umso gefährlicher, je größer der Explosionsradius ist. Ein großer Explosionsradius spielt umso mehr eine Rolle, wenn keine Rollback-Funktion vorhanden ist. Die Offenlegung von Anmeldedaten hat umso schwerwiegendere Folgen, wenn keine Kontrolle des ausgehenden Netzwerkverkehrs vorhanden ist. Sie können keines dieser Risiken vollständig angehen, ohne zu berücksichtigen, in welchem Zusammenhang es mit den anderen steht.

Welche Schutzfunktionen bieten die Agenten-Gurte?

Bei der Arbeit mit Agenten stellen Sie schnell fest, dass diese (scheinbar) Schutz bieten, da sie Sie um Ihre Zustimmung bitten, bevor sie eine bestimmte Aktion ausführen. Gleichzeitig bemerken Sie jedoch auch, dass es Unterschiede zwischen den Agenten gibt: Bei einigen müssen Sie nicht so viele Aktionen genehmigen wie bei anderen. Die Tatsache, dass Sie eine bestimmte Aktion genehmigen können, bedeutet, dass der Prozess, in dem der Agent läuft, diese Berechtigung bereits besitzt (oder davon ausgeht, dass er sie besitzt); in diesem Sinne handelt es sich also um weiche Schutzmaßnahmen. Der Agentenprozess entscheidet, ob die Nutzung der bereits vorhandenen Berechtigung zugelassen oder verweigert wird.

Sie können außerdem feststellen, dass diese Schutzmaßnahmen in der Regel auf der Ebene des Harness und nicht auf der Ebene der zugrunde liegenden Ressource definiert werden. Ein gutes Beispiel hierfür ist der Webzugriff: Einige Agenten ermöglichen eine Websuche, ohne zuvor um Genehmigung zu bitten; wenn Sie den Agenten jedoch ausdrücklich anweisen, eine bestimmte Website zu öffnen, wird zunächst um Erlaubnis gebeten. Technisch gesehen beinhalten beide Aktionen eine Verbindung zu Websites. Der Unterschied besteht darin, dass das Harness „im Internet suchen“ und „diese Website öffnen“ als zwei unterschiedliche Funktionen mit unterschiedlichen Vertrauensstufen und Genehmigungsregeln behandelt.

Da es sich bei all diesen Schutzmaßnahmen ohnehin um „weiche“ Schutzmaßnahmen handelt und da diese Schutzmaßnahmen je nach KI-Agent unterschiedlich sind, werden wir nicht im Detail darauf eingehen, was die einzelnen Agenten tun oder tun könnten. Wir werden dies aus folgender Perspektive betrachten: Wie können wir jeden beliebigen Agenten absichern? Damit werden wir uns als Nächstes befassen.

Technische Steuerflächen

Um sich klare Gedanken darüber zu machen, wie man einen Agenten gewinnen kann, ist es hilfreich, das Problem in konkrete Handlungsfelder zu unterteilen:

Vor dem Hintergrund dieser Kontrollmechanismen stellt sich nun die Frage, wo in der Praxis Schutzmaßnahmen ergriffen werden sollten. Mit anderen Worten: Wenn es diese Fähigkeiten sind, die das Versagen von Agenten gefährlich machen, welche technischen Kontrollmaßnahmen können wir dann einführen, um diese einzuschränken?

Grundlagen: Prozessisolierung

Als Erstes benötigen Sie eine Abgrenzung zwischen dem Agenten und dem Rest Ihres Computers.

Ohne diese Abgrenzung läuft der Agent als normaler Prozess in Ihrer üblichen Benutzerumgebung. Er sieht, was Sie sehen können, greift auf das zu, worauf Sie Zugriff haben, und nutzt dieselben Berechtigungen wie Sie. Zu diesem Zeitpunkt gibt es kaum Kontrollmöglichkeiten. Der Agent fordert zwar möglicherweise eine Genehmigung an, doch der zugrunde liegende Prozess läuft weiterhin mit weitreichenden Zugriffsrechten auf Host-Ebene. Die Prozessisolierung ändert dies. Sie bietet Ihnen einen Rahmen, um Regeln durchzusetzen.

Sobald der Agent isoliert ist, können Sie Entscheidungen darüber treffen, was er sehen darf, was er ändern darf, welchen Netzwerkzugriff er haben soll und auf welche lokalen Schnittstellen er zugreifen darf. Mit anderen Worten: Die Prozessisolierung löst zwar nicht das gesamte Problem, schafft jedoch eine technische Grenze, die spätere Kontrollmaßnahmen ermöglicht.

Optionen zur Prozessisolierung in verschiedenen Betriebssystemen

Wie Sie dies genau bewerkstelligen können, hängt vom jeweiligen Betriebssystem ab.

Unter Linux sind Container die gängige Standardlösung. Docker und Podman sind in der Regel der einfachste Weg, um zu verhindern, dass der Agent direkt auf dem Host ausgeführt wird, und gleichzeitig einen vertrauten Arbeitsablauf beizubehalten. Wenn Sie eine stärkere Isolierung wünschen, fügt gVisor eine weitere Barriere vor dem Host-Kernel hinzu, und Firecracker geht noch einen Schritt weiter, indem es die Workload in einer Mikro-VM ausführt.

Unter macOS besteht die übliche Wahl entweder in einer nativen Sandbox um den Prozess herum oder in einer Linux-Umgebung, die von Docker oder einem anderen VM-basierten Tool bereitgestellt wird. Anthropics srt Das ist hier interessant, da es Ihnen eine ressourcenschonende Möglichkeit bietet, einen Prozess innerhalb der Grenzen einer nativen Sandbox auszuführen, ohne zuvor einen kompletten VM-Workflow aufbauen zu müssen.

Entscheidend ist nicht, welches konkrete Tool Sie als Erstes wählen. Entscheidend ist vielmehr, dass der Agent nicht mehr als uneingeschränkter Host-Prozess ausgeführt wird.

Für die meisten Menschen ist der richtige Ausgangspunkt der einfachste Isolationsmechanismus, den sie tatsächlich konsequent anwenden werden. Es gibt zwar stärkere Isolationsmaßnahmen, doch ist es heute wertvoller, eine echte Abgrenzung zu schaffen, als eine perfekte zu planen und sie dann nie umzusetzen.

Nachdem die Grundlagen geschaffen sind, können wir damit beginnen, Steuerelemente auf die fünf zuvor definierten Flächen anzuwenden.

Dateisystemsteuerung

Was das Dateisystem betrifft, sollten wir standardmäßig keine Verzeichnisse oder Dateien vom Host für den Agenten freigeben. Für die Dateien oder Verzeichnisse, auf die der Agent zugreifen muss, um die von Ihnen beauftragte Aufgabe auszuführen, definieren wir drei Dateisystemklassen:

Schreibgeschützte Eingaben

Grundsätzlich sollte gelten, dass alles, was der Agent lediglich überprüfen muss, technisch gesehen schreibgeschützt ist. Bei Containern könnte dies dadurch erreicht werden, dass Host-Verzeichnisse schreibgeschützt eingebunden werden:

-v /home/user/docs:/docs:ro
-v /home/user/notes:/notes:ro

Auf diese Weise können wir sicherstellen, dass diese Dateien niemals verändert werden können.

Schreibbare Arbeitsbereiche

Für die Dateien und Verzeichnisse, an denen der Agent Änderungen vornehmen muss, werden wir zwei Optionen betrachten:

Git-Arbeitsverzeichnisse

Wenn es sich bei dem Arbeitsbereich um ein Git-Repository handelt, ist ein Git-Wortree ein übersichtlicher und einfacher Ansatz. Ein Wortree erstellt ein separates Arbeitsverzeichnis, das mit demselben Repository verknüpft ist und auf einen eigenen Zweig ausgecheckt wird. Entscheidend ist, dass der eigentliche Ordner „ .git “ im Haupt-Repository verbleibt. Das Worktree-Verzeichnis enthält lediglich eine ` .git ` -Datei (einen Verweis), nicht jedoch die Git-Daten selbst. Wenn Sie lediglich das Worktree-Verzeichnis in den Container einbinden, hat der Agent keinen Pfad zum Hauptordner ` .git ` und kann Ihre Historie nicht zerstören – auch nicht absichtlich.

# Create a dedicated worktree on a new branch for the agent to work in
git -C /home/user/project worktree add /home/user/agent-workspaces/project agent/session-1

# Mount only the worktree directory — not the parent repo — into the container
# --rm removes the container automatically when it exits, so no state persists between runs
docker run --rm -it \
  -v /home/user/agent-workspaces/project:/workspace \
  my-agent-image

Überprüfen Sie nach der Sitzung die Commits des Agenten im Zweig „ agent/session-1 “ und führen Sie diese nach eigenem Ermessen zusammen oder verwerfen Sie sie. Sollte etwas schiefgelaufen sein, löschen Sie den Zweig und entfernen Sie das Arbeitsverzeichnis – das Haupt-Repository bleibt davon unberührt.

OverlayFS

Eine weitere Linux-spezifische Option ist die Verwendung von OverlayFS. OverlayFS stellt eine „Copy-on-Write“-Schicht über einem echten Verzeichnis bereit. Der Agent sieht ein normales, beschreibbares Verzeichnis, doch Schreib-, Bearbeitungs- und Löschvorgänge erfolgen in einer temporären oberen Schicht und nicht in den darunterliegenden Originaldateien. Das bedeutet, dass der Agent so agieren kann, als hätte er vollen Schreibzugriff, Sie jedoch weiterhin überprüfen können, was er getan hat, und entscheiden können, ob die Änderungen übernommen werden sollen. Unter macOS bestehen die praktischen Alternativen in der Regel darin, in einem kopierten Arbeitsbereich zu arbeiten oder den Agenten in einer Linux-VM oder einer von Docker verwalteten Linux-Umgebung auszuführen und dort OverlayFS zu nutzen.

Konzeptionell lässt sich das Ganze in vier Teile gliedern:

Bei Containern könnte man wie folgt vorgehen:

# Prepare the writable, temporary OverlayFS directories
mkdir -p /tmp/agent-overlay/{upper,work,merged}

# Create a merged view:
# - the real project is the read-only base layer (lowerdir)
# - all agent changes go into /tmp/agent-overlay/upper
# - /tmp/agent-overlay/merged is the directory the container will see
sudo mount -t overlay overlay \
  -o lowerdir=/home/user/project,upperdir=/tmp/agent-overlay/upper,workdir=/tmp/agent-overlay/work \
  /tmp/agent-overlay/merged
# Note: mounting overlayfs requires root. If root is not available in your setup,
# fuse-overlayfs (https://github.com/containers/fuse-overlayfs) provides a rootless alternative.

# Give the container access only to the merged view
docker run --rm -it \
  -v /tmp/agent-overlay/merged:/workspace \
  my-agent-image

Nach Abschluss der Sitzung können Sie unter /tmp/agent-overlay/upper einsehen, was sich genau geändert hat. Die Originaldateien unter /home/user/project bleiben unberührt, es sei denn, Sie beschließen später, die Änderungen zurückzukopieren. Sollte das Ergebnis nicht zufriedenstellend sein, können Sie das Overlay aushängen und die temporäre obere Ebene verwerfen.

Temporärer Arbeitsspeicher

Agenten benötigen zudem einen Speicherort für temporäre Dateien: Downloads, Build-Artefakte, Parser-Ausgaben, Caches und andere sitzungsbezogene Zustände.

Dieser Speicherort sollte in der Regel „tmpfs“ oder ein anderes temporäres Verzeichnis sein, das nach Beendigung der Sitzung gelöscht wird.

docker run --rm -it \
  -v /home/user/project:/workspace \
  --tmpfs /tmp:rw,noexec,nosuid,size=512m \
  my-agent-image

In diesem Beispiel erhält der Agent weiterhin seinen normalen beschreibbaren Arbeitsbereich unter /workspace, doch /tmp wird durch einen Speicher im Arbeitsspeicher statt durch ein persistentes Verzeichnis auf der Festplatte bereitgestellt. Downloads, Build-Artefakte, Caches und Parser-Ausgaben können während der Sitzung dort gespeichert werden, verschwinden jedoch automatisch, wenn der Container beendet wird. Dies hat zwei Vorteile: Es reduziert die Datenflut, die jeder Agent-Lauf hinterlässt, und verringert damit auch einen Risikofaktor; außerdem lässt sich so viel leichter nachvollziehen, was der Agent tatsächlich behalten wollte und was er lediglich während der Arbeit benötigte.

Kontrollen für den Datenausgang aus dem Netzwerk

Diese Kontrollmaßnahme dient der Eindämmung des Risikos einer Datenexfiltration. Ein Agent, der über Lesezugriff auf Ihre Dateien sowie über Netzwerkzugang zum Internet verfügt, kann grundsätzlich beliebige Daten an einen beliebigen Endpunkt senden. Sie müssen kontrollieren, auf welche Ziele im Netzwerk der Agent zugreifen kann.

Firewall-Regeln

Die erste Option wäre eine Firewall, die standardmäßig den gesamten ausgehenden Datenverkehr blockiert und nur das zulässt, was Sie ausdrücklich genehmigen. Wenn Sie den Agenten in Docker ausführen, legen Sie auf dem Host Firewall-Regeln fest, die für das für den Agenten erstellte Docker-Netzwerk gelten.

Auf diese Weise würden Sie den Netzwerkzugang vollständig unterbinden; in der Praxis funktioniert dies jedoch nicht bei Agenten, deren Modelle und Inferenz cloudbasiert sind:

docker run --rm --network none your-prebuilt-agent-image

Um bestimmte IP-Adressen durchzulassen, gehen Sie unter Linux wie folgt vor:

# Create a dedicated network for the agent
docker network create agent_net

# Run the pre-built image on that network
docker run --rm --network agent_net --name agent your-prebuilt-agent-image

# On the host: find the bridge interface Docker created for that network
docker network inspect agent_net

# Then apply egress rules to that bridge in the DOCKER-USER chain
# Replace br-xxxxxxxxxxxx with the actual bridge name
iptables -I DOCKER-USER -i br-xxxxxxxxxxxx -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I DOCKER-USER -i br-xxxxxxxxxxxx -p udp --dport 53 -j ACCEPT
iptables -I DOCKER-USER -i br-xxxxxxxxxxxx -p tcp --dport 53 -j ACCEPT
iptables -I DOCKER-USER -i br-xxxxxxxxxxxx -d 160.79.104.0/23 -p tcp --dport 443 -j ACCEPT
iptables -A DOCKER-USER -i br-xxxxxxxxxxxx -j DROP

Der zu beachtende Kompromiss: Dies funktioniert, solange die Zieladressen stabil sind. IP-Adressen ändern sich jedoch häufig. Die API von Anthropic könnte zu unterschiedlichen Zeitpunkten über verschiedene IP-Adressen bereitgestellt werden, was die Pflege einer genauen Zulassungsliste von IP-Adressen erschwert.

Falls Sie keine Container verwenden: Unter Linux würden Sie dieses Problem in der Regel mit „ iptables “ oder „ nftables “ auf Host-Ebene lösen. Unter macOS ist das Äquivalent in der Regel der integrierte Paketfilter (pf).

DNS-Filterung

Gehen Sie noch einen Schritt weiter: Blockieren Sie die DNS-Auflösung für Domains, die Sie nicht genehmigt haben. Wenn der Agent eine nicht autorisierte Domain nicht auflösen kann, kann er diese unabhängig von der IP-Adresse nicht erreichen.

Dies eignet sich gut als erste Verteidigungslinie. Pi-hole oder Unbound, die so konfiguriert sind, dass bestimmte Domänen auf die Whitelist gesetzt werden, stellen eine sinnvolle Lösung dar. DNS-Filterung allein reicht jedoch nicht aus. Ein Angreifer (oder ein fehlerhafter Agent) kann IP-Adressen fest einprogrammieren und das DNS vollständig umgehen.

HTTP-Proxy mit Whitelist

Ein HTTP-Proxy, über den der Agent den gesamten Datenverkehr leiten muss, bietet Ihnen mehr Kontrolle als eine Firewall auf IP-Ebene. Die einfachste sinnvolle Variante ist die Host-Whitelist: Lassen Sie nur Anfragen an eine kleine Gruppe zugelassener Domains zu.

„mitmproxy“ habe ich in verschiedenen Situationen, in denen ich einen Proxy benötigte, am häufigsten verwendet. Sie können ein Python-Skript schreiben, das Ihre Zulassungsliste implementiert:

# mitmproxy_filter.py
from mitmproxy import http

ALLOWED_DOMAINS = {
    "api.anthropic.com",
    "api.github.com",
    # add only what your agent actually needs
}

def http_connect(flow: http.HTTPFlow):
    # Fires on the CONNECT request, before TLS — so we can block by hostname
    # without needing to intercept or decrypt the traffic.
    if flow.request.host not in ALLOWED_DOMAINS:
        flow.response = http.Response.make(
            403,
            f"Blocked: {flow.request.host} is not in the allowlist",
            {"Content-Type": "text/plain"},
        )

Führen Sie es aus:

mitmdump --listen-host 0.0.0.0 --listen-port 8080 -s mitmproxy_filter.py

Ich verwende hier „ mitmdump “, da dies die einfachste nicht-interaktive Methode ist, das Filterskript auszuführen. Wenn Sie die Verbindungen in Echtzeit überwachen möchten, während der Agent läuft, bietet „mitmproxy“ eine Terminal-Benutzeroberfläche und „mitmweb“ eine Browser-Benutzeroberfläche.

Leiten Sie anschließend den gesamten Datenverkehr aus Ihrem Agent-Container über den Proxy weiter. Mit Docker können Sie den Proxy über Umgebungsvariablen festlegen:

docker run --rm -it \
  -e HTTP_PROXY=http://proxy-host:8080 \
  -e HTTPS_PROXY=http://proxy-host:8080 \
  my-agent-image

Dies funktioniert sowohl für HTTP als auch für HTTPS auf Hostnamenebene. Bei HTTPS teilt der Client dem Proxy weiterhin mit, mit welchem Host er eine Verbindung herstellen möchte, sodass der Proxy dieses Ziel zulassen oder blockieren kann, ohne den verschlüsselten Inhalt überprüfen zu müssen.

Wenn Sie mehr als nur eine einfache Host-Whitelist erstellen möchten, wird die Sache etwas komplexer. Durch transparentes Proxying können Sie den Datenverkehr auch dann abfangen, wenn die Anwendung die Proxy-Einstellungen nicht berücksichtigt. Die Überprüfung von HTTPS-Pfaden, Headern oder Payloads erfordert eine TLS-Abfangung, was bedeutet, dass der Client der Zertifizierungsstelle des Proxys vertrauen muss. Dies kann in bestimmten Szenarien nützlich sein, ist jedoch wesentlich komplexer in der Einrichtung.

Geheimnisse – Steuerung

Während die Dateisystem- und Netzwerksteuerungen festlegen, worauf der Agent zugreifen darf, geht es bei den Geheimhaltungssteuerungen darum, wie wir sicherstellen, dass Agenten keine tatsächlichen Geheimnisse (z. B. API-Schlüssel, Tokens usw.) einsehen können. Wenn Ihr Agent die Anthropic-API, GitHub oder Ihre Kalender-API aufrufen muss, sollten sich diese API-Schlüssel nicht in der Umgebung oder im Dateisystem des Agenten befinden. Leiten Sie diese Aufrufe stattdessen über ein kontrolliertes Gateway, das die Anmeldedaten verwaltet und die Aufrufe im Namen des Agenten durchführt, nachdem überprüft wurde, dass die Anfrage den Richtlinien entspricht.

In der Praxis handelt es sich hierbei um einen kleinen Proxy- oder Sidecar-Prozess, der:

Sollte der Agent kompromittiert sein, kann der Angreifer über Ihr Gateway lediglich API-Aufrufe tätigen, die den Richtlinien entsprechen. Er erhält keinen Zugriff auf die unverschlüsselten API-Schlüssel.

agentgateway ist ein Sandbox-Projekt der CNCF (Cloud-Native Computing Foundation), das eine Richtlinien- und Kontrollschicht vor den Agent-Datenverkehr schaltet. Dank der vereinfachten LLM-Konfiguration sieht der für diesen Anwendungsfall relevante Teil wie folgt aus:

# agentgateway.yaml
llm:
  models:
    - name: claude-haiku
      provider: anthropic
      params:
        model: claude-3-5-haiku-20241022
        apiKey: "$ANTHROPIC_API_KEY"

Dann verweist Ihr Agent auf „Agent Gateway“ statt direkt auf „Anthropic“. Der Schlüssel befindet sich in der Umgebung des Gateways, nicht in der des Agenten. Der Agent erhält Zugriff auf das Modell, kann die Rohdaten der Anmeldedaten jedoch weder lesen noch abziehen.

Wie das Gateway diese Anmeldedaten erhält, ist eine separate Entscheidung. In einer einfachen privaten Umgebung können Sie diese beim Starten des Gateway-Containers vom Host bereitstellen. Wenn Sie zudem sicherstellen möchten, dass der Host keine Geheimnisse enthält, kann das Gateway diese stattdessen von einem Secret-Manager abrufen.

Ausführung und lokale Schnittstellensteuerung

Bislang lag der Schwerpunkt darauf, was der Agent lesen kann, wohin er Daten senden kann und welche geheimen Informationen er enthält. Es gibt noch eine weitere Kategorie von Befugnissen, die zu berücksichtigen ist: welche Werkzeuge und Hilfsschnittstellen er bei der Ausführung seiner Aufgaben aufrufen kann.

Dies ist von Bedeutung, da ein Agent über mehr tatsächliche Macht verfügen kann, als seine Dateisystem- und Netzwerksteuerungen vermuten lassen, wenn er privilegierte Hilfsprogramme auf demselben Rechner auslösen kann. Ein Shell-Befehl, der mit Docker kommunizieren kann, ein mit Schlüsseln geladener SSH-Agent, eine Datenbank, die auf localhost lauscht, ein Browser-Debug-Port oder ein MCP-Server mit weitreichenden Berechtigungen – all dies kann zu Umgehungsmöglichkeiten für eine ansonsten sorgfältig konfigurierte Umgebung werden.

Bei der Einrichtung persönlicher Agenten würde ich dies als einen kombinierten Kontrollbereich mit zwei praktischen Regeln behandeln.

Erstens: Beschränken Sie den Ausführungsumfang. Der Agent sollte nur eine kleine Auswahl an Befehlen ausführen können, die für die jeweilige Aufgabe tatsächlich nützlich sind: Suchen, Vergleichen, Erstellen, Testen, eventuell Lint. Je allgemeiner der von Ihnen gewährte Shell-Zugriff ist, desto mehr Möglichkeiten hat der Agent, einen Fehler oder eine Eingabeaufforderungs-Injektion in tatsächliche Nebenwirkungen umzuwandeln.

Zweitens: Entfernen Sie die lokalen Zugriffsrechte. Wenn der Agent den Docker-Socket, Ihren SSH-Agenten, lokale Administrator-Tools, Ports für die Browser-Automatisierung oder den Datenbankzugriff nicht benötigt, sollten diese Schnittstellen aus seiner Umgebung heraus schlichtweg nicht erreichbar sein. Andernfalls könnten Sie glauben, den Agenten eingeschränkt zu haben, da sein Dateisystem und sein Netzwerk kontrolliert werden, während er in Wirklichkeit immer noch über eine Hintertür zu weitaus leistungsfähigeren Funktionen verfügt.

Diese Kontrollen sind in einer privaten Umgebung in der Regel weniger aufwendig als Dateisystem- oder Netzwerkkontrollen, doch sie sind aus demselben Grund von Bedeutung: Sie legen fest, was der Agent tatsächlich tun kann, und nicht nur, welche Dateien er sehen kann.

In einer Docker-Umgebung lassen sich beide Regeln direkt in Flags für den Befehl „ docker run “ umsetzen:

# Partial example: filesystem and network controls omitted for brevity
docker run --rm -it \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --user agent:agent \
  my-agent-image
  # Note: /var/run/docker.sock and $SSH_AUTH_SOCK are intentionally not mounted

Es ist wichtig zu wissen, dass ein standardmäßiger Docker-Lauf sehr freizügig ist. Er gewährt jedem im Container ausgeführten Prozess die Möglichkeit, Vorgänge auf dem Host zu steuern. Sie müssen diese Berechtigung ausdrücklich entfernen. --cap-drop ALL deaktiviert Linux-Funktionen, die für Code- und Textaufgaben nicht benötigt werden, die jedoch von einem kompromittierten oder fehlerhaft funktionierenden Agenten missbraucht werden könnten. Hier einige konkrete Beispiele für Linux-Funktionen, die bei einem standardmäßigen Docker-Lauf aktiviert sind:

Protokollierung an Vertrauensgrenzen

All diese Kontrollmechanismen sind hilfreich, da sie die Möglichkeiten einschränken, was schiefgehen kann. Sie geben jedoch keinen Aufschluss darüber, was tatsächlich geschehen ist. Jeder Kontrollpunkt – das Dateisystem des Containers, die Netzwerk-Ausgangsschicht und das API-Gateway – dient zudem als Ort zur Protokollierung: Was der Agent versucht hat, was zugelassen wurde und was blockiert wurde. Dies erfüllt zwei Zwecke.

Zunächst einmal geht es darum, zu verstehen, was tatsächlich geschehen ist. Agenten verhalten sich nicht immer so, wie man es erwartet, und wenn das Ergebnis falsch oder überraschend ausfällt, möchte man im Nachhinein nachvollziehen können, was der Agent tatsächlich versucht hat. Ohne diese Einsicht bleibt einem nichts anderes übrig, als zu rätseln, ob es sich um eine schlechte Eingabeanweisung, ein Fehlverhalten des Tools oder etwas noch Besorgniserregenderes handelte.

Zweitens: Der schrittweise Aufbau von Vertrauen. Wenn Sie über ein Dutzend Sitzungen hinweg feststellen, dass der Agent genau das getan hat, was Sie erwartet haben, beginnen Sie, ihm mehr zu vertrauen. Und wenn etwas ungewöhnlich erscheint – wie beispielsweise eine Netzwerkanfrage, die Sie nicht erkennen –, fällt es Ihnen auf, anstatt dass Sie es völlig übersehen.

Der technische Blogbeitrag von GitHub zur Sicherheit ihres agentenbasierten Workflows ist hier lesenswert. Ihre Architektur überwacht jede Vertrauensgrenze: Sie behandeln die Frage „Was hat der Agent an dieser Grenze versucht?“ als vorrangiges Protokollierungsanliegen und nicht als nachträglichen Einfall. Dasselbe Prinzip gilt auch für einen persönlichen Agenten, auch wenn der Umfang ein anderer ist.

In der Praxis bedeutet dies für eine private Installation:

Alles zusammenfassen

Die Recherchen zu all diesen Themen für diesen Artikel haben mir viel über Agenten im Allgemeinen und deren Herangehensweise an das Thema Sicherheit vermittelt. Mir ist dabei auch bewusst geworden, dass all die Aufregung um OpenClaw auch für jeden anderen Agenten gilt, den Sie auf Ihrem Host ausführen. Ich vermute, der große Unterschied liegt darin, wie viel Vertrauen Sie in die Unternehmen setzen, die diese Agenten entwickeln, im Vergleich zu der Person, die OpenClaw entwickelt hat. Natürlich bietet OpenClaw Funktionen, über die andere KI-Agenten nicht verfügen, was es naturgemäß weniger sicher macht. Dennoch ist es gut, sich bewusst zu sein, dass jeder Agent, den Sie ausführen, Zugriff mit hohen Berechtigungen auf Ihren Host hat, auch wenn es nicht so scheint.

Für meine persönliche Konfiguration werde ich OpenClaw in einem Container einsetzen und alle bisher vorgestellten Kontrollmaßnahmen anwenden, um dann zu sehen, wie weit wir damit kommen. Zumindest gibt mir das die Gewissheit, dass der Agent keine Aktionen ausführt, um die ich ihn nicht gebeten habe. Und dank der Protokollierung werde ich zudem nachvollziehen können, was er tatsächlich versucht hat, welche Daten über das Netzwerk übertragen wurden und auf welche Dateien er zugegriffen hat. Diese Transparenz ist es, die dafür sorgt, dass sich die Konfiguration überschaubar anfühlt und nicht nur auf Hoffnung beruht.