MCP hat das Integrationsproblem gelöst. Es hat nur das Governance-Problem größer gemacht.

Am 9. Dezember 2025 spendete Anthropic das Model Context Protocol an die Agentic AI Foundation, einen unter dem Dach der Linux Foundation geführten Fonds, mitbegründet von Anthropic, Block und OpenAI. Drei Monate später verzeichneten die Python- und TypeScript-SDKs rund 97 Millionen monatliche Downloads. Inzwischen gibt es mehr als 10.000 öffentlich gelistete MCP-Server, jede Woche kommen Hunderte hinzu. Microsoft, Google DeepMind, Salesforce, Cloudflare, Replit, GitHub und die großen Coding-Assistenten liefern MCP-Unterstützung inzwischen nativ aus. Der Protokollkrieg ist vorbei. MCP hat gewonnen. Die Frage, die bislang noch nicht ernsthaft gestellt wurde – zumindest nicht auf dem Niveau, auf dem europäische Unternehmen sie stellen sollten –, lautet: Was haben sie eigentlich eingeführt, als sie MCP eingeführt haben? Das Protokoll ist echte, gute Ingenieursarbeit. Es ist zugleich ein neuer Perimeter, den die meisten Unternehmen noch gar nicht gezogen haben.

Dies ist der sechste Beitrag in der Reihe, die ich für neuland.ai schreibe. Der rote Faden ist klar: Im Enterprise-KI-Umfeld liegen Wert, Risiko und Differenzierung in der Schicht oberhalb und rund um das Modell, nicht im Modell selbst. Die Linie verlief bislang über Control Plane, dann Drift und Observability, dann Modell-Topologie, dann Tool-Call-Souveränität, dann Agentenarchitektur und die „lethale Trifecta“. [¹] Dieser Beitrag geht einen Schritt weiter. Die Tool-Schicht ist jetzt der neue Perimeter. Und MCP – sein Aufstieg, der Governance-Wechsel, seine aktuellen Grenzen und das, was die Roadmap 2026 explizit zugibt – ist die klarste Demonstration dafür, warum diese Aussage zählt.

Was MCP tatsächlich gelöst hat

Es lohnt sich, sauber zu benennen, was das Protokoll ist und was es verändert hat, denn der Business Case für die Einführung ist real. Vor MCP hat jede KI-Anwendung, die ein Tool nutzen wollte, eine individuelle Integration gebaut. Ein Assistent, der Zugriff auf Postgres, Slack-Messaging und GitHub-Repository-Suche brauchte, benötigte drei getrennt entwickelte Connectoren, jeweils gekoppelt sowohl an das API-Format des KI-Modells als auch an die Schnittstelle des externen Tools. Multipliziert man das mit den Dutzenden von Tools, die ein ernsthafter Enterprise-Agent benötigt, landet man bei dem, was die Literatur als N×M-Problem bezeichnet: Jedes Modell spricht mit jedem Tool über maßgeschneiderten Klebstoff, alles von Grund auf neu geschrieben, nichts wiederverwendbar. [²]

MCP, im November 2024 von den Anthropic-Ingenieuren David Soria Parra und Justin Spahr-Summers eingeführt, ersetzte das durch einen offenen Standard. Ein Tool stellt seine Fähigkeiten über einen MCP-Server bereit. Jeder MCP-fähige KI-Client kann diese Fähigkeiten über dasselbe Protokoll entdecken und nutzen. Das Wire-Format ist JSON-RPC 2.0; das Transportprotokoll seit der Spec-Version vom November 2025 ist Streamable HTTP. [³] Ein Server, jeder Client. Ein Client, jeder Server. Der Engineering-Case ist tatsächlich stark.

Das Wachstum war entsprechend steil. MCP stieg von rund zwei Millionen monatlichen SDK-Downloads zum Launch auf 97 Millionen im März 2026 – ein etwa 50-faches Wachstum in 16 Monaten. Zum Vergleich: Kubernetes brauchte etwa vier Jahre, um eine vergleichbare Deployment-Dichte zu erreichen. [⁴] Das Protokoll sitzt inzwischen hinter den großen Coding-Assistenten-Ökosystemen (Claude Code, Cursor, Zed, Windsurf), hinter Enterprise-Plattformen (Salesforce Agentforce, Microsoft Semantic Kernel, Azure OpenAI) und hinter den agentischen Frameworks, die in jedem Vertical von Finance bis Manufacturing proliferieren.

