Agent Gateways: Die Control-Plane für KI-Agenten in der Produktion

Solange ein KI-Agent sich darauf beschränkt, Informationen zu recherchieren oder eine Antwort zu verfassen, ist ein Fehler in der Regel rückgängig zu machen. Das Risiko ändert seinen Charakter, wenn der Agent eine Datenbank ändern, eine Zahlung auslösen, eine E-Mail versenden, ein Ticket erstellen oder einen Drittanbieterdienst aufrufen kann.

Ab diesem Punkt wird eine Architektur-Frage zentral:

Wer entscheidet wirklich, ob eine vom Modell vorgeschlagene Aktion ausgeführt werden kann?

Die Antwort kann nicht allein im Prompt des Agenten liegen. Ein probabilistisches Modell darf nicht die alleinige Verantwortung für die Autorisierung einer deterministischen Aktion tragen.

Das ist die Aufgabe des Agent Gateway: eine Kontrollschicht zwischen der vom Agenten erzeugten Absicht und ihrer Ausführung im realen System einzuführen.

AWS beschreibt sein AgentCore Gateway nun als eine einheitliche Konnektivitätsschicht zwischen Agenten, ihren Tools und ihren Ressourcen. Die Policy Engine kann Anfragen abfangen und jeden Tool-Aufruf vor der Gewährung des Zugriffs bewerten. Google stellt sein Agent Gateway ebenfalls als zentralen Punkt für die Durchsetzung von Richtlinien bei Tool-Aufrufen und agentenbasierten Kommunikationen dar. (AWS Documentation)

Die Kategorie ist noch in Entwicklung. Nicht alle Plattformen verstehen unter dem Begriff Agent Gateway genau das Gleiche. Aber der architektonische Bedarf ist bereits klar:

Sobald ein Agent erhebliche Nebenwirkungen hervorbringen kann, muss eine deterministische Kontrollschicht seine Entscheidung von der Ausführung trennen.

Was ist ein agent gateway?

Ein Agent Gateway ist ein Interceptions- und Policy-Enforcement-Punkt auf dem Ausführungspfad der Aktionen eines Agenten.

Seine Aufgabe ist nicht, das Modell intelligenter zu machen. Sie besteht darin, zu prüfen, dass die vorgeschlagene Aktion autorisiert, gültig, nachverfolgbar und kompatibel mit den operativen Constraints des Systems ist.

Ein vereinfachter Ablauf funktioniert wie folgt:

1. Das Modell schlägt die Nutzung eines Tools mit strukturierten Parametern vor.
2. Der Orchestrator übermittelt diese Anfrage an das Gateway.
3. Das Gateway prüft Identität, Berechtigungen, Parameter, Kontingente und Geschäftsregeln.
4. Die Aktion wird autorisiert, abgelehnt oder suspendiert, um auf eine menschliche Validierung zu warten.
5. Das Ergebnis des Tools wird protokolliert und an den Orchestrator zurückgegeben.

Im Fall von clientseitig ausgeführten Tools mit Claude startet das Modell nicht selbst den Geschäftscode. Es gibt einen tool_use-Block zurück, woraufhin die Anwendung entscheidet, ob das Tool ausgeführt werden soll, und ihm sein Ergebnis übermittelt. Diese Trennung bietet genau den Interceptionspunkt, der für die Durchsetzung von Richtlinien erforderlich ist. (Claude Platform Docs)

Ein Agent Gateway kann sein:

• ein Komponente, die im Orchestrator entwickelt wurde;
• ein unabhängiger Service;
• eine Schicht um ein vorhandenes API Gateway;
• ein Policy Engine angebunden an MCP Server;
• ein verwalteter Service, bereitgestellt von einer Cloud-Plattform.

Wesentlich ist also nicht, einen Artikel namens „Agent Gateway" zu kaufen. Wesentlich ist es, einen nicht zu umgehenden Enforcement-Punkt vor jeder sensitiven Aktion zu haben.

Warum prompts und statische berechtigungen nicht ausreichen

Eine Anweisung wie „niemals mehr als 5.000 € erstatten" ist nützlich, um das Modell zu lenken. Das ist keine Sicherheitsregel.

