KI-Agenten-Leitplanken: Freigabetore und Schadensbegrenzung

Es ist 3 Uhr morgens. Ihr Agent hat während Sie schlafen eine Warteschlange von Support-Tickets bearbeitet. Ein Ticket wirkt wie eine Eskalation, also erstellt der Agent eine Zusammenfassung und sendet sie per E-Mail an Ihren Chef. Die Zusammenfassung ist korrekt, die Grammatik sauber — aber niemand hat diese E-Mail angefordert, niemand hat sie vor dem Versand geprüft, und nichts konnte den Versand stoppen. Der Agent hat exakt das getan, was seine Anweisungen zuließen. Genau das sollte Sie wachhalten.

Apidog noch heute ausprobieren

Die schmerzhaftesten Fehler sind nicht unbedingt Halluzinationen oder abgestürzte Prozesse. Diese Fehler sind laut und werden meist schnell entdeckt. Gefährlich sind die leisen Fehler: Der Agent führt die vorgesehene Aktion korrekt aus, aber die Aktion selbst war falsch — etwa eine E-Mail senden, einen Datensatz löschen oder eine Bestellung auslösen — und zwischen Modellentscheidung und Live-Aktion gab es keine Kontrolle.

Schutzmaßnahmen sitzen genau an dieser Stelle. Sie prüfen Aktionen vor der Ausführung und entscheiden, ob sie:

• automatisch zugelassen,
• blockiert oder
• zur menschlichen Genehmigung vorgelegt werden.

Dieser Leitfaden zeigt vier praktische Schutzmaßnahmen:

1. Aktions-Whitelists
2. Genehmigungsschranken
3. Trockenlaufmodus
4. Explosionsradius-Limits

Entscheidend ist aber der nächste Schritt: Sie müssen testen, dass diese Schutzmaßnahmen tatsächlich greifen. Für den breiteren Kontext erklärt unser Artikel zu warum KI-Agenten in der Produktion versagen fünf Fehlermodi bei Agenten — fehlende Schutzmaßnahmen sind einer davon.

Aktionen nach ihrem potenziellen Schaden sortieren

Nicht jede Aktion braucht eine Genehmigung. Ein Agent darf normalerweise ohne menschliche Unterbrechung:

• Kalender lesen,
• Prognosen abrufen,
• Suchanfragen ausführen,
• schreibgeschützte Berichte abfragen,
• idempotente Statusabfragen wiederholen.

Wenn Sie jede dieser Aktionen genehmigen lassen, trainieren Sie Ihr Team nur darauf, gedankenlos auf „Ja“ zu klicken. Dann verlieren Genehmigungen ihren Wert, wenn sie wirklich nötig sind.

Erstellen Sie deshalb zwei Listen:

Kategorie	Beispiele	Ausführung
Whitelist	Lesen, Suchen, reversible Entwürfe, idempotente Abfragen	Automatisch
Geschützte Aktionen	Senden, Löschen, Bezahlen, Schreiben in Stammdatensysteme	Schranke oder Blockierung

Sortieren Sie nach Konsequenz, nicht nach HTTP-Methode.

Ein POST, der einen Entwurf erstellt, kann reversibel sein. Ein POST, der einen Entwurf erstellt und ihn per E-Mail versendet, ist es nicht.

const autoAllowedActions = [
  "calendar.read",
  "ticket.search",
  "report.get",
  "draft.create",
];

function requiresApproval(action: string) {
  return !autoAllowedActions.includes(action);
}

Ein brauchbarer Test lautet:

„Wie schlimm wäre es, wenn der Agent diese Aktion versehentlich hundertmal ausführt?“

Wenn die Antwort mehr als ein Achselzucken ist, gehört die Aktion nicht auf die Whitelist.

Bei destruktiven Aktionen einen Menschen einbeziehen

Für riskante Aktionen brauchen Sie eine Genehmigungsschranke. Der Ablauf ist einfach:

1. Der Agent plant eine Aktion.
2. Ihre Anwendung stoppt vor dem Seiteneffekt.
3. Ein Mensch sieht die konkrete Anfrage.
4. Erst nach einer expliziten Genehmigung wird die Aktion ausgeführt.

Das ist das Human-in-the-Loop-Muster. Es verwandelt einen potenziell irreversiblen Fehler in eine ablehnbare Anfrage.

Zeigen Sie Prüfern immer die echte Payload — nicht nur die Zusammenfassung des Agenten.

Schlecht:

Der Agent möchte eine E-Mail senden.

Gut:

{
  "action": "email.send",
  "to": ["[e-mail]"],
  "subject": "Eskalation: Ticket #4821",
  "body": "Zusammenfassung des Tickets ..."
}

Dasselbe gilt für Löschvorgänge:

{
  "action": "customer.delete",
  "customerId": "cus_123",
  "reason": "Vom Agenten als Duplikat erkannt"
}

Der Prüfer darf nicht darauf angewiesen sein, dass die Beschreibung des Agenten korrekt ist. Zeigen Sie die Anfrage, die tatsächlich gesendet würde.

Eine mögliche Implementierung:

type ApprovalRequest = {
  action: string;
  payload: unknown;
  reason: string;
};

async function executeAction(
  action: string,
  payload: unknown,
  approved: boolean
) {
  if (requiresApproval(action) && !approved) {
    return {
      status: "pending_approval",
      approvalRequest: {
        action,
        payload,
        reason: "Aktion kann externe oder irreversible Auswirkungen haben.",
      } satisfies ApprovalRequest,
    };
  }

  return callLiveEndpoint(action, payload);
}

Machen Sie Ablehnungen genauso einfach wie Genehmigungen. Wenn „Nein“ umständlich ist, wird Ihr Team reflexartig zustimmen — und die Schranke ist praktisch wirkungslos.

Die Diskussion zum Hinzufügen eines menschlichen Genehmigungsschritts, bevor ein Agent handelt zeigt ein wiederkehrendes Problem: Ohne lesbare, konkrete Payload kann ein Prüfer keine echte Entscheidung treffen.

Protokollieren Sie deshalb jede Entscheidung:

await auditLog.write({
  action: "email.send",
  decision: "rejected",
  reviewerId: currentUser.id,
  payload,
  timestamp: new Date().toISOString(),
});

So können Sie später nachvollziehen, welche Aktion angefragt, genehmigt oder abgelehnt wurde.

Dem Agenten einen Trockenlaufmodus geben

Eine Genehmigungsschranke schützt die Produktion. Ein Trockenlaufmodus schützt Ihr Vertrauen, bevor Sie in Produktion gehen.

Im Trockenlauf darf der Agent:

• Werkzeuge auswählen,
• Argumente erzeugen,
• API-Anfragen planen,
• seine Schritte ausführen,

aber keine echten Seiteneffekte auslösen. Stattdessen speichern Sie, was der Agent gesendet hätte.

type ExecutionMode = "dry-run" | "live";

async function runTool(
  mode: ExecutionMode,
  action: string,
  payload: unknown
) {
  if (mode === "dry-run") {
    return {
      status: "simulated",
      action,
      payload,
      message: "Keine Live-Anfrage ausgeführt.",
    };
  }

  return callLiveEndpoint(action, payload);
}

Ein Trockenlauf liefert Ihnen ein überprüfbares Transkript:

[
  {
    "step": 1,
    "action": "ticket.get",
    "payload": { "ticketId": "4821" }
  },
  {
    "step": 2,
    "action": "customer.lookup",
    "payload": { "email": "[e-mail]" }
  },
  {
    "step": 3,
    "action": "email.send",
    "payload": {
      "to": ["[e-mail]"],
      "subject": "Eskalation: Ticket #4821"
    }
  }
]

Damit wird aus „Der Agent hat etwas Merkwürdiges getan“ eine konkrete Aussage:

„Der Agent hat in Schritt 3 versucht, den Sende-Endpunkt aufzurufen.“

Eine dedizierte KI-Agenten-Debugger-Ansicht kann diese geplanten Aufrufe sichtbar machen und die Fehlersuche beschleunigen.

Trockenlauf und Genehmigungsschranke sind nicht austauschbar:

• Trockenlauf: Entwicklung und Staging, keine echten Auswirkungen.
• Genehmigungsschranke: Produktion, echte Aktion erst nach Bestätigung.

Sie brauchen normalerweise beides.

Den Explosionsradius begrenzen

Whitelists, Genehmigungsschranken und Trockenläufe entscheiden über einzelne Aktionen. Explosionsradius-Limits begrenzen dagegen den Gesamtschaden über viele Aktionen hinweg — auch dann, wenn einzelne Aktionen zulässig oder sogar genehmigt waren.

Drei Limits tragen den größten Teil der Last:

1. Bereiche und Berechtigungen begrenzen

Geben Sie dem Agenten nur die Anmeldeinformationen, die er wirklich braucht.

Ein Agent, der Issues in einem Projekt verwaltet, sollte ein auf dieses Projekt begrenztes Token erhalten — keinen Admin-Schlüssel für die gesamte Organisation.

