MCP-Sicherheit: KI-Agenten und ihre Tool-Anbindungen absichern

Von Wladimir Neuberger · Aktualisiert 27.10.2026

Was MCP ist und warum es ein Sicherheitsthema ist

Das Model Context Protocol (MCP) ist laut offizieller Spezifikation ein offenes Protokoll, das KI-Anwendungen mit externen Datenquellen und Werkzeugen verbindet. Es unterscheidet drei Rollen: Hosts sind die KI-Anwendungen, die Verbindungen aufbauen, Clients sind die Verbindungsstücke innerhalb des Hosts, Server stellen Kontext und Fähigkeiten bereit. Ein Server kann Ressourcen (Daten), Vorlagen (Prompts) und Werkzeuge (Funktionen, die das Modell ausführen darf) anbieten.

Für die Sicherheit ist vor allem der letzte Punkt wichtig. Die Spezifikation schreibt selbst, MCP ermögliche seine Fähigkeiten „durch beliebigen Datenzugriff und Codeausführungspfade“ und Werkzeuge stellten beliebige Codeausführung dar, die mit entsprechender Vorsicht zu behandeln sei. Wer einen MCP-Server anbindet, gibt also einem Dritten einen Platz im eigenen Agenten. Die Risikoliste für agentische Anwendungen der OWASP-Initiative für generative KI nennt das als eigenes Risiko: Agenten laden Werkzeuge, Daten oder Vorlagen zur Laufzeit von Dritten, und diese Quellen können kompromittiert sein.

Was die Spezifikation selbst verlangt

Die Spezifikation räumt ein, dass das Protokoll die Sicherheitsprinzipien nicht selbst durchsetzen kann. Umsetzen müssen sie die Anwendungen. Die Hinweise zu Werkzeugen und die Seite „Security Best Practices“ nennen unter anderem:

• Mensch in der Schleife: Bei Werkzeugaufrufen solle immer ein Mensch beteiligt sein, der sie ablehnen kann. Anwendungen sollen sichtbar machen, welche Werkzeuge dem Modell zur Verfügung stehen, und bei Aufrufen Bestätigungen einholen.
• Eingaben prüfen, Zugriff steuern: Server müssen alle Werkzeug-Eingaben validieren, Zugriffskontrollen umsetzen, Aufrufe in der Häufigkeit begrenzen und Ausgaben bereinigen.
• Clients in der Pflicht: Sie sollen bei sensiblen Operationen nachfragen, die Eingaben vor dem Aufruf anzeigen, um Datenabfluss zu vermeiden, Ergebnisse prüfen, bevor sie ans Modell gehen, Zeitlimits setzen und die Nutzung für spätere Prüfungen protokollieren.
• Beschreibungen sind nicht vertrauenswürdig: Beschreibungen des Werkzeugverhaltens, etwa Annotationen, gelten als nicht vertrauenswürdig, solange sie nicht von einem vertrauenswürdigen Server stammen.

Typische Risiken bei Tool-Anbindungen

Die folgenden Risiken sind in den Quellen beschrieben. Es sind konzeptionelle Beschreibungen, keine Anleitungen.

• Manipulierte Werkzeugbeschreibungen: Invariant Labs prägte dafür den Begriff „Tool Poisoning“. Gemeint sind Anweisungen in der Beschreibung eines Werkzeugs, die Nutzer nicht sehen, das Modell aber liest. Simon Willison ordnet das als Form der Prompt Injection ein, die immer dann auftreten kann, wenn ein Modell Werkzeuge nutzt und nicht vertrauenswürdigen Eingaben ausgesetzt ist.
• Nachträgliche Änderungen: Laut Invariant Labs kann ein Server eine Werkzeugbeschreibung ändern, nachdem der Nutzer sie freigegeben hat („Rug Pull“). Willison weist darauf hin, dass manche Clients über solche Änderungen nicht informieren.
• Imitation und Lieferkette: Als Beispiel für Lieferkettenrisiken nennt die Zusammenfassung der OWASP-Agenten-Liste einen bösartigen MCP-Server, der sich als bekannter E-Mail-Dienst ausgibt und heimlich Kopien aller Mails weiterleitet. Zu Werkzeugmissbrauch zählt dort außerdem, dass ein Agent durch einen ähnlich benannten Werkzeugnamen auf ein falsches Werkzeug gelenkt wird.
• Lokale Server: Laut Spezifikation laufen lokale MCP-Server mit den Rechten des Clients. Ohne Isolation und Zustimmung können eingeschleuste Startbefehle beliebigen Code auf dem Rechner ausführen.