Sie kann missverstanden, durch Prompt Injection umgangen, in einem zu langen Kontext verloren oder durch einen Denkfehler ignoriert werden.

OWASP ordnet excessive agency unter die Hauptrisiken von LLM-basierten Anwendungen ein: Ein Modell mit übermäßigen Funktionalitäten, Berechtigungen oder Autonomie kann aus einer unerwarteten, mehrdeutigen oder manipulierten Ausgabe heraus schädliche Aktionen auslösen. Der Leitfaden zu Agenten empfiehlt insbesondere Least Privilege, unabhängige Validierung sensitiver Aktionen und eine der Auswirkung angepasste menschliche Überwachung. (OWASP Gen AI Security Project)

Das Problem kommt nicht allein von einem „böswilligen" Agent. Ein Agent kann einen Incident auslösen, während er sein Ziel richtig verfolgt:

• er wiederholt eine Aktion wegen schlechtem Retry-Management;
• er misinterpretiert eine API-Antwort;
• er verwendet Informationen vom falschen Tenant;
• er wählt ein zu mächtiges Tool für die angeforderte Operation;
• er verkettete mehrere gültige Aktionen, die zusammen ein unerwünschtes Ergebnis produzieren;
• er wendet eine in einer E-Mail, einem Dokument oder einer Webseite injizierte Anweisung an;
• er setzt eine Operation fort, obwohl die erste Etappe teilweise fehlgeschlagen ist.

Der Schutz muss daher außerhalb des Denkprozesses des Modells liegen, in einer Schicht, die deterministische Regeln durchsetzen kann.

Die sechs kontrollen eines agenten in der produktion

Ein ernsthafter Gateway ist nicht nur eine Whitelist von Tools. Er muss sechs Fragen beantworten.

1. Identitätskontrolle

Wer fordert die Aktion an?

Man muss unterscheiden können:

• den Agent;
• die Anwendung oder den Workflow, der ihn ausführt;
• den Endnutzer, für den er handelt;
• die Organisation oder den Tenant;
• die Session;
• den Grad der erteilten Delegation.

Die Identität des Agenten darf sich nicht auf ein agent_id-Feld im Payload beschränken. Sie muss durch einen überprüfbaren Authentifizierungsmechanismus attestiert werden.

Google unterscheidet beispielsweise zwischen der Identität des Agenten selbst und seiner Fähigkeit, für sein eigenes Konto oder das eines Benutzers zu handeln. Das Agent Identity System stützt sich auf eine kryptografische Identität und den SPIFFE-Standard. (Google Cloud Documentation)

2. Autorisierungskontrolle

Kann dieser Agent dieses Tool in diesem spezifischen Kontext nutzen?

Die Regel darf nicht einfach nur sagen:

support-agent -> CRM-Zugriff

Sie muss ausdrücken können:

support-agent -> Lesezugriff auf Bestellungen des aktuellen Tenants -> keine globalen Exporte -> keine Löschungen -> Änderungen beschränkt auf bestimmte Felder

Das Least-Privilege-Prinzip muss auf Tools, Operationen, Ressourcen und Daten angewendet werden.

AWS ermöglicht beispielsweise, eine Policy Engine mit einem Gateway zu verknüpfen, um Tool-Aufrufe vor ihrer Ausführung zu bewerten. Regeln können als deterministische Richtlinien ausgedrückt werden, insbesondere mit Cedar. (AWS Documentation)

3. Parameter-kontrolle

Ist die Aktion mit diesen besonderen Parametern erlaubt?

Das Tool approve_refund zu autorisieren bedeutet nicht, alle Rückerstattungen zu autorisieren.

Das Gateway muss insbesondere überprüfen können:

• Beträge;
• Empfänger;
• Tenant-IDs;
• abgefragte Tabellen oder Spalten;
• zugängliche Domänen;
• Dateitypen und -größen;
• Datumsbereiche;
• Datenschemas;
• verbotene Werte.

Diese Validierung muss deterministisch sein und idealerweise auf strikten Schemas basieren, nicht auf einer zweiten Anweisung in natürlicher Sprache.