Der Übergang in die Linux-Foundation-Governance, angekündigt am 9. Dezember 2025, hat noch etwas Wichtiges getan: Er hat das Single-Vendor-Risiko entfernt, das Procurement-Teams bislang zurückhaltend gemacht hatte. MCP ist nicht länger Anthropic’s Protokoll. Es ist das Protokoll der Branche, auf derselben Governance-Schiene wie Kubernetes, PyTorch und Node.js. [⁵] Für eine Enterprise-Architektin, die eine mehrjährige Integrationsentscheidung unterschreibt, ist das relevant – und es sollte auch als solches anerkannt werden. Es ist allerdings eine notwendige Bedingung für das, was als Nächstes kommen muss, keine hinreichende.

MCP ist eine Execution Surface, nicht die einzige

Ein Punkt, den es sich lohnt, präzise zu ziehen, bevor wir weitergehen – ich habe ihn im Februar-Beitrag dieser Serie gemacht, und er ist seither nur relevanter geworden. MCP ist eine Execution Surface unter mehreren, die ein ernstzunehmender Enterprise-Agenten-Stack steuern können muss. CLI- und Shell-basierte Tool-Ausführung, direkte Codeausführungs-Sandboxes, Browser-Automatisierung, Workflow-Fabrics wie n8n und maßgeschneiderte Enterprise-Connectoren sind jeweils eigene Execution Surfaces. Keine davon verschwindet. Die ehrliche Ingenieurposition ist nicht „MCP versus CLI“ oder „MCP versus alles andere“ – die Online-Debatte dazu ist ideologischer, als es der technische Unterbau verdient. Die eigentliche Frage lautet: „Welche Execution Surface passt zu welcher Aufgabe, und was steuert über alle hinweg?“ [²]

Der wiederkehrende MCP-Fehlermodus im großen Maßstab ist derselbe, den ich im Februar argumentiert habe und den die Deployment-Daten 2026 weitgehend bestätigt haben. Das Protokoll funktioniert hervorragend für Tool-Discovery und -Invocation, aber sein Payload- und Kompositionsmodell kann unbeabsichtigt LLM-zentrierte Datenverarbeitung begünstigen: Tool-Definitionen werden in den Model-Context gezogen, Tool-Ausgaben sind häufig ausführlich, Filterung und Aggregation passieren im Modell statt durch deterministisches Preprocessing, und jede zusätzliche Fähigkeit erhöht die Kontextentropie. Das architektonisch sauberere Muster – ausführen, deterministisch reduzieren, ein begrenztes Ergebnis präsentieren, dann das Modell den nächsten Schritt planen lassen – ist schwerer durchzuhalten, wenn MCP als Default und nicht als eine Option unter mehreren behandelt wird. Nichts davon macht MCP zu einem schlechten Protokoll. Es macht MCP zu einem Protokoll, dessen Stärken Governance-Disziplin belohnen und dessen Schwächen durch ihr Fehlen verstärkt werden. [¹⁵]

Was die Schlagzeile nicht erzählt

Hier ist der Teil der Geschichte, den die Zahl 97 Millionen verdeckt. Jeder MCP-Server, an den ein Unternehmen sich anschließt, ist gleichzeitig ein Stück Drittanbieter-Code innerhalb seiner Trust Boundary, ein Credential-Holder mit realen organisatorischen Privilegien und eine Jurisdiktion, deren Implikationen für Datenflüsse die meisten Unternehmen nicht bewertet haben. Keine dieser drei Eigenschaften ist in der Unternehmens-IT für sich genommen neu. Neu ist die Geschwindigkeit, mit der sie zusammengefügt werden, und der Maßstab, in dem sie ausgerollt werden – basierend auf einem Protokoll, dessen Spezifikation Authentifizierung noch immer nicht zwingend vorschreibt.

