MCP-Gateway statt MCP-Chaos: Egress, Credentials und Policy-as-Code fuer Agenten im eigenen Netz

Wer 2026 KI-Agenten produktiv betreibt, betreibt faktisch ein verteiltes System aus Werkzeugservern. Das Model Context Protocol (MCP) hat den Anschluss dieser Werkzeuge radikal vereinfacht – und damit auch das unkontrollierte Wachstum. In vielen Häusern läuft heute ein halbes Dutzend MCP-Server, aufgesetzt von Entwicklern, angebunden per Direktverbindung, versorgt mit statischen API-Keys aus Umgebungsvariablen. Das ist kein Betrieb, das ist ein Bastelzustand mit Produktionsdaten.

Dieser Artikel beschreibt die Gegenmaßnahme, die sich 2026 als Konsens herausgebildet hat: ein zentrales MCP-Gateway im eigenen Netz, das Authentifizierung, Egress-Kontrolle, Credential-Injection und Audit-Logging bündelt. Wir gehen die Zahlenlage durch, die Referenzarchitektur, das CB4A-Muster für Secrets, Policy-as-Code auf Netzwerkebene und den Migrationspfad auf die MCP-Spezifikation 2026-07-28.

Die Lage: warum direkte Agent-zu-Server-Verbindungen nicht tragen

Die Sicherheitsbilanz des MCP-Ökosystems ist im ersten Halbjahr 2026 messbar geworden. Zwischen Januar und April 2026 wurden mehr als 40 CVEs gegen MCP-Implementierungen offengelegt – quer durch die Python-, TypeScript-, Java- und Rust-SDKs. Mitte 2026 lag die Kadenz bei rund einer neuen CVE alle vier Tage. Das ist keine Serie von Einzelfehlern, sondern ein strukturelles Muster: Ein junges Protokoll trifft auf Implementierungen, die Konfiguration in Kommandoausführung übersetzen.

Die belastbarste Bestandsaufnahme liefert die Studie Exposed by Design: A Dynamic Security Assessment of Internet-Facing MCP Servers at Scale von Nicolas Padilla (arXiv 2608.00150, eingereicht am 31.07.2026). Sie fand über 21.000 aus dem Internet erreichbare MCP-Server-Instanzen. 640 davon wurden über vier Messläufe als produktiv bestätigt, 414 dynamisch auditiert. Das Ergebnis dieser Audits ist der eigentliche Schockwert.

Befund	Wert	Quelle / Bezugsgröße
Offen erreichbare Instanzen	> 21.000	arXiv 2608.00150, Scan 07/2026
Ohne OAuth-Authentifizierung	91,8 %	von 414 dynamisch auditierten Servern
Tools mit freier Shell-Ausführung	687	ohne jede Zugriffskontrolle
Meldepflichtige Schwachstellen	68	SQL-Injection, SSRF, Path Traversal, Prompt-Template-Injection
Server, die binnen 3 Tagen verschwanden	41,6 %	der bestätigten Server zwischen zwei Messläufen
Ökosystemgröße (24.05.2026)	9.652 / 15.926	Records in der offiziellen Registry / GitHub-Repos mit Topic „mcp-server“

Der Wert, den viele überlesen, ist die Fluktuation: 41,6 Prozent der bestätigten Server waren drei Tage später weg. Ein Sicherheitsmodell, das darauf beruht, einzelnen Servern zu vertrauen, kann bei dieser Halbwertszeit nicht funktionieren. Vertrauen muss auf eine Allowlist wandern, die Sie selbst pflegen – nicht auf Server, die Ihr Team am Dienstag entdeckt und die am Freitag nicht mehr existieren.

Einzelfälle, die die Klasse der Fehler zeigen

• CVE-2026-33032 (März 2026, CVSS 9.8): nginx-ui-MCP-Integration, unauthentifizierte Befehlsausführung über den MCP-Message-Endpoint, über 2.600 öffentlich erreichbare Instanzen.
• CVE-2026-0755 (Januar 2026, CVSS 9.8): inoffizielles Gemini-MCP-Tool, Command Injection über execAsync.
• CVE-2025-6514: mcp-remote mit über 437.000 Downloads – Remote Code Execution auf der Client-Maschine über bösartige Authorization-Endpoints.
• CVE-2025-49596 (CVSS 9.4): MCP Inspector, unauthentifizierte RCE im Entwicklerwerkzeug selbst.

