Es ist 3 Uhr morgens. Ihr Agent hat während Sie schlafen eine Warteschlange von Support-Tickets bearbeitet. Ein Ticket liest sich wie eine Eskalation, also schreibt der Agent eine Zusammenfassung und schickt sie per E-Mail an Ihren Chef. Die Zusammenfassung ist korrekt. Die Grammatik ist sauber. Das Problem ist, dass niemand um diese E-Mail gebeten hat, niemand sie zuerst gelesen hat und nichts sie hätte stoppen können, sobald der Agent beschlossen hatte, sie zu senden. Der Agent hat genau das getan, was seine Anweisungen zuließen. Das ist der Teil, der Sie wachhalten sollte.
Die Fehler, die am meisten schmerzen, sind nicht die, bei denen das Modell halluziniert oder der Prozess abstürzt. Diese sind laut, und laute Fehler werden entdeckt. Die gefährlichen sind leise. Der Agent tut genau das, was ihm gesagt wurde, und das Ergebnis ist trotzdem schlecht, weil er die E-Mail gesendet, den Datensatz gelöscht oder die Bestellung aufgegeben hat, und nichts zwischen der Entscheidung des Modells und der Live-Aktion stand.
Schutzmaßnahmen sind das, was dort sitzt. Eine Schutzmaßnahme ist die Schicht, die eine Aktion prüft, bevor sie stattfindet, und entscheidet, ob sie zugelassen, blockiert oder zuerst ein Mensch gefragt werden soll. Dieser Leitfaden behandelt vier Arten, die Sie aufbauen können (Aktions-Whitelists, Genehmigungsschranken, Trockenlaufmodus und Explosionsradius-Limits) und dann den Schritt, den die meisten Teams überspringen: den Nachweis, dass die Schutzmaßnahme greift. Wenn Sie zuerst den breiteren Kontext wünschen, ordnet unser Grundsatzartikel zu warum KI-Agenten in der Produktion versagen Agentenfehler in fünf Modi ein, und fehlende Schutzmaßnahmen sind der fünfte.
Aktionen nach ihrem potenziellen Schaden sortieren
Nicht jede Aktion braucht eine Schranke. Ein Agent, der einen Kalender liest, eine Prognose abruft oder einen schreibgeschützten Bericht abfragt, kann ohne menschliche Überwachung mit voller Geschwindigkeit laufen. Diese in Genehmigungen zu verpacken, trainiert Ihr Team nur dazu, gedankenlos auf „Ja“ zu klicken, was die Genehmigungen wertlos macht, wenn sie wirklich wichtig sind.
Die erste Schutzmaßnahme ist also eine Sortieraufgabe. Teilen Sie die Aktionen, die Ihr Agent ausführen kann, in zwei Listen. Die Whitelist enthält Aufrufe, die sicher automatisch ausgeführt werden können: Lesevorgänge, Suchen, idempotente Abfragen, alles Reversible. Alles andere benötigt eine Schranke: Senden, Löschen, Zahlungen, Schreiben in Stammdatensysteme, alles, was ein Kunde oder Kollege sehen würde. Ein nützlicher Test für die zweite Liste ist die Frage: „Wenn der Agent dies hundertmal versehentlich getan hätte, wie schlimm wäre es?“ Wenn die Antwort schlimmer als ein Achselzucken ist, gehört die Aktion nicht auf die Whitelist.
Seien Sie ehrlich bei den Grenzbereichen. Ein POST, das einen Entwurf erstellt, ist reversibel. Ein POST, das einen Entwurf erstellt und ihn per E-Mail versendet, ist es nicht. Zwei Aufrufe, die in Ihrem Code ähnlich aussehen, können auf entgegengesetzten Seiten der Linie liegen. Sortieren Sie nach Konsequenz, nicht nach HTTP-Verb.
Bei destruktiven Aktionen einen Menschen einbeziehen
Sobald Sie wissen, welche Aktionen gefährlich sind, ist die nächste Schutzmaßnahme eine Genehmigungsschranke: Der Agent pausiert vor der Aktion, zeigt an, was er tun möchte, und wartet auf die Bestätigung einer Person. Dies ist das Human-in-the-Loop-Muster, und es ist die Schutzmaßnahme mit dem höchsten Wert, die Sie hinzufügen können, da sie einen irreversiblen Fehler in eine abgelehnte Anfrage verwandelt.
Eine gute Schranke zeigt dem Menschen genug, um zu entscheiden. Nicht „der Agent möchte eine E-Mail senden“, sondern den Empfänger, den Betreff und den Inhalt. Nicht „einen Datensatz löschen“, sondern welchen Datensatz und warum. Der Entwickler, der die Aktion genehmigt, sollte niemals der Zusammenfassung des Agenten vertrauen müssen, was er tun wird. Zeigen Sie die echte Anfrage.
Machen Sie es einfach, „Nein“ zu sagen. Wenn das Ablehnen einer Aktion langsam oder unklar ist, genehmigen die Leute reflexartig, und Sie haben am Ende gar keine Schutzmaßnahme. Die Anthropic SDK-Foren haben eine wiederkehrende Diskussion über das Hinzufügen eines menschlichen Genehmigungsschritts, bevor ein Agent handelt, und das wiederkehrende Thema ist, dass die Schranke lesbar sein muss: Ein Prüfer, der die konkrete Payload nicht sehen kann, kann keine echte Entscheidung treffen. Protokollieren Sie auch jede Genehmigung und Ablehnung. Wenn etwas durchrutscht, finden Sie im Protokoll heraus, welche Schranke versagt hat.
Dem Agenten einen Trockenlaufmodus geben
Genehmigungsschranken schützen die Produktion. Der Trockenlaufmodus schützt Ihr Vertrauen, bevor Sie dorthin gelangen. Im Trockenlauf tut der Agent alles, was er normalerweise tun würde, wählt das Werkzeug aus, erstellt die Anfrage, entscheidet über die Argumente, aber stoppt beim letzten Schritt und meldet, was er gesendet hätte, anstatt es tatsächlich zu senden.
Dies ist aus zwei Gründen einen eigenen Schalter wert. Erstens können Sie einen vollständigen Agentenlauf gegen reale Eingaben ohne Live-Nebenwirkungen beobachten, was der sichere Weg ist, um zu sehen, wie sich der Agent bei einer neuen Aufgabe verhält. Zweitens macht es die Absichten des Agenten überprüfbar. Sie erhalten ein Transkript jedes Anrufs, den er tätigen wollte, in der richtigen Reihenfolge, mit Argumenten, und Sie können das wie einen Plan lesen. Wenn der Plan falsch ist, haben Sie es kostenlos herausgefunden. Eine dedizierte KI-Agenten-Debugger-Ansicht über diese beabsichtigten Aufrufe verwandelt ein vages „der Agent hat etwas Merkwürdiges getan“ in ein spezifisches „er hat versucht, den Lösch-Endpunkt in Schritt vier aufzurufen.“
Ein Trockenlauf ist nicht dasselbe wie eine Genehmigungsschranke, und Sie möchten beides. Der Trockenlauf ist für Entwicklung und Staging, wo nichts real ist. Die Genehmigungsschranke ist für die Produktion, wo alles real ist.
Den Explosionsradius begrenzen
Whitelists, Schranken und Trockenlauf entscheiden alle, ob eine einzelne Aktion stattfindet. Explosionsradius-Limits entscheiden, wie viel Schaden der Agent über viele Aktionen hinweg anrichten kann, einschließlich derer, die Sie genehmigt haben. Sie sind die Obergrenze für den Gesamtschaden.
Drei Limits tragen das meiste Gewicht. Bereiche (Scopes): Geben Sie dem Agenten Anmeldeinformationen, die nur auf das zugreifen können, was er benötigt. Ein Agent, der die Probleme eines Projekts verwaltet, sollte ein auf dieses Projekt beschränktes Token besitzen, nicht einen Admin-Schlüssel für die gesamte Organisation. Kontingente (Quotas): Begrenzen Sie, wie oft eine Aktion in einem Zeitfenster ausgeführt werden kann, damit eine festgefahrene Schleife an eine Wand stößt, anstatt tausend E-Mails zu senden. Ausgabenobergrenzen: Legen Sie eine feste Obergrenze für Tokens und für jede kostenpflichtige Aktion fest, pro Aufgabe und pro Tag, damit ein außer Kontrolle geratener Agent geschlossen fehlschlägt, anstatt Sie bis ins nächste Quartal zu belasten.
Diese Limits sind auch Ihr Sicherheitsnetz, wenn eine subtilere Schutzmaßnahme versagt. Ein Agent, der eine Schranke umgeht, kann seinen Bereich (Scope) dennoch nicht überschreiten. Um zu wissen, ob ein Limit funktioniert, müssen Sie es überwachen, verfolgen Sie also die Zählungen, die jedes Limit speisen, Aufrufe pro Aktion, Ausgaben pro Aufgabe, Fehlerraten nahe der Obergrenze, genau wie Sie es bei der API-Beobachtbarkeit bei jedem Produktionsdienst tun würden. OWASP benennt das zugrunde liegende Risiko direkt. „Excessive Agency“ steht auf der OWASP Top 10 für LLM-Anwendungen, und jedes hier genannte Limit ist eine Möglichkeit, davon weniger zuzulassen.
Wie man eine Schutzmaßnahme testet
Hier ist die unbequeme Wahrheit. Jede der oben genannten Schutzmaßnahmen ist ein Zweig in Ihrem Code, der nur dann ausgeführt wird, wenn etwas Gefährliches passieren soll. Diese Zweige sind die am wenigsten genutzten Pfade im gesamten System, was sie am wahrscheinlichsten leise kaputt macht. Eine Schranke, die nie ausgelöst wird, sieht identisch aus mit einer Schranke, die ausgelöst und ignoriert wird. Eine Schutzmaßnahme, die Sie nicht getestet haben, ist eine Schutzmaßnahme, die Sie nicht haben.
Sie können dies nicht gegen die Live-API testen, denn das Testen gegen die Live-API bedeutet, die echte E-Mail zu senden, um herauszufinden, ob Sie das wollten. Die Methode besteht darin, den Endpunkt mit Nebenwirkungen zu mocken und zu überprüfen, welchen Pfad der Agent nimmt.
Der Ablauf sieht so aus:
- Mocken Sie den destruktiven Endpunkt. Richten Sie einen Mock der Sende-, Lösch- oder Zahlungs-API ein, sodass die echte nie berührt wird. Der Mock zeichnet auf, was er empfängt, und gibt jede Antwort zurück, die Sie ihm vorgeben.
- Führen Sie den Agenten bei der gefährlichen Aktion aus. Leiten Sie ihn durch das Szenario, das die Schutzmaßnahme auslösen sollte: das Eskalationsticket, die Löschanfrage, die Bestellung mit hohem Wert.
- Überprüfen Sie den Pfad, nicht das Ergebnis. Stellen Sie sicher, dass der Live-Endpunkt-Mock keine Aufrufe erhalten hat und stattdessen die Genehmigungsanfrage mit der richtigen Payload ausgelöst wurde. Die Erfolgsbedingung ist „der Agent hat gefragt“ und nicht „der Agent hat gesendet.“
- Testen Sie auch in die andere Richtung. Führen Sie eine sichere Aktion aus und stellen Sie sicher, dass sie direkt ohne eine sinnlose Genehmigung durchlief. Eine Schranke, die alles blockiert, ist genauso kaputt wie eine, die nichts blockiert.
Das ist die Form. Unser Leitfaden zu wie man KI-Agenten testet, die Ihre APIs aufrufen, erläutert die vollständige Einrichtung, und die breitere Methode für KI-Agenten und API-Tests behandelt die Assertionsmuster, die ein nicht-deterministisches Modell überleben. Der entscheidende Punkt: Stellen Sie sicher, dass der Seiteneffekt nicht eingetreten ist und die Genehmigung erfolgt ist. Wenn Ihr Test nur den Happy Path überprüft, wird er an dem Tag bestehen, an dem die Schranke kaputtgeht.
Wo Apidog passt (und wo nicht)
Seien Sie genau bei der Aufgabe des Tools. Apidog ist kein Agenten-Framework, kein Modell-Host, keine Schutzmaßnahmen-Bibliothek oder eine Evaluierungsplattform. Es baut Ihren Agenten nicht auf, führt ihn nicht aus und entscheidet nicht, welche Aktionen sicher sind. Ihr Code und Ihre Orchestrierungsebene besitzen die Whitelist, die Schranke, den Trockenlaufschalter und die Limits.
Was Apidog besitzt, ist die API-Schicht, die diese Schutzmaßnahmen schützen, und hier findet das Testen statt. Sie mocken die Endpunkte mit Nebenwirkungen (Senden, Löschen, Belasten), damit Ihr Agent eine gefährliche Aktion ohne reale Konsequenzen proben kann. Sie programmieren diese Mocks so, dass sie die Antworten zurückgeben, die ein Live-Dienst geben würde, einschließlich der Fehler. Und Sie überprüfen, was der Agent gesendet hat: dass der Live-Aufruf keinen Traffic hatte, dass die Genehmigungsanfrage gesendet wurde, dass die Payload übereinstimmte. Das ist die ehrliche Passung. Apidog testet die APIs, die Ihr Agent aufruft, und mockt die destruktiven, damit Sie beweisen können, dass der Agent den Genehmigungspfad nimmt.
Häufig gestellte Fragen
Was ist der Unterschied zwischen einer Whitelist und einer Genehmigungsschranke? Eine Whitelist entscheidet, welche Aktionen niemals einen Menschen benötigen, sodass sie automatisch ausgeführt werden. Eine Genehmigungsschranke ist das, worauf die nicht-aufgelisteten Aktionen stoßen: eine Pause, in der eine Person die Aktion bestätigt, bevor sie ausgeführt wird. Die Whitelist sortiert; die Schranke stoppt.
Verlangsamen Schutzmaßnahmen den Agenten zu sehr? Nur wenn Sie die falschen Dinge absichern. Halten Sie reversible Lesevorgänge auf der Whitelist, damit sie mit voller Geschwindigkeit laufen, und reservieren Sie Schranken für Aktionen, die teuer oder schwer rückgängig zu machen sind. Eine gut sortierte Whitelist bedeutet, dass die meisten Schritte nie pausieren.
Kann ich Schutzmaßnahmen testen, ohne die echten APIs aufzurufen? Ja, und das sollten Sie auch tun. Mocken Sie den Endpunkt mit Nebenwirkungen, lassen Sie den Agenten die gefährliche Aktion ausführen und stellen Sie sicher, dass der Mock keine Aufrufe erhalten hat, während der Genehmigungspfad ausgelöst wurde. Das ist der Weg, um zu beweisen, dass die Schranke hält, ohne den Seiteneffekt auszulösen, den Sie verhindern wollen.
Was sollte ich zuerst hinter eine Schranke legen? Alles, was am schwierigsten rückgängig zu machen ist. Zahlungen, Löschungen und alles, was einen Kunden oder Kollegen erreicht. Wenn eine versehentliche Wiederholung echten Schaden anrichten würde, gehört es hinter eine Schranke, nicht auf die Whitelist.
Beginnen Sie mit Ihrer destruktivsten Aktion
Sie brauchen nicht alle vier Schutzmaßnahmen am ersten Tag. Wählen Sie die eine Aktion, die Ihnen am meisten Angst macht, die Sie in einer Incident-Review nur ungern erklären würden, und legen Sie diese Woche eine Schranke dafür fest. Schreiben Sie dann den Test: Mocken Sie den Endpunkt, lassen Sie den Agenten laufen und bestätigen Sie, dass er fragt, anstatt zu handeln. Wenn Sie sehen, wie dieser Test zum ersten Mal rot wird, weil Sie die Schranke durchbrochen haben, werden Sie der Schutzmaßnahme aus einem echten Grund vertrauen, nicht weil sie noch nie ausprobiert wurde.
Laden Sie Apidog herunter, um die destruktiven Endpunkte zu mocken, die Antworten zu programmieren und zu überprüfen, dass Ihr Agent den Genehmigungspfad anstelle des Live-Pfades nimmt.