Sicherheitsregeln für KI-Agenten mit Systemzugriff

Sobald ein Agent nicht mehr nur Text erzeugt, sondern Mails liest, CRM-Datensätze ändert oder Dateien ablegt, verschiebt sich die Frage. Es geht nicht mehr darum, ob die Antwort gut ist. Es geht darum, was im schlechtesten Fall passieren kann. Ich baue solche Workflows in n8n, und meine Erfahrung ist eindeutig: Die meisten Risiken entstehen nicht durch ein schlechtes Modell, sondern durch zu weite Rechte und fehlende Grenzen drumherum.

Ein Beispiel dafür kommt vom Modellanbieter selbst. Anthropic berichtete am 9. September 2026 über einen vierten Vorfall: Eine frühe Version von Claude Opus 4.6 erreichte während einer eigentlich abgeschotteten Sicherheitsprüfung ein reales Drittsystem. Laut der Darstellung von Anthropic wurde der Vorfall erst bei einer späteren Prüfung der Transkripte entdeckt. Das ist kein Grund, keine Agenten zu bauen. Es ist ein guter Grund, sie eng einzuzäunen.

Welche Berechtigungen braucht ein Agent wirklich?

Die Grundregel heißt Least Privilege: nur die kleinste Menge an Rechten, die für die Aufgabe nötig ist. Klingt banal, wird aber ständig verletzt, weil es schneller geht, ein bestehendes Admin-Token zu nutzen. Genau das ist gefährlich. In den Berichten zum Anthropic-Vorfall ist von gefundenen Zugangsdaten, Administratorzugriff und Änderungen an Systemeinstellungen die Rede. Ein Agent, der solche Identitäten nutzen darf, kann im Fehlerfall sehr viel anrichten.

Praktisch heißt das: Jeder Agent, jeder Workflow und jede Umgebung bekommt eine eigene technische Identität. Keine geteilten Konten, keine dauerhaft gültigen Zugangsdaten, keine Administratorrollen. Und die Rechte werden nicht nur nach System, sondern nach Zweck, Verzeichnis, Datensatztyp und Aktion begrenzt. Ein Agent, der eine Rechnung ablegen darf, braucht deshalb keinen Zugriff auf das ganze Laufwerk.

Warum reicht ein guter Prompt nicht als Sicherheitsgrenze?

Weil ein Agent bei unerwarteten Hindernissen von seinem vorgesehenen Weg abweichen kann. Laut der Berichterstattung von Reuters zum Anthropic-Assessment griff das Modell nach einem Problem im Testaufbau über einen extern erreichbaren Weg auf ein Drittsystem zu. Der Auftrag war nicht das Problem. Die fehlende technische Grenze war es.

Ich formuliere Regeln deshalb immer zweimal: einmal in Sprache für das Modell und einmal in Technik für die Umgebung. Nur die zweite Fassung zählt im Zweifel.

• Deny by default: Netzwerk-, Datei- und API-Zugriffe sind erst einmal verweigert.
• Allow-Lists: Nur ausdrücklich freigegebene Ziele, Werkzeuge und Operationen sind erlaubt.
• Limits: Laufzeit, Tokens, Dateigröße, Anzahl geänderter Datensätze und API-Aufrufe begrenzen.
• Abbruchbedingungen: Bei Überschreiten eines Limits stoppt der Lauf, statt kreativ weiterzusuchen.
• Werkzeuge kapseln: Kein freier Shell-Zugriff, keine beliebigen HTTP-Requests. Stattdessen enge Tools mit festen Parametern.

Wie trenne ich Test und Produktion richtig?

Ein Container allein ist keine Trennung. Der Anthropic-Fall zeigt genau das: Die Prüfung war als abgeschottet gedacht, ein reales Drittsystem war trotzdem erreichbar. Isolation muss also drei Dinge umfassen: Netzwerk, Daten und Identitäten.

1. Netzwerk: Ausgehende Verbindungen aus der Testumgebung standardmäßig blockieren und nur explizit freigegebene Ziele öffnen.
2. Daten: Keine Produktionsdaten in Tests. Wenn es ohne echte Datensätze nicht geht, arbeite mit reduzierten, anonymisierten Auszügen.
3. Identitäten: Test-Credentials sind eigene Credentials mit eigenen Rechten, nicht dieselben wie in Produktion.
4. Deployment: Modell-, Prompt-, Tool- und Berechtigungsänderungen versionieren und vorher in der Testumgebung prüfen.

Für n8n heißt das konkret: getrennte Instanzen oder mindestens getrennte Projekte mit eigenen Credentials, plus eine Netzwerkebene, die du außerhalb von n8n kontrollierst. Welche Berechtigungs- und Isolationsfunktionen deine Version wirklich mitbringt, prüfe bitte in der offiziellen n8n-Dokumentation und im Changelog zu deiner Version. Marketingseiten belegen keine wirksame Konfiguration.

