MCP-Server absichern mit Azure API Management

In den meisten Unternehmen, die gerade mit Claude Code, GitHub Copilot oder vergleichbaren KI-Agenten arbeiten, läuft mindestens ein MCP-Server, den die IT-Abteilung nicht kennt. Ein Entwickler hat sich per claude mcp add schnell die Anbindung an Jira, Slack oder eine interne Datenbank eingerichtet, weil es den Alltag beschleunigt - und niemand hat geprüft, welchem Server da eigentlich vertraut wird, welche Berechtigungen er bekommt oder wohin die Daten fließen, die er zurückliefert. MCP-Server absichern heißt deshalb zuerst: sichtbar machen, was längst läuft, bevor man über Policies spricht.

Das Model Context Protocol (MCP) ist die Anbindung, über die Claude Code und vergleichbare Agenten auf externe Tools und Daten zugreifen - wie diese Anbindung auf Client-Seite technisch funktioniert, haben wir im Grundlagenartikel zum Claude-Code-Harness eingeordnet. Dieser Artikel setzt eine Ebene höher an und beschäftigt sich mit der Governance-Frage: Welche konkreten Angriffsvektoren nennen die MCP-Spezifikation selbst und unabhängige Sicherheitsstellen wie die NSA und die Coalition for Secure AI (CoSAI)? Und wie lässt sich Azure API Management als zentrale Schicht vor MCP-Server-Zugriffe schalten, die Registry, Authentifizierung, Rate Limiting und Audit-Logging bündelt?

Zwei Dinge vorweg, weil sie den ganzen Artikel prägen. Erstens ersetzt eine Gateway-Schicht keine saubere Serverauswahl - sie macht ungeprüfte Server sichtbar und kontrollierbar, mehr nicht. Zweitens ist ein Teil dessen, was Sie hier lesen, ausdrücklich als Public Preview markiert, weil Microsoft mitten in der Entwicklung einer dedizierten KI-Gateway-Ebene für genau dieses Problem steckt.

Warum MCP-Server zum Governance-Problem werden

MCP ist ein offener, herstellerübergreifender Standard - anders als bei einer einzelnen Plattform gibt es keine zentrale Stelle, die von sich aus alle MCP-Verbindungen im Unternehmen kennt. Für Claude Code haben wir die drei Konfigurations-Scopes (Local, Project, User) im Grundlagenartikel bereits eingeordnet; das Problem betrifft aber jeden MCP-fähigen Client gleichermaßen, nicht nur Claude Code. Anthropics eigene Dokumentation formuliert es unumwunden: Claude Code habe „no built-in MCP server registry that users can browse and install from” - eine zentrale Übersicht existiert von Haus aus nicht, sie muss aktiv aufgebaut werden.

Verschärft wird das durch die Spezifikation selbst: Autorisierung ist bei MCP ausdrücklich optional. Die aktuelle MCP-Spezifikation (Version 2026-07-28, siehe unten) hält fest, dass Implementierungen über HTTP-Transport der Authorization-Spezifikation folgen sollten - verpflichtend ist das nicht, und für den STDIO-Transport rät die Spezifikation sogar ausdrücklich davon ab und verweist stattdessen auf Umgebungsvariablen. Ein MCP-Server kann also völlig legitim ohne jede eingebaute Zugriffskontrolle betrieben werden. Genau diese Lücke ist der Ansatzpunkt für eine vorgeschaltete Governance-Schicht.

Die MCP-Spezifikation: offiziell benannte Angriffsvektoren

Die aktuelle MCP-Spezifikation trägt den Versionsstand 2026-07-28 und ist laut modelcontextprotocol.io die derzeit gültige „Current”-Revision (Stand: August 2026). Ihr „Security Best Practices”-Dokument, das die Authorization-Spezifikation ergänzt, beschreibt eine Reihe konkret benannter Angriffe mit Mitigation - das ist keine lose Sammlung, sondern die offizielle Referenz für Implementierer und Sicherheitsteams:

