Wie prüfen Sie die Berechtigungen von Anthropic Knowledge Work Plugins vor der MCP-Anbindung? 2026

Kurzurteil: erst prüfen, dann verbinden

Symptom: Ein Plugin meldet eine erfolgreiche Verbindung, aber Sie wissen nicht, welche Dateien, Zugangsdaten oder Aktionen dabei erreichbar sind.
Schnellste Abhilfe: Prüfen Sie das vollständige Plugin-Paket, das MCP-Ziel und die erforderlichen Rechte. Testen Sie anschließend mit einem eingeschränkten Konto und nicht sensiblen Daten. Die Einstufung „LLM08“ der OWASP zu übermäßiger Handlungsbefugnis macht deutlich, warum unnötige Aktionen ein eigenständiges Risiko darstellen. Eine erfolgreiche Verbindung ist keine Sicherheitsfreigabe.

Für Entwickler: Prüfen Sie Skills, Befehle, Hooks, Skripte und MCP-Konfigurationen vor der Installation.
Für technische Administratoren: Grenzen Sie Zielservice, Konto, Zugriffsumfang und Datenfluss voneinander ab.
Für Sicherheitsverantwortliche: Halten Sie Prüfumfang, Testergebnisse und Freigaben so fest, dass eine andere Person sie nachvollziehen kann.

Zuletzt geprüft am 09.10.2026 anhand des öffentlichen Plugin-Repositorys, seiner Prüfrichtlinie und der verfügbaren MCP-Dokumentation. Prüfen Sie vor einer Freigabe immer den konkreten Plugin-Stand und die eingesetzte Connector-Konfiguration.

Das sichtbare Paket ist nur ein Teil der Prüfung

Eine Installationsanleitung erklärt, wie ein Plugin vorgesehen ist, verwendet zu werden. Sie belegt nicht, dass sämtliche ausgelieferten Bestandteile für Ihren konkreten Einsatz unbedenklich sind. Prüfen Sie deshalb das Repository des Plugins und nicht nur dessen Beschreibung. Das Repository von Anthropic Knowledge Work Plugins ist der Ausgangspunkt, um die Dateien und Verzeichnisse der jeweils geprüften Version festzustellen.

Rechnen Sie nicht damit, dass jedes Plugin dieselben Bestandteile mitbringt. Erfassen Sie die tatsächlich vorhandenen Dateien und ordnen Sie ihnen mögliche Wirkungen zu:

• README und sonstige Dokumentation: Welche Aufgabe beschreibt das Plugin? Welche Voraussetzungen und Dienste nennt es? Prüfen Sie, ob die Beschreibung Einschränkungen erwähnt, die für Ihren Einsatz relevant sind.
• Manifest und Metadaten: Welche Komponenten werden als Teil des Plugins aufgeführt? Stimmen die Einträge mit den tatsächlich vorhandenen Dateien überein?
• Skills und Anweisungen: Welche Aktionen soll das Modell ausführen? Achten Sie auf pauschale Aufforderungen, Inhalte aus Dateien weiterzugeben, externe Dienste aufzurufen oder Änderungen vorzunehmen.
• Befehle und Agenten: Welche Arbeitsabläufe werden ausgelöst, und welche Eingaben können sie verarbeiten? Prüfen Sie, ob ein Befehl mehr Zugriff voraussetzt, als seine beschriebene Aufgabe erfordert.
• Hooks: Wann werden sie aktiv? Ein Hook kann für die Prüfung relevant sein, wenn er bei bestimmten Ereignissen automatisch ausgeführt wird. Kontrollieren Sie deshalb Auslöser und zugehörigen Code gemeinsam.
• MCP-Konfiguration und Skripte: Welcher Server wird angesprochen? Wie wird er gestartet oder erreicht? Lesen Sie Skripte, die Konfigurationen verändern, Prozesse starten oder Informationen an andere Dienste übergeben könnten.

Diese Übersicht ist ein Prüfraster und keine Behauptung, dass jedes Plugin alle genannten Dateitypen enthält. Notieren Sie fehlende, zusätzliche und unerwartet benannte Dateien. Vergleichen Sie den Inhalt außerdem mit der im Prüfprotokoll festgehaltenen Revision oder dem Prüfdatum. Ändert sich der geprüfte Stand, gilt die frühere Prüfung nicht automatisch für die neue Version.