Authentifizierung ist in MCP optional. Sie ist eine empfohlene Best Practice. Sie ist keine zwingende Anforderung des Protokolls. Anfang 2026 veröffentlichte Forschung dokumentierte mehr als 1.800 aktive MCP-Server im öffentlichen Internet ohne jegliche Authentifizierung – typischerweise, weil sie auf Basis von Tutorials gebaut wurden, die vor der Aufnahme von OAuth-Unterstützung in die Spezifikation entstanden. [⁶] Trend Micro hat bislang 102 MCP-spezifische CVEs katalogisiert. [⁷] Der SAFE-MCP-Katalog der OpenSSF führt über 80 Angriffstechniken, die speziell auf MCP-basierte Tool-Systeme zielen, darunter Prompt Injection, Confused-Deputy-Angriffe, bei denen Agenten Aufgaben delegieren, ohne den Autorisierungsscope zu verengen, Context-Integrity-Verluste durch unzureichende Audit Trails und „Rug-Pull“-Angriffe, bei denen ein zuvor vertrauenswürdiger MCP-Server nach der Enterprise-Einführung stillschweigend manipuliert wird. [⁸] Atlassians eigene Security-Guidance für Kunden, die MCP einführen, dokumentiert zusätzlich Naming-Collision- und Tool-Impersonation-Angriffe, bei denen ein Agent auf der Suche nach „Safe Operation Guide“ unbemerkt bei „Safe Operations Guide“ landet. [⁹]

Die Supply-Chain-Dimension folgt demselben Muster, das ich im letzten Beitrag zur „lethalen Trifecta“ aufgezeigt habe. [¹⁰] Wenn 12 Prozent der Skills im OpenClaw-ClawHub-Registry bösartig sind, wenn laut Bishop Fox’ AIMap-Studie 8.000 offene MCP-Server im öffentlichen Internet exponiert sind, ist die Implikation nicht, dass ein bestimmtes Protokoll „kaputt“ ist. Die Implikation ist, dass die Agenten-Tool-Schicht inzwischen eine Supply-Chain-Angriffsfläche im Umfang von npm oder PyPI besitzt – und die Procurement-, Audit- und Governance-Prozesse, die europäische Unternehmen über das letzte Jahrzehnt rund um npm und PyPI aufgebaut haben, für MCP noch nicht existieren.

Die Roadmap ist das Eingeständnis

Der stärkste Beweis, dass diese Lücke real ist, kommt aus dem MCP-Projekt selbst. Die MCP-Roadmap 2026, veröffentlicht am 5. März 2026 unter der neuen Linux-Foundation-Governance, listet vier strategische Prioritäten. Die vierte heißt unverblümt „Enterprise Readiness“. [¹¹] Unter diesem Punkt stehen genau die Themen, die jede Enterprise-Architektin vom Protokoll fordert:

• End-to-End-Audit Trails, die für regulatorische Compliance ausreichen

• SSO-integrierte Authentifizierung, die statische Client-Secrets durch gemanagte Flows ersetzt

• Definierte Gateway- und Proxy-Semantik, damit über Intermediäre gerouteter Traffic klare Regeln zur Autorisierungsweitergabe und Session-Affinity hat

• Konfigurationsportabilität über MCP-Clients hinweg

Die Roadmap hält ebenso offen fest, dass „eine Enterprise WG noch nicht existiert“, dass sich die Working Group erst formiert, und dass „der Großteil der Enterprise-Readiness-Arbeit als Extensions und nicht als Core-Spec-Änderungen landen wird“. [¹¹] Das ist die Sprache einer Community, die die richtige strategische Entscheidung trifft – den Kern schlank zu halten und Enterprise-Anforderungen in Extensions zu leben – und es ist genau das Richtige auf Governance-Ebene eines Protokolls. Es ist aber ebenso das öffentliche Eingeständnis, dass die Eigenschaften, die ein Unternehmen benötigt, um MCP im Einklang mit europäischen Regulierungspflichten zu betreiben, noch nicht ausgeliefert sind – und dass das Design, wie sie ausgeliefert werden sollen, offene Arbeit ist.

Für eine Organisation, die MCP 2026 unter den Realitäten von DSGVO-Auditpflichten, DORA-Logging-Anforderungen oder den Traceability-Vorgaben des EU AI Act ausrollt, ist genau dies die Lücke. Das Protokoll ist produktionsreif. Die Enterprise-Governance-Schicht oberhalb des Protokolls ist – nach eigener Beschreibung der Maintainer – ein offenes Work Item, in das sich interessierte Community-Mitglieder einbringen.

Die juristische Dimension, über die niemand spricht