Confused Deputy Problem. Ein MCP-Proxy-Server mit statischer Client-ID gegenüber einem Drittanbieter-Autorisierungsserver kann missbraucht werden, um Autorisierungscodes ohne echte Nutzerzustimmung zu erlangen - ausgenutzt wird die Kombination aus statischer Client-ID, dynamischer Client-Registrierung und einem beim Anbieter gesetzten Consent-Cookie. Gegenmaßnahme laut Spezifikation: zwingend eine Per-Client-Consent-Prüfung durch den Proxy vor der Weiterleitung.
Token Passthrough. Ein Server, der Tokens ungeprüft entgegennimmt und unverändert an nachgelagerte APIs durchreicht, hebelt Rate Limiting und Audit-Trails aus und verwischt, welcher Client gehandelt hat. Die Spezifikation ist eindeutig: „MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server.”
Server-Side Request Forgery (SSRF). Ein bösartiger Server kann während der OAuth-Metadaten-Discovery URLs liefern, die auf interne Ressourcen oder Cloud-Metadaten-Endpunkte (169.254.169.254) zeigen und so Credentials abgreifen.
State Handle Hijacking. Weil MCP seit dieser Version zustandslos ist, vergeben Server bei Bedarf eigene Handles (etwa eine Workflow-ID). Ein erratenes oder abgefangenes Handle erlaubt fremden Zustand zu manipulieren, wenn der Server dessen Besitz fälschlich als Authentifizierung behandelt.
Local MCP Server Compromise. Lokal laufende Server mit Ein-Klick-Konfiguration können versteckte, schädliche Startbefehle enthalten, wenn Clients keine explizite, ungekürzte Bestätigung des tatsächlichen Befehls einholen.
OAuth Authorization URL Validation. Bösartige Server können javascript:- oder shell-injizierbare URLs als Autorisierungs-Endpunkt liefern, um XSS oder Remote Code Execution im Client auszulösen.

Eine Einordnung aus der Recherche: Der Begriff „Tool Poisoning” - manipulierte Tool-Beschreibungen, die ein Modell zu ungewollten Aktionen verleiten - taucht in diesem Dokument nicht als eigener Abschnitt auf. Die Spezifikation adressiert das verwandte Risiko eher grundsätzlich, mit der Empfehlung, dass ein Mensch in der Schleife bleibt und Clients klar anzeigen, welche Tools einem Modell zur Verfügung stehen. „Tool Poisoning” als prominenter Begriff stammt aus den Sicherheitspapieren im nächsten Abschnitt - ein Unterschied, den man kennen sollte, wenn Sicherheitsteams sich auf unterschiedliche Quellen beziehen.

NSA und CoSAI: unabhängige Einschätzungen von außerhalb der Spezifikation

Zwei Papiere ergänzen die Spezifikation aus einer Betreiber- statt aus einer Protokoll-Perspektive.

Die NSA hat über ihr Artificial Intelligence Security Center (AISC) das Papier „Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation” veröffentlicht (2026, Quelle: media.defense.gov). Die Kernwarnung: MCPs schnelle Verbreitung sei den passenden Sicherheitsmaßnahmen vorausgeeilt. Konkret benennt die NSA unter anderem unkontrollierte automatisierte Aktionen - Agenten, die eigenständig ein neues Tool nutzen oder eine neue Aktion ausführen - sowie unzureichende Eingabeprüfung, weil MCP Daten zwischen Systemen passieren lässt, ohne verbindliche Inhaltsprüfungen vorzuschreiben. Die Empfehlungen sind konkret: Eingaben vor der Verarbeitung gegen definierte Regeln prüfen, automatisierte Aktionen als hochriskant in strikten Berechtigungsgrenzen führen, jede Tool-Ausführung detailliert protokollieren, sowie Zugriffskontrolle, Tool-Ausführung, Agenten-Berechtigungen und die Governance von Drittanbieter-Integrationen zusammenhängend behandeln.

Die Coalition for Secure AI (CoSAI), ein OASIS-Open-Projekt mit Beteiligung unter anderem von Google, Microsoft, IBM und Trend Micro, hat am 27. Januar 2026 das Whitepaper „Model Context Protocol (MCP) Security” veröffentlicht. Es benennt nach eigener Angabe „nearly 40 distinct threats” über zwölf Bedrohungskategorien hinweg - von Authentifizierungsschwächen über Input-Validation-Fehler bis zu unzureichender Beobachtbarkeit. Relevant für diesen Artikel: Tool Poisoning ist einer der Begriffe, die das CoSAI-Papier explizit verwendet - zusammen mit „Prompt Injection”, beide unter „Data/Control Boundary Failures” eingeordnet. Das Papier behandelt außerdem „Confused Deputy” wie „Token Passthrough” im Kontext von Token-Austausch-Empfehlungen - inhaltlich deckungsgleich mit der MCP-Spezifikation, aber in ein breiteres Vokabular eingeordnet.