Prüfen Sie zusätzlich die Richtlinie, nach der das Repository Inhalte annimmt oder bewertet. Die Prüfrichtlinie des Repositorys liefert Kontext zum Veröffentlichungsprozess. Sie ersetzt aber nicht Ihre Prüfung der konkreten Dateien und des geplanten Einsatzes. Repository-Prüfung, interne Freigabe und Rechtevergabe sind unterschiedliche Schritte.

Welche Dateien gehören vor dem Anschluss auf die Prüfliste?

Beginnen Sie beim konkreten Plugin mit der Dokumentation und den Metadaten. Erfassen Sie anschließend alle vorhandenen Skills, Befehle, Agentendefinitionen, Hooks, MCP-Konfigurationen und Skripte. Suchen Sie nicht nur nach Dateien, die ausdrücklich „Sicherheit“ im Namen tragen: Auch unauffällige Hilfsskripte können für Startverhalten oder Datenfluss relevant sein.

Vergleichen Sie die Liste mit der beschriebenen Funktion. Bei einer nicht erklärten Datei, einem zusätzlichen Ziel oder einem undokumentierten Befehl sollten Sie zunächst nachfragen. Halten Sie fest, welche Revision Sie geprüft haben, damit sich eine spätere Wiederholung auf denselben Stand bezieht. Stimmen die Dateien nicht mit der Beschreibung überein, behandeln Sie die Abweichung als offenen Prüfpunkt und nicht als harmlose Formalität.

MCP-Verbindung und Berechtigungen

Ein MCP-Connector verbindet einen Client mit einem Dienst oder Server. Aus seinem Namen können Sie jedoch nicht zuverlässig ableiten, welche Ressourcen erreichbar sind oder welche Aktionen möglich sind. Ebenso beweist eine Anzeige wie „verbunden“ zunächst nur, dass eine Verbindung hergestellt werden konnte. Sie belegt nicht, dass Datenzugriff und Aktionen den Vorgaben Ihrer Organisation entsprechen.

Das MCP-Protokollmaterial und die Dokumentation zur Autorisierung helfen dabei, Protokoll und Autorisierungsablauf einzuordnen. Für Ihre Prüfung müssen Sie dennoch den konkret eingesetzten Connector, das konfigurierte Ziel und die tatsächlich gewährten Rechte ermitteln. Halten Sie mindestens fest:

• welcher Dienst angesprochen wird und über welche Verbindung;
• welches Konto oder welche Identität die Anfrage autorisiert;
• ob die Autorisierung lesenden Zugriff, Änderungen oder weitere Aktionen ermöglicht;
• welche Ressourcen und Datenbereiche im Test erreichbar sind;
• welche Eingaben oder Projektdaten bei einer Anfrage an den Connector übergeben werden.

Trennen Sie Anmeldeinformationen für den Zieldienst von einer möglichen Weitergabe über Dienstgrenzen hinweg. Ein Zugriffstoken kann dazu dienen, Anfragen bei dem Dienst zu autorisieren, für den es ausgestellt wurde. Daraus folgt nicht automatisch, dass ein anderes System das Token erhält. Umgekehrt dürfen Sie auch nicht ohne Prüfung annehmen, dass Zugangsdaten ausschließlich lokal bleiben. Lesen Sie Connector-Dokumentation und Konfiguration und prüfen Sie die beobachtbaren Anfragen, bevor Sie sensible Konten verwenden.

Die Datei CONNECTORS.md im Repository kann die vom Projekt beschriebenen Connectoren erläutern. Vergleichen Sie diese Angaben mit der konkreten Konfiguration, dem Autorisierungsablauf und Ihrem genehmigten Anwendungsfall. Wenn Ziel, Konto oder Datenumfang nicht eindeutig feststehen, behandeln Sie die Verbindung als ungeklärt – nicht als freigegeben.

Risikoarten nach Artefakt und Auswirkung