Neben den Sicherheits- und Audit-Lücken gibt es ein drittes Thema, das spezifisch europäische Unternehmen betrifft und im breiteren MCP-Diskurs fast niemand sauber adressiert. Jeder MCP-Server läuft irgendwo. Ein Call an einen MCP-Server ist ein Datenfluss. Das Protokoll ist jurisdiktionsneutral; sein Deployment ist es nicht.

Wenn ein in der EU gehosteter KI-Agent einen in den USA gehosteten MCP-Server aufruft – und die großen kommerziellen MCP-Server US-amerikanischer Anbieter sind standardmäßig meist US-gehostet –, dann überquert der Kontext des Agenten, inklusive aller Daten, die er zuvor aus internen europäischen Systemen gezogen hat, den Atlantik. Diese Daten unterliegen ab dem Moment, in dem sie am ausländischen Endpoint ankommen, dem CLOUD Act und US-Vertragsrecht. Kein Maß an EU-Residenz für die Modellschicht ändert daran etwas. Das EU-gehostete Modell hat seine Inferenz innerhalb der European Data Boundary erbracht; der darauf folgende Tool-Call hat die Daten wieder hinausgeführt. [¹²] Der Grund, warum ich im letzten Copilot-Stück argumentiert habe, dass Compliance eine Systemeigenschaft ist, liegt exakt in diesem Muster. [¹³] MCP macht dieses Muster einfacher zusammenzubauen, einfacher im großen Stil auszurollen – und einfacher, es im Procurement-Review zu übersehen.

Das ist kein Argument gegen MCP. Es ist ein Argument gegen MCP-ohne-Orchestrierungsschicht. Das Protokoll liefert das Wire-Format. Es liefert nicht den Perimeter.

Wie Enforcement-by-Construction für MCP aussieht
Die architektonische Antwort auf die genannten Themen ist strukturell dieselbe, die ich in den letzten fünf Beiträgen vertreten habe. Die Orchestrierungsschicht ist der Ort, an dem die Arbeit passiert, weil nur dort die gesamte MCP-Topologie gleichzeitig sichtbar ist. Konkret erzwingt eine MCP-bewusste Orchestrierungsschicht Folgendes:

Execution-Surface-Auswahl. Die erste Frage lautet, ob eine Aufgabe überhaupt über MCP laufen sollte. Manche Workloads sind als CLI-Aufruf mit deterministischer Output-Reduktion besser aufgehoben; manche gehören in ein sandboxed Code-Execution-Modul; manche passen in eine Workflow-Fabric wie n8n; manche benötigen tatsächlich die Reichweite des MCP-Ökosystems. Die Orchestrierungsschicht wählt pro Aufgabe die passende Execution Surface, statt alles durch ein Protokoll zu zwingen. MCP ist ein mächtiger Adapter, um Ökosysteme zu hebeln; es ist nicht automatisch die Standard-Tool-Schicht, nur weil das SDK bequem ist.

Server-Allowlisting und Provenance-Verifikation. Nicht jeder MCP-Server ist im Scope. First-Party-Server etablierter Enterprise-Anbieter sind anders zu bewerten als ein Community-Server aus einem GitHub-Account, der seit drei Monaten aktiv ist. Die Orchestrierungsschicht setzt das Allowlisting durch; der Agent sieht niemals Server, die außerhalb dieses Rahmens liegen.

Identity Propagation und Audit. Jeder MCP-Tool-Call trägt die Identität der menschlichen Nutzerin, die ihn ausgelöst hat; der Audit Trail lebt in der Umgebung der Orchestrierungsschicht, nicht im MCP-Server. Das „Recht auf Vergessenwerden“ unter der DSGVO, die Auditpflichten unter DORA und die Traceability-Anforderungen des EU AI Act setzen genau dies deterministisch voraus.

Scope-Minimierung. Jeder MCP-Server erhält exakt den Tool- und Datenscope, den seine konkrete Rolle benötigt. Agenten, die ein Tool nutzen wollen, sehen nur diejenigen Tools, zu deren Nutzung sie in diesem Kontext autorisiert sind. Das ist dasselbe Prinzip der Least Privilege aus dem klassischen Identity Management, angewandt auf Tool-Calls.