4. Verhaltenskontrolle

Bleibt das Gesamtverhalten des Agenten normal?

Ein isolierter Aufruf kann gültig sein, während die komplette Sequenz nicht gültig ist.

Das Gateway muss erkennen können:

• Schleifen;
• Anrufs-Bursts;
• Retries ohne Backoff;
• abnormale Kosten;
• plötzliche Tool-Wechsel;
• ungewöhnliche Aktionsfolgen;
• Ablehnung-Volumen, das einen blockierten oder falsch konfigurierten Agent zeigt.

Rate Limits und Circuit Breaker müssen pro Agent, Benutzer, Tenant, Tool und Aktionstyp berechnet werden, nicht nur pro IP-Adresse.

5. Effekt-kontrolle

Sollte die Aktion sofort ausgeführt werden?

Nicht alle Aktionen bergen das gleiche Risiko.

Eine vernünftige Policy kann unterscheiden:

• schreibgeschützte Aktionen;
• reversible Schreibvorgänge;
• externe, für Dritte sichtbare Aktionen;
• Finanzoperationen;
• Löschungen;
• Berechtigungsänderungen;
• irreversible Aktionen.

Bei kritischen Operationen kann das Gateway vorgeben:

• menschliche Validierung;
• verstärkte Authentifizierung;
• Benutzerbestätigung;
• ein Vier-Augen-Prinzip;
• eine vorherige Simulation;
• einen Idempotency Key;
• aufgeschobene Ausführung.

Die von Agent-Plattformen angebotenen Approval-Mechanismen folgen dieser Logik. OpenAI sieht insbesondere Pausen und Validierungen für Aufrufe vor, die Nebenwirkungen produzieren oder als destruktiv angesehen werden. (OpenAI Developers)

6. Kontrolle nach der ausführung

Was ist wirklich passiert?

Eine Aktion zu autorisieren reicht nicht aus. Man muss auch protokollieren:

• die ursprüngliche Anfrage;
• Identität und Delegation;
• die angewendete Policy;
• die Gateway-Entscheidung;
• die validierten Parameter;
• das aufgerufene Tool;
• die Tool-Antwort;
• den Endzustand;
• etwaige Fehler oder Kompensationen.

Dieses Nachverfolgungsprotokoll ermöglicht es, einen Incident zu rekonstruieren, die Performance von Agenten zu messen und eine schlechte Entscheidung des Modells von einem Fehler des externen Systems zu unterscheiden.

Das Tracing des OpenAI Agents SDK protokolliert beispielsweise Generierungen, Tool-Aufrufe, Handoffs, Guardrails und Custom Events eines Run. Diese Observability ist nützlich, aber sie ersetzt nicht ein dauerhaftes, auf die Anforderungen des Unternehmens abgestimmtes Geschäftsprotokoll. (OpenAI)

Wo positioniert man das gateway in der architektur?

Die korrekte Darstellung ist nicht unbedingt:

LLM -> Gateway -> Tool

In vielen Systemen kontaktiert das Modell das Tool nie direkt. Es produziert einen strukturierten Aufruf-Vorschlag, dann entscheidet der Orchestrator über die Fortsetzung.

Eine treuere Architektur sieht so aus:

┌────────────────────────┐
│ Benutzer / Ereignis    │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ Agent Orchestrator     │
│ LangGraph, n8n, custom │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ LLM                    │
│ Tool-Call-Vorschlag    │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ AGENT GATEWAY          │
│                        │
│ • Identität            │
│ • Autorisierung        │
│ • Validierung          │
│ • Kontingente          │
│ • menschliche Approval │
│ • Protokollierung      │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ Tool-Executor          │
│ API, MCP, Worker       │
└───────────┬────────────┘
            │
┌───────────▼────────────┐
│ Geschäftssystem        │
│ CRM, DB, Email, ERP    │
└────────────────────────┘

Das Gateway ist somit ein Policy Enforcement Point, platziert vor dem Tool-Executor.

Es muss unmöglich sein, diesen Punkt zu umgehen, indem man direkt anruft:

• die Datenbank;
• einen MCP Server;
• die Business-API;
• eine Cloud Function;
• einen Worker;
• einen Drittanbieter-Service.

Ein Gateway, das nur einen Zugriffspfad kontrolliert, während der Agent direkte Credentials zu den Tools hat, schafft eine Illusion von Sicherheit.

Agent gateway, API gateway und ai gateway: was sind die unterschiede?

Die drei Kategorien überschneiden sich teilweise, aber sie sprechen nicht genau das gleiche Problem an.

Ein API Gateway wie Kong, Nginx oder ein Cloud Service kann einen Teil der Lösung ausmachen. Es kann Anfragen bereits authentifizieren, begrenzen und protokollieren.

Was normalerweise fehlt, ist der agentenspezifische und geschäftliche Kontext:

• welcher Agent handelt;
• in wessen Namen;
• welche Absicht oder Aufgabe laufend ist;
• welches Tool aufgerufen wird;
• welche Effekte die Aktion haben kann;
• welche Geschäftsrichtlinie gilt;
• ob menschliche Genehmigung erforderlich ist;
• ob dieser Aufruf Teil einer anormalen Schleife ist.

Der richtige Ansatz ist also nicht unbedingt, das API Gateway zu ersetzen. Es kann angereichert oder durch eine dem Agenten gewidmete Policy-Schicht ergänzt werden.

Google definiert sein Agent Gateway übrigens als eine Netzwerk-Abstraktion, die Client-Agent-, Agent-Tool- und Agent-Agent-Interaktionen mit angewendeten Sicherheitsrichtlinien und Zugriffskontrolle regelt. (Google Cloud Documentation)

Drei konkrete use cases

Case 1: ein agent verwaltet kundenrückerstattungen

Der Agent analysiert eine Anfrage und schlägt eine Rückerstattung vor.

Eine Gateway-Policy könnte vorgeben:

Betrag ≤ 200 € :
    automatische Ausführung

200 € < Betrag ≤ 2.000 € :
    Ausführung erlaubt, wenn Konto Geschäftskriterien erfüllt

Betrag > 2.000 € :
    obligatorische menschliche Validierung

Betrag > 10.000 € :
    automatische Ablehnung für diesen Workflow

Die Modell-Entscheidung bleibt nützlich: Sie kann den Fall qualifizieren und einen Betrag vorschlagen. Aber die Finanzautorisierung wird durch eine unabhängige Regel kontrolliert.

AWS nutzt genau ein Rückerstattungs-Szenario in seiner Dokumentation, um zu zeigen, wie Policies autorisierte Beträge begrenzen können. (AWS Documentation)

Case 2: ein agent fragt sensible daten ab

Einem Agent einen generischen SQL-Zugang zu geben ist selten eine gute Idee.

Eine sicherere Architektur stellt enge Tools zur Verfügung:

get_customer_orders(customer_id)
get_order_status(order_id)
get_monthly_sales_summary(period)

Das Gateway prüft dann:

• dass der Benutzer auf den angeforderten Kunden zugreifen kann;
• dass der Tenant zur Session passt;
• dass nur autorisierte Spalten zurückgegeben werden;
• dass unnötige PII maskiert werden;
• dass der Aufruf schreibgeschützt bleibt;
• dass das Datenvolumen angemessen ist.

Der beste Schutz vor einer gefährlichen SQL-Query ist oft immer noch, das Modell nie in die Lage zu versetzen, willkürliches SQL zu generieren.

Case 3: ein agent konsumiert kostenpflichtige APIs

Ein Agent kann eine große Rechnung erzeugen, ohne dass einzelne Aufrufe anormal wären.

Das Gateway kann mehrere Budgets anlegen:

100 Aufrufe pro Minute pro Agent
1.000 Aufrufe pro Stunde pro Tenant
200 € pro Tag für den Workflow
10 € maximal pro einzelne Ausführung

Über einem Schwellenwert kann es:

• Aufrufe verlangsamen;
• einen Circuit Breaker öffnen;
• zu einem billigeren Modell oder Provider wechseln;
• nur das betroffene Tool suspendieren;
• auf Validierung warten;
• den Run stoppen.