Dazu kommt die Lieferkette. Der OX-Security-Report The Mother of All AI Supply Chains (April 2026) beziffert rund 150 Millionen betroffene Downstream-Package-Downloads und bis zu 200.000 potenziell verwundbare Instanzen. Ursache ist derselbe Mechanismus: Konfigurationswerte werden im STDIO-Transport ohne ausreichende Sanitisierung zu Kommandozeilen.

Die Credential-Hygiene bildet die Ausgangslage ab. Ein Astrix-Audit von über 5.200 MCP-Servern (Oktober 2025) fand nur 8,5 Prozent mit OAuth, 53 Prozent mit statischen API-Keys oder Personal Access Tokens und 79 Prozent, die Schlüssel per Umgebungsvariable übergeben. Equixly maß im Februar 2026 43 Prozent Anfälligkeit für Command Injection, BlueRock Security 36,7 Prozent SSRF-Anfälligkeit bei über 7.000 untersuchten Servern.

Die CSI benennt vier operative Anforderungen, an denen sich jede Architektur messen lassen muss: kryptografische Message-Integrität auf Protokollebene statt nur TLS; Least Privilege an der Tool-Call-Grenze ohne Ambient Authority; ein manipulationssicheres, kryptografisch signiertes Audit-Log über jede Agenten-Aktion und jeden Tool-Call; sowie durchgängige Trust Chains über Clients, Gateways und Server. Als Maßnahmen nennt sie unter anderem filternde Egress-Proxies, DLP, Sandboxing, Output-Filtering und lokale MCP-Scans.

Referenzarchitektur: das Gateway als einziger Ausgangspunkt

Die Zielarchitektur ist unspektakulär und genau deshalb tragfähig: Ein Reverse-Proxy im eigenen Rechenzentrum terminiert sämtlichen Agent-zu-Tool-Verkehr. Agenten kennen ausschließlich die Gateway-Adresse. Kein Agent hält eine Zielserver-URL, keinen Hostnamen, keinen Port.

Die vier Eigenschaften, die das Gateway liefern muss

1. Identität am Eingang. Der Agent authentifiziert sich per OIDC-Token gegen den unternehmenseigenen Identity Provider. Aus diesem Token leitet das Gateway ab, welche Tools dieser Agent für welchen Nutzer aufrufen darf – nicht der Agent selbst.
2. mTLS nach hinten. Zwischen Gateway und MCP-Servern läuft gegenseitige TLS-Authentifizierung. Ein Server, der kein gültiges Client-Zertifikat des Gateways sieht, antwortet nicht. Damit sind Direktverbindungen aus dem Netz heraus technisch unmöglich, nicht nur untersagt.
3. Rate-Limits und Quotas je Tool. Ein Agent in einer Schleife ist der Normalfall, nicht die Ausnahme. Ohne Limit pro Tool und pro Agent wird aus einem Logikfehler ein Ausfall des angebundenen ERP-Systems.
4. Per-Tool-Observability. Latenz, Fehlerquote und Aufrufvolumen je einzelnem Tool – nicht aggregiert über „den Agenten“. Ohne diese Granularität ist Kapazitätsplanung Raten.

Betrieblich passt das Gateway in jedes bestehende Setup: als Container unter Docker für kleine Installationen, als Deployment in Kubernetes mit Netzwerk-Policies für alles darüber. Entscheidend ist nicht die Laufzeitumgebung, sondern dass es die einzige Route ist. Ein Gateway, das man umgehen kann, ist Dekoration. Wie sich ein solcher Durchsetzungspunkt in eine On-Premise-KI-Landschaft einfügt, beschreiben wir auf unserer Seite zum KI-Gateway.

Ein Hinweis zur Erwartungshaltung: Ein Gateway ist ein Guardrail auf Transportebene. Es ersetzt weder die Härtung der Server dahinter noch die Prüfung der Tool-Beschreibungen auf Prompt-Injection. Es sorgt dafür, dass ein Treffer begrenzt bleibt und dokumentiert ist.

Credential-Injection: Secrets gehören nicht in den Agenten-Kontext

Der gravierendste Konstruktionsfehler heutiger Setups: Der Agent hält das Credential. Ein API-Key liegt in der Umgebungsvariable des MCP-Servers oder – schlimmer – wandert als Teil eines Tool-Parameters durch den Modellkontext. Damit steht er in Traces, in Debug-Logs, in Konversationshistorien und potenziell in Trainingsdaten.

