2/3+170 XP

Guardrails, Permissions und Human-in-the-Loop

# Guardrails, Permissions und Human-in-the-Loop

2024 wurde der Chatbot eines Autohändlers dazu überredet, einem Verkauf eines Trucks für einen Dollar zuzustimmen. Das sei "rechtlich bindend", scherzte der Kunde und machte einen Screenshot der Antwort. Der Bot hatte keine Bremse. Er konnte alles sagen, und (in einer gefährlicheren Variante) hätte er alles *tun* können.

Stellen Sie sich denselben Agent nun verbunden mit Ihrem E-Mail-Postfach, Ihrem Kalender und der Firmenkreditkarte vor. Ein Agent, der in der realen Welt handeln kann, braucht Grenzen, die er nicht überschreiten kann. Diese Lektion handelt von diesen Grenzen: was erlaubt ist, wann ein Mensch gefragt werden muss und wie man den Schaden begrenzt.

Warum Agents Bremsen brauchen

Ein Chatbot redet nur. Ein Agent (eine KI, die über Tools handeln kann, etwa eine E-Mail senden oder eine API aufrufen) tut tatsächlich Dinge. Das ist der ganze Sinn und gleichzeitig das ganze Risiko.

Drei Failure Modes treten ständig auf:

Falsche Aktion. Der Agent erstattet 5.000 $ statt 50 $.
Richtige Aktion, falsches Ziel. Er mailt den Entwurf an das ganze Unternehmen statt an eine Person.
Runaway Loops. Er wiederholt eine fehlschlagende Aufgabe 400 Mal, und jeder Versuch kostet Geld.

Guardrails sind der Weg, den Nutzen zu behalten und die Katastrophe zu entfernen. Es gibt drei Hauptwerkzeuge: Permissions (was der Agent tun *darf*), Approvals (wann ein Mensch zuerst zustimmen muss) und Limits (harte Obergrenzen, die er nicht überschreiten kann).

Permissions: die Tool-Allow-List

Das erste Guardrail besteht darin, zu entscheiden, welche Tools der Agent überhaupt anfassen darf. Das ist eine Tool-Allow-List: eine explizite Liste der ihm verfügbaren Aktionen. Was nicht auf der Liste steht, existiert für den Agent einfach nicht.

Denken Sie daran wie an eine Schlüsselkarte für einen neuen Praktikanten. Sie geben ihm nicht Zugang zu jedem Raum im Gebäude. Sie geben ihm die drei Türen, die er braucht.

Ein Support-Agent bekommt vielleicht:

search_knowledge_base (read-only, sicher)
create_draft_reply (erzeugt Text, sendet nichts)
escalate_to_human (gibt ab)

Beachten Sie, was *nicht* dabei ist: kein send_email, kein issue_refund, kein delete_account. Der Agent kann Arbeit vorbereiten, aber alles Irreversible übernimmt eine Person oder ein strengeres System.

Eine nützliche Gewohnheit: Sortieren Sie jedes Tool in read (sicher, Dinge nachschauen), write (verändert etwas, riskanter) und irreversibel (gibt Geld aus, sendet Nachrichten, löscht Daten). Read-Tools können meist frei laufen. Write- und irreversible Tools verdienen zusätzliche Prüfung.

Das Tool scopen, nicht nur benennen

Einem Agent ein send_email-Tool zu geben ist keine ausreichende Kontrolle. *Scopen* Sie es. Beschränken Sie das Tool zum Beispiel so, dass es nur an Adressen innerhalb Ihrer eigenen Firmendomain mailen kann oder nur auf Threads antworten darf, die der Nutzer begonnen hat. Das Tool selbst erzwingt die Regel, sodass der Agent sie nicht brechen kann, egal was er "entscheidet".

Human-in-the-Loop: der Approval-Schritt

Bei riskanten Aktionen ist die sicherste Bremse ein Mensch. Human-in-the-Loop (oft als HITL abgekürzt) bedeutet, dass der Agent vor einer sensiblen Aktion pausiert und darauf wartet, dass eine Person zustimmt oder ablehnt.

Das Muster ist einfach:

1. Der Agent entscheidet, dass er eine Aktion ausführen will (diese Erstattung senden).

2. Statt sie auszuführen, *schlägt* der Agent sie vor und pausiert.

3. Ein Mensch sieht den Vorschlag und klickt auf Zustimmen oder Ablehnen.

4. Erst nach der Zustimmung läuft die Aktion.

