MCP-Verbindungen ueber das AI Gateway absichern

MCP gibt KI-Agenten Zugriff auf Ihre Tools und Daten. So ueberwachen, inspizieren und blockieren Sie schaedlichen MCP-Traffic auf der Gateway-Ebene.

MCP gibt Agenten die Schluessel — wer bewacht die Tuer?

Das Model Context Protocol (MCP) wird rasant zum Standard, ueber den KI-Agenten mit externen Tools interagieren — Datenbanken, Dateisysteme, APIs, Code-Repositories. Statt Integrationen fest zu verdrahten, stellen Entwickler MCP-Server bereit, die Agenten dynamisch entdecken und aufrufen.

Das ist maechtig. Aber es ist auch eine massive Erweiterung Ihrer Angriffsflaeche.

MCP gibt einem KI-Modell effektiv die Faehigkeit, Dateien zu lesen, Datenbanken abzufragen, HTTP-Anfragen zu stellen und Code auszufuehren — alles basierend auf Instruktionen, die es in seinem Kontextfenster erhaelt. Wenn ein Angreifer diesen Kontext beeinflussen kann, kann er steuern, was der Agent mit Ihren Tools macht.

Die meisten Sicherheitsempfehlungen fuer MCP konzentrieren sich auf den Bau sicherer Server. Das ist wichtig, aber nur die halbe Wahrheit. Wenn Ihr Team MCP-Server von Drittanbietern nutzt — oder auch interne, die Sie nicht selbst geschrieben haben — brauchen Sie Sicherheit dort, wo der Traffic fließt: am Gateway.

Die MCP-Angriffsflaeche

Bevor wir Abwehrmaßnahmen besprechen, kartieren wir die Bedrohungen. MCP fuehrt vier Risikokategorien ein, die bei traditionellen API-Aufrufen nicht existierten:

Tool Poisoning — Ein boesartiger MCP-Server kann Tools mit irreführenden Beschreibungen anbieten. Das Tool namens read_file koennte tatsaechlich Daten an einen externen Endpunkt exfiltrieren. Da das Modell Tools anhand ihrer Beschreibungen auswaehlt, kann eine manipulierte Beschreibung das Agentenverhalten umlenken — ohne sichtbare Aenderung fuer den Nutzer.

Datenexfiltration ueber Tool-Ausgaben — Ein MCP-Server gibt Daten als Tool-Ergebnisse an das Modell zurueck. Hat der Server Zugriff auf sensible Systeme (Datenbanken, interne APIs), kann er PII, Zugangsdaten oder proprietaere Daten in den Kontext des Modells einschleusen — von wo sie in Logs, Antworten oder nachfolgende Tool-Aufrufe leaken koennen.

Prompt Injection ueber Tool-Beschreibungen — MCP-Tool-Beschreibungen werden in den System-Kontext des Modells aufgenommen. Ein Angreifer, der eine Tool-Beschreibung kontrolliert, kann Instruktionen injizieren, die die Absicht des Nutzers ueberschreiben. Das ist indirekte Prompt Injection, angewandt auf Tool-Metadaten.

Uebermaessig permissive Server-Konfigurationen — MCP-Server legen oft mehr Faehigkeiten offen als noetig. Ein Dateisystem-Server koennte Lese-/Schreibzugriff auf die gesamte Festplatte gewaehren, wenn der Agent nur ein Verzeichnis braucht. MCP selbst hat kein eingebautes Berechtigungsmodell.

Warum Server-seitige Sicherheit nicht reicht

OWASP hat einen praktischen Leitfaden fuer sichere MCP-Server-Entwicklung veroeffentlicht, der Eingabevalidierung, Ausgabebereinigung und Least-Privilege-Konfigurationen abdeckt. Solide Empfehlungen — fuer Server-Autoren.

Aber die meisten Teams schreiben keine eigenen MCP-Server. Sie nutzen welche. Community-Server fuer GitHub, Slack, Jira, Datenbanken und Dateisysteme werden mit minimalem Review in agentische Workflows eingebunden. Sie vertrauen darauf, dass jeder verbundene Server:

• Seine Eingaben korrekt validiert
• Keine sensiblen Daten in Tool-Ergebnissen leakt
• Beschreibungen hat, die das tatsaechliche Verhalten widerspiegeln
• Ihre Daten nicht an Dritte weitergibt

Das ist viel Vertrauen. Und selbst bei internen Servern, die Sie kontrollieren, fehlt zentralisierte Sichtbarkeit darueber, was zur Laufzeit tatsaechlich durch MCP-Verbindungen fließt.

