+150 XP

Guardrails: Berechtigungen, Review und Kosten

# Guardrails: Berechtigungen, Review und Kosten

Ein Agent, der eine E-Mail senden, einen Pull Request mergen oder Geld bewegen kann, ist nur so sicher wie die Gates, die Sie vor diese Aktionen setzen. Das Modell generiert nicht mehr nur Text. Es handelt, und eine selbstbewusste Halluzination wird zur realen Konsequenz. Diese Lektion behandelt die Kontrollebene: zu entscheiden, was ein Agent anfassen darf, wann ein Mensch zustimmen muss, was niemals unbeaufsichtigt laufen sollte und wie Sie verhindern, dass eine außer Kontrolle geratene Loop Ihr Budget verbrennt.

Die drei Failure Modes, gegen die Sie sich absichern

Jedes Guardrail, das Sie bauen, lässt sich einem davon zuordnen:

1. Falsche Aktion ausgeführt. Der Agent tut etwas, das er nicht tun sollte (löscht einen Datensatz, schreibt dem falschen Kunden).

2. Richtige Aktion, falscher Scope. Der Agent tut das Richtige, aber mit zu großer Reichweite (erstattet die gesamte Bestellung statt einer einzelnen Position).

3. Runaway-Kosten. Eine Loop, ein Retry-Sturm oder ein riesiger Tool-Output, der wieder in den Kontext wandert und Ihre Token-Rechnung hochtreibt.

Berechtigungen adressieren #1 und #2. Human Review fängt die hochriskanten Ränder beider ab. Kostenkontrollen kümmern sich um #3. Behandeln Sie das als getrennte Systeme, nicht als eine große „sei vorsichtig“-Anweisung.

Berechtigungen: den Scope der Tools begrenzen, nicht den Prompt

Der größte Fehler ist, Sicherheit in den Prompt zu schreiben („lösche nie etwas, ohne zu fragen“). Prompts sind Vorschläge. Berechtigungen leben in Code und Konfiguration, wo das Modell sich nicht daran vorbeireden kann.

In ChatGPT (dem Produkt)

Wenn Sie mit Custom GPTs und GPT Actions bauen, definieren Sie über das OpenAPI-Schema genau, welche API-Endpunkte die Action ansprechen darf. Das GPT kann keinen Endpunkt aufrufen, den Sie nicht freigegeben haben. Nutzen Sie OAuth in der Auth-Konfiguration der Action, damit jeder Nutzer mit seinen eigenen Berechtigungen handelt und nicht mit einem gemeinsamen Key. Den Auth-Flow finden Sie in der Actions-Dokumentation.

Connectors (Google Drive, SharePoint, GitHub und andere) erben die Berechtigungen des verbundenen Kontos. Wenn Sie einen Read-only-Service-Account verbinden, erhält der Agent ausschließlich Leserechte. Richten Sie das zugrundeliegende Konto mit Least Privilege ein, bevor Sie es verbinden.

Der ChatGPT Agent browst, führt Code aus und nutzt Connectors in einer Sandbox-Umgebung, und er hält vor folgenreichen Schritten wie dem Absenden eines Formulars oder einem Kauf inne, um zu fragen. Behandeln Sie diese eingebaute Bestätigung als Untergrenze, nicht als Ihre gesamte Strategie.

In der API (wo Sie alles kontrollieren)

Mit der Responses API und dem Agents SDK sind Berechtigungen einfach Code um Ihre Tool-Funktionen herum. Das Modell schlägt einen Aufruf vor; Ihr Code entscheidet, ob er ausgeführt wird.

python
ALLOWED_REFUND_CEILING = 100_00  # cents

def issue_refund(order_id: str, amount_cents: int) -> dict:
    if amount_cents > ALLOWED_REFUND_CEILING:
        return {
            "status": "needs_review",
            "reason": f"Amount {amount_cents} exceeds auto-approve ceiling",
        }
    result = payments.refund(order_id, amount_cents)
    return {"status": "done", "refund_id": result.id}

