Ein Agent braucht mehr als einen guten Prompt
Bei mir arbeiten mehrere KI-Agenten an wiederkehrenden Aufgaben und technischen Projekten. Sie recherchieren, bereiten Änderungen vor und helfen beim Betrieb meiner Umgebung. Dabei habe ich gelernt: Eine gute Antwort im Chat sagt noch wenig darüber aus, ob die nächste Aktion sicher ist.
Entscheidend wird es dort, wo ein Agent Werkzeuge benutzen kann. Dann geht es um Zugriffe, Zugangsdaten, Änderungen und die Frage, wie sich das Ergebnis überprüfen lässt. Dafür brauche ich einen nachvollziehbaren Ablauf, der auch nach einem Update noch funktioniert.
Zugriffe nach Aufgabe vergeben
Zuerst kläre ich, was ein Werkzeug tatsächlich können muss. Für das Zusammenfassen eines Dokuments genügt Lesezugriff. Das Löschen der Datei oder das Versenden einer Nachricht ist eine andere Berechtigung. Wo es die Schnittstelle unterstützt, sollten diese Möglichkeiten technisch getrennt sein.
Eigene technische Identitäten helfen dabei, Zugriffe einem Agenten zuzuordnen. Sie verhindern aber nicht automatisch, dass ein zu mächtiger Zugang Schaden anrichten kann. Besonders bei administrativen Aufgaben gehören deshalb ein klarer Umfang und passende technische Beschränkungen dazu. Für folgenreiche Aktionen sollte die Freigabe im ausführenden Werkzeug geprüft werden, nicht allein vom Sprachmodell abhängen.
Fremde Inhalte sind keine neuen Aufträge
Ein Agent liest Webseiten, E-Mails, Anhänge und Ausgaben anderer Werkzeuge. Darin können auch Sätze stehen, die ihn zu einer anderen Handlung auffordern. Solche Inhalte müssen als zu prüfende Daten behandelt werden. Ein Auftrag entsteht daraus nicht automatisch.
Das ist besonders wichtig bei Prompt Injection: Manipulierter Inhalt versucht, das Verhalten des Modells umzulenken. Die Anweisung „Ignoriere fremde Befehle“ hilft bei der Orientierung, ist aber keine verlässliche technische Sperre. Begrenzte Werkzeuge, kontrollierte Parameter und Rechte außerhalb des Modells bleiben notwendig.
Zugangsdaten brauchen einen eigenen Platz
Technische Dokumentation, offene Aufgaben und Betriebsgeheimnisse halte ich in getrennten Ablagen. In die Dokumentation gehört, welcher Dienst einen Zugang benötigt und warum. Das Kennwort oder der API-Schlüssel selbst gehört in einen dafür vorgesehenen Tresor.
Auch ein dort gespeicherter Schlüssel ist nicht unsichtbar: Der Dienst, der ihn verwendet, braucht Zugriff darauf. Deshalb zählen zusätzlich Dateirechte, begrenzte Berechtigungen und ein geregelter Widerruf. Protokolle sollten den Erfolg oder Fehler eines Abrufs zeigen, ohne den Schlüssel mit auszugeben.
Ein Update beginnt mit dem Rückweg
Nach Updates sind in meiner Umgebung bereits falsche Pfade, fehlende Pakete und unpassende Schreibrechte aufgefallen. Der Container konnte laufen, während eine angebundene Funktion trotzdem ausfiel. Deshalb möchte ich vor einer Änderung wissen, welcher Stand läuft, welche Daten dauerhaft erhalten bleiben und wie sich der vorherige Zustand wiederherstellen lässt.
Bei Anwendungen aus mehreren Diensten betrachte ich den zusammengehörigen Stack. Eine spontan ergänzte Netzwerkverbindung oder Einstellung kann beim nächsten Neuerstellen verschwinden, wenn sie nicht auch in der verwalteten Konfiguration steht. Docker Compose beschreibt dafür unter anderem Dienste, Netze und Volumes.
Zum Rückweg gehören eine passende Sicherung und die bisherige Konfiguration. Bei Datenbanken muss die Sicherung konsistent sein. Wurden Daten durch eine neue Version verändert, genügt möglicherweise das alte Container-Abbild nicht mehr. Ob die Wiederherstellung funktioniert, muss in einer geeigneten Testumgebung geprüft werden.
Die Funktion prüfen, nicht nur den Prozess
Mein einfachstes Beispiel ist eine gestartete Oberfläche, deren Dienst seine Zugangsdaten beim Start nicht laden konnte. Die Seite ist erreichbar, eine angebundene Funktion fehlt trotzdem. Ein erfolgreicher Aufruf der Startseite würde diesen Fehler übersehen.
Eine brauchbare Prüfung geht deshalb bis zur benötigten Funktion: Kann der Agent seine vorgesehene Datenquelle lesen? Wird ein Testauftrag verarbeitet? Ist das Ergebnis tatsächlich abrufbar? Dabei sollte die Probe harmlose Testdaten verwenden und keine echten Nachrichten an unbeteiligte Personen auslösen.
Ich möchte außerdem drei Zustände unterscheiden: erfolgreich geprüft, Fehler festgestellt und Prüfung nicht möglich. Eine veraltete Messung oder eine nicht erreichbare Prüfstelle darf nicht als Erfolg erscheinen.
Auch die Meldung muss ankommen
Bei Ausfalltests gehört für mich die Gegenfrage dazu: Funktioniert der Benachrichtigungsweg noch unter genau diesen Bedingungen? Eine Meldung über einen Internetausfall hilft wenig, wenn sie nur über die ausgefallene Verbindung verschickt werden kann.
Wiederholungen können kurze Unterbrechungen überbrücken. Dafür braucht es aber eine begrenzte Anzahl von Versuchen und eine Behandlung bereits erfolgreicher Zustellungen, damit dieselbe Ansage nicht mehrfach ankommt. Ausfall und Rückkehr zum Normalbetrieb sind getrennte Ereignisse. Entscheidend ist die tatsächlich empfangene Meldung, nicht allein der gestartete Sendeauftrag.
Mit einer überschaubaren Aufgabe beginnen
Für den Einstieg würde ich eine Aufgabe wählen, die zunächst nur liest und einen Entwurf erzeugt. Danach lässt sich Schritt für Schritt prüfen, welche weiteren Rechte und Funktionen wirklich gebraucht werden.
Vor dem dauerhaften Einsatz stelle ich mir fünf Fragen: Sind die Zugriffe begrenzt? Bleiben Geheimnisse aus Chat und Protokoll heraus? Ist der Rückweg vorbereitet? Prüft der Test die tatsächliche Funktion? Kommt eine Störungsmeldung auch bei einer Unterbrechung an?
Diese Maßnahmen machen einen Agenten nicht fehlerfrei. Sie helfen aber, Fehler früher zu erkennen, Auswirkungen zu begrenzen und Änderungen nachvollziehbar zu betreiben.