Bemerkenswert ist weniger jedes einzelne Detail als die Konvergenz: Eine staatliche Sicherheitsbehörde, eine Industriekoalition und die Protokoll-Spezifikation selbst kommen unabhängig voneinander auf dieselbe kurze Liste - Identität und Zugriffskontrolle, Token-Handling, Eingabevalidierung, Beobachtbarkeit. Das ist ein brauchbarer Prüfkatalog, wenn Sie MCP-Server in Ihrer Organisation bewerten wollen, unabhängig davon, welche Gateway-Lösung Sie am Ende einsetzen.

Azure API Management vor MCP-Server schalten: die produktiven Bausteine

Azure API Management unterstützt MCP-Server-Governance bereits seit der Ignite-Konferenz im November 2025 in den regulären Tarifstufen - Developer, Basic, Standard, Premium sowie deren v2-Varianten - ohne Preview-Kennzeichnung. Zwei Wege stehen dafür zur Verfügung:

Erstens lässt sich eine bereits in API Management verwaltete REST-API als MCP-Server exponieren: Ausgewählte API-Operationen werden dabei automatisch zu MCP-Tools. Zweitens lässt sich ein bestehender, extern gehosteter MCP-Server - etwa ein LangServe-Tool-Server oder eine Logic-App-basierte Integration - hinter API Management proxyen und zentral governen. In beiden Fällen entsteht ein API-Management-eigener MCP-Endpunkt, den Clients wie Claude Code oder VS Code mit GitHub Copilot ansprechen, während API Management die Backend-Verbindung hält.

Governance läuft dabei über dieselben Policy-Bausteine, die API Management für klassische REST-APIs kennt, angewendet auf alle Tool-Aufrufe eines MCP-Servers:

Rate Limiting und Kontingente über rate-limit-by-key, zum Beispiel begrenzt auf eine feste Zahl an Aufrufen pro IP-Adresse und Zeitfenster.
Authentifizierung und Autorisierung über die validate-azure-ad-token-Policy, die eingehende JWTs gegen Microsoft Entra ID prüft, wahlweise mit Einschränkung auf bestimmte Client-Application-IDs - wie sich MCP-Server zusätzlich als Entra-Anwendung registrieren und mit Conditional Access schützen lassen, ordnen wir gesondert ein.
IP-Filterung, um Zugriffe auf bekannte Client-Netzbereiche zu beschränken.
Caching von Tool-Antworten, um Backend-Last zu reduzieren.
Outbound-Absicherung über den Credential Manager: API Management kann OAuth-2.0-Tokens für den Zugriff auf das eigentliche Backend selbst verwalten und per get-authorization-context-Policy dynamisch anhängen, statt Client-Tokens einfach durchzureichen.

Für die Sichtbarkeit - den eingangs beschriebenen Kern des Problems - kommt Azure API Center ins Spiel: eine zentrale Registrierungs- und Discovery-Stelle sowohl für MCP-Server über API Management als auch für außerhalb betriebene Server, durchsuchbar über ein eigenes Entwickler-Portal. Für Audit und Monitoring greift die bestehende Azure-Monitor-Integration: Application Insights erfasst Requests, Responses und Telemetrie, Korrelations-IDs lassen sich über Header verfolgen, und eine trace-Policy kann pro MCP-Server zusätzliche Kontextinformationen wie eine Agenten-ID protokollieren.

Zwei Einschränkungen gehören zur ehrlichen Einordnung dazu: MCP-Prompts unterstützt API Management aktuell nicht - bei MCP-Ressourcen ist der Stand uneinheitlich dokumentiert: Die allgemeine Übersichtsseite nennt nur MCP-Tools als unterstützt, die speziell auf extern gehostete Server bezogene Anleitung (neuer datiert) führt für diesen Fall zusätzlich MCP-Ressourcen als unterstützt auf. Unabhängig davon stehen die MCP-Funktionen nicht innerhalb von API-Management-Workspaces zur Verfügung. Ein extern gehosteter Server muss außerdem mindestens MCP-Version 2025-06-18 sprechen und, falls er Autorisierung implementiert, die dort beschriebenen Standards einhalten (Stand: August 2026).

Die neue AI Gateway tier: dedizierte KI-Governance-Ebene (Public Preview, Stand August 2026)

