Sind MCP und AI Agent Skills sicher? Die 10 Sicherheitsrisiken, die Sie vor der Nutzung von Drittanbieter-KI-Tools 2026 prüfen müssen

Zehn Risikofelder müssen Sie vor einer Freigabe getrennt prüfen: Die OWASP-Kontrollen für MCP und die Einordnung von übermäßiger Handlungsfreiheit bei KI-Agenten zeigen, warum ein Werkzeugname allein keine Sicherheitsgarantie ist. MCP und AI Agent Skills sind weder grundsätzlich sicher noch grundsätzlich unsicher. Geben Sie sie nur frei, wenn Herkunft und Abhängigkeiten nachvollziehbar sind, Rechte zur Aufgabe passen, Datenziele bekannt sind und die Ausführung ausreichend isoliert ist. Können Sie eines davon nicht verifizieren, verschieben Sie die Freigabe.

Dieser Beitrag richtet sich an Entwickler, die MCP-Dienste anbinden, an Nutzer, die AI Agent Skills installieren, und an technische Verantwortliche, die Agenten bereitstellen oder Sicherheitsprüfungen festlegen. Sie erhalten eine Risikoeinordnung, ein Bewertungsraster und einen Ablauf für die Prüfung vor dem Produktiveinsatz.

Zuletzt aktualisiert: 2026. Fachliche Grundlage sind die unten verlinkten MCP-, OWASP-, NIST- und Skills-Dokumente. Versions- und Implementierungsunterschiede prüfen Sie vor der Freigabe erneut anhand der jeweiligen Projektunterlagen.

MCP und AI Agent Skills sicher beurteilen: Herkunft, Rechte und Datenfluss prüfen

Wie erkennen Sie, ob eine Drittanbieterquelle vertrauenswürdig ist? Suchen Sie nach einem nachvollziehbaren Herausgeber, einer offiziellen Bezugsquelle, aktuellen Wartungsinformationen und überprüfbaren Änderungen. Ein bekannter Name genügt nicht: Entscheidend ist, ob Sie den konkreten Inhalt, seine Abhängigkeiten und seine tatsächliche Ausführung prüfen können. Die MCP-Sicherheitsrichtlinie des Projekts bietet einen Bezugspunkt für die Sicherheitsbehandlung im MCP-Umfeld. Sie ersetzt aber keine Prüfung des konkreten Servers oder seiner Laufzeitumgebung.

Bei Skills gilt dasselbe für Anweisungen und mitgelieferte Dateien. Die Skills-Spezifikation beschreibt den vorgesehenen Rahmen; die Hinweise zum Erstellen eines Skills sind eine nützliche Quelle, um Aufbau und Bestandteile eines Skills einzuordnen. Lesen Sie den tatsächlich installierten Inhalt, nicht nur die Kurzbeschreibung im Verzeichnis.

Für die erste Entscheidung können Sie jede Dimension mit 0 bis 2 Punkten bewerten. Das Raster ist eine Prüfhilfe, kein empirischer Sicherheitswert: 0 bedeutet „Nachweis fehlt oder erheblicher Mangel“, 1 „teilweise nachvollziehbar“, 2 „belegt und kontrolliert“. Ein niedriger Wert bei Herkunft, Datenfluss oder Ausführungsgrenze ist ein Grund, nicht freizugeben.

Prüfoption	Herkunft und Wartung	Berechtigungen und Datenfluss	Ausführung und Kontrolle	Entscheidung
Freigeben	Herausgeber und Bezugsquelle sind prüfbar	Aufgabe, Datenziele und Rechte sind klar begrenzt	Isolierter Test, Protokollierung und Widerruf sind möglich	Nur für den geprüften Umfang
Erst nacharbeiten	Einzelne Angaben oder Kontrollen fehlen	Rechte oder Datenwege sind unvollständig dokumentiert	Ausführung kann noch eingegrenzt werden	Bis zum Nachweis gesperrt lassen
Ablehnen oder pausieren	Quelle oder Wartungsstatus bleibt unklar	Unnötige Rechte oder unbekannte Datenziele	Ausführung nicht kontrollierbar, Abschaltung ungeklärt	Keine produktive Freigabe

Die Punkte sollten Sie nicht einfach addieren und einen hohen Gesamtwert als Entwarnung behandeln. Ein ungeklärter Abfluss vertraulicher Daten lässt sich nicht durch gute Dokumentation an anderer Stelle ausgleichen. Notieren Sie pro Dimension den Nachweis, etwa einen Link auf die offizielle Quelle, die geprüfte Rechtekonfiguration oder den Test des Widerrufs.

MCP-Risiken bei Werkzeugaufrufen und Datenflüssen erkennen

Die Risiken hängen von der konkreten Funktion, den Berechtigungen und den Eingaben ab. Sie treten nicht automatisch bei jedem MCP-Dienst auf. Prüfen Sie, was der Dienst tatsächlich tun kann und welche Daten er dafür erhält.