Das Modell sieht die Payment-Credentials nie und kann das Limit nicht anheben. Die Regel wird dort durchgesetzt, wo es zählt.

Das Review-Gate: ein konkretes Beispiel

Hier ist das Muster, das der Einstieg versprochen hat: Ein Agent entwirft eine Aktion, aber ein Mensch genehmigt sie, bevor sie ausgeführt wird. Das ist ein zweiphasiges Tool. Phase eins liefert einen Vorschlag zurück. Ein Mensch (oder ein separater Approval-Schritt) bestätigt. Phase zwei führt aus.

Stellen Sie sich einen Support-Agent vor, der Rückerstattungsanfragen bearbeitet. Er soll die mühsame Arbeit machen (Bestellung nachschlagen, Richtlinie lesen, Rückerstattung entwerfen), aber oberhalb einer Schwelle niemals eigenständig Geld bewegen.

python
from openai import OpenAI
client = OpenAI()

PENDING = {}  # in production, use a real datastore

def propose_refund(order_id: str, amount_cents: int, reason: str) -> dict:
    token = f"refund_{order_id}"
    PENDING[token] = {"order_id": order_id, "amount_cents": amount_cents}
    return {
        "status": "awaiting_approval",
        "approval_token": token,
        "summary": f"Refund ${amount_cents/100:.2f} on {order_id}: {reason}",
    }

def commit_refund(approval_token: str) -> dict:
    job = PENDING.pop(approval_token, None)
    if not job:
        return {"status": "error", "reason": "unknown or already-used token"}
    receipt = payments.refund(job["order_id"], job["amount_cents"])
    return {"status": "done", "refund_id": receipt.id}

Der Agent kann propose_refund frei aufrufen. Er kann commit_refund physisch nicht ohne ein gültiges Token aufrufen, und dieses Token erscheint in Ihrem System erst, nachdem ein Mensch auf Genehmigen geklickt hat. Die Aufgabe des Modells endet bei „das würde ich tun wollen“. Das „Ja“ gehört einem Menschen.

Das ist das mentale Modell für jede hochriskante Automatisierung: Vorschlag von der KI, Commit vom Menschen, wobei der Commit-Schritt hinter einem Token liegt, das das Modell nicht fälschen kann.

Building Human-in-the-Loop AI Agents

Watch on YouTube

Wo der Mensch hingehört

Nicht jede Aktion braucht dasselbe Gate. Sortieren Sie Ihre Tools in drei Kategorien:

  • Auto: read-only oder trivial reversibel (Bestellung nachschlagen, Text entwerfen, Dokumente durchsuchen). Kein Gate.
  • Review: folgenreich, aber Routine (Kunden-E-Mail senden, Ticket anlegen, Rückerstattung unter einem Limit). Mensch genehmigt, idealerweise im Batch.
  • Nie unbeaufsichtigt: irreversibel oder mit großem Blast Radius (Produktionsdaten löschen, Geld über einem Limit überweisen, an alle Nutzer veröffentlichen, Berechtigungen ändern). Immer ein Mensch, immer geloggt.

Machen Sie diese Kategorien in Ihrem Design-Dokument explizit. „In welcher Kategorie ist dieses Tool?“ ist die erste Frage bei jeder neuen Capability, die Sie hinzufügen.

Was niemals unbeaufsichtigt automatisiert werden darf

Einige Kategorien gehören in die dritte Schublade, egal wie gut Ihr Agent ist:

  • Irreversible Löschungen von Kunden- oder Produktionsdaten.
  • Ausgehende Finanztransaktionen über einem kleinen, festen Limit.
  • Änderungen an Identität und Zugriff (Rollen vergeben, Credentials anderer rotieren, Sharing-Einstellungen ändern).
  • Öffentliche oder Massenkommunikation (öffentlich posten, an eine ganze Liste mailen, alles, was man nicht zurückholen kann).
  • Rechtliche oder Compliance-Verpflichtungen (Unterschreiben, Zustimmung zu Bedingungen, behördliche Meldungen).