Neben dieser produktiven, in bestehende APIM-Tarife integrierten Lösung hat Microsoft eine eigenständige AI Gateway tier eingeführt - ein separat bereitgestellter, vollständig verwalteter Gateway-Ressourcentyp speziell für KI-Workloads, der KI-Modelle und MCP-Tools unter einem gemeinsamen Endpunkt bündelt. Laut Dokumentation (ms.date: 2026-07-23) befindet sich die AI Gateway tier in Public Preview; die eigenständige Ankündigung folgte Anfang August 2026, nachdem einzelne AI-Gateway-Fähigkeiten der klassischen APIM-Tarife bereits auf der Build-Konferenz im Juni 2026 erweitert worden waren.

Anders als die klassische APIM-Integration ist die AI Gateway tier nicht auf XML-Policies aufgebaut: Governance-Regeln werden als Karten im Portal konfiguriert - Content Safety, IP-Filter, Token- und Request-Rate-Limits. MCP-Server werden als ein einziger governter Endpunkt (.../toolservers/<server-name>/mcp) geführt, der Backends aus drei Quellen föderiert: einem entfernten MCP-Server per URL, einer OpenAPI-Spezifikation, oder einem von über tausend eingebauten SaaS-Connectoren ohne eigenen Server. Pro Backend lässt sich die Authentifizierung wählen - keine, API-Key, OAuth 2.0 oder Managed Identity. Administratoren melden sich über Microsoft Entra ID an; Anwendungen authentifizieren sich über Runtime Access Keys im api-key-Header.

Genau bei diesen Runtime Access Keys liegt eine Einschränkung, die man vor produktivem Einsatz kennen sollte: Laut Microsofts eigener Dokumentation ist ein solcher Schlüssel gateway-scoped - er erreicht jedes Modell und jedes Tool hinter dem Gateway, nicht nur eines. Least-Privilege-Zuschnitt läuft damit ausschließlich über Anzahl und Zuteilung der Schlüssel, nicht über feingranulare Scopes pro Schlüssel; Microsofts eigene Empfehlung: pro Anwendung und Umgebung einen eigenen Schlüssel ausstellen. Wer aus der APIM-Welt mit granularen Subscription-Keys pro Produkt kommt, sollte diesen Unterschied einplanen.

Weitere Preview-Realitäten, die Microsoft offen benennt: Verfügbarkeit ist „best effort” ohne SLA, APIs, Telemetrie, Limits, Regionen und Preismodell können sich vor der allgemeinen Verfügbarkeit noch ändern, Preise folgen erst später. Regional ist die Preview auf zwei Regionen beschränkt - East US 2 und Sweden Central - , sodass Datenresidenz-Überlegungen für europäische Kunden aktuell auf Sweden Central oder auf die allgemeine Verfügbarkeit hinauslaufen. Microsofts eigener Rat für die Preview-Phase: mit unkritischen Workloads starten, kontrollierte Pilotprojekte, klare Rollback-Pläne.

Die Netzwerkfrage stellt sich dabei auch in die andere Richtung: warum ein KI-Gateway vor einer privat abgeschotteten Foundry-Ressource separat netzwerkisoliert werden muss, behandeln wir gesondert.

Token Passthrough in der Praxis: wo Azure API Management hilft - und wo nicht

Der Abschnitt zur MCP-Spezifikation weiter oben hat Token Passthrough als explizit verbotenes Muster benannt. Hier lohnt ein genauer Blick, weil Azure API Management selbst in diese Falle führen kann, wenn die Konfiguration nicht bewusst gestaltet ist: Laut Dokumentation werden Request-Header - mit gewissen Ausnahmen - bei MCP-Tool-Aufrufen standardmäßig an das Backend weitergereicht. Praktisch, weil nachgelagerte APIs ohne Zusatzkonfiguration funktionieren - aber genau das Anti-Pattern, vor dem die MCP-Spezifikation warnt, wenn ein vom Client mitgeschickter Authorization-Header unvalidiert bis ins Backend durchgereicht wird.

Der spezifikationskonforme Weg vermeidet das an zwei Stellen: eingehend über die validate-azure-ad-token-Policy, die ein Client-Token gegen Microsoft Entra ID prüft, bevor es weitergeht; und ausgehend über den Credential Manager, der ein eigenes, backend-spezifisches Token verwaltet, statt das Client-Token durchzureichen. Beide Bausteine zusammen - Validierung am Eingang, eigene Backend-Credentials am Ausgang - bilden genau die Trennung, die „MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server” aus der Spezifikation verlangt. Wer API Management vor MCP-Server schaltet, sollte diese Konfiguration aktiv einrichten, statt sich auf die automatische Header-Weiterleitung zu verlassen.