Zu weitreichende Lese-, Schreib- oder Ausführungsrechte. Das Risiko entsteht, wenn ein Dienst mehr Zugriff bekommt, als seine Aufgabe erfordert, etwa Schreibzugriff für eine reine Suchfunktion. Prüfen Sie die angeforderten Rechte einzeln und vergleichen Sie sie mit dem vorgesehenen Arbeitsablauf. Begrenzen Sie den Zugriff auf notwendige Ressourcen und trennen Sie Lese- von Schreibrechten, sofern die Implementierung das unterstützt.
Prompt Injection über zurückgegebene Inhalte. Ein Werkzeugergebnis kann Text enthalten, der den Agenten zu einer unerwarteten Handlung auffordert. Das ist besonders relevant, wenn der Agent externe Dokumente, Webseiten oder Nachrichten einliest und anschließend selbst Aktionen ausführen darf. Die OWASP-Leitlinie zu Prompt-Injection-Abwehr empfiehlt Schutzmaßnahmen entlang der Verarbeitung solcher Eingaben. Behandeln Sie zurückgegebene Inhalte als nicht vertrauenswürdig, prüfen Sie daraus abgeleitete Aktionen und verlangen Sie für folgenreiche Vorgänge eine gesonderte Bestätigung.
Unerwartete Übermittlung sensibler Daten. Parameter, Kontext oder Werkzeugverhalten können Informationen an ein Ziel weitergeben, das in Ihrer Annahme nicht vorgesehen war. Prüfen Sie dafür Ein- und Ausgaben, Konfiguration, Dokumentation und – soweit verfügbar – Netzwerk- oder Anwendungsprotokolle. Achten Sie insbesondere darauf, ob Prompts, Dateien oder Ergebnisse an externe Dienste weitergereicht werden. Richten Sie die Prüfung auf Zugriff, Eingaben und Datenbehandlung aus.

Prüfhinweis: Eine Funktion darf nicht allein deshalb vertrauliche Daten erhalten, weil der Agent technisch darauf zugreifen kann. Geben Sie nur die Daten frei, die für den konkreten Arbeitsgang erforderlich sind.

Kann MCP zu einer Offenlegung sensibler Daten führen? Ja, wenn ein Aufruf vertrauliche Inhalte in einen nicht genehmigten Datenweg bringt, wenn Ausgaben ungeprüft weitergeleitet werden oder wenn zu breite Rechte den Zugriff auf zusätzliche Informationen ermöglichen. Das ist eine bedingte Gefahr, keine pauschale Eigenschaft von MCP. Dokumentieren Sie für jeden Datenweg, welche Daten ein- und ausgehen, wer sie verarbeiten darf und wie Sie einen Zugriff beenden.

Herkunft und Ausführung von MCP-Diensten und Skills absichern

Manipulierte oder nicht nachvollziehbare Komponenten. Ein Dienst, Paket oder eine Abhängigkeit kann aus einer unklaren Quelle stammen oder nicht mehr nachvollziehbar gepflegt werden. Das Risiko ist relevant, wenn Sie weder Herausgeber noch Bezugsweg noch Änderungen verifizieren können. Bevorzugen Sie offizielle Projektquellen und prüfen Sie Wartungshinweise, Änderungsverlauf sowie bekannte Sicherheitsmitteilungen. Fehlt ein überprüfbarer Bezugspunkt, führen Sie die Komponente nicht mit produktiven Daten aus.
Skill-Anweisungen, die Nutzerabsicht oder Schutzregeln umgehen. Ein Skill kann Anweisungen enthalten, die den Agenten zu Handlungen außerhalb des erwarteten Auftrags lenken. Lesen Sie den vollständigen Inhalt und suchen Sie nach Vorgaben, die Sicherheitsregeln ignorieren, Daten weitergeben oder zusätzliche Werkzeuge aufrufen lassen. Prüfen Sie den Aufbau und den konkreten Inhalt des jeweiligen Skills; die Freigabe erfordert eine Sichtung der tatsächlich installierten Dateien.
Skripte, Befehle oder Abhängigkeiten mit unerwarteter Wirkung. Das Risiko entsteht, wenn installierte Bestandteile außerhalb der beschriebenen Funktion Dateien verändern, Prozesse starten oder weitere Komponenten laden. Prüfen Sie jede ausführbare Datei und jeden Installationsschritt, bevor Sie ihn starten. Testen Sie in einer Umgebung ohne produktive Zugangsdaten und ohne unnötigen Zugriff auf lokale Verzeichnisse. Lassen sich Wirkung und Abhängigkeiten nicht nachvollziehen, stoppen Sie die Installation.

