Guardrails für KI-Agenten: So richtest du Freigaben und Budgets ein

Guardrails für KI-Agenten sind Backend-Kontrollen. Sie schränken ein, worauf ein Agent zugreifen, was er ausführen und wie viel Geld er verbrauchen darf - selbst wenn das Modell unsichere Instruktionen liefert. Bei einer Lovable-App fängt man am besten mit engen Tool-Berechtigungen, aktionsspezifischen Freigaben, Audit-Logs und strikten Ausgabenlimits an. Diese Anleitung überführt solche Kontrollen in eine handfeste Support-Agent-Architektur, inklusive Copy-Paste-Prompt und Tests vor dem Launch.

Was Guardrails für KI-Agenten kontrollieren müssen

Ein Modell schlägt eine Aktion vor. Die Anwendung entscheidet, ob diese Aktion erlaubt ist. Diese Grenze muss stehen.

Geht eine App im Oktober 2026 live, lautet die entscheidende Frage nicht, ob das Modell Tool-Calls beherrscht. Wichtig ist vielmehr: Kann ein fehlerhafter Tool-Call Mandantengrenzen verletzen, Geld transferieren oder die Rechnung in die Höhe treiben?

Ein typisches Beispiel: Ein Support-Agent liest Tickets, entwirft Antworten und schlägt Rückerstattungen vor. Das Lesen eines freigegebenen Tickets birgt kaum Risiken. Das Versenden einer Antwort hat Außenwirkung. Eine Rückerstattung verschiebt echtes Geld. Diese Aktionen dürfen keinesfalls denselben Berechtigungsregeln unterliegen.

| Aktion | Standard-Policy | Backend-Durchsetzung | | --- | --- | --- | | Ticket lesen | Erlauben innerhalb des Mandanten-Scopes | Authentifizierte Mitgliedschaft und Ticket-Zugehörigkeit prüfen | | Antwort entwerfen | Erlauben ohne Versand | Entwurf speichern, keine E-Mail-Zugangsdaten exponieren | | Antwort senden | Zunächst Freigabe erforderlich | Exakten Empfänger, Text und Anhänge freigeben | | Rückerstattung ausstellen | Autorisierte Freigabe erforderlich | Ursprüngliche Zahlung, Betrag, Währung und verbleibenden erstattungsfähigen Betrag validieren | | Datensätze löschen | Im ersten Release verweigern | Kein Lösch-Tool bereitstellen |

Das sind produktbezogene Policies, keine universellen Schwellenwerte. Ein medizinischer Workflow verlangt andere Regeln als ein internes Tool für Meeting-Zusammenfassungen.

Fünf Kontrollmechanismen sind entscheidend:

1. Identität: Welcher Nutzer und welcher Mandant haben diesen Durchlauf gestartet?
2. Scope: Welche Datensätze und Tools sind erreichbar?
3. Autorität: Welche Aktionen erfordern die Freigabe einer zweiten Person?
4. Budget: Wie viele Aufrufe und wie viel Geld dürfen verbraucht werden?
5. Nachweis: Was ist passiert, und lässt sich das lückenlos rekonstruieren?

Output-Validatoren und Injection-Detektoren helfen zwar, ersetzen diese Kontrollen aber nicht. Selbst ein perfekt formatierter Erstattungsantrag kann auf die Zahlung eines völlig fremden Kunden abzielen.

Wer noch nach dem passenden Workflow sucht, schaut in unsere Guides für KI-Agenten. Besser mit einem einzigen, wertstiftenden Tool starten als mit einem Allzweck-Agenten und unbeschränktem HTTP-Zugriff.

Einen Freigabe-Workflow in Lovable bauen

Lovable eignet sich bestens für die Benutzeroberfläche und das Gerüst der Anwendung. Autorisierung, Freigabeprüfung und Tool-Ausführung gehören jedoch in Server-Funktionen oder einen Worker. Ein Setup mit Supabase ist eine naheliegende Option, das Prinzip greift aber bei jeder transaktionalen Datenbank.