Das ist dasselbe Problem, das API-Gateways vor einem Jahrzehnt fuer Microservices geloest haben: Sie brauchen einen Engpass, an dem Sie den gesamten Traffic inspizieren, loggen und mit Richtlinien versehen koennen — unabhaengig davon, was auf beiden Seiten laeuft.

MCP-Sicherheit auf Gateway-Ebene

Ein AI Gateway zwischen Ihrem Agenten und seinen MCP-Servern liefert Kontrollen, die weder Client noch Server allein durchsetzen koennen:

Tool-Call-Argumente inspizieren — Bevor ein Tool-Aufruf den MCP-Server erreicht, kann das Gateway die Argumente auf PII scannen (Namen, E-Mail-Adressen, Kreditkartennummern, API-Keys) und sie entweder schwaerzen oder den Aufruf komplett blockieren. So verhindern Sie, dass Ihr Agent versehentlich Kundendaten an ein Drittanbieter-Tool sendet.

Gesamten MCP-Traffic auditieren — Jeder Tool-Aufruf, jedes Ergebnis, jeder Fehler — geloggt mit vollem Kontext inklusive Trace-ID, ausloesender Prompt und Reasoning des Modells. Das schafft den Audit-Trail, den Compliance-Teams brauchen und den MCP nativ nicht bietet.

Injection erkennen und blockieren — Wenn das Gateway Prompt-Injection-Muster in Tool-Beschreibungen oder Tool-Ergebnissen erkennt, kann es die Antwort blockieren, bevor sie das Modell erreicht. Das ist der entscheidende Unterschied zwischen dem Loggen eines Angriffs und seinem Verhindern.

Tool-Aufrufe rate-limitieren — Ein Agent in einer Endlosschleife kann API-Kontingente aufbrauchen und Kosten in die Hoehe treiben. Rate Limiting auf Gateway-Ebene pro Tool, pro Server oder pro Trace verhindert, dass durchdrehende Agenten Schaden anrichten.

Allowlists durchsetzen — Nur Tool-Aufrufe an genehmigte MCP-Server zulassen. Wenn eine manipulierte Tool-Beschreibung versucht, den Agenten an einen unautorisierten Endpunkt umzuleiten, blockiert das Gateway den Aufruf.

Mit Evals die MCP-Tool-Nutzung verstehen

Logging zeigt, was passiert ist. Evals zeigen, ob es das Richtige war.

Wenn MCP-Traffic durch Ihr Gateway fließt, koennen Sie LLM-as-a-Judge-Evaluierungen auf Tool-Call-Muster ausfuehren, um Fragen zu beantworten, die Logs allein nicht klaeren:

Welche Tools ruft das Modell tatsaechlich auf? — Verfolgen Sie die Tool-Call-Verteilung ueber Ihre MCP-Server. Wenn ein Modell ploetzlich ein Tool aufruft, das es nie zuvor genutzt hat, lohnt sich ein genauerer Blick.

Sind die Tool-Aufrufe relevant fuer die Nutzeranfrage? — Ein Eval kann bewerten, ob jeder Tool-Aufruf angesichts des urspruenglichen Prompts notwendig und angemessen war. Ein niedriger Relevanz-Score kann darauf hindeuten, dass das Modell per indirekter Injection manipuliert wird — oder schlicht verwirrt ist.

Leakt das Modell Daten zwischen Tool-Aufrufen? — Evaluieren Sie, ob sensible Informationen aus der Ausgabe eines Tools in die Eingabe eines anderen Tools weitergegeben werden. Das deckt Datenexfiltrations-Muster auf, die eine Einzelaufruf-Inspektion uebersehen wuerde.

Qualitaets-Scoring fuer Tool-Ergebnisse — Nicht alle MCP-Server sind gleich. Eval-Scores zur Qualitaet von Tool-Ergebnissen helfen Ihnen, Server zu identifizieren, die verrauschte, unvollstaendige oder irreführende Daten liefern — bevor Ihre Nutzer es merken.

Evals auf Produktions-MCP-Traffic verwandeln Ihr Gateway von einem passiven Beobachter in einen aktiven Qualitaets- und Sicherheitsmonitor.

Inspizieren, auditieren und blockieren — nicht nur loggen

Die meisten Observability-Tools behandeln MCP-Traffic als einen weiteren Satz Log-Eintraege. Das reicht nicht, wenn Ihr Agent Schreibzugriff auf Produktionssysteme hat.