Die Herkunft eines Pakets allein sagt nicht, ob es für Ihre konkrete Nutzung geeignet ist. Ebenso ist ein öffentlich einsehbarer Quelltext kein Nachweis, dass das ausgeführte Artefakt exakt diesem Inhalt entspricht. Vergleichen Sie – sofern die Quelle dies ermöglicht – den bereitgestellten Inhalt mit dem geprüften Stand und dokumentieren Sie, was tatsächlich installiert wurde.

Verknüpfte Werkzeuge, Geheimnisse und Zugangsdaten begrenzen

Offengelegte Schlüssel und Zugangsdaten. Zugangstoken können in Konfigurationsdateien, Prompts, Ausgaben oder Protokollen landen. Prüfen Sie, wo Geheimnisse gespeichert werden, wer sie lesen kann und ob Debug-Ausgaben sie enthalten. Verwenden Sie keine dauerhaften Produktionszugänge für erste Tests. Begrenzen Sie Berechtigungen und Gültigkeitsumfang; halten Sie einen Widerrufsweg bereit.
Kettenaufrufe und ein „Confused Deputy“. Ein einzelnes Werkzeug kann unauffällig wirken, während eine Kette aus Agent, MCP-Dienst und weiteren Werkzeugen zusammengenommen eine nicht autorisierte Handlung ermöglicht. Der Agent könnte etwa Daten mit einem Werkzeug abrufen und sie über ein anderes weitergeben. Das Risiko besteht dann, wenn Autorisierung nur pro Werkzeug geprüft wird, nicht aber für den gesamten Ablauf. Prüfen Sie, welche Daten zwischen Werkzeugen fließen, welche Identität eine Aktion ausführt und an welchen Stellen eine menschliche Bestätigung erforderlich ist. Die OWASP-Einordnung zu übermäßiger Handlungsfreiheit unterstreicht, warum Umfang und Grenzen delegierter Aktionen geprüft werden müssen.

Eine sinnvolle Kontrolle betrachtet daher nicht nur die einzelne Schnittstelle. Zeichnen Sie den Ablauf vom ursprünglichen Nutzerauftrag bis zur letzten Aktion auf: Welche Komponente empfängt Daten? Welche darf sie verändern? Welche kann nach außen senden? Wenn Sie diese Kette nicht nachvollziehen können, begrenzen Sie die Verbindung auf nicht vertrauliche Testdaten und schreibgeschützte Aufgaben.

Wichtig: Speichern Sie kein Geheimnis im Kontext, nur weil der Agent es kurzfristig benötigt. Prüfen Sie vorab, ob die jeweilige Integration ein kontrolliertes Verfahren für Zugangsdaten unterstützt und wie Sie eine Offenlegung erkennen und beheben.

Identität, Protokollierung und Rücknahme verbindlich testen

Schwache Authentifizierung oder unzureichende Token-Verwaltung. Wiederverwendbare, übermäßig berechtigte oder offengelegte Zugangsdaten erhöhen die Folgen eines Fehlers. Prüfen Sie, wie Identität festgestellt, Autorisierung vergeben und ein Token widerrufen wird. Vermeiden Sie gemeinsam genutzte Zugangsdaten, wenn die Plattform eine Zuordnung zu einzelnen Nutzern oder Diensten unterstützt. Die NIST-Einordnung zu Identität und Zugangsdaten für agentische KI erläutert, weshalb eine belastbare Identitätsgrundlage bei Agenten wichtig ist. Verlassen Sie sich nicht auf eine allgemeine Beschreibung: Kontrollieren Sie die tatsächlich eingesetzte Authentifizierung.
Fehlende Auditierbarkeit oder kein Rücknahmeplan. Ohne verwertbare Aufzeichnungen können Sie eine unerwartete Aktion womöglich nicht zuordnen. Ohne getesteten Widerruf lässt sich ein problematischer Zugriff schwer begrenzen. Prüfen Sie, ob wichtige Aufrufe, Identitäten, Zeitpunkte und Änderungen nachvollziehbar protokolliert werden, ohne dabei unnötig sensible Inhalte in Logs zu schreiben. Ermitteln Sie außerdem, wie Sie eine Integration deaktivieren, Rechte entziehen und eine Änderung auf einen bekannten Zustand zurücksetzen. Testen Sie diese Schritte, bevor der Dienst produktive Aufgaben übernimmt.

Wie sollten Sie Rechte und Ausführungsisolation festlegen? Starten Sie mit dem engsten Zugriff, der den Test ermöglicht. Trennen Sie Test- und Produktivzugänge, beschränken Sie sichtbare Dateien und Ressourcen und sperren Sie unnötige Netzwerk- oder Schreibzugriffe. Führen Sie Skripte zunächst in einer kontrollierten Umgebung aus. Die konkrete Isolation hängt von Betriebssystem, Agentenplattform und Dienstkonfiguration ab; die Bezeichnung „Sandbox“ allein belegt nicht, dass alle relevanten Zugriffe begrenzt sind.