Für einen schlanken Prototyp mit einem Lese-Tool und einer freigabepflichtigen Schreibaktion sollte man etwa 6 bis 12 Entwicklerstunden einplanen. Das ist ein Schätzwert, keine Garantie für produktionsreifen Code aus dem Generator. Zahlungsanbindung und Security-Reviews kosten extra Zeit.

1. Das minimale Datenmodell anlegen

Diese Tabellen sind nötig:

• `agent_runs`: Mandant, initiierender Nutzer, Status, Policy-Version, Limits und Kostenzähler.
• `agent_actions`: Run, typisierter Tool-Name, kanonische Argumente, Argument-Hash, Ablaufzeit und Ausführungsstatus.
• `agent_approvals`: Aktion, genehmigende Person, genehmigter Argument-Hash, Entscheidung und Ablaufzeit.
• `agent_events`: Run, Aktion, Zeitstempel, Event-Typ, Akteur und bereinigte Metadaten.
• `agent_usage`: Reservierung, Request-ID des Providers, geschätzte Kosten, tatsächliche Kosten und Abgleichsstatus.

Jeder relevante Datensatz braucht eine `tenant_id`. Für Tabellen mit Browserzugriff sollte Row-Level Security aktiv sein. Nutzt das Backend erweiterte Zugriffsrechte, muss es die Mandantenzugehörigkeit trotzdem explizit prüfen, da solche Dienstkonten RLS-Regeln umgehen können.

Das Frontend darf Durchläufe anstoßen oder Freigaben übermitteln. Ausführungsstatus, Budgets oder Audit-Logs darf der Browser niemals direkt manipulieren.

2. Präzise Tools bereitstellen

Spezifische Aufrufe wie `get_ticket(ticket_id)` und `propose_refund(payment_id, amount_minor, currency, reason)` sind generischen Varianten wie `fetch_url(url)` oder `execute_sql(query)` immer vorzuziehen.

Parameter gehören gegen ein striktes Schema validiert. Unbekannte Felder fliegen raus. Zielressourcen werden ausschließlich innerhalb des authentifizierten Mandanten geladen. Die Mandanten-Identität stammt immer aus dem authentifizierten Request, niemals aus Argumenten, die das Modell erzeugt hat.

Für den Prototyp deckelt man vorgeschlagene Erstattungen am besten bei 5.000 Untereinheiten in USD, also 50 Dollar. Vorsicht: Nicht jede Währung hat zwei Nachkommastellen. Vorschläge oberhalb des konfigurierten Limits gehören abgelehnt oder in einen separaten manuellen Prüfpfad umgeleitet.

Secrets des Payment-Providers haben im Agenten nichts verloren. Er darf auch keine neuen Empfänger für Erstattungen erfinden - wohin das Geld zurückfließt, bestimmt allein der Bezahldienst.

3. Die exakte Aktion freigeben, nicht den Chatverlauf

Eine Freigabe nach dem Motto "Agenten weitermachen lassen" greift viel zu kurz.

Zeig dem Operator die Kundendaten, die ursprüngliche Zahlung, Betrag, Währung, Begründung und das passende Ticket. Gespeichert wird die Genehmigung gegen einen Hash der kanonischen Aktions-Payload, bestehend aus Tool-Name, Mandant, Ressourcen-IDs und Argumenten.

In Version eins sollten Vorschläge unveränderlich sein. Ändert jemand den Betrag, entsteht ein neuer Vorschlag, der eine frische Freigabe verlangt. Eine Gültigkeitsdauer von 15 Minuten ist ein solider Startwert, der sich später anpassen lässt.

Vor der Ausführung muss das System sicherstellen:

• Die genehmigende Person besitzt die nötige Rolle in diesem Mandanten.
• Die Freigabe ist nicht abgelaufen und stimmt exakt mit dem gespeicherten Hash überein.
• Die Aktion steht noch auf "pending" und wurde noch nicht verarbeitet.
• Die Zahlung ist nach wie vor für die geplante Erstattung berechtigt.
• Der Durchlauf wurde nicht abgebrochen und verfügt über ausreichend Budget.

Autorisierungen müssen zum Ausführungszeitpunkt erneut geprüft werden. Jemand könnte seine Finanzrolle kurz nach dem Klick auf Freigeben verlieren.

4. Ausführung atomar sperren

Der Übergang der freigegebenen Aktion muss atomar in der Datenbank verriegelt werden. Es darf unter keinen Umständen passieren, dass zwei Worker den Status gleichzeitig von `approved` auf `executing` setzen.

Danach erfolgt der Provider-Aufruf mit einem stabilen Idempotenzschlüssel, der sich aus der Aktions-ID ableitet (sofern die Schnittstelle das unterstützt). Jeder Retry muss genau diesen Schlüssel wiederverwenden.

Datenbank und externe APIs teilen sich keine gemeinsame Transaktion. Läuft ein Payment-Request in einen Timeout, ist das Ergebnis schlicht unbekannt, nicht automatisch fehlgeschlagen. Vor einem Neuversuch fragt man den Provider ab oder nutzt dessen Idempotenzmechanismus zur Abstimmung. Niemals darf eine neue Zahlungsoperation ausgelöst werden, bloß weil die erste Antwort verloren ging.

Die Freigabe-Oberfläche sollte diese Ungewissheit transparent machen. "Prüfe Provider-Status" ist deutlich ehrlicher als ein grünes Häkchen oder eine voreilige Fehlermeldung.

Budgets und Audit-Logs integrieren

Budgetkontrollen müssen den nächsten API-Aufruf abfangen, statt nur über die Ausgaben von gestern zu informieren.

Für den Prototyp des Support-Agenten bieten sich folgende Startwerte an:

| Limit | Startwert | Zweck | | --- | --- | --- | | Modell-Aufrufe pro Run | 8 | Verhindert endlose Reasoning-Schleifen | | Tool-Aufrufe pro Run | 12 | Begrenzt externe Interaktionen | | Aktive Ausführungszeit | 120 Sekunden | Stoppt neue Aufgaben nach Ablauf der Frist | | Modell- und Tool-Budget | 0,25 $ pro Run | Deckelt geschätzte Betriebskosten | | Tägliches Mandanten-Budget | 10 $ | Begrenzt Schäden durch wiederholte Durchläufe | | Retry-Kontingent | 2 Retries pro Operation | Verhindert ausufernde Wiederholungsversuche |

Wartet das System auf menschliche Freigabe, darf kein Worker im Leerlauf blockieren. Vorschlag speichern, Run pausieren und nach erfolgter Freigabe über einen neuen Job fortsetzen. Wie lange ein pausierter Run gültig bleibt, sollte separat festgelegt werden.

Ein Timeout macht eine bereits gesendete externe Aktion nicht ungeschehen. Künftige Schritte abbrechen, laufende Requests gezielt abgleichen.

Kosten vor dem Absenden reservieren

Kostet ein Call unter den definierten Input- und Output-Limits maximal 0,04 Dollar, reserviert man genau diesen Betrag vorab. Nach erfolgreichem Aufruf wird der tatsächliche Verbrauch abgerechnet und der Restbetrag wieder freigegeben.

Die Freigaberegel lautet:

```text settled_cost + active_reservations + next_reservation <= budget ```

Prüfung und Reservierung müssen atomar erfolgen, sowohl für den einzelnen Run als auch für das Tagesbudget des Mandanten. Bei einem einfachen Read-then-Write-Ansatz drohen Budgetüberschreitungen, wenn parallele Worker denselben Restbetrag sehen.