Der Test: *Wenn der Agent das einmal falsch macht, kann ich es rückgängig machen, bevor jemand Schaden nimmt?* Wenn die Antwort nein lautet, führt ein Mensch es aus. Scheduled Tasks verschärfen das, denn ein Scheduled Task in ChatGPT läuft, während Sie nicht zusehen. Alles, was nach Zeitplan läuft, sollte einen Entwurf oder eine Benachrichtigung produzieren und keine irreversible Aktion ins Leere abfeuern.

Wissenscheck

1. Warum argumentiert die Lektion, dass Sicherheitsregeln in den Prompt zu schreiben (z. B. „lösche nie etwas, ohne zu fragen“) der größte Fehler ist?

2. Ein Agent führt korrekt eine Rückerstattung aus, erstattet aber die gesamte Bestellung statt der angefragten einzelnen Position. Welcher Failure Mode ist das?

3. Wie sollte man laut Lektion die eingebaute Bestätigung des ChatGPT Agents vor folgenreichen Schritten behandeln?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE korrekten Aussagen dazu, wie Berechtigungen bei Custom GPTs, GPT Actions und Connectors funktionieren.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE korrekten Zuordnungen eines Guardrail-Systems zu dem Failure Mode, den es primär adressiert.

Wählen Sie alle richtigen Antworten aus.

Kosten im Griff behalten

Agents loopen. Das ist ihre Stärke und ihr finanzielles Risiko. Ein einzelner fehlerhafter Run kann ein Tool fünfzigmal aufrufen, jedes aufgeblähte Ergebnis wieder in den Kontext füttern und still eine Rechnung auflaufen lassen, die weit über einem normalen Chat liegt. Kostenkontrolle ist ein Guardrail, kein Nachgedanke.

Die Loop begrenzen

Das wichtigste Limit ist die maximale Anzahl an Schritten, die ein Agent gehen darf. Im Agents SDK setzen Sie ein Turn-Limit, damit ein feststeckender Agent stoppt statt endlos zu kreisen.

python
from agents import Agent, Runner

agent = Agent(name="support", instructions=SYSTEM_PROMPT, tools=[propose_refund])

result = Runner.run_sync(agent, "Refund order 8842, item was defective", max_turns=8)

Wenn der Agent in acht Turns nicht fertig wird, hält er an. Dieser einzelne Parameter ist der Unterschied zwischen einer begrenzten Aufgabe und einer außer Kontrolle geratenen Loop.

Kontrollieren, was wieder in den Kontext kommt

Token-Kosten kumulieren, weil jedes Tool-Ergebnis dem Kontext hinzugefügt und beim nächsten Aufruf erneut mitgesendet wird. Ein API-Dump mit 20.000 Tokens, von dem das Modell nur ein Feld gebraucht hat, kostet Sie in jedem weiteren Turn. Kürzen und fassen Sie Tool-Outputs zusammen, bevor Sie sie zurückgeben.

python
def search_logs(query: str) -> dict:
    rows = db.search(query, limit=2000)
    return {"matched": len(rows), "top": rows[:5]}  # not all 2000

Geben Sie die Anzahl und eine Stichprobe zurück, nicht den ganzen Heuhaufen. Das Modell braucht den Rohdump selten, und Ihr Geldbeutel ganz sicher nicht.

Modellgröße passend wählen und die günstigen Hebel nutzen

Sie brauchen nicht für jeden Schritt Ihr leistungsfähigstes Modell. Klassifikation und Extraktion an ein kleineres, günstigeres Modell zu routen und das Frontier-Modell für echtes Reasoning zu reservieren, ist einer der wirksamsten Kostenhebel überhaupt. Prüfen Sie die aktuelle Modellpalette und die Preise pro Token auf der OpenAI-Preisseite, denn die genauen Modelle und Zahlen ändern sich im Zeitverlauf.