Die Antwort darauf heißt CB4A – Credential Broker for Agents. Der IETF-Draft draft-hartman-credential-broker-4-agents-00 erschien im März 2026, motiviert durch die TeamPCP/LiteLLM-Supply-Chain-Kompromittierung. Sein Kernprinzip ist eine saubere Gewaltenteilung: Policy Decision Point (PDP) und Credential Delivery Point (CDP) werden getrennt. Wer „ja“ sagt, fasst nie Credentials an; wer Credentials herausgibt, entscheidet nie. Der Draft hält zugleich fest, dass der Broker das höchstwertige Angriffsziel der gesamten Architektur ist – eine Aussage, die man beim Betrieb ernst nehmen sollte.

Die konkrete Umsetzung beschreibt das Linux-Foundation-Projekt agentgateway (ursprünglich von Solo.io, am 25.08.2025 in die Linux Foundation aufgenommen) im Beitrag Credential Injection Patterns for AI Agents vom 27.07.2026. Umgesetzt ist dort CB4A Model A, das Proxy-Gateway-Muster:

• Der Agent erhält nie ein echtes Credential – auch kein kurzlebiges.
• Das Gateway fängt den ausgehenden Call ab, wendet die Policy an und injiziert das Bearer-Credential just-in-time in den Request-Header.
• Token binden an die Nutzeridentität, nicht an eine Session.
• Die Authentisierung läuft zweibeinig: Leg 1 ist „eager auth“ beim Verbindungsaufbau über ein IdP-JWT; Leg 2 ist „elicitation“ – der Third-Party-OAuth-Token wird beim ersten Tool-Call abgefangen und in einem Security Token Service abgelegt.

Die Alternativen aus demselben Text sind Model B (Token Minting: kurzlebige, eng gescopte Token mit DPoP-Sender-Constraint) und Model C (langlebige Credentials mit nachträglicher Revocation). Model C wird als schwächstes Muster ausdrücklich nicht empfohlen. Für die meisten Unternehmen ist Model A das primäre Muster.

CB4A-Modell	Agent sieht Credential?	Einsatzempfehlung
Model A – Proxy Gateway	Nein, Injektion am Egress	Primäres Muster
Model B – Token Minting	Ja, kurzlebig und DPoP-gebunden	Wenn Direktverbindung unvermeidbar
Model C – langlebige Credentials	Ja, dauerhaft	Ausdrücklich nicht empfohlen

Wenn das Gateway Credentials hält, wird der Vault zum kritischsten Bauteil. Der Folgebeitrag Protecting the Token Vault vom 03.08.2026 beschreibt den KMS-basierten Schutz genau dieses Speichers. Praktisch heißt das: Hardware- oder KMS-gestützte Verschlüsselung, getrennte Administrationsrechte für Vault und Gateway-Konfiguration, und Rotation zentral statt in jedem Agenten. Der Nebeneffekt ist erheblich – ein rotierter Schlüssel wird an genau einer Stelle getauscht, nicht in acht Deployment-Manifesten.

Egress-Allowlisting: die harte Grenze

Ohne definierte Ausgangsziele kann kein Guardrail einen fehlgeleiteten Agenten stoppen. Ein Modell, das über eine manipulierte Tool-Beschreibung dazu gebracht wird, Daten an eine fremde Adresse zu senden, tut das – wenn die Adresse erreichbar ist. Egress-Allowlisting ist die notwendige Bedingung dafür, dass alle anderen Kontrollen überhaupt wirken. Hinreichend ist sie nicht: Die NSA nennt Egress-Filterung ausdrücklich zusammen mit DLP, Sandboxing, Output-Filtering und Message-Integrität.

Drei Regeln, die in der Praxis funktionieren

1. Default-Deny für ausgehende Verbindungen. Alles, was nicht auf der Liste steht, wird verworfen – nicht geloggt und durchgelassen. Ein Warn-Modus ist als Einführungsphase legitim, als Dauerzustand ist er wertlos.
2. Zielliste je Tool, nicht je Agent. Ein Tool hat einen klar umrissenen Zweck und damit eine kurze, stabile Zielliste. Ein Agent kombiniert Tools und hätte damit die Vereinigungsmenge aller Rechte – genau das Ambient-Authority-Problem, das die NSA-CSI benennt.
3. DNS- und Proxy-Interception gegen Umgehung. Ein Allowlisting auf Hostnamen-Ebene ohne kontrollierten Resolver ist umgehbar. Interner Resolver, transparenter Forward-Proxy, keine direkten ausgehenden Routen aus dem Agenten-Netzsegment.