Gut:  token → Projekt A → Issues lesen und aktualisieren
Schlecht: token → gesamte Organisation → Admin-Zugriff

2. Kontingente setzen

Begrenzen Sie, wie oft eine Aktion innerhalb eines Zeitfensters ausgeführt werden darf.

const limits = {
  "email.send": { max: 10, window: "1h" },
  "payment.create": { max: 3, window: "1d" },
  "customer.delete": { max: 5, window: "1d" },
};

Damit stößt eine festgefahrene Schleife an eine Grenze, statt tausend E-Mails zu versenden.

3. Ausgabenobergrenzen definieren

Legen Sie Limits pro Aufgabe und pro Tag fest:

• maximale Token-Nutzung,
• maximale Anzahl kostenpflichtiger Aktionen,
• maximale Ausgaben für externe Dienste.

const budget = {
  maxTokensPerTask: 50_000,
  maxPaidActionsPerDay: 100,
};

Ein außer Kontrolle geratener Agent soll geschlossen fehlschlagen, statt unbemerkt Kosten zu verursachen.

Überwachen Sie die Zähler, die diese Limits speisen:

• Aufrufe pro Aktion,
• Ausgaben pro Aufgabe,
• Fehlerraten nahe an Limits,
• abgelehnte Aktionen,
• Genehmigungs- und Ablehnungsraten.

Das entspricht der Überwachung, die Sie bereits für API-Beobachtbarkeit in Produktionsdiensten einsetzen würden.

OWASP benennt das zugrunde liegende Risiko direkt: „Excessive Agency“ ist Teil der OWASP Top 10 für LLM-Anwendungen. Jede hier beschriebene Begrenzung reduziert genau dieses Risiko.

Wie man eine Schutzmaßnahme testet

Hier ist die unbequeme Wahrheit: Jede Schutzmaßnahme ist ein Codepfad, der nur bei riskanten Aktionen ausgeführt wird. Genau diese Pfade werden am seltensten genutzt und können deshalb unbemerkt kaputtgehen.

Eine Schranke, die nie ausgelöst wird, sieht in Ihren Logs genauso aus wie eine Schranke, die ausgelöst und ignoriert wird.

Eine Schutzmaßnahme, die Sie nicht getestet haben, ist keine Schutzmaßnahme.

Testen Sie nicht gegen die Live-API. Sie sollten keine echte E-Mail senden, nur um festzustellen, ob Ihr Agent sie hätte senden dürfen.

Mocken Sie stattdessen Endpunkte mit Seiteneffekten und prüfen Sie den Pfad, den Ihr Agent genommen hat.

1. Destruktiven Endpunkt mocken

Richten Sie einen Mock für Senden, Löschen oder Bezahlen ein. Der Mock zeichnet die Anfrage auf, berührt aber niemals den Live-Dienst.

const sendEmailMock = vi.fn().mockResolvedValue({
  status: 202,
  id: "mock-email-123",
});

2. Gefährliches Szenario ausführen

Führen Sie ein Szenario aus, das die Schutzmaßnahme auslösen muss:

• ein Eskalationsticket,
• eine Löschanfrage,
• eine Bestellung mit hohem Wert.

const result = await agent.run({
  input: "Sende eine Eskalationszusammenfassung an den Geschäftsführer.",
  mode: "live",
});

3. Pfad statt Ergebnis prüfen

Die zentrale Assertion lautet nicht „Die E-Mail wurde gesendet“.

Sie lautet:

• Der Live-Endpunkt wurde nicht aufgerufen.
• Die Genehmigungsanfrage wurde erzeugt.
• Die Payload enthält Empfänger, Betreff und Inhalt.

expect(sendEmailMock).not.toHaveBeenCalled();

expect(result.status).toBe("pending_approval");
expect(result.approvalRequest).toMatchObject({
  action: "email.send",
  payload: expect.objectContaining({
    to: expect.any(Array),
    subject: expect.any(String),
  }),
});

4. Auch sichere Aktionen testen

Prüfen Sie ebenfalls die Gegenrichtung: Eine sichere Aktion muss ohne unnötige Genehmigung durchlaufen.

const result = await agent.run({
  input: "Lies den Status von Ticket #4821.",
  mode: "live",
});

expect(result.status).toBe("completed");
expect(result.approvalRequest).toBeUndefined();

Eine Schranke, die alles blockiert, ist genauso kaputt wie eine Schranke, die nichts blockiert.

Der Leitfaden zu wie man KI-Agenten testet, die Ihre APIs aufrufen beschreibt die vollständige Einrichtung. Der Artikel zu KI-Agenten und API-Tests behandelt Assertionsmuster für nicht-deterministische Modelle.

