Kein Tool-Call ohne Gateway

Was zwischen Agent und System passiert

Ohne Gateway spricht der Agent direkt mit dem Werkzeug. Das funktioniert im Prototyp und ist in Produktion nicht verantwortbar: Es gibt keine Stelle, an der ein Aufruf abgelehnt, begrenzt oder dokumentiert werden kann.

MCP (Model Context Protocol)

Offener Standard für die Anbindung von Werkzeugen und Datenquellen an LLM-Anwendungen. Ein einmal gebauter MCP-Server funktioniert mit jedem MCP-fähigen Client — das reduziert Integrationsaufwand und Anbieterbindung.

MCP Registry

Verzeichnis verfügbarer MCP-Server samt Tool-Beschreibungen. Sie verschiebt die Werkzeugauswahl von der Startzeit in die Laufzeit: Ein Agent kann Werkzeuge entdecken, die es beim Deployment noch nicht gab.

Tool-Gateway

Kontrollpunkt zwischen Agent und Werkzeug mit Authentifizierung, Schema-Validierung, Rate-Limiting, Policy-Entscheid und Audit-Log. Es ist die einzige Stelle, an der ein Aufruf technisch verhindert werden kann.

Werkzeuge, die wir ohnehin betreiben

Der Vorteil eines Managed Service Providers als Plattformbetreiber: Die Systeme, die ein Agent ansprechen soll, betreiben wir häufig bereits. Diese MCP-Server sind Teil des Katalogs, weitere entstehen projektbezogen.

Discovery zur Laufzeit

Statisch konfigurierte Werkzeuglisten altern schlecht: Jedes neue Tool erfordert ein Deployment, jede Entfernung hinterlässt tote Verweise. Über die Registry fragt der Agent zur Laufzeit, welche Werkzeuge für seine Aufgabe verfügbar und für seine Identität freigegeben sind.

# Was ein Agent sehen und aufrufen darf. Die Registry liefert nur
# Werkzeuge zurueck, die zu Selector UND Scopes des Agenten passen.
agent: action-agent

discovery:
  selector: "domain in (billing, crm) and trust == verified"
  refresh: 5m

tools:
  # Lesend: grosszuegig, aber mit Statement-Allowlist.
  - name: postgres.query
    allow: true
    constraints: { statements: ["SELECT"], max_rows: 500 }

  # Schreibend mit Geld: Limit im Gateway, nicht im Prompt.
  # Ein Modell kann eine Prompt-Regel ignorieren — diese hier nicht.
  - name: stripe.refund
    allow: true
    constraints: { max_amount_eur: 250, currency: ["EUR"] }
    require_approval_above_eur: 250
    idempotent: true

  # Nicht verifizierte Quellen: erlaubt, aber isoliert und
  # mit markierter Rueckgabe, die nie als Anweisung gilt.
  - name: partner.lookup
    allow: true
    sandbox: strict
    egress: ["partner.example:443"]
    treat_output_as: untrusted_data

audit:
  record: [agent_id, tool, params_sanitized, latency_ms, tokens, decision]
  retention: "365d"

Agentic Supply Chain: das neue Risiko

2026 ist das ein eigener Risikotyp und kein Randthema mehr: Ein MCP-Server, ein Connector oder ein Prompt-Template kann sich zur Laufzeit anders verhalten, als es deklariert. Drei Muster sehen wir regelmäßig:

• Tool-Beschreibung als Angriffsfläche. Die Beschreibung eines Werkzeugs landet im Modellkontext. Wer sie kontrolliert, beeinflusst das Verhalten des Agenten — auch ohne je aufgerufen zu werden.
• Rückgabe als Anweisung. Ein Dokument, eine Ticketnotiz oder eine API-Antwort enthält Text, der wie eine Anweisung aussieht. Ohne klare Trennung zwischen Daten und Instruktion folgt das Modell ihr. Das ist Prompt Injection über die Hintertür.
• Verhaltensänderung nach Update. Ein extern gepflegter MCP-Server ändert sein Verhalten in einer neuen Version, ohne dass sich das Schema ändert.

Unsere Gegenmaßnahmen: verifizierte Quellen mit gepinnter Version, Ausführung nicht vertrauenswürdiger Server in einer isolierten Umgebung mit Egress-Allowlist, konsequente Markierung von Rückgaben als Daten — und Schema-Validierung auch auf dem Rückweg. Mehr dazu im Kapitel Sandboxing und Containment.

Was das nicht löst