Capability-Decomposition im Lichte der „lethalen Trifecta“. Kein einzelner Agent im System hält gleichzeitig einen MCP-Server, der private Daten lesen kann, einen MCP-Server, der untrusted Content ingestet, und einen MCP-Server, der nach außen kommunizieren kann. Die Orchestrierungsschicht komponiert Execution Paths, die diese Trennung respektieren.

Jurisdiktionales Routing. Wenn ein Agent eine Fähigkeit benötigt, routet die Orchestrierungsschicht zu MCP-Servern in der passenden Jurisdiktion. EU-residente Workloads rufen EU-gehostete MCP-Server auf; die Option, nicht-EU-Server zu nutzen, ist eine bewusst gesetzte Policy-Entscheidung, die im Audit Trail landet – kein zufälliger Datenfluss.

Wo neuland.ai steht
Genau dies ist strukturell das, wofür der neuland.ai HUB im Kontext von MCP und der darüberliegenden Execution-Surface-Landschaft gebaut ist. Der neuland.ai HUB ist hyperscaler-unabhängig und on-premises oder in einer EU-lokalisierten Private Cloud deploybar. Er sitzt oberhalb heterogener Execution Surfaces – MCP-Server (First-Party und freigegebene Third-Party), CLI- und Shell-Execution-Module, kontrollierte Code-Execution-Sandboxes, Browser-Automation-Surfaces, Workflow-Fabrics wie n8n und direkte Enterprise-Connectoren – und appliziert Identity, RBAC, Audit, Policy und Capability-Abstraktion einheitlich über alle hinweg. Tool-Call-Metadaten werden erzwungen; Capability-Decomposition ist automatisch statt optional; jurisdiktionales Routing ist ein Policy-Parameter statt ein architektonischer Unfall. [¹⁴]

Der Punkt, den ich präzise setzen möchte – weil ich ein eng verwandtes Argument im Februar gemacht habe: MCP-als-Adapter bleibt das richtige Design. [¹⁵] Was sich seit Februar geändert hat, sind der Maßstab und die Position, die das Protokoll inzwischen im agentischen KI-Markt einnimmt. MCP durch eine Governance-Schicht zu adoptieren, die auch die anderen Execution Surfaces steuert, ist gute Architektur. MCP direkt und ohne diese Governance-Schicht in ein Unternehmen einzuführen, ist derselbe Fehler, wie Laptops ohne Identity Provider ans Firmennetz zu hängen – und wird im Rückblick genauso erinnert werden.

Persönliche Einschätzung
Der Schritt in die Linux-Foundation-Governance ist gut für die Branche. Dass MCP zu einem vendor-neutralen Standard geworden ist, entfernt eine der strukturellen Barrieren, die ernsthafte Enterprise-Procurement-Teams 2024 und den Großteil von 2025 in einer Warteschleife gehalten haben. Das ist ein Gewinn und sollte als solcher anerkannt werden.

Was er nicht ist – und nie sein konnte –, ist ein Ersatz für die Enterprise-Governance-Schicht oberhalb des Protokolls. Die MCP-Roadmap 2026 ist im Kern das öffentliche Eingeständnis dessen – die Enterprise-Readiness-Items sind echte Arbeit, die offen betrieben wird, aber sie ist noch nicht abgeschlossen, und das Meiste davon wird als Extension und nicht als Kernänderung landen. Die ehrliche Lesart aus Sicht einer Enterprise-Architektin lautet: Das Protokoll hat sich schneller stabilisiert als die Governance darum herum. Die nächsten zwölf Monate sind die Lücke zwischen diesen beiden Zuständen. Organisationen, die diese Lücke nutzen, um die Management-Schicht oberhalb des Protokolls zu bauen, werden für die zweite Welle agentischer Deployments produktionsreif sein. Organisationen, die MCP als Plug-and-Play-Infrastruktur behandeln, werden 2027 damit verbringen, Compliance nachträglich auf Integrationen aufzupfropfen, die nie dafür entworfen waren.