Die Tabelle ordnet Prüffelder möglichen Folgen zu; sie sagt nicht voraus, dass ein bestimmtes Plugin diese Folgen tatsächlich verursacht. Entscheidend ist der Abgleich zwischen Dokumentation, Implementierung und Verhalten im isolierten Test.

Abweichungen zwischen Beschreibung und Verhalten

Vergleichen Sie für jede Komponente drei Dinge: die beschriebene Aufgabe, die Anweisungen beziehungsweise Konfiguration und die beobachtete Wirkung. Ein Plugin für Zusammenfassungen benötigt möglicherweise Zugriff auf die Inhalte, die zusammengefasst werden sollen. Daraus folgt nicht ohne Weiteres, dass es Dateien verändern oder zusätzliche externe Dienste kontaktieren muss. Fragen Sie deshalb bei jeder angeforderten Berechtigung: Welche konkrete Funktion wäre ohne sie nicht möglich?

Achten Sie auf Zugriffe, die über den Auftrag hinausgehen: etwa nicht benötigte Projektverzeichnisse, Schreibrechte bei einer reinen Analyse oder externe Aufrufe ohne klare Verbindung zum Arbeitsablauf. Untersuchen Sie bei Hooks nicht nur den Namen, sondern auch, wann sie ausgelöst werden. Prüfen Sie bei Skripten, welche Eingaben sie verarbeiten und ob sie Netzwerkzugriffe, Dateiänderungen oder das Starten weiterer Prozesse vorsehen.

Ein praxisnaher Fall: Ein Team möchte ein Plugin zunächst nur verwenden, um ausgewählte Projektunterlagen auszuwerten. Die Anweisungen wirken lesend, doch die Konfiguration bindet einen Connector mit weiter reichenden Rechten ein. Solange Sie nicht belegt haben, welche Rechte der Connector bei den tatsächlichen Aufrufen nutzt und ob sich der Umfang reduzieren lässt, ist der gewünschte Analyseablauf nicht gleichbedeutend mit einem reinen Lesezugriff.

Stimmen Beschreibung und Implementierung nicht überein, unterbrechen Sie den Pilotversuch. Bitten Sie die zuständige technische Stelle um eine Erklärung und eine erneute Prüfung der betroffenen Dateien. Eine plausible Erklärung ist noch keine Freigabe: Erst wenn die Abweichung verstanden und dokumentiert ist, entscheiden Sie über einen erneuten Test.

Auch die Richtlinie für das Softwareverzeichnis liefert Kontext zu Sicherheits- und Kompatibilitätsanforderungen. Eine Veröffentlichung, Prüfung oder Aufnahme in ein Verzeichnis macht das Plugin jedoch nicht automatisch für Ihre Datenklassifizierung, internen Vorgaben oder verwendeten Konten geeignet.

Welche Zugangsdaten und Projektdaten können betroffen sein?

Die Antwort hängt vom konkreten Connector, der Autorisierung und dem Testkonto ab. Prüfen Sie, welche Identität den Zieldienst anspricht, auf welche Projektbereiche dieses Konto Zugriff hat und welche Eingaben der Skill an den Connector übergibt. Wenn Dokumentation und Konfiguration diese Fragen nicht beantworten, testen Sie kontrolliert, statt Annahmen aus dem Connectornamen abzuleiten.

Verwenden Sie für den Test keine echten Geheimnisse in Anweisungen oder Protokollen. Ein Token ist nicht bloß ein technischer Parameter: Sein Rechteumfang bestimmt, welche Daten oder Aktionen über das zugehörige Konto erreichbar sein können. Stimmen Sie den Umgang mit personenbezogenen Informationen außerdem mit den Datenschutzvorgaben Ihrer Organisation ab. Die Datenschutzhinweise sind ein ergänzender Anlaufpunkt, ersetzen aber keine organisationsspezifische Freigabe.

Belegt ein erfolgreicher Verbindungsstatus die Freigabe?

