Dein Blog zum Thema digitales Business

Ein MCP-Server liefert Code und Text, denen dein Agent ab dem ersten Aufruf glaubt

Das Model Context Protocol (MCP) lässt Server Tools bereitstellen, die ein Sprachmodell aufrufen kann. Laut MCP-Spezifikation können Tools zum Beispiel Datenbanken abfragen, APIs aufrufen oder etwas berechnen. Jedes Tool hat einen Namen, eine Beschreibung und ein Eingabeschema. Tools sind dort als „model-controlled“ beschrieben: Das Modell entdeckt sie und ruft sie selbstständig auf, abhängig vom Kontext und von deinen Prompts. Für einen KI-Agenten ist ein MCP-Server damit die Schnittstelle, über die er in fremde Systeme greift.

Ein Server, den du nicht selbst geschrieben hast, bringt zwei Dinge von außen mit. Das erste ist Code. Ein lokaler Server läuft als Prozess auf deinem Rechner, und die Spezifikation nennt als Risiko, dass Angreifer damit beliebige Befehle mit den Rechten des Clients ausführen können. Das zweite ist Text. Die Beschreibungen der Tools landen im Kontext des Modells. Invariant Labs hat im April 2025 unter dem Namen Tool Poisoning einen Angriff beschrieben, der genau hier ansetzt: Anweisungen stehen in einer Tool-Beschreibung, die für Nutzer unsichtbar, für das Modell aber sichtbar ist.

Grundlage dieses Beitrags sind die Seiten Security Best Practices und Tools der MCP-Spezifikation (Version 2025-11-25) und die Analyse von Invariant Labs, die Prüfliste unten übersetzt sie in die Sicht dessen, der einen Server einbindet. Wo eine Aussage aus der Quelle stammt, steht die Quelle im Satz. Empfehlungen ohne Quellenangabe sind die Übersetzung in deine Praxis.

Der Beitrag Prompt-Injection: Wenn Text zum Angriffsvektor wird erwähnt MCP als Beispiel für einen Vorfall. Hier geht es um die Prüfung davor: was du klärst, bevor ein Agent einen Server zum ersten Mal aufruft.

Acht Prüfpunkte vor der ersten Nutzung

1. Herkunft und Betreiber. Wer hat den Server geschrieben, wer betreibt ihn, wo liegt der Quellcode, wird er gepflegt? Die Spezifikation führt Server aus nicht vertrauenswürdigen Quellen ausdrücklich als Risiko auf und nennt unter anderem zwei Wege: eine schädliche Nutzlast im Server selbst und einen schädlichen Startbefehl in einer Client-Konfiguration. Die Fragen nach Maintainer und Historie sind dieselben wie bei einer Action, die du zum ersten Mal einbindest, und die Vorgehensweise steht in GitHub Actions vor dem ersten Einsatz prüfen.

2. Lokal oder remote. Bei einem lokalen Server prüfst du den Startbefehl. Die Spezifikation verlangt von Clients mit Ein-Klick-Konfiguration, den Befehl samt Argumenten ungekürzt anzuzeigen und eine ausdrückliche Zustimmung einzuholen. Zeigt dein Client das nicht, liest du die Konfigurationsdatei selbst. Achte auf sudo, auf Netzwerkaufrufe und auf Zugriffe auf Home-Verzeichnis oder SSH-Schlüssel; solche Muster nennt die Spezifikation als Warnzeichen. Empfohlen wird außerdem, lokale Server in einer Sandbox mit minimalen Standardrechten zu starten, mit eingeschränktem Zugriff auf Dateisystem und Netzwerk. Bei einem Remote-Server läuft der Code beim Betreiber. Was du in Tool-Argumenten schickst, verlässt deinen Rechner. Allgemein empfiehlt die Spezifikation Clients, Tool-Eingaben vor dem Aufruf anzuzeigen, um schädlichen oder versehentlichen Datenabfluss zu vermeiden.

3. Welche Tools und welche Rechte. Lass dir die Tool-Liste des Servers im Rohformat ausgeben. Die Antwort auf tools/list enthält pro Tool Name, Beschreibung und Eingabeschema. Frage bei jedem Tool: Liest, schreibt oder löscht es? Passt das zum Zweck des Servers? Im Beispiel von Invariant Labs hat ein Tool add, das zwei Zahlen addieren soll, einen dritten Parameter namens sidenote. Ein Parameter, den der Zweck nicht erklärt, ist ein Prüfanlass.

4. Tool-Beschreibungen im Rohtext lesen. Im Cursor-Test von April 2025 sah das Modell laut Invariant Labs die vollständige Beschreibung inklusive versteckter Anweisungen, der Nutzer dagegen nur einen vereinfachten Tool-Namen, die Argumente blieben verborgen. Als Ursache nennen sie, dass viele Clients eingebundene Tool-Beschreibungen nicht ausreichend bereinigen, prüfen oder anzeigen. Im Beispielangriff steht in der Beschreibung ein <IMPORTANT>-Block, der das Modell anweist, die Konfigurationsdatei des Editors und einen privaten SSH-Schlüssel zu lesen. Für dich heißt das: Lies jede Beschreibung vollständig, im Rohtext, nicht in der Kurzansicht des Clients. Achte auf Anweisungen an das Modell statt einer Beschreibung der Funktion, auf Verweise auf Dateien, Pfade und Zugangsdaten und auf Formulierungen, die etwas vor dir verbergen sollen. Die Spezifikation schreibt Clients außerdem vor, Tool-Annotationen als nicht vertrauenswürdig zu behandeln, solange der Server nicht vertrauenswürdig ist. Beschreibungen nennt sie dort nicht ausdrücklich. Invariant Labs beschreibt zusätzlich das Tool Shadowing: Ein schädlicher Server kann Beschreibungen so vergiften, dass Daten abfließen, die über andere, vertrauenswürdige Server erreichbar sind. Im Experiment ging es um ein send_email-Tool. Prüfe deshalb auch, welche Server dein Agent gleichzeitig nutzt.