Eine minimale implementierung

Die erste Version muss kein autonomes Produkt sein. Ein gut entworfener Wrapper um den Tool-Executor kann genügen.

from dataclasses import dataclass
from datetime import datetime, timezone
from decimal import Decimal
from typing import Any, Callable


class GatewayDenied(Exception):
    pass


@dataclass(frozen=True)
class InvocationContext:
    agent_id: str
    user_id: str
    tenant_id: str
    run_id: str


@dataclass(frozen=True)
class ToolPolicy:
    handler: Callable[..., Any]
    write_operation: bool = False
    max_amount: Decimal | None = None
    requires_approval: bool = False


class AgentGateway:
    def __init__(self, policies: dict[str, ToolPolicy], audit_sink):
        self.policies = policies
        self.audit_sink = audit_sink

    def invoke(
        self,
        context: InvocationContext,
        tool_name: str,
        params: dict[str, Any],
        approved_by: str | None = None,
    ) -> Any:
        started_at = datetime.now(timezone.utc)
        decision = "denied"
        result_status = "not_executed"

        try:
            policy = self.policies.get(tool_name)

            if policy is None:
                raise GatewayDenied("Tool not allowed")

            self._verify_identity(context)
            self._check_rate_limits(context, tool_name)
            self._validate_schema(tool_name, params)
            self._enforce_tenant_scope(context, params)

            if policy.max_amount is not None:
                amount = Decimal(str(params.get("amount", 0)))

                if amount > policy.max_amount:
                    raise GatewayDenied("Amount exceeds policy limit")

            if policy.requires_approval and approved_by is None:
                raise GatewayDenied("Human approval required")

            decision = "allowed"

            # Für wiederholbare Schreibvorgänge einen Idempotency Key verwenden.
            result = policy.handler(
                **params,
                tenant_id=context.tenant_id,
                idempotency_key=f"{context.run_id}:{tool_name}",
            )

            result_status = "succeeded"
            return result

        except Exception:
            result_status = "failed"
            raise

        finally:
            self.audit_sink.write({
                "timestamp": started_at.isoformat(),
                "agent_id": context.agent_id,
                "user_id": context.user_id,
                "tenant_id": context.tenant_id,
                "run_id": context.run_id,
                "tool": tool_name,
                "decision": decision,
                "result_status": result_status,
                # Nicht blind Secrets oder PII protokollieren.
                "params": self._redact(params),
                "approved_by": approved_by,
            })

Dieser Code veranschaulicht das Interceptions-Prinzip. Das ist kein produktionsbereites Gateway.

Je nach Kontext fehlt noch:

• kryptografische Authentifizierung;
• verteilter Storage für Kontingente;
• Delegation-Policy;
• strikte Schema-Validierung;
• Secret Management;
• Redaction sensibler Daten;
• dauerhafte und geschützte Protokolle;
• Timeouts;
• begrenzte Retries;
• Kompensationsmechanismen;
• hohe Verfügbarkeit;
• Revocation Procedures;
• Schutz vor direktem Tool-Zugriff.

Implementierungs-roadmap

Phase 1: aktionen inventarisieren und berechtigungen reduzieren

Vor dem Entwickeln eines Gateway listen Sie alle Agenten zugänglichen Tools auf.

Dokumentieren Sie für jedes Tool:

• zugängliche Ressourcen;
• mögliche Operationen;
• Nebenwirkungen;
• Reversibilität oder Irreversibilität;
• freigegebene sensible Daten;
• potenzielle Kosten;
• erforderlicher Approval-Grad.

Beginnen Sie dann mit:

• Entfernen unnötiger Tools;
• Trennen von Lese- und Schreibzugriffen;
• Ersatz generischer Tools durch enge Business-Operationen;
• Hinzufügen von Schema-Validierung;
• Protokollieren von Aufrufen und ihren Ergebnissen.

Phase 2: policies zentralisieren

Fügen Sie einen strukturierten Ausführungs-Kontext hinzu:

• Agent-Identität;
• Benutzer;
• Tenant;
• Run;
• Workflow-Absicht;
• Risiko-Grad;
• aktive Delegation.

Zentralisieren Sie dann:

• Autorisierungsregeln;
• Betragslimits;
• Kontingente;
• Approvals;
• zeitliche Einschränkungen;
• Daten-Regeln;
• Circuit Breaker.

Phase 3: industrialisieren

Wenn mehrere Teams, Agenten oder Umgebungen die gleichen Tools duplizieren, transformieren Sie die Schicht in einen gemeinsamen Service.

Fügen Sie hinzu:

• ein Policy Engine;
• zentrale Identitätsverwaltung;
• ein Agent und Tool Registry;
• versionierte Policies;
• korrelierte Traces;
• Alerts;
• Policy Tests;
• einen Observation-Modus ohne Blocking;
• Incident Procedures;
• Compliance Checks.

Das NIST AI Risk Management Framework empfiehlt, Funktionen zu identifizieren, die menschliche Überwachung erfordern, Rollen und Verantwortungen zu definieren und Kontroll-Mechanismen an Kontext und Risiko-Grad anzupassen. (NIST)

Die häufigsten implementierungs-fehler

1. Tool-namen kontrollieren, aber nicht die parameter

Eine Whitelist, die send_email autorisiert, ohne Empfänger, Domain, Content oder Volume zu prüfen, bietet nur beschränkten Schutz.

Eine nützliche Autorisierung bezieht sich auf:

Agent + Benutzer + Tenant + Tool + Operation + Ressource + Parameter

2. Einen umgehungs-weg offen lassen

Wenn der Workflow das CRM oder die Datenbank direkt aufrufen kann, ist das Gateway kein Enforcement Point.

Geschäftssystem-Credentials müssen vom kontrollierten Executor gehalten werden, nicht direkt dem Modell oder einem alternativen Worker freigelegt.

3. Nur die anfrage protokollieren

Eine Aktion kann autorisiert und dann teilweise fehlschlagen.

Man muss protokollieren:

• die Entscheidung;
• Ausführungs-Beginn;
• das Ergebnis;
• Retries;
• den Endzustand;
• etwaige Kompensationen.

Bei asynchronen Systemen verwenden Sie eine gemeinsame Korrelations-ID über Agent-Run, Invocation, Job und Business Event.

4. Secrets in traces speichern

Tools manipulieren oft Tokens, PII, Finanzdaten oder Kundencontent.

Ein nützliches Audit Trail bedeutet nicht, alle Parameter und Antworten unfiltriert zu protokollieren. Redaction und Retention Policies müssen von Anfang an geplant werden.

5. Die gleichen limits auf alle aktionen anwenden

Hundert Katalog-Lesezugriffe und hundert Überweisungen haben nicht das gleiche Risiko.

Policies müssen abhängen von:

• dem Tool;
• dem Impact;
• dem Tenant;
• dem Finanzbetrag;
• der Reversibilität;
• des Vertrauens in den Workflow.

6. Blockieren ohne den orchestrator zu informieren

Wenn eine Aktion abgelehnt wird, sollte der Agent einen verwertbaren Fehler erhalten:

{
  "code": "HUMAN_APPROVAL_REQUIRED",
  "message": "Refunds above 2000 EUR require approval.",
  "retryable": false
}

Eine vage Antwort wie Access denied zwingt den Agent oft, die gleiche Aktion zu wiederholen.

7. Observability mit autorisierung verwechseln

Einen Aufruf zu tracen hindert ihn nicht an der Ausführung.

Tracing hilft zu verstehen. Das Gateway muss auch können:

• autorisieren;
• ablehnen;
• ändern;
• suspendieren;
• Approval anfragen;
• einen Circuit Breaker öffnen.

Eigenentwickelter gateway oder spezialisierte lösung?

Die Anzahl der Agenten ist nicht das richtige Kriterium.

Ein einzelner Agent, der Überweisungen durchführen kann, kann starke Infrastruktur rechtfertigen. Fünfzig schreibgeschützte Agenten auf öffentlichen Daten können hinter einem relativ einfachen Wrapper bleiben.