Nein. Der Verbindungsstatus beantwortet nicht, ob die Rechte angemessen sind, ob die Datenweitergabe genehmigt ist oder ob der Ablauf den internen Sicherheitsregeln entspricht. Er zeigt auch nicht von selbst, ob unerwartete Datei- oder Schreibzugriffe stattfinden. Verwenden Sie ihn daher nur als technischen Zwischenschritt. Für eine Freigabe benötigen Sie zusätzlich einen abgegrenzten Test, dokumentierte Ergebnisse und die Zustimmung der zuständigen Stelle.

Minimum-Rechte-Test und prüfbare Nachweise

Führen Sie den Test getrennt von produktiven Projektordnern und Konten durch. Eine geeignete Umgebung enthält ein begrenztes Testkonto, nicht sensible Beispieldaten und einen nachvollziehbaren Weg, den Zugriff nach dem Test wieder zu entziehen. Prüfen Sie nicht nur den Erfolgsfall: Eine sinnvolle Berechtigungsgrenze muss auch dann erkennbar bleiben, wenn eine Aktion nicht erlaubt ist.

1. Prüfumfang festlegen. Notieren Sie Plugin-Revision, Connector, Testkonto, zulässige Daten und ausdrücklich nicht genehmigte Aktionen. Ohne klaren Umfang lässt sich später nicht feststellen, was ein Testergebnis tatsächlich belegt.
2. Zugang beschränken. Verwenden Sie ein Konto, das nur die benötigten Testressourcen erreicht. Vermeiden Sie produktive Zugangsdaten und Konten mit pauschalen Verwaltungsrechten.
3. Unkritischen Beispieldatensatz bereitstellen. Verwenden Sie eine eigens dafür bestimmte Datei oder einen Testdatensatz ohne personenbezogene oder vertrauliche Inhalte. So können Sie Datenzugriffe beobachten, ohne reale Arbeitsdaten zu gefährden.
4. Lesenden Zugriff auslösen. Prüfen Sie, welche Ressourcen das Plugin tatsächlich anfragt. Vergleichen Sie das Ergebnis mit dem erwarteten Umfang und dokumentieren Sie jeden Zugriff, der nicht zum Testauftrag gehört.
5. Schreibaktionen separat untersuchen. Erteilen Sie Schreibrechte nicht allein deshalb, weil die Verbindung sie anbietet. Falls eine Änderung für den vorgesehenen Einsatz nötig ist, testen Sie sie mit einem reversiblen Beispieldatensatz und einer gesonderten Genehmigung.
6. Externe Anfragen prüfen. Beobachten Sie, ob der Ablauf den erwarteten Zieldienst kontaktiert oder ob weitere Ziele auftreten. Unklare oder nicht genehmigte Anfragen sind ein Grund, den Test anzuhalten und die Konfiguration zu klären.
7. Fehlerpfad und Entzug prüfen. Stellen Sie fest, wie sich das Plugin bei fehlender Berechtigung verhält. Beenden Sie den Test anschließend und entziehen oder deaktivieren Sie den Testzugang nach dem vorgesehenen Verfahren.

Halten Sie Ergebnisse knapp, aber nachvollziehbar fest: geprüfter Stand, Testumfang, erwartete und beobachtete Zugriffe, Abweichungen, verantwortliche prüfende Person und Freigabeentscheidung. Protokolle sollten aussagekräftig genug sein, um die Prüfung zu wiederholen, aber keine vollständigen Tokens, Passwörter oder sonstigen Geheimnisse enthalten. Schwärzen Sie sensible Werte, bevor Sie Nachweise teilen oder ablegen.

Wie lässt sich ein MCP-Aufruf mit minimalen Rechten prüfen?

Beginnen Sie mit einem Konto, dessen Zugriff auf die für den Test bestimmten Ressourcen begrenzt ist. Verwenden Sie nicht sensible Beispieldaten und lösen Sie die vorgesehene Aktion gezielt aus. Prüfen Sie danach, ob nur erwartete Dateien gelesen und nur genehmigte Ziele aufgerufen wurden. Wenn Schreibzugriff nicht Teil des Testzwecks ist, darf er nicht beiläufig erteilt werden. Erfordert der vorgesehene Ablauf Schreibzugriff, genehmigen und testen Sie diesen getrennt mit einem reversiblen Beispieldatensatz.