Bei der Buchführung empfiehlt sich die Arbeit mit Integer-Mikrodollars oder Festkommazahlen in der Datenbank. Retries müssen mitzählen, separat abgerechnete Tools gehören ebenso hinein. Niemals eine Reservierung auflösen, nur weil ein Request in einen Timeout gelaufen ist - zuerst klären, ob der Provider ihn verarbeitet hat.

Schätzungen bieten nur dann verlässlichen Schutz, wenn sich jede Gebühr sauber begrenzen lässt. Fallen bei einem Tool unvorhersehbare Nutzungsgebühren an, sollte man dessen Zugriff drosseln, die Reservierung vorsichtig nach oben schrauben oder es ganz aus dem automatischen Ablauf heraushalten. Ausgabenlimits direkt beim Provider dienen als zusätzliches Fangnetz.

Ein Rechenbeispiel (keine aktuellen Provider-Preise): Bei angenommenen 1 Dollar pro Million Input-Token und 5 Dollar pro Million Output-Token schlägt ein Call mit 6.000 Input- und 1.000 Output-Tokens mit 0,011 Dollar zu Buche. Acht identische Calls kosten 0,088 Dollar, Tools und Infrastruktur noch nicht eingerechnet. Da spätere Aufrufe meist mehr Kontext mitschleppen, errechnet man Reservierungen besser anhand des konkreten Requests, statt einfach den ersten Call hochzurechnen.

Die Build-Credits von Lovable haben nichts mit den KI-Laufzeitkosten der Anwendung zu tun. Für das Builder-Abo hilft unser Lovable-Pricing-Guide, die gewählten Runtime-Dienste kalkuliert man separat.

Entscheidungen protokollieren, ohne Kundendaten preiszugeben

Ins Protokoll gehören: Run- und Action-IDs, Tool-Name, Policy-Version, Autorisierungsentscheidung, Freigabe-Referenz, Latenz, Retry-Zähler, Kosten und Request-ID des Providers.

Access-Tokens, vollständige Zahlungsdaten oder ganze private Tickets gehören niemals in einen allgemeinen Event-Stream. Bereinigte Zusammenfassungen und Referenzen reichen völlig aus. Müssen sensible Payloads zwingend gespeichert werden, verlangen sie eigene Zugriffsbeschränkungen und klare Löschfristen.

Für Anwendungsrollen sollten Events ausschließlich als Append-only konfiguriert sein. Das stärkt die Nachvollziehbarkeit, schützt aber nicht vor Manipulationen durch Datenbank-Administratoren. Strengere Compliance-Vorgaben verlangen oft separaten, unveränderbaren Speicher.

Abgelehnte Aktionen und Abgleichprozesse müssen genauso penibel geloggt werden wie Erfolge. Andernfalls blendet das Dashboard genau die Vorfälle aus, die dringend analysiert werden müssen.

Copy-Paste-Prompt und Checkliste für den Launch

Diesen Prompt nach Anbindung des Backends in Lovable einfügen. Vor dem Anwenden empfiehlt es sich, das Tool die Migration und die serverseitige Autorisierung erklären zu lassen. In unserer Prompt-Bibliothek finden sich weitere Vorlagen, um KI-Änderungen präzise zu steuern.