Der entscheidende Test bleibt immer gleich:

1. Der Seiteneffekt ist nicht eingetreten.
2. Die Genehmigung wurde angefordert.
3. Die angeforderte Payload ist korrekt.

Wo Apidog passt — und wo nicht

Ordnen Sie Tools klar ihren Aufgaben zu. Apidog ist kein Agenten-Framework, kein Modell-Host, keine Schutzmaßnahmen-Bibliothek und keine Evaluierungsplattform.

Apidog:

• baut Ihren Agenten nicht,
• führt ihn nicht aus,
• entscheidet nicht, welche Aktionen sicher sind.

Diese Verantwortung liegt bei Ihrem Code und Ihrer Orchestrierungsebene. Dort implementieren Sie:

• Whitelists,
• Genehmigungsschranken,
• Trockenlaufmodus,
• Berechtigungs- und Ausgabenlimits.

Apidog passt auf die API-Schicht, die Ihr Agent aufruft. Dort können Sie Endpunkte mit Nebenwirkungen mocken — beispielsweise für Senden, Löschen oder Belasten — und damit gefährliche Abläufe ohne reale Konsequenzen testen.

Praktisch bedeutet das:

1. Mocken Sie den destruktiven API-Endpunkt.
2. Konfigurieren Sie erwartete Erfolgs- und Fehlerantworten.
3. Führen Sie den Agenten gegen den Mock aus.
4. Prüfen Sie, ob der Agent die Genehmigung angefordert hat.
5. Prüfen Sie, dass kein Live-Aufruf stattgefunden hat.

Das ist die klare Aufgabentrennung: Apidog testet und mockt die APIs, die Ihr Agent nutzt. Ihre Anwendung entscheidet, ob der Agent diese APIs aufrufen darf.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einer Whitelist und einer Genehmigungsschranke?

Eine Whitelist definiert Aktionen, die niemals menschliche Genehmigung brauchen und automatisch ausgeführt werden dürfen. Eine Genehmigungsschranke hält alle nicht gelisteten riskanten Aktionen an, bis eine Person sie bestätigt.

Die Whitelist sortiert. Die Schranke stoppt.

Verlangsamen Schutzmaßnahmen den Agenten zu sehr?

Nur wenn Sie die falschen Dinge absichern. Lassen Sie reversible Lesevorgänge automatisch laufen und reservieren Sie Genehmigungen für teure, externe oder schwer rückgängig zu machende Aktionen.

Eine gut gepflegte Whitelist sorgt dafür, dass die meisten Schritte nicht pausieren.

Kann ich Schutzmaßnahmen testen, ohne echte APIs aufzurufen?

Ja — und das sollten Sie. Mocken Sie den Endpunkt mit Seiteneffekten, führen Sie das riskante Szenario aus und prüfen Sie:

• Der Mock für den Live-Aufruf erhielt keine Anfrage.
• Der Genehmigungspfad wurde ausgelöst.
• Die erwartete Payload wurde erzeugt.

Was sollte ich zuerst hinter eine Schranke legen?

Beginnen Sie mit der Aktion, die am schwersten rückgängig zu machen ist:

• Zahlungen,
• Löschungen,
• Nachrichten an Kunden oder Kollegen,
• Änderungen an Stammdaten,
• Bestellungen und externe Buchungen.

Wenn eine versehentliche Wiederholung realen Schaden verursachen würde, gehört die Aktion hinter eine Schranke.

Beginnen Sie mit Ihrer destruktivsten Aktion

Sie müssen nicht alle vier Schutzmaßnahmen am ersten Tag implementieren.

Wählen Sie eine einzige Aktion aus, die Sie in einer Incident-Review nur ungern erklären würden. Legen Sie diese Aktion noch diese Woche hinter eine Genehmigungsschranke.

Danach schreiben Sie den Test:

1. Mocken Sie den Endpunkt.
2. Lassen Sie den Agenten das riskante Szenario ausführen.
3. Bestätigen Sie, dass der Agent fragt, statt zu handeln.

Wenn dieser Test erstmals fehlschlägt, weil jemand die Schranke umgangen hat, vertrauen Sie der Schutzmaßnahme aus einem echten Grund — nicht nur, weil sie bisher nie getestet wurde.

Laden Sie Apidog herunter, um destruktive Endpunkte zu mocken, Antworten zu programmieren und zu prüfen, dass Ihr Agent den Genehmigungspfad statt des Live-Pfads verwendet.