Die Entscheidung sollte von der Kritikalität abhängen.

Beginnen sie intern, wenn:

• Sie wenige Tools haben;
• die Workflows beherrscht sind;
• die Regeln einfach sind;
• Sie bereits starke IAM und Observability Infrastruktur haben;
• die Schicht nah bei der Anwendung bleiben kann.

Industrialisieren oder kaufen sie, wenn:

• mehrere Teams die gleichen Kontrollen duplizieren;
• Policies zentralisiert werden müssen;
• Agenten mehrere Runtimes nutzen;
• MCP Server und Tools sich vervielfachen;
• Audit-Anforderungen anwachsen;
• Policies zu pflegen wird organisatorisch oder kognitiv belastend.

Woher weiß man, ob der agent ein gateway braucht?

Vergeben Sie einen Punkt für jede positive Antwort:

• Schreibt der Agent in ein Geschäftssystem?
• Kann er Daten löschen oder öffentlich machen?
• Verarbeitet er personenbezogene oder vertrauliche Daten?
• Kann er Ausgaben auslösen?
• Kann er einen Kunden oder Dritte kontaktieren?
• Hat er Zugriff auf mehrere Tools?
• Agiert er für mehrere Benutzer oder Tenants?
• Kann eine Aktion irreversibel sein?
• Kann ein Fehler zu einem Compliance Incident führen?
• Läuft der Workflow ohne direkte menschliche Überwachung?

Interpretation

• 0 bis 2 Punkte: ein einfacher Wrapper, enge Berechtigungen und Logs können genügen.
• 3 bis 5 Punkte: implementieren Sie einen expliziten Enforcement Point und versionierte Policies.
• 6 Punkte oder mehr: behandeln Sie das Gateway als kritische Architektur-Komponente.

Diese Gitter ist kein Standard. Sie soll eine auf Projektgröße oder Agent-Anzahl allein basierende Entscheidung vermeiden.

Schlussfolgerung

Ein Agent Gateway ist kein magischer Proxy, der ein agentenisches System automatisch sichert.

Es ist ein Architektur-Prinzip:

Die probabilistische Entscheidung des Modells darf nie allein die Autorisierung einer echten Aktion ausmachen.

Sobald ein Agent Nebenwirkungen hat, müssen Sie einen Kontrollpunkt haben, der seine Identität, Delegation, Berechtigungen, Parameter, Verhalten und Aktion-Impact prüfen kann.

Drei Prinzipien sind zu merken:

1. Der Prompt leitet; die Policy autorisiert.
   Eine Anweisung in natürlicher Sprache ersetzt keine deterministische Regel.

2. Die Kontrolle muss nicht zu umgehen sein.
   Alle sensiblen Zugriffe müssen durch denselben Enforcement Point.

3. Der Kontroll-Grad hängt vom Impact ab, nicht von der Agent-Anzahl.
   Ein einzelner Agent kann starke Governance rechtfertigen, wenn er Zahlungen, Berechtigungen oder sensible Daten verwaltet.

Sie brauchen nicht unbedingt eine spezialisierte Plattform vom ersten Prototype an. Aber Sie müssen früh definieren, wo die Grenze zwischen dem Agent-Vorschlag und dem liegt, was Ihr System wirklich autorisiert.

response = client.messages.create(
    model=MODEL_NAME,
    max_tokens=1024,
    tools=tool_definitions,
    messages=messages,
)

for block in response.content:
    if block.type != "tool_use":
        continue

    try:
        result = gateway.invoke(
            context=invocation_context,
            tool_name=block.name,
            params=block.input,
        )

        tool_result = {
            "type": "tool_result",
            "tool_use_id": block.id,
            "content": serialize_result(result),
        }

    except GatewayDenied as exc:
        tool_result = {
            "type": "tool_result",
            "tool_use_id": block.id,
            "is_error": True,
            "content": str(exc),
        }

    messages.append({
        "role": "assistant",
        "content": response.content,
    })

    messages.append({
        "role": "user",
        "content": [tool_result],
    })