5. Rechte und Scopes minimal halten. Die Spezifikation beschreibt als Fehlerbild einen Token mit breiten Scopes wie files:*, db:* oder admin:*, der von vornherein vergeben wurde, weil der Server alle Scopes angeboten und der Client sie alle angefragt hat. Gelangt ein solcher Token in fremde Hände, etwa über Logs, öffnet er laut Spezifikation den Zugriff auf weitere Tools und Ressourcen, die mit der Aufgabe nichts zu tun haben, und lässt sich nur schwer widerrufen. Empfohlen wird ein Modell mit möglichst kleinem Startumfang, der nur risikoarme Lese- und Erkundungsoperationen enthält, und einer Erweiterung erst dann, wenn eine privilegierte Operation tatsächlich gebraucht wird. Als häufige Fehler führt sie Wildcard-Scopes (*, all, full-access) auf. Für dich heißt das: den Zustimmungsdialog lesen, nicht durchklicken, und dem Server einen eigenen Zugang mit den Rechten geben, die seine Aufgabe braucht, nicht dein persönliches Konto. Wie du erteilte Berechtigungen dauerhaft im Blick behältst, steht in OAuth-Scopes installierter GitHub-Apps: nie wieder geprüft.

6. Freigabe pro Tool. Die Spezifikation empfiehlt, dass immer ein Mensch in der Schleife bleibt und Aufrufe ablehnen kann. Anwendungen sollen anzeigen, welche Tools dem Modell angeboten werden, Aufrufe sichtbar kennzeichnen und Bestätigungen einholen. Eine Bestätigung ist aber nur so viel wert wie das, was sie zeigt. Im Cursor-Test von April 2025 zeigte die Oberfläche dem Nutzer nur einen kurzen Tool-Namen, obwohl er dem Aufruf zustimmen musste. Für dich heißt das: Gib Tools einzeln frei statt den Server als Ganzes und trenne lesende von schreibenden Tools. Bestätige nur Aufrufe, bei denen du die Eingaben gesehen hast.

7. Stand festhalten und Änderungen bemerken. Invariant Labs beschreibt den Rug Pull: Ein schädlicher Server kann die Tool-Beschreibung ändern, nachdem der Client sie bereits freigegeben hat. Ihre Empfehlung an Clients lautet, die Version des MCP-Servers und seiner Tools festzuhalten und die Integrität der Tool-Beschreibung per Hash oder Prüfsumme zu verifizieren, bevor sie ausgeführt wird. Für dich heißt das: Server nur mit fester Version oder festem Commit einbinden statt mit der jeweils neuesten, den Hash der geprüften tools/list-Antwort ablegen und bei jeder Abweichung die Punkte 3 und 4 neu durchlaufen. Auch hier gilt die Unterscheidung aus dem Actions-Beitrag: Festhalten ersetzt die Prüfung nicht, es sorgt nur dafür, dass du weißt, was du geprüft hast.

8. Protokollierung. Die Spezifikation empfiehlt Clients, die Nutzung von Tools zu Audit-Zwecken zu protokollieren. Im Abschnitt zu Token-Weiterreichung nennt sie fehlende Nachvollziehbarkeit als Risiko: Log-Einträge am Zielsystem zeigen dann womöglich eine andere Herkunft als den Server, der tatsächlich aufgerufen hat. Halte deshalb pro Aufruf fest, welcher Server, welches Tool, mit welchen Argumenten, wann und mit welchem Ergebnis. Ohne diese Spur kannst du nach einem Vorfall nicht sagen, was ein Server getan hat.

Sechs Testfälle in einer Wegwerf-Umgebung

• Server ohne echte Zugangsdaten und ohne Zugriff auf dein Home-Verzeichnis starten, tools/list abrufen: Tools und Parameter entsprechen der Dokumentation, nichts Zusätzliches.
• Die Beschreibung jedes Tools im Rohtext durchsuchen: keine Anweisungen an das Modell, keine Dateipfade, keine Bezüge zu Zugangsdaten.
• Ein lesendes Tool aufrufen: Der Client zeigt Toolnamen und Eingaben vor dem Aufruf. Lehnst du ab, findet kein Aufruf statt.
• Eine Aktion außerhalb der erteilten Scopes oder Verzeichnisse versuchen: wird abgelehnt.
• Im Testaufbau eine Tool-Beschreibung ändern: Dein Hash-Vergleich schlägt an.
• Nach den Aufrufen ins Log schauen: Server, Tool, Argumente, Zeitpunkt und Ergebnis sind zu finden.

Schlägt einer der sechs Fälle fehl, vertraust du dem Server, weil er läuft, nicht weil du ihn geprüft hast.

Wo das Thema an Nachbarthemen grenzt

Die Prüfung beantwortet eine Frage: Darf dieser Server in den Werkzeugkasten deines Agenten? Sie ersetzt nicht die Kontrollen an anderer Stelle. Was passiert, wenn ein Agent selbst committet und pusht, steht in Der Agent committet allein: lokale Git-Hooks vor dem Push. Wie Text in Issues und Repositories zum Angriffsvektor wird, behandelt der bereits genannte Beitrag zur Prompt-Injection. Ein MCP-Server ist Code und Text von außen. Er bekommt Vertrauen erst nach der Prüfung, nicht mit der Installation.

Wo Unterstützung ansetzt

Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.

Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.