Für Tool-Use-Szenarien mit Schreibrechten empfiehlt sich zusätzlich eine Zweiteilung der Liste: lesende Ziele werden breit freigegeben, schreibende eng und namentlich. Die 687 Tool-Instanzen mit uneingeschränktem Shell-Zugriff aus der arXiv-Studie sind die Mahnung dazu.

Policy-as-Code auf Netzwerkebene

Bis 2026 scheiterte Enforcement an einem banalen Problem: Wer entscheiden wollte, welches Tool gerade aufgerufen wird, musste den JSON-RPC-Body parsen. Für ein Gateway ist das teuer, für eine WAF praktisch unmöglich.

Die MCP-Spezifikation 2026-07-28 löst das. Mit SEP-2243 sind die Header Mcp-Method und Mcp-Name auf Streamable-HTTP-POST-Requests verpflichtend. Ergänzend erlaubt x-mcp-header Custom-Header aus Tool-Parametern. Damit können Gateways und WAFs routen, autorisieren und messen, ohne den Body anzufassen. Weicht ein Header vom Body ab, greift der HeaderMismatchError mit Fehlercode −32020 (umnummeriert von −32001) – die Diskrepanz ist also ein definierter Fehlerfall und kein stiller Bypass.

Daraus folgt der Betriebsmodus: Regeln gehören versioniert ins Repository, nicht in eine Gateway-UI. Eine Policy-Datei, die Mcp-Name auf Rollen und Zielsysteme abbildet, ist reviewbar, diffbar und rollbackfähig. Und sie ist testbar – was in der Praxis der wichtigste Punkt ist: Zu jeder Positivregel gehört ein Negativfall in der Testsuite. Wenn Ihre Policy-Tests nur prüfen, dass erlaubte Aufrufe durchgehen, testen Sie die Hälfte.

Audit-Log: was Sie protokollieren müssen

Die NSA-CSI verlangt ein manipulationssicheres, kryptografisch signiertes Audit-Log über jede Agenten-Aktion und jeden Tool-Call. Für deutsche Unternehmen kommt der doppelte Nutzen hinzu: Dieselben Datensätze tragen die Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO und die Protokollierungsanforderungen des EU AI Act.

Ein brauchbarer Log-Satz je Tool-Call enthält mindestens:

• Agenten-Identität – die Non-Human-Identity aus dem OIDC-Token, plus die menschliche Identität, in deren Auftrag gehandelt wird.
• Tool und Methode – direkt aus Mcp-Name und Mcp-Method übernommen.
• Parameterhash statt Parameterinhalt – nachweisbar identisch, ohne personenbezogene Daten zu duplizieren.
• Entscheidung – allow oder deny, mit der Regel-ID, die gegriffen hat.
• Zeitstempel, Zielsystem, Ergebnisstatus – inklusive HTTP-Status und Latenz.
• Trace-Kontext – die Spezifikation 2026-07-28 dokumentiert mit SEP-414 OpenTelemetry-Felder (traceparent, tracestate, baggage) als _meta-Konvention. Damit lässt sich ein Tool-Call ohne Eigenbau durch die gesamte Kette verfolgen.

Zwei Festlegungen fehlen in fast jedem Erstentwurf: die Aufbewahrungsfrist und die Pseudonymisierung. Legen Sie beides vor dem Produktivgang fest – 90 Tage für den operativen Log, längere Fristen nur für signierte Compliance-Auszüge, und Parameterhashes statt Klartext, sobald personenbezogene Daten im Spiel sein können. Ein Audit-Log, das selbst zum Datenschutzproblem wird, ist kein Fortschritt. Details zur Absicherung solcher Ketten behandeln wir unter KI-Sicherheit und Härtung.

Migrationspfad von bestehenden MCP-Servern

Der häufigste Fehler bei der Einführung ist die Reihenfolge. Wer das Gateway davorstellt, aber die alten Direktrouten offen lässt, hat den Aufwand und keinen Gewinn. Der Pfad, der sich bewährt hat:

1. Inventarisieren. Welche MCP-Server laufen, wer hat sie aufgesetzt, welche Credentials nutzen sie, welche Tools exponieren sie? Erfahrungsgemäß findet man in dieser Phase zwei bis drei Server, von denen die IT nichts wusste.
2. Vom Netz nehmen, dann anbinden. Server zuerst aus dem erreichbaren Segment entfernen, anschließend hinter dem Gateway wieder verfügbar machen. Nicht umgekehrt. In den allermeisten Unternehmensszenarien braucht kein MCP-Server eine Internet-Erreichbarkeit – das allein entfernt die größte Angriffsfläche.
3. Read-only-Parallelbetrieb. In der ersten Phase laufen nur lesende Tools über das Gateway, schreibende bleiben deaktiviert. So testen Sie Policies unter Last, ohne Datenrisiko.
4. Alt-Features mit Auslauffristen versehen. Jede Ausnahme bekommt ein Datum. Ohne Frist wird aus „übergangsweise“ ein Dauerzustand.
5. Schreibrechte stufenweise freigeben – Tool für Tool, jeweils mit dokumentierter Zielliste und Rate-Limit.