Die Client-Seite nicht vergessen: MCP-Governance in Claude Code selbst

Eine Gateway-Schicht wie Azure API Management kontrolliert den Netzwerkpfad zwischen Client und Server - sie steuert aber nicht, welche Server ein einzelner Claude-Code-Client überhaupt erst kontaktieren darf. Diese zweite, komplementäre Ebene liegt bei Anthropic selbst und lässt sich mit der Azure-Seite kombinieren, statt sie zu ersetzen.

Für zentral verwaltete Umgebungen bietet Claude Code eine managed-mcp.json, mit der Administratoren entweder einen festen Server-Satz ausrollen oder MCP über eine leere Server-Map vollständig deaktivieren. Eine weichere Variante sind allowedMcpServers und deniedMcpServers, kombiniert mit allowManagedMcpServersOnly, um eine Positivliste verbindlich zu machen, statt sie durch Nutzereinstellungen aufweichen zu lassen. Wichtig für die Wirksamkeit: Ein Eintrag über serverName allein ist laut Anthropics Dokumentation keine verlässliche Sicherheitskontrolle, weil der Name frei vom Nutzer vergeben wird - „a user can call any server github”. Wirksam durchgesetzt wird eine Regel erst über serverUrl oder serverCommand. Genau hier lässt sich die Brücke zu Azure API Management schlagen: Eine Organisation kann in allowedMcpServers gezielt die URL ihres API-Management-Endpunkts eintragen und damit erzwingen, dass Claude-Code-Sessions MCP-Server nur über die governte Schicht erreichen, nicht direkt.

Ergänzend verlangt Claude Code beim ersten Verbinden eines neuen MCP-Servers eine explizite Trust-Verification, und Anthropics Sicherheitsseite formuliert die Grenze der eigenen Verantwortung klar: Anthropic prüft Connectors gegen Listing-Kriterien, bevor sie im Anthropic Directory erscheinen, „but does not security-audit or manage any MCP server.” Die inhaltliche Prüfung eines Servers bleibt Aufgabe der einsetzenden Organisation - das deckt sich mit der Vertrauensfrage zwischen Agenten aus dem Artikel zu Claude Code Agent Teams und mit den Zero-Trust-Überlegungen für KI-Agenten an anderer Stelle (Zero Trust für KI-Agenten).

Ein pragmatischer Fahrplan für die Einführung

Wer MCP-Server im eigenen Unternehmen absichern will, muss nicht mit der Public-Preview-Ebene anfangen. Eine sinnvolle Reihenfolge:

Bestandsaufnahme. Erfassen, welche MCP-Server bereits im Einsatz sind - per Nutzerbefragung, bestehende .mcp.json-Dateien oder OpenTelemetry (OTEL_LOG_TOOL_DETAILS=1 liefert MCP-Server- und Tool-Namen in Claude Code).
Registry aufbauen. Azure API Center als zentralen Katalog einrichten - auch für Server, die noch nicht über API Management laufen.
Nicht-kritische Server zuerst governen. Die GA-verfügbare APIM-Integration nutzen, um Server hinter Rate Limiting, validate-azure-ad-token und IP-Filterung zu bringen, bevor kritische Systeme angebunden werden.
Token Passthrough aktiv vermeiden. Eingehende Tokens validieren, Backend-Credentials über den Credential Manager verwalten - nicht auf automatische Header-Weiterleitung verlassen.
Client-Seite ergänzen. allowedMcpServers beziehungsweise managed-mcp.json in Claude Code so konfigurieren, dass Sessions MCP-Server nur über die governte Schicht erreichen.
AI Gateway tier gezielt pilotieren. Für unkritische, neue KI-Workloads evaluieren, aber angesichts fehlender SLA und Regionsbeschränkung nicht als alleinigen Pfad für geschäftskritische MCP-Zugriffe einplanen, solange die Preview-Kennzeichnung gilt.

Häufige Fragen zu MCP-Server-Sicherheit und Azure API Management

Was ist Token Passthrough bei MCP-Servern, und warum ist es verboten?