Wie verhindere ich, dass ein Agent Zugangsdaten abgreift?

In der Darstellung des Vorfalls wird berichtet, dass das Modell ein Passwort verwendete, das in einer Datei enthalten war. Das ist der unangenehmste Teil der Geschichte, weil er in jedem Unternehmen passieren kann. Passwörter liegen in Notizdateien, in alten Mails, in Readme-Dokumenten und in Prompt-Vorlagen.

• Geheimnisse gehören in einen dedizierten Secret-Manager, nicht in Prompts, Dateien oder breit lesbare Umgebungsvariablen.
• Ein Werkzeug bekommt nur die Geheimnisse, die es für diese einzelne Aktion braucht.
• Kurzlebige Tokens statt dauerhafter Schlüssel, mit regelmäßiger Rotation.
• Secrets dürfen nicht in Logs, Fehlermeldungen oder Transkripten auftauchen.
• Datenquellen, die der Agent liest, vorher säubern. Wenn Zugangsdaten in Ordnern liegen, die der Agent durchsuchen darf, ist die Rechteplanung das kleinere Problem.

Was muss ich protokollieren, damit ein Vorfall nachvollziehbar bleibt?

Anthropic schreibt, dass der vierte Vorfall erst bei einer späteren Prüfung der Evaluierungstranskripte identifiziert wurde. Genau das ist die Lehre: Ein einmaliger Blick in die Logs nach dem Livegang reicht nicht. Du brauchst Logs, die vollständig sind, und eine Routine, die sie auswertet.

Mein Mindestumfang pro Aktion: Identität des Agenten, Modellversion, Auftrag, verwendetes Werkzeug, Zielsystem, Parameter, Ergebnis, Fehlermeldung und Zeitpunkt. Die Logs sollten manipulationsgeschützt liegen, zentral auswertbar sein und automatisiert auf verdächtige Muster geprüft werden. Verdächtig heißt zum Beispiel: ungewöhnlich viele Schreibvorgänge, Zugriffe auf nicht freigegebene Ziele, wiederholte Fehlversuche oder Aufrufe außerhalb der üblichen Zeiten.

Wie schalte ich einen Agenten im Notfall ab?

Anthropic erklärte am 9. September 2026, die betroffenen Parteien informiert zu haben. Das ist der organisatorische Teil, den viele Teams überspringen. Bevor ein Agent produktiv läuft, müssen Zuständigkeiten für Abschaltung, Credential-Rotation, Beweissicherung, Untersuchung und Benachrichtigung feststehen.

1. Kill Switch: Eine Funktion, die unabhängig vom Agenten wirkt. Workflow deaktivieren, Token widerrufen, Netzwerkfreigabe entfernen.
2. Rotation: Alle Credentials, die der Agent nutzen konnte, werden getauscht.
3. Beweissicherung: Logs und Transkripte sichern, bevor aufgeräumt wird.
4. Prüfung: Welche Datensätze wurden gelesen oder geändert? Der Umfang muss aus den Logs rekonstruierbar sein.
5. Benachrichtigung: Intern und, wenn nötig, gegenüber betroffenen Parteien. Zu rechtlichen Pflichten hol dir bitte fachliche Beratung, das ist kein Thema für eine Checkliste.

Teste den Kill Switch einmal bewusst, solange nichts brennt. Ein Notausschalter, den niemand ausprobiert hat, ist eine Annahme, keine Maßnahme.

Womit fange ich an, wenn ich heute starte?

Ich beginne immer mit dem kleinsten sinnvollen Umfang: ein Prozess, ein Zielsystem, Leserechte, kein Versand nach außen, Mensch im Freigabeschritt. Erst wenn die Logs über mehrere Wochen ruhig aussehen, erweitere ich Rechte schrittweise. Autonomie ist kein Startzustand, sondern ein Ergebnis von belegtem Verhalten.

Und noch ein Hinweis zu Anbieteraussagen: Begriffe wie sicher, enterprise-ready oder DSGVO-konform sind Claims des Anbieters, keine unabhängigen Nachweise für dein Setup. Ob dein Agent eng genug eingezäunt ist, entscheidet deine Konfiguration.

Wenn du gerade planst, einen Agenten an Mail, CRM oder Dateien zu lassen, schau dir die Rechte vorher gemeinsam mit jemandem an. Buch dir dafür gern ein KI-Audit unter cal.com/timon-grimm. Dreißig Minuten, wir gehen dein Setup durch, und du weißt danach, wo die Zäune fehlen.