Sie brauchen nicht bei allem eine Zustimmung. Das würde den Agent so langsam machen, wie die Arbeit selbst zu erledigen. Genehmigen Sie nur die Aktionen, die irreversibel oder teuer sind. Lassen Sie das Sichere durchlaufen.

Hier eine anbieterneutrale Skizze, wie ein Approval-Gate in einer Tool-Call-Loop aussieht. Die Logik ist dieselbe, ob Sie das OpenAI Agents SDK, das Claude Agent SDK oder Googles ADK verwenden:

python

# Tools that always require a human to approve before running
NEEDS_APPROVAL = {"send_email", "issue_refund", "delete_record"}

def run_tool(name, args):
    if name in NEEDS_APPROVAL:
        # Pause and ask a person
        if not human_approves(name, args):
            return {"status": "rejected", "reason": "Human declined."}
    return execute(name, args)

# The agent loop
while not done:
    action = agent.next_action()          # model proposes a tool call
    result = run_tool(action.name, action.args)
    agent.observe(result)                 # feed the outcome back in

Der Kerngedanke: Das Modell *schlägt vor*, Ihr Code *entscheidet*, ob es ausgeführt wird. Der Agent hat nie direkt die Hände am gefährlichen Knopf.

Approvals leicht prüfbar machen

Eine Approval-Anfrage, die nur "Aktion genehmigen?" sagt, ist nutzlos. Der Mensch kann sie nicht beurteilen. Zeigen Sie das volle Detail:

> Der Agent will eine E-Mail senden

> An: jane@acme.com

> Betreff: Ihre Erstattung von 50,00 $

> Text: Hallo Jane, wir haben Ihre Erstattung bearbeitet...

> [Zustimmen] [Ablehnen] [Bearbeiten]

Geben Sie dem Prüfer genug Kontext, um einen Fehler in zwei Sekunden zu erkennen. Eine "Bearbeiten"-Option ist ein Plus: Der Mensch korrigiert den Betrag von 500 $ auf 50 $ und stimmt dann zu.

Limits: Obergrenzen, die der Agent nicht überschreiten kann

Approvals hängen davon ab, dass ein Mensch aufmerksam ist. Limits funktionieren auch, wenn niemand hinschaut. Es sind harte Obergrenzen, die von Ihrem Code erzwungen werden, nicht vom Urteil des Modells.

Häufige Limits:

Spending Cap. Der Agent darf höchstens 100 $ pro Tag ausgeben. Versuch 101 schlägt automatisch fehl.
Rate Limit. Nicht mehr als 20 E-Mails pro Stunde, damit eine Runaway Loop nicht spammt.
Step Budget. Stopp nach 15 Aktionen an einer einzelnen Aufgabe, damit er nicht endlos loopt.
Data Boundary. Er darf die Support-Datenbank lesen, aber nie die Payroll-Datenbank.

Ein Spending Cap ist in der Praxis nur eine laufende Summe, die Ihr Code vor jeder Ausgabe prüft:

python

DAILY_CAP = 100.00

def issue_refund(amount):
    if spent_today() + amount > DAILY_CAP:
        return {"status": "blocked", "reason": "Daily cap reached."}
    charge(amount)
    return {"status": "ok"}

Weil das in Ihrem Code läuft, kann der Agent sich nicht daran vorbeireden. Kein geschickter Prompt lässt die Zahl höher werden. Genau das macht Limits stärker als Anweisungen.

Anweisungen sind keine Guardrails

"Gib nie mehr als 100 $ aus" in den System-Prompt zu schreiben, ist ein *Vorschlag*, keine Garantie. Modelle können verwirrt, gejailbreakt oder einfach im Irrtum sein. Echte Guardrails leben im umgebenden Code und in den Tools, wo das Modell keine Stimme hat. Nutzen Sie den Prompt, um Verhalten zu lenken, aber erzwingen Sie die harten Regeln außerhalb des Modells.

Für einen soliden, kostenlosen Überblick, wie diese Kontrollen in ein größeres Sicherheitsbild passen, ist das NIST AI Risk Management Framework gut lesbar und anbieterneutral.

Wissenscheck

1. Was ist der grundlegende Unterschied zwischen einem Chatbot und einem Agent, der Guardrails für letzteren so entscheidend macht?

2. Ein Agent wiederholt einen fehlschlagenden API-Call 400 Mal und verbrennt bei jedem Versuch Geld. Welchen Failure Mode zeigt das?

3. Warum enthält die Tool-Allow-List eines gut entworfenen Support-Agents 'create_draft_reply', aber nicht 'send_email'?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE richtigen Antworten. Welche sind die drei Hauptwerkzeuge, um Agents sicher zu halten, wie in der Lektion beschrieben?

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE richtigen Antworten. Was leistet das Guardrail 'Tool-Allow-List'?