Das Sicherheitsmodell fuer MCP braucht drei Schichten:

Schicht 1: Echtzeit-Inspektion — Jeder Tool-Aufruf wird im laufenden Betrieb gescannt. PII-Erkennung laeuft auf Argumenten und Ergebnissen. Injection-Muster werden gegen Tool-Beschreibungen und -Ausgaben abgeglichen. Das geschieht synchron, bevor die Daten ihr Ziel erreichen.

Schicht 2: Aktive Blockierung — Wenn die Inspektion eine Bedrohung findet, flaggt das Gateway sie nicht nur — es blockiert den Aufruf. Das Modell erhaelt eine Fehlerantwort, der Trace protokolliert den blockierten Aufruf mit Begruendung, und ein Alert wird ausgeloest. Das ist der Unterschied zwischen „wir haben einen Injection-Versuch in unseren Logs erkannt" und „wir haben einen Injection-Versuch gestoppt, bevor er ausgefuehrt wurde."

Schicht 3: Kontinuierliche Evaluierung — Evals laufen asynchron auf abgeschlossenen Traces und fangen Muster ab, die Echtzeit-Inspektion nicht erkennen kann — etwa schrittweise eskalierende Berechtigungen ueber eine Kette von Tool-Aufrufen oder ein Modell, das durch wiederholte subtile Injections langsam zu einem bestimmten Tool gesteuert wird.

// Beispiel: MCP-Tool-Aufruf durch ein Gateway
// Das Gateway inspiziert, loggt und kann bei jedem Schritt blockieren

const response = await fetch("https://proxy.grepture.com/v1/chat/completions", {
  method: "POST",
  headers: {
    "Authorization": "Bearer gpt_your_key",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "claude-sonnet-4-5-20250514",
    messages: [
      { role: "user", content: "Summarize the Q1 sales report" }
    ],
    tools: [
      {
        type: "function",
        function: {
          name: "read_document",
          description: "Read a document from the company drive",
          parameters: {
            type: "object",
            properties: {
              path: { type: "string" }
            }
          }
        }
      }
    ]
  }),
});

// Das Gateway:
// 1. Loggt die gesamte Tool-Call-Kette in einem Trace
// 2. Scannt Tool-Argumente auf PII/Secrets vor der Weiterleitung
// 3. Prueft Tool-Beschreibungen auf Injection-Muster
// 4. Blockiert den Aufruf bei erkannter Bedrohung
// 5. Fuehrt asynchrone Evals zu Tool-Call-Relevanz und Datenfluss aus

Wie Grepture hilft

Grepture sitzt als AI Gateway im Request-Pfad — das bedeutet, MCP-Tool-Aufrufe, die ueber Ihre LLM-API laufen, passieren automatisch Grepture. Das gibt Ihnen:

Volle Trace-Sichtbarkeit — Jeder Tool-Aufruf erscheint im Trace-Wasserfall und zeigt die vollstaendige Kette von Tool-Aufrufen mit Timing, Argumenten und Ergebnissen. Sie sehen genau, was Ihr Agent getan hat und in welcher Reihenfolge.

PII-Erkennung auf Tool-Traffic — Greptures Erkennungsregeln laufen auf Tool-Call-Argumenten und -Ergebnissen und fangen sensible Daten ab, bevor sie Ihre Infrastruktur verlassen oder in den Kontext Ihres Modells gelangen. Ueber 50 integrierte PII-Muster, plus benutzerdefinierte Regeln.

Injection-Erkennung und -Blockierung — Prompt-Injection-Erkennung greift auf den gesamten Anfrage-Kontext, einschließlich Tool-Beschreibungen und -Ergebnisse. Wird eine Injection erkannt, kann Grepture die Anfrage blockieren und den Versuch protokollieren.

Evals auf Tool-Call-Muster — Fuehren Sie Evaluatoren auf Ihrem MCP-Traffic aus, um Tool-Call-Relevanz zu bewerten, anomale Muster zu erkennen und Qualitaet ueber die Zeit zu verfolgen. Benutzerdefinierte Eval-Prompts lassen Sie domaenenspezifische Qualitaetskriterien fuer die Tool-Nutzung Ihres Agenten definieren.

Kosten- und Usage-Tracking — Verfolgen Sie Token-Verbrauch und Kosten pro Trace, damit Sie genau wissen, was jeder MCP-gestuetzte Workflow kostet — einschließlich des Overheads von Tool-Call-Ketten.