Vor der Freigabe in fünf Schritten prüfen und bei Bedarf stoppen

Verwenden Sie diesen Ablauf vor jeder produktiven Anbindung. Halten Sie die Ergebnisse fest, damit spätere Änderungen nicht stillschweigend eine bereits geprüfte Freigabe entwerten.

Quelle und Wartung verifizieren. Bestätigen Sie Herausgeber, offizielle Bezugsquelle und nachvollziehbare Wartungsinformationen. Prüfen Sie, ob der installierte Inhalt tatsächlich der geprüften Version entspricht.
Rechte und Datenwege auflisten. Erfassen Sie alle angeforderten Lese-, Schreib- und Ausführungsrechte. Notieren Sie, welche Eingaben übertragen und welche Ausgaben an andere Werkzeuge weitergereicht werden.
Anweisungen, Skripte und Abhängigkeiten lesen. Suchen Sie nach unerwarteten Befehlen, zusätzlichen Downloads, Zugriff auf Dateien und Vorgaben, die den Nutzerauftrag umgehen könnten.
Isoliert testen. Verwenden Sie nicht vertrauliche Testdaten, begrenzte Zugangsdaten und eine Umgebung, in der unnötige Ressourcen nicht erreichbar sind. Prüfen Sie auch, wie der Agent auf manipulierte oder widersprüchliche Werkzeugausgaben reagiert.
Protokollierung und Widerruf erproben. Stellen Sie fest, ob kritische Aktionen nachvollziehbar sind, wie Rechte entzogen werden und ob sich der Dienst ohne unkontrollierte Nebenwirkungen deaktivieren lässt.

Pausieren Sie die Freigabe, wenn der Datenempfänger nicht feststellbar ist, die angeforderten Rechte über die Aufgabe hinausgehen oder die Ausführung nicht ausreichend eingeschränkt werden kann. Dasselbe gilt, wenn Sie weder Änderungen noch sicherheitsrelevante Aktionen nachvollziehen oder Zugangsdaten zuverlässig widerrufen können. Beheben Sie die Lücke und wiederholen Sie die betroffene Prüfung, statt sie mit einer Gesamtbewertung zu übergehen.

Hypothetisches Beispiel: Ein Team möchte einen Skill einsetzen, der Projektdateien zusammenfasst und Ergebnisse über einen MCP-Dienst an ein weiteres Werkzeug übergibt. Die Herkunft ist prüfbar, aber die Dokumentation erklärt nicht, ob die Originaldateien an einen externen Empfänger übertragen werden. Das Team gibt den Skill nicht für echte Projektdaten frei. Es klärt zuerst den Datenweg, testet mit eigens erstellten Beispieldateien und aktiviert die Weitergabe erst, wenn Empfänger, Berechtigungen und Protokollierung den internen Anforderungen entsprechen. Das ist ein Prüfszenario, kein Bericht über einen realen Vorfall.

Die vorhandene Umgebung mit einer isolierten Mac-Testumgebung abwägen

Ein gemeinsam genutzter Entwicklerrechner kann persönliche und berufliche Zugangsdaten vermischen. Ein gewöhnlicher Cloud- oder Testaufbau kann Daten an nicht ausreichend geprüfte Dienste weiterreichen. Und wenn Test- und Produktivumgebung dieselben Dateien oder Berechtigungen verwenden, ist ein Fehler schwerer einzugrenzen. Diese Nachteile gelten nicht automatisch für jede Installation; prüfen Sie Ihre tatsächliche Architektur.

Für kurzfristige Agententests kann eine separate Mac-Umgebung eine Alternative zum Ausführen auf dem täglich genutzten Rechner sein. Sie ist aber nicht automatisch sicherer: Entscheidend bleiben Zugriffskontrolle, Datenübertragung, Protokollierung und die Möglichkeit, die Umgebung nach dem Test zurückzusetzen. Vergleichen Sie vor der Anmietung die tatsächlich angebotenen Zugriffs- und Rücksetzbedingungen mit Ihrer Prüfliste. VPSSpark bietet Informationen zu verfügbaren Optionen über die Bestellseite; bei offenen Fragen zu den Bedingungen können Sie VPSSpark kontaktieren. Übertragen Sie keine vertraulichen Daten, bevor Sie die konkreten Eigenschaften der ausgewählten Umgebung geprüft haben.

Für die Entscheidung über MCP und AI Agent Skills bleibt der Maßstab derselbe: Verifizieren Sie Quelle, Rechte, Datenfluss und Ausführung. Wenn einer dieser Punkte offen ist, bleibt die Freigabe aus – unabhängig davon, ob der Test lokal, in einer gemieteten Mac-Umgebung oder auf einer anderen Infrastruktur stattfindet.