Dokumentieren Sie auch, was bei verweigerter Berechtigung geschieht. Ein Plugin, das bei einem fehlenden Zugriff auf ein anderes, nicht genehmigtes Ziel ausweicht, benötigt eine zusätzliche Prüfung. Halten Sie fest, wie Sie Testkonto und Berechtigung nach der Prüfung deaktivieren oder entziehen. So bleibt die Nachprüfung möglich, ohne geheime Werte in den Unterlagen abzulegen.

Entscheidung nach Datenklasse und Änderungsrisiko

Treffen Sie die Entscheidung anhand der Daten, der tatsächlichen Rechte und der Prüfbarkeit – nicht anhand des Veröffentlichers allein. Die OWASP-Einordnung zu übermäßiger Handlungsbefugnis begründet, warum unnötige Handlungsmöglichkeiten ein eigener Prüfpunkt sein sollten; sie ist jedoch keine pauschale Aussage über ein bestimmtes Plugin. Messen Sie den Rechteumfang an der konkreten Aufgabe.

Wählen Sie einen begrenzten Pilotbetrieb, wenn der Datenumfang niedrig ist, der Connector auf ein Testkonto beschränkt werden kann, die erforderlichen Aktionen klar sind und Sie sie nachvollziehbar protokollieren können. Halten Sie den Pilotbereich klein und erweitern Sie ihn erst nach erneuter Prüfung.

Schränken Sie den Anschluss ein, wenn das Plugin grundsätzlich geeignet erscheint, der Connector aber mehr Rechte anbietet als nötig. Suchen Sie nach einer engeren Berechtigung, einem getrennten Testkonto oder einer Konfiguration, die den Zugriff auf notwendige Ressourcen begrenzt. Lässt sich die Einschränkung nicht umsetzen oder belegen, bleibt der Anschluss ungeklärt.

Lehnen Sie den Anschluss vorerst ab, wenn Zielservice oder Datenfluss unklar sind, Zugangsdaten nicht angemessen geschützt werden können, die Implementierung der Beschreibung widerspricht oder Aktionen nicht zuverlässig nachvollziehbar sind. Bei sensiblen Daten und Schreibaktionen ist eine gesonderte Genehmigung erforderlich; ein erfolgreicher Verbindungstest ersetzt sie nicht.

Wenn Sie Skills im Team einführen, ergänzen Sie die Prüfung durch klare Zuständigkeiten für Änderungen, Konten und Datenzugriffe. Die Freigabe sollte anhand des konkreten Plugins, des Testumfangs und Ihres internen Verfahrens erfolgen. Bei Tests in einer entfernten Entwicklungsumgebung gehören auch Identitätsverwaltung, Zugriff auf Projektdateien und der Umgang mit Zugangsdaten in denselben Prüfplan.

Abschluss: erst die Rechtefrage lösen, dann den Pilot freigeben

Ein ungeprüfter Anschluss auf dem persönlichen Entwicklergerät ist bequem, kann aber vorhandene Projektdateien und Kontozugänge in denselben Arbeitskontext bringen. Ein gemeinsam genutztes oder nur kurzzeitig eingerichtetes Testsystem kann wiederum unklare Zuständigkeiten und schwer nachvollziehbare Zugriffe erzeugen. Und selbst eine vertraute lokale Umgebung schützt nicht vor einem Connector, dessen Rechteumfang größer ist als für die Aufgabe erforderlich. In allen Fällen bleiben getrennte Testkonten, eine klare Datenbegrenzung und ein nachvollziehbarer Entzug der Zugriffe notwendig.

Wenn Sie für einen zeitlich begrenzten Pilotlauf eine eigene Mac-Umgebung benötigen, kann das Mieten eines Macs von Kvmjet gegenüber dem Kauf zusätzlicher Hardware eine flexible Erprobung ermöglichen. Es ersetzt weder die Plugin-Prüfung noch die Freigabe des MCP-Zugriffs. Für langfristige, gleichbleibende Arbeitslasten oder Tests mit besonderen physischen Schnittstellen sollten Sie dagegen auch einen eigenen Rechner oder eine passend kontrollierte lokale Umgebung prüfen.