Wählen Sie alle richtigen Antworten aus.

Alles zusammen: ein Refund-Agent

Entwerfen wir einen realistischen Agent und legen alle drei Guardrails übereinander.

Aufgabe: Erstattungsanfragen von Kunden in einem Support-Postfach bearbeiten.

Permissions (Allow-List):

look_up_order (read, sicher)
check_refund_policy (read, sicher)
draft_refund (write, bereitet vor, führt nicht aus)
issue_refund (irreversibel)

Approvals:

Erstattungen unter 50 $, die der Policy entsprechen: automatisch genehmigt, der Agent führt sie aus.
Erstattungen ab 50 $ oder alles außerhalb der Policy: pausiert für einen Menschen.

Limits:

Tageslimit von insgesamt 2.000 $ über alle Erstattungen.
Maximal 30 Erstattungsaktionen pro Stunde.
Stopp und Eskalation nach 10 Schritten an einem Fall.

Verfolgen wir nun eine Anfrage. Ein Kunde will 200 $ für eine verspätete Lieferung zurück. Der Agent schaut die Order nach (sicher), prüft die Policy (sicher) und entwirft die Erstattung. Weil 200 $ die 50-$-Schwelle überschreitet, pausiert er. Ein Support-Mitarbeiter sieht den vollständigen Vorschlag, bestätigt, dass die Lieferung tatsächlich verspätet war, und klickt auf Zustimmen. Die Erstattung läuft und zählt gegen das Tageslimit von 2.000 $.

Wenn ein Bug den Agent 50 Erstattungen in einer Minute versuchen ließe, stoppt ihn das Rate Limit bei 30. Wenn eine Prompt Injection (eine versteckte Anweisung, die in einer Kundennachricht platziert wird, um den Agent zu kapern) ihm sagte, 10.000 $ zu erstatten, blockiert das Tageslimit es und der Approval-Schritt fängt es ab. Die Schichten stützen sich gegenseitig.

Diese Schichtung ist die eigentliche Lektion. Kein einzelnes Guardrail genügt. Permissions verkleinern, was möglich ist, Approvals fangen Urteilsfehler ab, und Limits begrenzen den Worst Case. Zusammen lassen sie einen Agent weitgehend selbstständig laufen und machen eine Katastrophe nahezu unmöglich.

Building Safe AI Agents: Guardrails and Human Oversight

Watch on YouTube

Die Bremsen über die Zeit justieren

Streng starten, dann lockern. Gehen Sie mit Approval auf fast allem live. Beobachten Sie die Vorschläge eine Woche. Die Aktionen, die Menschen jedes einzelne Mal ohne Änderungen genehmigen, sind Kandidaten für Auto-Approval. Die, die Menschen häufig bearbeiten oder ablehnen, bleiben gegated.

So bekommen Sie Daten statt Vermutungen. Sie erfahren, *wo* der Agent vertrauenswürdig ist, und lassen ihn dort frei laufen, während ein Mensch bei den wirklich riskanten Entscheidungen bleibt.

Für anbieterspezifische Wege, diese Kontrollen zu verdrahten (native Approval-Hooks, Tool-Permission-Einstellungen und Budget-Features), siehe die Deep-Dive-Blöcke zum OpenAI Agents SDK, zum Claude Agent SDK und zu Googles ADK. Die Konzepte hier lassen sich direkt übertragen, nur die Syntax ändert sich.

Key Takeaways

Nutzen Sie eine Tool-Allow-List. Der Agent kann nur Tools verwenden, die Sie explizit freigeben. Sortieren Sie jedes Tool in read, write und irreversibel und scopen Sie die riskanten eng.
Setzen Sie bei irreversiblen oder teuren Aktionen einen Menschen in den Loop. Das Modell schlägt vor, Ihr Code entscheidet, ob es läuft. Zeigen Sie Prüfern das volle Detail, damit die Zustimmung Sekunden dauert.
Erzwingen Sie harte Limits im Code, nicht im Prompt. Spending Caps, Rate Limits und Step Budgets stoppen Runaway Loops und Jailbreaks, auch wenn niemand hinschaut.
Schichten Sie die Guardrails. Permissions, Approvals und Limits fangen jeweils auf, was die anderen übersehen. Keine einzelne Bremse genügt.
Streng starten und mit Daten lockern. Gaten Sie beim Start alles, dann auto-approven Sie die Aktionen, die Menschen immer durchwinken.