Kontrollen für KI-Agenten-Gateways sind die Betriebsregeln, die entscheiden, was ein Agent aufrufen darf, wie viel er ausgeben darf, welche Nachweise protokolliert werden müssen und wann die Ausführung pausieren, zurückfallen oder anhalten muss. Ohne diese Kontrollen wird ein Agenten-Gateway zu einer schnelleren Methode, um Tool-Wildwuchs, unkontrollierte Token-Ausgaben und unklare Produktionsausfälle zu verbergen.
Das Ziel ist nicht, jeden Agenten in Prozesse zu zwängen. Das Ziel ist es, das Verhalten von Agenten überprüfbar zu machen, bevor es die Produktionsbenutzer erreicht. Ein Support-Agent, der Bestellungen nachschlagen kann, ein Programmier-Agent, der Dateien bearbeiten kann, und ein Finanz-Agent, der Rechnungen vergleichen kann, sollten nicht denselben Tool-Zugriff, dasselbe Budget, dieselbe Protokollierung oder dieselbe Stopp-Richtlinie teilen.
Verwenden Sie diesen Leitfaden, um Kontrollen für KI-Agenten-Gateways als Richtlinien, Nachweisfelder und Akzeptanztests zu entwerfen. Validieren Sie dann die aktuellen Nachweise für das Flatkey-Modell, das Routing, die Nutzung und die Abrechnung auf der Seite Flatkey-Preise vor der Einführung.
Kontrollen für KI-Agenten-Gateways beginnen mit einer Richtliniengrenze
Ein Agenten-Gateway befindet sich zwischen Agenten-Laufzeitumgebungen, Modell-APIs, internen Tools und der Finanzprüfung. Das macht es zu einem guten Ort, um vier Entscheidungen zu standardisieren:
| Kontrollbereich | Gateway-Frage | Produktionsnachweis |
|---|---|---|
| Tool-Nutzung | Welche Tools kann dieser Workflow aufrufen, mit welchen Argumenten und unter wessen Genehmigung? | Tool-Name, Schema-Version, Argumente, Genehmigungsstatus, Ergebnisstatus |
| Budgets | Wie hoch dürfen die Ausgaben für Eingabe, Ausgabe, Schlussfolgerung, Tools, Wiederholungsversuche und Fallback sein? | Token-Anzahl, Anfragekosten, Besitzerschlüssel, Budgetergebnis, Fallback-Ausgaben |
| Protokolle | Was ist passiert, welche Route hat es bedient und was kann später überprüft werden? | Anfrage-ID, Workflow, Modell, Route, Tool-Aufrufe, Stopp-Grund, Fehlercode |
| Stopp-Bedingungen | Wann sollte die Ausführung beendet werden, es erneut versuchen, eine Genehmigung anfordern, zurückfallen oder sicher fehlschlagen (fail-closed)? | Stopp-Bedingung, Fallback-Grund, Prüferentscheidung, Endzustand |
Diese Kontrollen für KI-Agenten-Gateways sollten wie eine Infrastrukturrichtlinie überprüft werden, nicht wie ein Prompt-Text. Der Prompt kann die Absicht erklären, aber die Gateway-Richtlinie sollte erzwingen, was passiert, wenn das Modell ein sensibles Tool anfordert, ein Budget überschreitet, ein unerwartetes Tool-Ergebnis erhält oder in eine Schleife gerät.
Kontrollen für die Tool-Nutzung: Weniger Tools erlauben, als der Agent kennt
Der Aufruf von Tools (Tool Calling) ist leistungsstark, da er Modelle mit realen Systemen verbindet. Hier geht ein Agent auch vom Vorschlag zur Handlung über. Die Dokumentation zum Function Calling von OpenAI beschreibt Tool-Aufrufe als einen mehrstufigen Prozess: Das Modell fordert ein Tool an, Ihre Anwendung führt es aus und die Ausgabe des Tools wird an das Modell zurückgegeben. Die Dokumentation zur Tool-Nutzung von Anthropic lässt Claude in ähnlicher Weise tool_use-Blöcke zurückgeben, wobei der Anwendungscode für die Ausführung verantwortlich ist. Das Function Calling von Google Gemini hängt ebenfalls von deklarierten Funktionen und vom Modell generierten Funktionsaufrufen ab.
Dieses gängige Muster ist für die Kontrollen von KI-Agenten-Gateways von Bedeutung: Das Modell sollte das Tool nicht direkt ausführen. Ihr Gateway oder Ihre Laufzeitumgebung sollte entscheiden, ob das angeforderte Tool erlaubt ist, ob die Argumente der Richtlinie entsprechen, ob eine Genehmigung erforderlich ist und ob das Ergebnis des Tools sicher zurückgesendet werden kann.
Verwenden Sie eine dreischichtige Tool-Richtlinie:
- Tool-Katalog: der vollständige Satz von Tools, die in der Organisation existieren.
- Workflow-Zulassungsliste: die kleinere Gruppe von Tools, die eine bestimmte Agenten-Route aufrufen darf.
- Einschränkung auf Turn-Ebene: die für diese Anfrage verfügbaren Tools nach Überprüfung von Rolle, Mandant, Umgebung, Budget und Risiko.
Ein Kundensupport-Agent kann beispielsweise im normalen Modus auf lookup_order, search_policy und open_ticket zugreifen. Er sollte keinen Zugriff auf issue_refund, cancel_contract oder delete_account erhalten, bis der Workflow einen genehmigten Eskalationspfad erreicht.
Die Kontrolle sollte explizit sein:
workflow: support_resolution_agent
tool_policy:
default_mode: deny
allowed_tools:
- lookup_order
- search_policy
- open_ticket
approval_required:
- issue_refund
- cancel_subscription
blocked_tools:
- export_customer_database
schema_rules:
require_strict_arguments: true
reject_unknown_fields: true
log_redacted_arguments: true
on_violation:
action: stop
user_message: ask_for_human_reviewDer Leitfaden zum Function Calling von OpenAI empfiehlt klare Funktionsbeschreibungen, JSON-Schemata, einen strikten Modus (wo unterstützt) und die anfängliche Begrenzung der verfügbaren Funktionen. Das ist nicht nur ein Ratschlag zur Modellleistung. Es ist auch eine Kontrolle für das Agenten-Gateway: weniger exponierte Tools bedeuten weniger ungültige Zustände, die nach einem Vorfall überprüft werden müssen.
Budgetkontrollen: Begrenzen Sie die gesamte Ausführung, nicht nur einen einzelnen Modellaufruf
Die Kosten für einen Agenten entstehen selten durch eine einzige, saubere Anfrage. Sie setzen sich zusammen aus Tool-Schemata, Gesprächsverlauf, Abrufkontext, Reasoning-Tokens, Tool-Ergebnissen, Wiederholungsversuchen, Fallback-Modellen und wiederholten Versuchen nach teilweisen Fehlschlägen.
Budgetkontrollen für KI-Agenten-Gateways sollten die gesamte Ausführung abdecken:
| Budgetbereich | Was zu begrenzen ist | Warum es wichtig ist |
|---|---|---|
| Anfragebudget | Eingabe-Token, Ausgabe-Token, Reasoning-Token, max. Modellaufrufe | Verhindert, dass eine einzelne Runde zu einem überraschenden Kostenereignis wird |
| Tool-Budget | Anzahl der Tool-Aufrufe, Größe des Tool-Ergebnisses, Ausgaben für externe APIs | Verhindert Tool-Schleifen und teure Datenabrufe |
| Wiederholungsbudget | Anzahl der Wiederholungen, wiederholbare Statuscodes, Backoff-Fenster | Trennt Resilienz von unkontrollierter Wiederholung |
| Fallback-Budget | Anzahl der Fallback-Modelle, Fallback-Kostengrenze, Fallback-Grund | Verhindert, dass Zuverlässigkeit eine defekte primäre Route verschleiert |
| Besitzer-Budget | Projekt-, Team-, Kunden-, Umgebungs-, Schlüssel- oder Workflow-Limit | Macht Ausgaben für Finanz- und Technikabteilungen überprüfbar |
Das Gateway sollte bei Überschreitung eines harten Limits den Zugriff verweigern (Fail-Closed). Es kann zusammenfassen, eine Reduzierung des Umfangs anfordern, eine menschliche Überprüfung in die Warteschlange stellen oder einen kontrollierten Fehler zurückgeben. Es sollte nicht stillschweigend einen größeren Prompt senden, auf eine teurere Route wechseln oder es immer wieder versuchen.
Verwenden Sie diese Budget-Struktur:
budget_policy:
workflow: invoice_reconciliation_agent
owner_key: finance_ops
per_request:
max_input_tokens: 32000
max_output_tokens: 4000
max_model_calls: 4
max_tool_calls: 5
per_session:
max_total_tokens: 90000
max_total_cost_usd: reviewed_threshold
retry:
max_attempts: 2
retryable_statuses: [408, 409, 429, 500, 502, 503, 504]
fallback:
max_fallbacks: 1
require_reason: true
on_over_budget:
action: stop_or_request_scope_reductionHier wird die öffentliche Produktoberfläche von Flatkey relevant. Die aktuelle Homepage von Flatkey positioniert die Plattform rund um einheitlichen Modellzugriff, Routing, Abrechnung, Nutzungsanalysen und Betriebskontrollen. Die aktuelle Preisseite beschreibt Prepaid-Aufladungen, Nutzungsanalysen, Kostenkontrollen, Anforderungsprotokolle, eine einzige Rechnung über alle Anbieter hinweg und Beschaffungswege für Teams. Betrachten Sie diese als aktuellen öffentlichen Planungsnachweis und führen Sie dann vor der Produktion Ihren eigenen Test im Dashboard durch.
Protokolle: Beweise aufzeichnen, nicht nur rohe Prompts
Agentenprotokolle müssen zwei Fragen beantworten: Was ist zur Laufzeit passiert, und wer kann beweisen, dass die Richtlinie funktioniert hat?
Die Dokumentation zur Beobachtbarkeit des AI Gateway von Vercel beschreibt Gateway-Protokolle für Ausgaben, Modellnutzung, Beobachtbarkeitsmetriken, Anforderungszusammenfassungen, API-Schlüssel und Anforderungsprotokolle. Die Dokumentation zur Beobachtbarkeit des Agents SDK von OpenAI beschreibt Traces, die Modellaufrufe, Tool-Aufrufe, Übergaben, Guardrails und benutzerdefinierte Spans enthalten können. Diese Beispiele deuten auf dieselbe betriebliche Anforderung hin: Agenten-Gateways benötigen Protokolle, die das Modellverhalten mit Entscheidungen zu Routen, Tools, Budgets und Stopps verbinden.
Für die Kontrollen von KI-Agenten-Gateways sollten mindestens diese Felder protokolliert werden:
| Feld | Beispiel | Warum es wichtig ist |
|---|---|---|
request_id | vom Gateway generierte UUID | Verbindet Modell-, Tool-, Abrechnungs- und Support-Datensätze |
workflow_class | support_agent, code_agent, finance_agent | Gruppiert Richtlinien- und Akzeptanztests |
owner_key | Team, App, Kunde, Umgebung | Unterstützt die Zuweisung von Ausgaben und die Überprüfung von Missbrauch |
requested_model | Modell-Alias oder Routenname | Zeigt, was die App angefordert hat |
served_model | tatsächlicher Anbieter/Modell | Zeigt, was das Gateway bereitgestellt hat |
tool_calls | Name, Schemaversion, redigierte Argumente, Status | Beweist das Verhalten der Tool-Richtlinie |
usage | Eingabe-, Ausgabe-, Reasoning-, Cache-, Gesamt-Token | Verbindet Verhalten mit Kosten |
budget_result | erlaubt, gewarnt, blockiert | Beweist, dass die Kostenkontrolle ausgeführt wurde |
stop_condition | completed, max_steps, over_budget, approval_required | Erklärt, wie die Ausführung beendet wurde |
fallback_reason | timeout, 429, provider_error, quality_gate | Trennt Wiederherstellung von Drift |
Protokollieren Sie nicht alles für immer, nur weil es einfach ist. Kundendaten, Prompts, Tool-Ergebnisse und Dateien können sensible Informationen enthalten. Ein langlebiges Protokolldesign sollte Schwärzung, Aufbewahrung, Zugriffsüberprüfung, Exportanforderungen und Vorgehensweisen bei Vorfällen definieren. Das Gateway sollte genügend Beweise speichern, um die Nutzung zu debuggen und abzugleichen, ohne jede Anfrage in ein unkontrolliertes Datenarchiv zu verwandeln.
Stopp-Bedingungen: Definieren Sie das Ende der Ausführung, bevor das Modell startet
Stopp-Bedingungen sind nicht nur Modell-Stoppsequenzen. Sie sind die Regeln, die eine Agentenausführung sicher beenden.
Anbieter-APIs bieten unterschiedliche Oberflächen für Antworten und Stopps. Die Messages API von Anthropic legt in ihrer Dokumentation stop_reason-Felder wie Tool-Nutzung, Rundenende, maximale Token und Stoppsequenzen offen. Die Guardrails-Dokumentation des Agents SDK von OpenAI beschreibt Guardrails und menschliche Überprüfung als Kontrollen, die entscheiden, wann eine Ausführung fortgesetzt, pausiert oder gestoppt wird. In der Produktion sollte Ihr Gateway diese anbieterspezifischen Zustände in einen Workflow-Zustand normalisieren, den Ihr Team versteht.
Verwenden Sie eine Stopp-Matrix:
| Stopp-Bedingung | Gateway-Aktion | Verhalten für den Benutzer | Erforderlicher Nachweis |
|---|---|---|---|
| Abgeschlossen | Endgültige Antwort zurückgeben | Normale Antwort | endgültiges Modell, Nutzung, keine ungelösten Tools |
| Tool-Genehmigung erforderlich | Pausieren | „Diese Aktion muss überprüft werden“ | Tool-Aufruf, Argumente, Genehmiger, Entscheidung |
| Budget überschritten | Stoppen oder nach Reduzierung des Umfangs fragen | „Die Anfrage eingrenzen“ | Budgetfeld, Schwellenwert, Besitzerschlüssel |
| Maximale Anzahl an Schritten erreicht | Stoppen | „In diesem Durchlauf nicht abschließbar“ | Schrittzahl, letzte Aktion, Schleifensignal |
| Tool-Fehler | Wiederholen, Fallback oder Stoppen | Klarer Fehlerpfad | Tool-Status, Fehlerklasse, Anzahl der Wiederholungsversuche |
| Anbieter-Timeout | Wiederholen oder Fallback | Verschlechterte, aber kontrollierte Antwort | Route, Timeout, Fallback-Grund |
| Richtlinienverstoß | Stoppen | Verweigern oder an einen Menschen weiterleiten | ausgelöste Richtlinie, geschwärztes Beispiel |
| Geringe Konfidenz oder fehlender Nachweis | Nachfragen oder eskalieren | „Weitere Informationen benötigt“ | fehlendes Feld, Bewertungsergebnis |
Wichtig ist, dass jeder Endzustand einen Namen hat. Wenn die einzigen Zustände „Erfolg“ und „Fehler“ sind, können Teams nicht feststellen, ob der Agent die Richtlinie eingehalten hat oder nur versehentlich angehalten wurde.
Eine praktische Vorlage für die Steuerung von KI-Agenten-Gateways
Verwenden Sie eine Richtliniendatei, die von den Abteilungen Technik, Sicherheit, Finanzen und Produkt gemeinsam überprüft werden kann:
policy_name: ai_agent_gateway_controls_v1
owner:
team: ai_platform
reviewers:
- engineering
- finance
- security
workflow_classes:
support_agent:
route: balanced_text_tool_route
allowed_tools: [lookup_order, search_policy, open_ticket]
approval_tools: [issue_refund, cancel_subscription]
max_tool_calls: 5
max_model_calls: 4
code_agent:
route: code_review_route
allowed_tools: [read_repo, search_repo, propose_patch]
approval_tools: [apply_patch, run_shell_command]
max_tool_calls: 12
max_model_calls: 8
budget_rules:
require_owner_key: true
block_when_owner_budget_exceeded: true
require_fallback_reason: true
log_rules:
capture_request_id: true
capture_requested_and_served_model: true
capture_tool_call_status: true
redact_sensitive_arguments: true
stop_rules:
max_steps: 12
max_retries_per_tool: 1
on_policy_violation: stop
on_approval_required: pause
acceptance_tests:
- blocked_tool_is_not_executed
- over_budget_request_fails_closed
- approval_tool_pauses_run
- fallback_records_reason
- request_log_contains_usage_and_stop_conditionDiese Datei ersetzt keinen Anwendungscode. Sie gibt dem Code einen Vertrag zur Durchsetzung und den Prüfern ein konkretes Artefakt zur Inspektion.
Abnahmetests vor der Produktion
Führen Sie Abnahmetests für jede Workflow-Klasse durch, bevor der Traffic live geschaltet wird:
- Senden Sie eine normale Anfrage und bestätigen Sie, dass nur erlaubte Tools verfügbar gemacht werden.
- Fordern Sie ein blockiertes Tool an und bestätigen Sie, dass das Tool nicht ausgeführt wird.
- Fordern Sie ein genehmigungspflichtiges Tool an und bestätigen Sie, dass der Durchlauf mit einem wiederaufnehmbaren Zustand pausiert.
- Senden Sie einen übergroßen Prompt und bestätigen Sie, dass das Gateway stoppt oder eine Reduzierung des Umfangs anfordert.
- Lösen Sie einen Tool-Fehler aus und bestätigen Sie, dass die Anzahl der Wiederholungsversuche, der Fallback-Grund und der Endzustand protokolliert werden.
- Erzwingen Sie ein Anbieter-Timeout und bestätigen Sie, dass der Fallback innerhalb des Fallback-Budgets bleibt.
- Lösen Sie die maximale Anzahl an Schritten aus und bestätigen Sie, dass der Durchlauf nicht in einer Schleife endet.
- Bestätigen Sie, dass die Anforderungsprotokolle den Besitzerschlüssel, das angeforderte Modell, das bereitgestellte Modell, die Nutzung, den Tool-Status, das Budgetergebnis und die Stopp-Bedingung anzeigen.
- Führen Sie einen Stichprobenabgleich der Finanzen von den Anforderungsprotokollen zur Rechnung oder zur Bewegung des Prepaid-Guthabens durch.
- Führen Sie denselben Test erneut aus, nachdem Sie Modelle, Tools, Prompts oder die Routing-Richtlinie geändert haben.
Kombinieren Sie diesen Artikel mit den Anleitungen von Flatkey zur KI-API-Gateway-Architektur, LLM-API-Gateway-Architektur, KI-API-Lastenausgleich und Failover und zum Design von Modell-Routing-Richtlinien. Die Gateway-Architektur entscheidet, wo die Kontrollen angesiedelt sind; die Abnahmetests beweisen, dass sie funktionieren.
Wo Flatkey ins Spiel kommt
Flatkey sollte nicht der einzige Ort sein, an dem Ihre Agenten-Richtlinie existiert. Bewahren Sie die Richtlinie im Code, in der Konfiguration oder in einem internen Kontroll-Repository auf. Nutzen Sie Flatkey als Gateway-Oberfläche, auf der Teams den Modellzugriff, die Überprüfung von Routen, die Sichtbarkeit der Nutzung, Anforderungsprotokolle, Kostenkontrollen, Prepaid-Guthaben und die Rechnungsprüfung zentralisieren können.
Ein praktischer Rollout von Flatkey sieht so aus:
- Wählen Sie einen Agenten-Workflow mit bekannten Tools und Besitzern.
- Definieren Sie die erlaubten Tools, Genehmigungs-Tools, Budgetobergrenzen, Protokollfelder und Stopp-Bedingungen.
- Überprüfen Sie die aktuellen Modell- und Preisoptionen auf der Seite Flatkey-Preise.
- Führen Sie die Abnahmetests mit einem Nicht-Produktionsschlüssel durch.
- Überprüfen Sie die Protokolle auf das angeforderte Modell, das bereitgestellte Modell, die Nutzung, die Routing-Entscheidung, den Fallback-Grund und die Stopp-Bedingung.
- Verschieben Sie nur den getesteten Workflow in die Produktion.
- Fügen Sie neue Tools und Fallback-Routen zeilenweise in der Richtlinie hinzu.
Wenn der Nachweis erbracht ist, holen Sie sich einen Schlüssel und halten Sie den ersten Rollout eng begrenzt. Die stärksten Kontrollen für KI-Agenten-Gateways sind in der Produktion unspektakulär: Jeder Tool-Aufruf hat einen Grund, jede Budgetentscheidung eine Spur, jeder Fehler eine benannte Stopp-Bedingung, und jeder Prüfer kann sehen, was passiert ist.
FAQ
Was sind Kontrollen für KI-Agenten-Gateways?
Kontrollen für KI-Agenten-Gateways sind Richtlinien, die den Tool-Zugriff, Budgets, Protokolle, das Fallback-Verhalten und Stopp-Bedingungen für Agenten-Workflows regeln, die Modelle und Tools über ein Gateway aufrufen.
Sind Kontrollen für KI-Agenten-Gateways dasselbe wie Modell-Routing?
Nein. Modell-Routing entscheidet, welches Modell oder welcher Anbieter eine Anfrage bedienen soll. Kontrollen für KI-Agenten-Gateways entscheiden, ob der Agent ein Tool aufrufen, mehr Budget ausgeben, es erneut versuchen, auf eine Alternative zurückgreifen, zur Genehmigung pausieren oder anhalten darf.
Was sollte bei der Tool-Nutzung durch Agenten protokolliert werden?
Protokollieren Sie die Anfrage-ID, die Workflow-Klasse, den Besitzerschlüssel, das angefragte Modell, das ausgelieferte Modell, den Tool-Namen, die Schema-Version, geschwärzte Argumente, den Ergebnisstatus, die Nutzung, das Budgetergebnis, den Fallback-Grund und die Stopp-Bedingung.
Sollten sensible Tools dem Modell jederzeit zur Verfügung stehen?
Nein. Halten Sie den vollständigen Tool-Katalog von der Zulassungsliste (Allowlist) des Workflows getrennt. Sensible Tools sollten eine Genehmigung, einen engeren Geltungsbereich oder einen separaten Eskalationsweg erfordern.
Wie sollten Budgetüberschreitungen gehandhabt werden?
Harte Budgetüberschreitungen sollten zu einem Fail-Closed-Verhalten führen. Das Gateway kann eine Reduzierung des Geltungsbereichs anfordern, zusammenfassen, eine Überprüfung in die Warteschlange stellen oder einen kontrollierten Fehler zurückgeben, aber es sollte nicht stillschweigend auf eine teurere Route wechseln.
Wie hilft Flatkey bei den Kontrollen für KI-Agenten-Gateways?
Flatkey bietet Teams eine einzige Gateway-Oberfläche für Modellzugriff, Routing-Überprüfung, Nutzungstransparenz, Anforderungsprotokolle, Kostenkontrollen, Prepaid-Guthaben und Rechnungsprüfung. Nutzen Sie diese Oberfläche zusammen mit Policy-as-Code und Abnahmetests für produktive Agenten-Workflows.