Ein kurzer Blick auf den regulatorischen Hintergrund, da ich in den letzten beiden Beiträgen dazu geschrieben habe und sich die Lage weiterentwickelt hat. Am 7. Mai 2026 hat die EU mit dem Digital Omnibus on AI die Hochrisiko-Pflichten aus Anhang III auf den 2. Dezember 2027 und die Pflichten aus Anhang I auf den 2. August 2028 verschoben. [¹⁶] Die GPAI-Durchsetzungsbefugnisse aus Kapitel V bleiben auf dem ursprünglichen Datum 2. August 2026. Die strategische Implikation bleibt unverändert: Der Druck durch harte Fristen ist etwas gesunken, der Käuferscrutiny hat zugenommen, und die Organisationen, die jetzt die architektonische Arbeit leisten, werden diejenigen sein, die 2028 noch Enterprise-Procurement-Entscheidungen gewinnen.

Das Protokoll hat gewonnen. Die Governance ist noch offen. Das ist die Arbeit, die vor uns liegt.

¹ Serienartikel unter neuland.ai/insights. Bisherige Beiträge: „Control Panels, Execution Surfaces…“ (Feb 2026); „Wenn KI-Systeme plötzlich schlechter werden“ (Apr 2026); „Open weights took the top spot. Meta walked away.“ (Apr/Mai 2026); „Compliance is a system property, not a checkbox“ (Mai 2026); „The lethal trifecta is not a vulnerability. It is a property of the system.“ (Mai 2026).
² Zum N×M-Integrationsproblem und seiner Formalisierung: WorkOS, „Everything your team needs to know about MCP in 2026“, März 2026; Decode The Future, „What Is MCP? Model Context Protocol Explained for 2026“, März 2026. Zur breiteren Einordnung von MCP als eine Execution Surface unter mehreren (neben CLI/Shell, Code Execution, Browser-Automation, Workflow-Fabrics wie n8n und maßgeschneiderten Connectoren) siehe Abschnitt 3 von „Control Panels, Execution Surfaces…“ (neuland.ai, Februar 2026).
³ MCP, eingeführt im November 2024 von Anthropic, entwickelt von David Soria Parra und Justin Spahr-Summers. Aktuelle kanonische Spec-Version: 2025-11-25. Wire-Format: JSON-RPC 2.0. Primärer Transport: Streamable HTTP. Offizielle SDKs: Python, TypeScript, C#, Java, Swift; Third-Party-SDKs in Rust und Go.
⁴ MCP-SDK-Downloadzahlen pro Monat: ~2 Millionen zum Launch (November 2024), 97 Millionen im März 2026. Kubernetes-Vergleich zitiert in der Branchenberichterstattung zur Linux-Foundation-Governance-Transition; siehe ai2.work, „Model Context Protocol Hits 97M Installs as Linux Foundation Takes Over“, April 2026.
⁵ Anthropic-Spende von MCP an die Agentic AI Foundation (AAIF), 9. Dezember 2025. AAIF ist ein unter dem Dach der Linux Foundation geführter Fonds, mitbegründet von Anthropic, Block und OpenAI. Siehe GitHub Blog, „MCP joins the Linux Foundation“, Dezember 2025; Linux-Foundation-Presseunterlagen, Dezember 2025.
⁶ Epinium-Research, Q1 2026: 1.800+ aktive MCP-Server im öffentlichen Internet ohne Authentifizierungsschicht. Authentifizierung in der MCP-Spezifikation ist optional, nicht verpflichtend. Siehe Epinium, „MCP Enterprise Security and Governance“, 2026.
⁷ Trend Micro: 102 MCP-spezifische CVEs, katalogisiert bis April 2026. Siehe Pomerium, „MCP Server Security Risks: What Development Teams Need to Know in 2026“, April 2026.
⁸ OpenSSF AI/ML Security Working Group, SAFE-MCP-Katalog: 80+ Angriffstechniken, die speziell auf Tool-basierte LLM-Systeme via MCP zielen, darunter Prompt Injection, Confused-Deputy-Angriffe, Context-Integrity-Verluste und Rug-Pull-Angriffe. OWASP GenAI Security Project, „A Practical Guide for Securely Using Third-Party MCP Servers“, November 2025.
⁹ Atlassian, „MCP Clients: Understanding the potential security risks“, Juni 2025. Dokumentiert Prompt Injection, bösartige Serverinstruktionen, Rug-Pull/Tool-Redefinition und Naming-Collision/Impersonation-Angriffe gegen Enterprise-MCP-Deployments.
¹⁰ Siehe Fußnote 1 und den Beitrag zur „lethalen Trifecta“, Mai 2026. Supply-Chain-Zahlen: 12 % der OpenClaw-ClawHub-Skills als bösartig eingestuft (Zscaler ThreatLabz, Mai 2026); 8.000+ offene MCP-Server und 175.000+ exponierte Ollama-Instanzen laut Bishop Fox’ AIMap-Tool (Release 30. April 2026); 40.000+ exponierte OpenClaw-Instanzen laut SecurityScorecard, Default-Config speichert Credentials im Klartext in lokalen Files.
¹¹ Model Context Protocol 2026 Roadmap, veröffentlicht am 5. März 2026 von David Soria Parra (Lead Maintainer). Vier strategische Schwerpunkte: (1) Transport Evolution and Scalability, (2) Agent Communication Primitives, (3) Governance Maturation, (4) Enterprise Readiness. Enterprise-Readiness-Items: Audit Trails, SSO-integrierte Authentifizierung, Gateway/Proxy-Patterns, Konfigurationsportabilität. Roadmap-Hinweis: „an Enterprise WG does not yet exist… most of the enterprise readiness work to land as extensions rather than core spec changes.“ Siehe blog.modelcontextprotocol.io.
¹² Zum zugrunde liegenden Compliance-Argument – CLOUD-Act-Exposure, Schrems-II-Rechtsprechung, Begrenzungen der EU Data Boundary, Rüge des EDPS zur M365-Nutzung der EU-Kommission – siehe den vorherigen Beitrag dieser Serie „Compliance is a system property“, Mai 2026. Microsofts Dokumentation schließt Bing-Websuche und Anthropic-Modelltraffic in Microsoft 365 Copilot explizit von den Zusagen zur EU Data Boundary aus.
¹³ Siehe Fußnote 1; „Compliance is a system property, not a checkbox“, Mai 2026.
¹⁴ Referenzierte Fähigkeiten des neuland.ai HUB: Identity / RBAC / Audit Trail / Tool-Call-Governance / Capability-Abstraktion / Multi-LLM-Routing / hyperscaler-unabhängiges Deployment (on-premises, EU-Private-Cloud, Hyperscaler-Region nach Bedarf) / MCP-Server-Allowlisting und jurisdiktionales Routing. Die neuland.ai AG trägt Verantwortung für Inhaltsqualität und saubere Ergebnislieferung.
¹⁵ Siehe „Control Panels, Execution Surfaces und das Ende der Prompt-First-Automatisierung“, neuland.ai, 19. Februar 2026. Der Beitrag vertrat zwei Positionen, die es sich lohnt, hier zu wiederholen. Erstens: MCP ist am besten als Adapter-Pattern innerhalb einer Control-Plane-Architektur zu verstehen, nicht als Fundament an sich – und MCP langfristig abzulehnen, wäre strategisch naiv, weil Ökosysteme und Interop gewinnen. Zweitens: MCPs wiederkehrender Fehlermodus im großen Maßstab ist, dass es unbeabsichtigt LLM-zentrierte Datenverarbeitung begünstigen kann – ausführliche Tool-Ausgaben, die ins Modell zurückfließen, Filterung und Transformation durch das LLM statt durch deterministisches Preprocessing, steigende Kontextentropie mit jeder weiteren Capability. Das Gegenmuster lautet „always reduce before reasoning“ – ausführen, Output deterministisch formen, dann das Modell den nächsten Schritt planen lassen. Beide Positionen gelten im Mai 2026 weiterhin; geändert hat sich der Deployment-Maßstab und damit die Governance-Lücke, die der aktuelle Beitrag adressiert.
¹⁶ Provisorische politische Einigung von Rat der EU und Europäischem Parlament zum Digital Omnibus on AI, 7. Mai 2026. Hochrisiko-Pflichten aus Anhang III verschoben vom 2. August 2026 auf 2. Dezember 2027 (16 Monate Verzögerung); Anhang-I-Pflichten verschoben auf 2. August 2028 (12 Monate Verzögerung); Artikel 50(2) zum Watermarking auf 2. Dezember 2026 vertagt; neues Verbot für nicht-einvernehmliche intime KI-Bildgenerierung und CSAM. GPAI-Durchsetzungsbefugnisse aus Kapitel V bleiben auf dem ursprünglichen Zeitplan (2. August 2026). Formale Verabschiedung vor diesem Datum erwartet.