Was KI-Agenten selbst entscheiden dürfen – und wann ich gefragt werden will

Ein KI-Agent kann Dateien lesen, Programme starten und Änderungen vorbereiten. Mit den passenden Rechten kann er auch Daten löschen, Geld ausgeben oder etwas veröffentlichen. Die Frage ist also nicht nur, was er kann, sondern auch, was er in diesem Auftrag darf.

Ich arbeite mit Agenten auf mehreren Rechnern. Daraus ist eine einfache Regel gewachsen: Je schwerer die Folgen rückgängig zu machen sind, desto wichtiger werden enge Berechtigungen und eine bewusste Entscheidung. Der folgende Ablauf ist meine Arbeitsweise und ein Ausgangspunkt für eigene Regeln – kein allgemeiner Sicherheitsnachweis.

Eine Frage, bevor der Agent losläuft

Stell dir vor, ein Rechner hat wenig Speicherplatz. Ein Agent findet einen großen Cache und schlägt vor, ihn zu entfernen. Das klingt harmlos. Ob es das ist, hängt davon ab, wem die Daten gehören, was der Cache enthält und ob gerade ein Build darauf zugreift.

Auf meinem Leitstand für sechs Rechner habe ich deshalb Vorschlag und Ausführung getrennt. Die Agenten melden, was sie gefunden haben. Ausgeführt werden nur vorgesehene Befehle, die zur Rolle des Rechners passen und die ich freigegeben habe. Eine Freigabe bezieht sich auf einen konkreten Vorschlag und eine Antwort.

Das löst nicht jedes Sicherheitsproblem. Im Leitstand habe ich beispielsweise auch dokumentiert, dass ein offener Einrichtungslink für einen neuen Passkey ein Risiko darstellt. Ein Schutz ist nur so gut wie seine Grenzen und seine tatsächliche Umsetzung.

Vier Stufen für die Praxis

Die passende Grenze hängt vom Auftrag ab. Für einen ersten Überblick hilft mir diese Einteilung:

„Lokal“ heißt dabei nicht automatisch „ungefährlich“: Eine lokale Datei kann die einzige Kopie sein oder gerade von einem anderen Programm gebraucht werden. Umgekehrt kann das Lesen einer Datei vertrauliche Informationen offenlegen. Entscheidend sind Wirkung, Daten und Berechtigung – nicht nur das Werkzeug.

Was eine brauchbare Freigabe enthalten sollte

Ein einfaches „Darf ich aufräumen?“ reicht mir nicht. Ich möchte vorher wissen:

1. Was genau? Welcher Rechner, welcher Ordner oder welcher Dienst ist betroffen?
2. Warum? Welches Problem soll die Handlung lösen?
3. Welche Folgen? Was wird verändert oder gelöscht, welche Kosten können entstehen?
4. Wie geprüft? Welche Informationen stützen den Vorschlag, was ist noch unbekannt?
5. Wie zurück? Gibt es eine Sicherung oder einen anderen nachvollziehbaren Rückweg?

Ein Vorschlag könnte lauten: „Der Build-Cache auf Rechner A belegt viel Platz. Ich schlage vor, nur diesen Cache zu entfernen. Ein laufender Build könnte betroffen sein; ich prüfe vorher aktive Prozesse. Eine Wiederherstellung ist durch erneutes Erzeugen möglich, kann aber Zeit kosten.“ Erst mit echten Befunden wird daraus eine Entscheidungsvorlage; die Angaben hier sind ein Beispiel.

Der Agent braucht passende Rechte – nicht nur gute Anweisungen

Eine Anleitung wie „Bitte keine Geheimnisse lesen“ hilft bei der Zusammenarbeit. Sie ersetzt keine Zugriffskontrolle. Wenn ein Agent technisch Zugriff auf produktive Schlüssel, ein Postfach oder eine Zahlungsfunktion hat, kann eine fehlerhafte Ausführung dort Folgen haben.

Deshalb lohnt es sich, für den konkreten Auftrag zu prüfen:

• Welche Dateien und Dienste muss der Agent tatsächlich erreichen?
• Kann er zunächst lesend oder in einer getrennten Arbeitsumgebung arbeiten?
• Welche Aktionen sollten technische Berechtigungen oder gesonderte Freigaben begrenzen?
• Wo werden Ergebnisse und Fehlversuche nachvollziehbar festgehalten, ohne Schlüssel oder personenbezogene Daten unnötig zu protokollieren?
• Wer prüft das Ergebnis, und wie wird eine Änderung zurückgenommen?

Wie ich Zugangsdaten grundsätzlich behandle, steht im Beitrag KI im Betrieb: API-Schlüssel und Passwörter sicher halten.

Ein grünes Ergebnis ist noch keine Wirkung

Wenn der Agent meldet „erledigt“, schaue ich nach dem passenden Beleg. Bei einem Text kann das die gespeicherte Datei sein. Bei einem Programm ein geeigneter Test. Bei einer Website die Darstellung in der vorgesehenen Umgebung. Ein erfolgreicher Build zeigt beispielsweise, dass der Build lief; er beweist nicht, dass eine echte Kundennachricht zugestellt wurde.

Auch ein Freigabeknopf ist kein Beweis, dass ein System sicher ist. Dafür müsste man unter anderem Berechtigungen, Umsetzung, Umgehungsmöglichkeiten und Wiederherstellung prüfen. Der Aufwand hängt davon ab, wie groß ein möglicher Schaden wäre.

Checkliste für den ersten eigenen Auftrag

• Das Ziel und die erlaubten Dateien oder Dienste in einem Satz festhalten.
• Lesezugriff, lokale Vorbereitung und externe Änderungen unterscheiden.
• Geheimnisse und personenbezogene Daten auf das nötige Maß begrenzen.
• Für Löschen, Veröffentlichung, Kosten und produktive Daten einen konkreten Freigabepunkt festlegen.
• Vor jeder Freigabe betroffene Ressourcen, Folgen und Rückweg ansehen.
• Nach der Aktion das Ergebnis am passenden Ort prüfen und offene Punkte festhalten.

KI-Agenten können viel Arbeit abnehmen. Die Verantwortung dafür, welchen Auftrag sie bekommen und welche Wirkung sie haben dürfen, bleibt bei uns. Für mich wird das nicht durch möglichst viele Rückfragen gelöst, sondern durch klare Grenzen und überprüfbare Ergebnisse.

Weiterlesen: Sechs Rechner, ein Leitstand · Claude Code und Codex zusammen nutzen.