Token Passthrough bezeichnet das Anti-Pattern, dass ein MCP-Server Tokens vom Client entgegennimmt, ohne zu prüfen, ob sie tatsächlich für ihn ausgestellt wurden, und sie unverändert an nachgelagerte APIs weiterreicht. Die MCP-Spezifikation verbietet das ausdrücklich, weil es Sicherheitskontrollen wie Rate Limiting umgeht, Audit-Trails unbrauchbar macht und im Zusammenspiel mit dem Confused-Deputy-Problem zu Identitätsverwechslungen führen kann.

Was ist Tool Poisoning bei MCP-Servern?

Tool Poisoning bezeichnet manipulierte Tool-Beschreibungen oder -Metadaten, die ein Modell dazu verleiten, unerwünschte Aktionen auszuführen, ohne dass Nutzer das erkennen. Die MCP-Spezifikation behandelt das Risiko nicht als eigenen Abschnitt, sondern nur grundsätzlich über Transparenz-Empfehlungen; das CoSAI-Papier führt „Tool Poisoning” dagegen explizit als eigenen Begriff.

Ist Azure API Management für die Absicherung von MCP-Servern bereits produktionsreif?

Für die klassischen Tarifstufen (Developer bis Premium v2) ja: MCP-Server-Governance über Policies, Authentifizierung und Monitoring ist seit November 2025 ohne Preview-Kennzeichnung verfügbar. Die dedizierte AI Gateway tier mit ihrem eigenen, für KI-Workloads gebauten Portal ist dagegen aktuell Public Preview, ohne SLA und mit eingeschränkter Regionsverfügbarkeit (Stand: August 2026).

Was ist der Unterschied zwischen der klassischen APIM-MCP-Unterstützung und der neuen AI Gateway tier?

Die klassische Unterstützung erweitert bestehende API-Management-Tarife um MCP-spezifische Funktionen und nutzt dieselben XML-Policies wie reguläre REST-APIs. Die AI Gateway tier ist eine eigenständige, neu bereitgestellte Ressource speziell für KI-Modelle und MCP-Tools mit portalbasierten Policy-Karten statt XML, einem Self-Service-Katalog und gateway-weiten statt fein granularen Zugriffsschlüsseln - aktuell Public Preview.

Was ist das Confused-Deputy-Problem bei MCP?

Es beschreibt eine Schwachstelle bei MCP-Proxy-Servern, die mit statischer Client-ID gegenüber einem Drittanbieter-Autorisierungsserver auftreten: Ein Angreifer kann über einen manipulierten Link und ein bereits gesetztes Consent-Cookie einen Autorisierungscode abgreifen, ohne dass die betroffene Person erneut zustimmen musste. Die MCP-Spezifikation verlangt als Gegenmaßnahme eine Per-Client-Consent-Prüfung durch den Proxy vor jeder Weiterleitung an den Drittanbieter.

Reicht eine Gateway-Schicht wie Azure API Management aus, um MCP-Server abzusichern?

Nein. Sie zentralisiert Zugriffskontrolle, Rate Limiting und Logging für den Netzwerkpfad, ersetzt aber nicht die inhaltliche Prüfung eines Servers, bevor er überhaupt zugelassen wird - dafür sind Registry und Bewertungsprozess zuständig, nicht das Gateway. Ergänzend braucht es Client-seitige Kontrollen wie allowedMcpServers in Claude Code, damit Sessions den governten Pfad nicht umgehen können.

Fazit

MCP-Server sind in vielen Unternehmen bereits im Einsatz, oft ohne dass jemand eine bewusste Sicherheitsentscheidung dafür getroffen hat - das macht sie zu einem Governance-Thema, nicht nur zu einem technischen. Die MCP-Spezifikation selbst benennt die relevanten Angriffe präzise, von Confused Deputy über das explizit verbotene Token Passthrough bis zu SSRF; NSA und CoSAI kommen unabhängig davon auf dieselben Kernthemen. Azure API Management bietet dafür bereits heute, ohne Preview-Vorbehalt, eine produktive Governance-Schicht mit Rate Limiting, Authentifizierung über Entra ID und zentralem Audit-Logging - die neue AI Gateway tier erweitert das um eine dedizierte, für KI-Workloads gebaute Oberfläche, allerdings mit den Einschränkungen einer Public Preview. Wer beide Ebenen kombiniert - Netzwerk-Governance über API Management und Client-seitige Allowlists in Claude Code - schließt mehr Lücken als jede Maßnahme für sich allein.

Quellen (Stand: August 2026, Abruf 20.08.2026):