```text Build a guarded support-agent prototype with a Supabase backend.

Scope:

• Read tenant-authorized tickets.
• Draft replies without sending.
• Propose USD refunds up to 5000 cents.
• Use a mock payment adapter first. No live refunds.

Create agent_runs, agent_actions, agent_approvals, agent_events, and agent_usage tables with tenant isolation. Use integer microdollars for cost accounting.

Security:

• Derive user and tenant authorization server-side.
• Never expose provider or service-role secrets in browser code.
• Reject unknown tool names and invalid argument fields.
• Browser clients cannot modify execution state or cost counters.
• Elevated backend credentials require explicit tenant checks.

Approvals:

• Show the exact payment, amount, currency, and reason.
• Store immutable proposals and hash canonical action payloads.
• Require a finance-role approval with a 15-minute expiry.
• Recheck role, hash, expiry, payment eligibility, and run state.
• Atomically claim actions before execution.
• Reuse one provider idempotency key per action.
• Reconcile unknown provider outcomes before retrying.

Budgets:

• Maximum 8 model calls and 12 tool calls per run.
• $0.25 run budget and $10 tenant daily budget.
• Atomically reserve bounded costs before dispatch.
• Settle actual usage and retain unresolved reservations.
• Suspend workers while awaiting approval.

UI:

• Run list, approval inbox, action details, redacted event timeline.
• Cancel control that blocks future dispatches.
• Clearly label mock actions and unknown provider outcomes.

Add automated tests for cross-tenant access, expired approvals, changed payloads, concurrent execution, budget races, and timeouts. Explain deployment requirements and any unimplemented controls. ```

Vor der Aktivierung eines produktiven Schreib-Tools muss folgendes stehen:

• [ ] Ein Nutzer aus Mandant A kann keine Aktionen aus Mandant B lesen oder freigeben.
• [ ] Ein manipuliertes Ticket kann kein unbekanntes Tool aufrufen.
• [ ] Veränderte Argumente machen eine Freigabe ungültig.
• [ ] Abgelaufene oder entzogene Genehmiger-Rechte verhindern die Ausführung.
• [ ] Parallele Worker lösen exakt eine externe Operation aus.
• [ ] Parallele Reservierungen können das festgelegte Limit nicht überschreiten.
• [ ] Nach einem Timeout startet ein Abgleich statt eines blinden Neuversuchs.
• [ ] Das Abbrechen eines Runs blockiert neue Aufrufe zuverlässig.
• [ ] Logs enthalten weder Zugangsdaten noch unnötige sensible Daten.

Das Rollout erfolgt am besten in drei Phasen: gemockte Aktionen, echte Lesezugriffe mit vorgeschlagenen Schreibaktionen und schließlich ein einzelnes produktives Schreib-Tool für interne Operatoren. Erst wenn abgelehnte Aktionen, Kosten und unklare Statusmeldungen im Alltag geprüft wurden, lohnt sich der Ausbau.

Kann ein System-Prompt Prompt-Injections verhindern?

Nein. Ein System-Prompt lenkt zwar das Verhalten, aber nicht vertrauenswürdige Tickets, Dokumente oder Webseiten können das Modell dennoch manipulieren. Tool-Calls aus dem Modell sollten grundsätzlich wie ungesicherte Requests behandelt werden. Backend-Berechtigungen, strikte Schemas, begrenzte Scopes und Freigabeprozesse begrenzen den Schaden, falls die Instruktionen unterwandert werden.

Braucht jede Agenten-Aktion eine menschliche Freigabe?

Nein. Autorisierte Lesezugriffe und revidierbare Entwürfe laufen in der Regel automatisch. Freigaben sind Pflicht, sobald Geld fließt, externe Nachrichten rausgehen, Daten gelöscht oder Berechtigungen verändert werden. Jede Ausnahme für automatische Ausführungen sollte eng gesteckt, messbar und zwingend außerhalb des Modells durchgesetzt sein.

Was kosten Guardrails für KI-Agenten?

In der Planung schlägt der hier beschriebene, gemockte Prototyp mit 6 bis 12 Entwicklerstunden zu Buche. Live-Integrationen und Security-Reviews kommen obendrauf. Ein kleines Entwicklungs-Deployment liegt bei monatlich etwa 25 bis 75 Dollar für Backend- und Worker-Dienste - exklusive Lovable, Modellkosten und kostenpflichtiger Tools. Ein Blick in die aktuellen Provider-Tarife lohnt sich. Der größte Kostenfaktor zu Beginn ist fast immer die Implementierung samt Tests, nicht die Freigabe-Maske.