Was Sie mit 2026-07-28 gleich mitmigrieren

Die Spezifikation 2026-07-28 (Vorgänger: 2025-11-25) verändert das Betriebsmodell so deutlich, dass eine Gateway-Einführung ohnehin darauf aufsetzen sollte:

• Sessions sind weg. Protokoll-Sessions und der Header Mcp-Session-Id wurden mit SEP-2567 entfernt. Gateways brauchen keine Session-Affinität mehr – Load-Balancing wird trivial. Wer heute noch Sticky Sessions plant, plant für die Vorgängerversion.
• MCP ist stateless. Der Handshake aus initialize und notifications/initialized entfällt (SEP-2575); jede Anfrage trägt Protokollversion und Client-Capabilities in _meta.
• Neues RPC server/discover, das Server implementieren müssen – die saubere Grundlage für ein Gateway-seitiges Tool-Inventar.
• HTTP+SSE ist formal deprecated. Migration auf Streamable HTTP; SSE-Resumability und Last-Event-ID wurden entfernt.
• OAuth 2.0 Dynamic Client Registration (RFC 7591) ist deprecated zugunsten von Client ID Metadata Documents. Wer die Gateway-Anbindung neu baut, sollte gar nicht erst über DCR gehen.

Damit steht der Kern: Ein Gateway, das auf Mcp-Method und Mcp-Name routet, ohne Session-Affinität skaliert, Credentials nach CB4A Model A am Egress injiziert, gegen eine Default-Deny-Allowlist prüft und jeden Call signiert protokolliert. Das ist der Unterschied zwischen einem MCP-Setup, das ein Audit übersteht, und einem, das man erklären muss. Unterstützung bei Aufbau und Anbindung finden Sie unter MCP-Integration.

Quellen & Primärbelege

Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. arXiv 2608.00150 Exposed by Design, Nicolas Padilla, 31.07.2026
2. modelcontextprotocol.io MCP-Spezifikation 2026-07-28, Key Changes
3. agentgateway.dev Credential Injection Patterns for AI Agents (CB4A Model A)
4. agentgateway.dev Teil 2: Protecting the Token Vault, 03.08.2026
5. blog.christianposta.com Credential Brokering Patterns for AI Agents, Teil 1
6. media.defense.gov NSA CSI: MCP Security Design Considerations (PDF)
7. nsa.gov Pressemitteilung zur CSI, Mai 2026
8. speakeasy.com Analyse: Gateway als Trust Boundary
9. executivegov.com Veröffentlichungsdatum 21.05.2026
10. forkast.news Zusammenfassung der Exposure-Zahlen
11. practical-devsecops.com Registry-, Astrix-, Equixly- und BlueRock-Zahlen
12. securitywall.co CVE-Kadenz Januar bis April 2026
13. authzed.com Timeline der MCP-Vorfälle mit CVE-IDs und CVSS
14. linuxfoundation.org agentgateway in der Linux Foundation, 25.08.2025

Häufig gestellte Fragen zum MCP-Gateway

Reicht ein Reverse-Proxy, oder brauche ich ein dediziertes MCP-Gateway?

Ein generischer Proxy kann TLS terminieren, aber nicht auf Tool-Ebene autorisieren, Secrets injizieren oder Per-Tool-Metriken liefern. Genau dafür existieren MCP-Gateways.

Was ist das CB4A-Muster?

Credential-Broker-for-Agents: Das Gateway injiziert Zugangsdaten just-in-time beim ausgehenden Aufruf, sodass sie nie im Agenten-Kontext oder in Traces auftauchen.

Wie helfen die neuen MCP-Header Mcp-Method und Mcp-Name?

Gateways und WAFs können damit routen, messen und Regeln durchsetzen, ohne JSON-Bodies zu parsen – die technische Voraussetzung für Policy-Enforcement auf Netzwerkebene.

Müssen MCP-Server aus dem Internet erreichbar sein?

In den allermeisten Unternehmensszenarien nein. Interne Erreichbarkeit hinter dem Gateway genügt und entfernt die größte Angriffsfläche vollständig.