Ein Gespräch mit dem KI-Forscher Sebastian Wallkötter bietet Einblicke in die Standardisierung, Sicherheitsherausforderungen und die grundlegenden Fragen, die die Einführung von künstlicher Intelligenz in Unternehmen betreffen.
Einführung in MCP
Standards hängen nicht von technischer Überlegenheit ab, sondern von der Akzeptanz. Das Model Context Protocol (MCP) erkannte dies von Anfang an. Es wurde Ende 2024 von Anthropic veröffentlicht und löste das scheinbar einfache Problem, wie KI-Modelle mit externen Werkzeugen interagieren sollten. Das Design des Protokolls war so einfach, dass es die Implementierung förderte, und sein Nutzen war klar genug, um die Nachfrage zu steigern. Innerhalb weniger Monate hatte MCP die Netzwerk-Effekte ausgelöst, die eine gute Idee in einen Branchenstandard verwandeln. Doch wie Sebastian Wallkötter, ein KI-Forscher und Dateningenieur, in einem kürzlichen Gespräch erklärt, hat diese schnelle Akzeptanz kritische Fragen zu Sicherheit, Skalierbarkeit und der Eignung von KI-Agenten aufgeworfen.
Warum MCP das Rennen um Standards gewonnen hat
Das Model Context Protocol löste das, was wie ein einfaches Problem erschien: Wie kann man eine wiederverwendbare Möglichkeit schaffen, damit KI-Modelle auf Werkzeuge und Dienste zugreifen können? Vor MCP musste jeder Anbieter von großen Sprachmodellen (LLM) und jeder Werkzeugentwickler individuelle Integrationen erstellen. MCP bot eine gemeinsame Sprache.
„MCP konzentriert sich wirklich sehr auf das Aufrufen von Werkzeugen“, erklärt Wallkötter. „Sie haben Ihren Agenten oder LLM oder etwas Ähnliches, und dieses soll mit Google Docs oder Ihrer Kalender-App oder GitHub interagieren.“
Der Erfolg des Protokolls spiegelt andere Geschichten der Plattformstandardisierung wider. So wie Facebook kritische Masse erreichte, als genügend Nutzer beitraten, um das Netzwerk wertvoll zu machen, erreichte MCP einen Wendepunkt, an dem Anbieter es unterstützen wollten, weil die Nutzer es verlangten, und die Nutzer es wollten, weil die Anbieter es unterstützten. Dieser Netzwerk-Effekt trieb die Akzeptanz über geografische Grenzen hinweg voran, ohne dass eine offensichtliche regionale Präferenz zwischen US-amerikanischen und europäischen Implementierungen bestand.
Die Sicherheitsblindheit
Die schnelle Akzeptanz offenbarte jedoch erhebliche Lücken in der ursprünglichen Spezifikation. Wallkötter weist darauf hin, dass Entwickler schnell eine kritische Schwachstelle entdeckten: „Die erste Version des MCP hatte überhaupt keine Authentifizierung. Jeder auf der Welt konnte einfach zu jedem MCP-Server gehen und ihn aufrufen, was offensichtlich nach hinten losgehen kann.“
Die Herausforderung der Authentifizierung erweist sich als komplexer als bei traditionellen Web-Sicherheitsmodellen. MCP umfasst drei Parteien: den Nutzer, den LLM-Anbieter (wie Anthropic oder OpenAI) und den Dienstanbieter (wie GitHub oder Google Drive). Traditionelle Web-Authentifizierung behandelt gut zwei Parteien-Interaktionen. Ein Nutzer authentifiziert sich bei einem Dienst, und diese Beziehung ist unkompliziert. MCP erfordert jedoch die gleichzeitige Berücksichtigung aller drei Parteien.
„Sie haben den MCP-Server, den LLM-Anbieter und dann den Nutzer selbst“, erklärt Wallkötter. „Welchen Teil authentifizieren Sie? Authentifizieren Sie, dass es Anthropic ist, das mit GitHub kommuniziert? Aber der Nutzer ist ja da, oder? Also authentifiziert tatsächlich der Nutzer.“
Die Situation wird noch komplexer bei autonomen Agenten. Wenn ein Nutzer einen Reiseplanungsagenten anweist, einen Urlaub zu buchen, und dieser Agent beginnt, verschiedene MCP-Server ohne direkte Aufsicht des Nutzers anzurufen, wer trägt die Verantwortung für diese Aktionen? Ist es das Unternehmen, das den Agenten gebaut hat? Der Nutzer, der die Anfrage initiiert hat? Diese Frage hat technische, rechtliche und ethische Dimensionen, die die Branche noch zu klären versucht.
Das Problem der Eingabeaufforderung
Über die Authentifizierung hinaus stehen MCP-Implementierungen vor einer weiteren Sicherheitsherausforderung, für die es keine klare Lösung gibt: die Eingabeaufforderungsinjektion. Diese Schwachstelle ermöglicht es böswilligen Akteuren, das Verhalten von KI zu übernehmen, indem sie Eingaben erstellen, die die beabsichtigten Anweisungen des Systems überschreiben.
Wallkötter zieht einen Vergleich zu einem älteren Web-Sicherheitsproblem. „Es erinnert mich ein wenig an die alten SQL-Injektionszeiten“, bemerkt er. In den frühen Tagen des Webs fügten Entwickler Benutzereingaben direkt in Datenbankabfragen ein, was Angreifern ermöglichte, bösartige SQL-Befehle einzufügen. Die Lösung bestand darin, die Abfragestruktur von den Daten zu trennen und parametrisierte Abfragen zu verwenden, die Benutzereingaben als reine Daten und nicht als ausführbaren Code behandelten.
„Ich vermute, dass die Lösung sehr ähnlich sein wird, wie wir es für SQL-Datenbanken gelöst haben“, schlägt Wallkötter vor. „Sie senden zuerst die Eingabeaufforderung selbst und dann alle Daten, die Sie in die verschiedenen Teile der Eingabeaufforderung einfügen möchten, separat, und dann gibt es ein System, das vor dem LLM sitzt und die Daten überprüft und versucht herauszufinden, ob es eine Eingabeaufforderungsinjektion gibt.“
Trotz dieses potenziellen Ansatzes existiert noch keine weit verbreitete Lösung. LLM-Anbieter versuchen, Modelle zu trainieren, um Systemanweisungen über Benutzereingaben zu priorisieren, aber diese Sicherheitsvorkehrungen bleiben unvollkommen. „Es gibt immer Wege, das zu umgehen, denn es gibt keinen narrensicheren Weg, das zu tun“, räumt Wallkötter ein.
Das Problem der Eingabeaufforderung erstreckt sich über Sicherheitsbedenken hinaus und betrifft auch die Zuverlässigkeit. Wenn ein MCP-Server Daten zurückgibt, die in den Kontext des LLM eingebettet werden, können diese Daten Anweisungen enthalten, die das beabsichtigte Verhalten überschreiben. Ein KI-Agent, der einem sorgfältig gestalteten Workflow folgt, kann durch unerwartete Inhalte in einer Antwort aus der Bahn geworfen werden. Bis diese Schwachstelle behoben ist, tragen autonome Agenten, die ohne menschliche Aufsicht arbeiten, inhärente Risiken.
Die Falle der Werkzeugüberlastung
Die Benutzerfreundlichkeit von MCP schafft ein unerwartetes Problem. Da das Hinzufügen eines neuen Werkzeugs unkompliziert ist, sammeln Entwickler oft Dutzende von MCP-Servern in ihren Anwendungen. Diese Fülle beeinträchtigt die Leistung messbar.
„Ich habe ein paar Beispiele gesehen, bei denen die Leute sehr enthusiastisch über MCP-Server waren und dann mit 30, 40 Servern mit all den Funktionen endeten“, beobachtet Wallkötter. „Plötzlich sind 40 oder 50 Prozent Ihres Kontextfensters von Anfang an mit Werkzeugdefinitionen belegt.“
Jedes Werkzeug benötigt eine Beschreibung, die seinen Zweck und seine Parameter für das LLM erklärt. Diese Beschreibungen verbrauchen Tokens im Kontextfenster, dem begrenzten Raum, in dem das Modell alle relevanten Informationen speichert. Wenn Werkzeugdefinitionen die Hälfte des verfügbaren Kontexts einnehmen, hat das Modell weniger Platz für tatsächliche Gesprächshistorie, abgerufene Dokumente oder andere kritische Informationen. Die Leistung leidet vorhersehbar.
Über die Einschränkungen des Kontextfensters hinaus führt eine zu große Anzahl von Werkzeugen zu Verwirrung für das Modell selbst. Aktuelle LLM-Generationen haben Schwierigkeiten, zwischen ähnlichen Werkzeugen zu unterscheiden, wenn ihnen umfangreiche Optionen präsentiert werden. „Der allgemeine Konsens im Internet ist derzeit, dass etwa 30 die magische Zahl in der Praxis zu sein scheint“, bemerkt Wallkötter und beschreibt die Schwelle, ab der die Modellleistung merklich abnimmt.
Diese Einschränkung hat architektonische Implikationen. Sollten Entwickler einen großen Agenten mit vielen Fähigkeiten oder mehrere kleinere Agenten mit fokussierten Werkzeugsets erstellen? Die Antwort hängt teilweise von den Kontextanforderungen ab. Wallkötter bietet eine einprägsame Kennzahl: „Sie erhalten für die meisten anständigen Agenten heutzutage etwa 200.000 Tokens im Kontextfenster. Und das ist ungefähr so viel wie Stolz und Vorurteil, das gesamte Buch.“
Diese „Jane-Austen-Metrik“ bietet eine intuitive Skala. Wenn ein Agent umfangreiche Geschäftskontexte, Formatierungsrichtlinien, Projektgeschichte und andere Hintergrundinformationen benötigt, kann dieses angesammelte Wissen schnell einen erheblichen Teil des verfügbaren Raums ausfüllen. Das Hinzufügen von 30 Werkzeugen oben drauf könnte das System über die effektive Betriebsgrenze hinausdrängen.
Die Lösung besteht oft in einer strategischen Agentenarchitektur. Anstatt einen universellen Agenten zu erstellen, könnten Organisationen spezialisierte Agenten für unterschiedliche Anwendungsfälle einsetzen: einen für die Reiseplanung, einen für das E-Mail-Management und einen dritten für die Kalenderkoordination. Jeder behält ein fokussiertes Werkzeugset und spezifische Anweisungen bei, um die Komplexität und Verwirrung eines überladenen universellen Agenten zu vermeiden.
Wann man KI nicht einsetzen sollte
Wallkötters Hintergrund in der Robotik bietet eine unerwartete Perspektive zur Bewertung von KI-Implementierungen. Seine Doktorarbeit über humanoide Roboter offenbarte eine anhaltende Herausforderung: stabile Anwendungsfälle zu finden, in denen humanoide Formfaktoren echte Vorteile gegenüber einfacheren Alternativen bieten.
„Das Problem mit humanoiden Robotern ist, dass sie ein wenig wie ein instabiler Gleichgewichtszustand sind“, erklärt er und greift auf ein physikalisches Konzept zurück. Ein Pendel, das perfekt aufrecht balanciert ist, könnte theoretisch unbegrenzt stehen bleiben, aber jede kleine Störung lässt es fallen. „Wenn Sie das leicht stören, wenn Sie es nicht perfekt hinbekommen, fällt es sofort wieder herunter.“ Humanoide Roboter stehen vor ähnlichen Herausforderungen. Obwohl sie faszinierend sind und beeindruckende Demonstrationen bieten, haben sie Schwierigkeiten, ihre Komplexität zu rechtfertigen, wenn einfachere Lösungen existieren.
„Sobald Sie wirklich darüber nachdenken, was wir damit tun können, stehen Sie sofort vor der wirtschaftlichen Frage, ob Sie tatsächlich die aktuelle Konfiguration des Humanoiden benötigen, mit der Sie beginnen?“, fragt Wallkötter. „Sie können die Beine wegnehmen und stattdessen Räder anbringen. Räder sind viel stabiler, einfacher zu bauen und robuster.“
Dieses Denken lässt sich direkt auf aktuelle KI-Agentenimplementierungen anwenden. Wallkötter stieß kürzlich auf ein Beispiel: ein ausgeklügeltes KI-Codierungssystem, das einen Agenten beinhaltete, der speziell dafür entwickelt wurde, unzuverlässige Tests in einem Codebestand zu identifizieren.
„Ich fragte, warum Sie einen Agenten und ein KI-System mit einem LLM haben, das versucht herauszufinden, ob ein Test unzuverlässig ist?“, erinnert er sich. „Könnten Sie nicht einfach den Test 10 Mal aufrufen und sehen, ob er gleichzeitig fehlschlägt und besteht? Denn das ist ja das, was ein unzuverlässiger Test ist, oder?“
Das Muster wiederholt sich in der gesamten Branche. Teams setzen KI auf Probleme ein, die einfachere, zuverlässigere und kostengünstigere Lösungen haben. Der Reiz, modernste Technologie zu nutzen, kann einfache Alternativen verschleiern. Eine LLM-basierte Lösung könnte erhebliche Rechenressourcen kosten und dennoch gelegentlich fehlschlagen, während ein deterministischer Ansatz das Problem sofort und zuverlässig lösen könnte.
Diese Beobachtung erstreckt sich über individuelle technische Entscheidungen hinaus zu breiteren strategischen Fragen. Die Flexibilität von MCP erleichtert es, KI-Fähigkeiten in bestehende Arbeitsabläufe zu integrieren. Diese einfache Integration kann zu reflexiver KI-Akzeptanz führen, ohne sorgfältig zu prüfen, ob KI für eine bestimmte Aufgabe echten Mehrwert bietet.
„Ist das wirklich der richtige Weg, oder ist es nur so, dass KI eine coole Sache ist, die wir einfach überall einsetzen sollten?“, fragt Wallkötter. Diese Frage verdient ernsthafte Überlegung, bevor Ressourcen für KI-gestützte Lösungen bereitgestellt werden.
Das Paradoxon des Arbeitsmarktes
Das Gespräch offenbarte eine unerwartete Perspektive auf die Auswirkungen von KI auf die Beschäftigung. Wallkötter war zunächst der Meinung, dass KI die Arbeiter eher ergänzen als ersetzen würde, was den historischen Mustern bei früheren technologischen Umwälzungen entspricht. Jüngste Beobachtungen haben diese Sichtweise jedoch kompliziert.
„Ich denke, ich lag diesbezüglich tatsächlich ganz falsch“, gesteht er und reflektiert über seine früheren Vorhersagen. Als KI erstmals in den Mainstream trat, entstand in der Branche eine gängige Meinung: „Sie werden nicht durch KI ersetzt, sondern durch eine Person, die KI verwendet.“ Wallkötter war zunächst dieser Ansicht, indem er Parallelen zu historischen Technologieadoptionszyklen zog.
„Als die Schreibmaschine herauskam, kritisierten Menschen, die darin ausgebildet waren, mit Feder und Tinte zu schreiben, dass sie den Geist des Schreibens töten würden, und es sei einfach tot, und niemand werde eine Schreibmaschine benutzen. Es sei nur eine seelenlose Maschine“, bemerkt er. „Schaut man ein paar Jahrzehnte später zurück, benutzen alle Computer.“
Dieses Muster der anfänglichen Ablehnung gefolgt von universeller Akzeptanz schien auch auf KI zuzutreffen. Der entscheidende Unterschied liegt in der Art der automatisierten Arbeit und ob diese Arbeit in einem festen oder erweiterbaren Pool existiert. Die Softwareentwicklung veranschaulicht die erweiterbare Kategorie. „Sie können jetzt, wenn Sie zuvor ein Ticket aus Ihrem Ticketsystem erhalten haben, die Lösung programmieren, die Merge-Anfrage senden, das nächste Ticket erhalten und den Zyklus wiederholen. Dieses Stück kann jetzt schneller erledigt werden, sodass Sie mehr Tickets bearbeiten können“, erklärt Wallkötter.
Die Zeit, die bei Wartungsarbeiten eingespart wird, beseitigt nicht den Bedarf an Ingenieuren. Vielmehr verschiebt sie, wie sie ihre Zeit aufteilen. „Die gesamte Zeit, die Sie sparen, weil Sie jetzt weniger Zeit mit Wartung verbringen können, können Sie jetzt mit Innovation verbringen“, beobachtet er. „Was passiert, ist, dass Sie den Shift haben, wie viel Zeit Sie mit Innovation verbringen, wie viel Zeit Sie mit Wartung verbringen, und dieser Innovationspool wächst.“
Der Kundenservice hingegen präsentiert ein ganz anderes Bild. „Es gibt nur so viele Kundenfälle, die eingehen, und die meisten Unternehmen innovieren zumindest nicht in dem, was sie für den Kundenservice tun“, erklärt Wallkötter. „Sie wollen, dass es gelöst wird, sie wollen, dass die Kunden Antworten auf ihre Fragen finden, und sie wollen, dass die Erfahrung, mit dem Unternehmen zu sprechen, gut ist. Aber das ist im Grunde genommen der Punkt.“
Die Unterscheidung ist deutlich. Im Kundenservice wird das Arbeitsvolumen durch eingehende Anfragen bestimmt, nicht durch die Kapazität des Teams. Wenn KI diese Anfragen effektiv bearbeiten kann, wird die Rechnung einfach. „Da haben Sie nur noch Arbeit für eine Person, wenn Sie zuvor Arbeit für vier Personen hatten.“
Diese Trennung zwischen erweiterbaren und festen Arbeitslasten könnte bestimmen, welche Rollen von Verdrängung betroffen sind und welche transformiert werden. Das Muster erstreckt sich über diese beiden Beispiele hinaus. Jede Rolle, in der erhöhte Effizienz Möglichkeiten für zusätzliche wertvolle Arbeit schafft, scheint widerstandsfähiger zu sein. Jede Rolle, in der das Arbeitsvolumen extern begrenzt ist und Innovation keine Priorität hat, ist einem höheren Risiko ausgesetzt.
Wallkötters überarbeitete Perspektive erkennt eine komplexere Realität an, als einfache Narrative über Ergänzung oder Ersatz vermuten lassen. Die Frage ist nicht, ob KI Arbeitsplätze ersetzt oder ergänzt, sondern welche spezifischen Merkmale einer Rolle ihren Verlauf bestimmen. Die Antwort erfordert eine Untersuchung der Natur der Arbeit selbst, der Einschränkungen des Arbeitsvolumens und ob Effizienzgewinne zu erweiterten Möglichkeiten oder reduzierten Personalbedarfen führen.
Der Weg nach vorn
Die rasche Akzeptanz von MCP zeigt das Verlangen der KI-Branche nach Standardisierung und Interoperabilität. Das Protokoll löste ein echtes Problem und tat dies mit ausreichender Einfachheit, um eine weit verbreitete Implementierung zu fördern. Doch die Herausforderungen, die aus dieser Akzeptanz hervorgehen, verdeutlichen die Unreife des Feldes in kritischen Bereichen.
Sicherheitsbedenken hinsichtlich Authentifizierung und Eingabeaufforderungsinjektion erfordern grundlegende Lösungen, keine inkrementellen Patches. Die Branche muss robuste Rahmenbedingungen entwickeln, die die einzigartigen drei Parteien-Dynamiken der Interaktionen von KI-Agenten bewältigen können. Bis diese Rahmenbedingungen existieren, wird die Unternehmensbereitstellung erhebliche Risiken mit sich bringen.
Das Problem der Werkzeugüberlastung und die grundlegende Frage, wann KI eingesetzt werden sollte, weisen beide auf die Notwendigkeit einer größeren Disziplin im Systemdesign hin. Die Fähigkeit, Werkzeuge einfach hinzuzufügen, sollte nicht dazu führen, dass Werkzeuge nachlässig hinzugefügt werden. Organisationen sollten bewerten, ob KI bedeutende Vorteile gegenüber einfacheren Alternativen bietet, bevor sie sich auf komplexe Agentenarchitekturen festlegen.
Wallkötters Perspektive, die sowohl durch Erfahrungen in der akademischen Robotik als auch in der kommerziellen KI-Entwicklung geprägt ist, betont die Bedeutung, „stabile Anwendungsfälle“ zu finden, anstatt technologischen Fähigkeiten um ihrer selbst willen nachzujagen. Das instabile Gleichgewicht humanoider Rob