Zwei weitere Hebel:

  • Prompt Caching senkt die Kosten für den wiederkehrenden, statischen Teil Ihres Prompts (System-Instructions, Tool-Definitionen), wenn dasselbe Präfix erneut auftritt. Halten Sie Ihre stabilen Inhalte vorne, damit sie gecacht werden.
  • Structured Outputs halten Antworten knapp und parsebar, was die Re-Prompt-und-Retry-Zyklen vermeidet, die Ihre Ausgaben stillschweigend verdoppeln. Sie definieren das Schema, und das Modell liefert genau diese Form.

Ausgaben beobachten, nicht entdecken

Setzen Sie in den Billing-Einstellungen Ihres OpenAI-Kontos ein hartes monatliches Usage Limit, damit ein Bug das Budget nicht leerziehen kann. Legen Sie API-Keys pro Umgebung an (einen für Dev, einen für Prod), damit Sie Ausgaben zuordnen und den lauten Key widerrufen können. Und dann beobachten Sie das Usage Dashboard. Ein Kostenausschlag in einem Chart ist eine Frühwarnung; eine überraschende Rechnung ist ein Postmortem.

Die Ebenen zusammensetzen

Ein gut abgesicherter Agent hat alle drei Systeme gleichzeitig im Einsatz:

1. Berechtigungen legen fest, welche Tools existieren und welchen Scope jedes hat, durchgesetzt im Code.

2. Review-Gates sitzen vor den folgenreichen Tools, mit einer Trennung von Propose und Commit, sodass ein Mensch jedes irreversible „Ja“ verantwortet.

3. Kostenkontrollen begrenzen die Loop, trimmen, was wieder in den Kontext kommt, routen zum passenden Modell und alarmieren bei Ausgaben.

Keines davon lebt im Prompt. Der Prompt formt Verhalten; die Guardrails setzen Grenzen durch. Wenn Sie eine neue Capability hinzufügen, stellen Sie alle drei Fragen in dieser Reihenfolge: *Was kann das anfassen? Wer genehmigt es? Was kostet es, wenn es loopt?*

Key Takeaways

  • Setzen Sie Berechtigungen im Code durch, nicht im Prompt. Nutzen Sie GPT-Actions-Schemas, Connector-Konten mit Least Privilege und Prüfungen auf Tool-Ebene, die das Modell nicht übergehen kann.
  • Verwenden Sie ein Propose-dann-Commit-Gate für hochriskante Aktionen. Der Agent liefert einen Vorschlag plus Token; erst die Genehmigung eines Menschen gibt den Commit-Schritt frei.
  • Führen Sie eine explizite „nie unbeaufsichtigt“-Liste: irreversible Löschungen, Geld über einem festen Limit, Zugriffsänderungen, Massenkommunikation und rechtliche Verpflichtungen.
  • Begrenzen Sie die Schrittzahl jedes Agents mit max_turns (oder dem Äquivalent) und kürzen Sie Tool-Outputs, damit aufgeblähte Ergebnisse nicht in jeder Loop erneut in den Kontext wandern.
  • Setzen Sie ein hartes Billing-Limit, nutzen Sie getrennte Keys pro Umgebung und routen Sie günstige Schritte an günstigere Modelle. Beobachten Sie das Usage Dashboard, damit ein Ausschlag eine Warnung ist und keine Rechnung.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • OAuth für user-scoped Actions oder solche mit Schreibzugriff nutzen; API Keys nur für gemeinsame Read-only-Zugriffe
  • Propose-then-commit-Gates mit Tokens für alle Aktionen mit hohem Risiko einsetzen
  • Harte Abrechnungslimits setzen, mit separaten API-Keys pro Umgebung
Vollständiges Action Playbook ansehen

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.