Auch die beste Absicherung beseitigt Prompt Injection nicht vollständig. Willison schrieb 2025, es gebe dagegen keine überzeugende Lösung. Planen Sie deshalb so, dass ein manipulierter Agent nur begrenzten Schaden anrichten kann.

Maßnahmen: unsere Empfehlung

Die folgende Liste ist unsere Empfehlung aus dem Bau eigener Agenten, etwa des Sprach-Agenten CITT mit Anbindung an Kalender und CRM. Sie stützt sich auf die oben genannten Quellen, ist aber keine Zitatsammlung.

• Allowlist statt Offenheit: Es dürfen nur freigegebene Server angebunden werden. Neue Server nimmt eine benannte Person ins Verzeichnis auf, nicht der Agent und nicht jeder Entwickler nach Belieben.
• Zugriff begrenzen: Jeder Server und jedes Werkzeug bekommt nur die Rechte, die die Aufgabe braucht, bevorzugt lesend. Die Spezifikation empfiehlt, mit wenigen Berechtigungen zu beginnen und erst bei Bedarf zu erweitern, statt alle Berechtigungen auf Vorrat zu vergeben. OWASP rät bei übermäßiger Handlungsfreiheit zu schmalen Werkzeugen statt offener wie einer Shell.
• Versionen festlegen: Server und Werkzeugdefinitionen werden auf eine geprüfte Version festgelegt. Invariant Labs empfiehlt, Server und Werkzeuge zu pinnen und die Integrität per Prüfsumme zu kontrollieren. Eine Änderung der Beschreibung löst eine erneute Prüfung aus.
• Bestätigung bei Folgen: Löschen, Bezahlen, Versenden an Externe und Änderungen an Zugängen verlangen eine Freigabe durch einen Menschen, die in der Anwendung erzwungen wird und nicht nur im Prompt steht.
• Isolation: Lokale Server laufen in einer Sandbox mit minimalen Rechten, etwa im Container, ohne Zugriff auf Home-Verzeichnis, SSH-Schlüssel und andere Geheimnisse.
• Protokollierung: Jeder Aufruf wird mit Server, Werkzeug, Eingaben und Auslöser gespeichert. Ohne dieses Protokoll lässt sich nach einem Vorfall nicht rekonstruieren, was der Agent getan hat.

Prüfung vor dem Einsatz

Bevor ein Server in einen produktiven Agenten kommt, genügt eine kurze, wiederholbare Prüfung. Sie ersetzt keinen Sicherheitstest, hält aber die offensichtlichen Fehler fern.

• Herkunft: Wer betreibt den Server, wo liegt der Quellcode, wer pflegt ihn? Bei unklarer Herkunft nicht anbinden.
• Werkzeugliste lesen: Alle Namen, Beschreibungen und Parameter vollständig ansehen, nicht nur die Kurzfassung der Oberfläche. Auffällig sind Beschreibungen, die dem Modell Anweisungen geben.
• Rechte vergleichen: Verlangt der Server mehr Zugriff, als sein Zweck braucht? Dann weniger Rechte vergeben oder einen anderen Server wählen.
• Testbetrieb: Zuerst mit Testdaten und ohne produktive Zugangsdaten laufen lassen und die Aufrufe im Protokoll lesen.
• Wiederholung: Bei jedem Update und in festen Abständen erneut prüfen, weil sich Werkzeuge nach der Freigabe ändern können.

Häufige Fragen

Quellen

• Model Context Protocol — Specification (Überblick, Abschnitt „Security and Trust & Safety“)
• Model Context Protocol — Specification: Tools (Abschnitte „User Interaction Model“ und „Security Considerations“)
• Model Context Protocol — Security Best Practices (u. a. lokale Server, Token Passthrough, Scope Minimization)
• Invariant Labs — MCP Security Notification: Tool Poisoning Attacks
• Simon Willison — Model Context Protocol has prompt injection security problems (9. April 2025)
• Giskard — OWASP Top 10 for Agentic Applications 2026: Security Guide (u. a. ASI02 und ASI04)
• OWASP GenAI Security Project — LLM06:2025 Excessive Agency

Die Einordnung beruht auf den genannten Veröffentlichungen. Prüfen Sie bei Entscheidungen die Originalquelle.

Weiterlesen

• Rechte und Freigaben für KI-Agenten: Excessive Agency vermeiden
• Zugangsdaten für KI-Agenten: Schlüssel, Tokens und Identitäten sicher verwalten
• Cyber Security im Agentenzeitalter: Was sich ändert, wenn KI selbst handelt