Bevor ein Agent Produktionsdaten berührt: Die Checklist für Sicherheitsvorkehrungen
Das Risiko besteht nicht darin, dass das Modell etwas Falsches sagt. Es besteht darin, dass der Agent etwas Falsches tut – mit Berechtigungen, in einem System, das kein Undo bietet.
Warum Agenten eine andere Risikokategorie darstellen
Ein Chatbot, der halluciniert, produziert einen falschen Satz. Ein Agent mit Werkzeugzugriff produziert eine Nebenwirkung: Ein Datensatz wird aktualisiert, eine E-Mail wird gesendet, eine Zeile wird gelöscht. Die Fehlerfläche ist nicht länger die Qualität des Textes, sondern der Blast-Radius der Aktionen. Deshalb sehen die Kontrollen, die hier zählen, eher wie Infrastruktursicherheit aus als wie Prompt-Engineering.
Prüfung eins: was kann es tatsächlich erreichen
Schreiben Sie alle Werkzeuge auf, die der Agent aufrufen kann, und was jedes davon mit dem Zustand machen kann. Die meisten Teams entdecken an diesem Schritt, dass ein read-only-Helfer ein Credential mit etwas teilt, das schreibt. Begrenzen Sie Credentials pro Werkzeug, nicht pro Agent, und bevorzugen Sie Token, die ablaufen.
Prüfung zwei: gibt es ein Tor für irreversible Aktionen
Klassifizieren Sie jede Aktion als reversibel, reversibel-mit-Aufwand oder irreversibel. Alles in der dritten Kategorie benötigt einen menschlichen Bestätigungsschritt, der nicht durch eine clevere Anweisung im Inhalt umgangen werden kann, den der Agent liest. Beachten Sie, dass die nicht vertrauenswürdige Eingabe nicht nur der Benutzerprompt ist – es sind auch die Dokumente, Webseiten und Werkzeugergebnisse, die der Agent verbraucht.
Prüfung drei: können Sie nachvollziehen, was passiert ist
Sie benötigen eine Spur jeder Werkzeugaufruf mit seinen Argumenten und Ergebnis, die lange genug aufbewahrt wird, um ein Ereignis zu rekonstruieren. Wenn etwas schiefgeht, ist die Frage nie, was das Modell gesagt hat, sondern was es getan hat und in welcher Reihenfolge.
Prüfung vier: gibt es ein Budget
Begrenzen Sie Schritte, Token, Wanduhrzeit und Geld pro Lauf. Ausufernde Schleifen sind das häufigste Agenten-Ereignis, und sie sind billig zu verhindern. Zeigen Sie die Begrenzung im Produkt an, damit der Benutzer die Begrenzung sieht, anstatt ein Hang.
Prüfung fünf: was passiert bei fehlerhafter Ausgabe
Definieren Sie den Fehlerpfad, bevor Sie ihn benötigen. Wenn der Agent einen unparsablen Werkzeugaufruf zurückgibt, versucht er es erneut, fragt den Benutzer oder stoppt? Leise für immer wiederholen und leise aufgeben sind beide schlechte Standardwerte; wählen Sie einen absichtlich und protokollieren Sie ihn.
Prüfung sechs: kann eine Person es abschalten
Es muss einen einzelnen Schalter geben, der alle Agentenaktivitäten ohne eine Bereitstellung stoppt. Dies klingt offensichtlich und fehlt häufig, weil Agenten tendenziell als Funktionen innerhalb anderer Systeme bereitgestellt werden, anstatt als ein Service mit seinem eigenen Kill-Schalter.
Was daraus folgt
- Das Risiko eines Agents ist der Radius seiner Aktionen, nicht die Korrektheit des Textes
- Berechtigungen pro Werkzeug beschränken und ein nicht umgehbares Tor für unumkehrbare Aktionen einrichten
- Aufrufspuren von Werkzeugen mit Argumenten und Ergebnissen speichern – Vorfälle werden aus Aktionen und nicht aus Ausgaben rekonstruiert
- Schritte, Token, Zeit und Geld pro Durchlauf begrenzen und einen Schalter bauen, der alles stoppt