Ist ein MCP Server sicher? Was der NIS2 Durchgang bei jedem Aufruf prüft

Was kann ein Assistent über den MCP Server tun, und was nicht?

MCP (Model Context Protocol) ist ein offener Standard, über den ein KI Assistent wie Claude oder Copilot mit einem anderen Programm arbeitet. Der NIS 2 Durchgang bietet dafür einen MCP Server unter /api/mcp an. Ein verbundener Assistent liest dort Ihren Durchgang und füllt aus, was die Punkte fragen.

Er arbeitet als die Person, die ihn verbunden hat, mit genau deren Rechten. Sind ihr bestimmte Bereiche zugewiesen, füllt ihr Assistent nur diese aus. Der Assistent einer Person in der Rolle Prüfer oder Rechtlicher Prüfer liest, füllt aber nichts aus.

Ob im Browser angemeldet oder mit Schlüssel: Ein Assistent erreicht eine feste Liste von Funktionen der App, und die App prüft das bei jedem Aufruf. Auf der Liste steht keine Funktion, die eine Zeile löscht, Kollegen einlädt, einen Punkt abschließt oder unterschreibt. Das bleibt bei Menschen in der App.

Was prüft der Server bei jedem Aufruf?

Jeder Aufruf wird für sich geprüft. Zuerst der Schlüssel: Signatur, Ablaufdatum, ob die Person seitdem alle ihre Assistenten getrennt hat und ob diese eine Verbindung noch besteht.

Dann dieselben Schranken wie in der App: Mitgliedschaft im Unternehmen, Rolle, ob der Durchgang für das Konto freigeschaltet ist, die zugewiesenen Bereiche. Dazu der Schalter „Assistenten für dieses Unternehmen erlauben“, der aus ist, bis ein Admin ihn einschaltet.

Kommt ein Aufruf aus einem Browser von einer anderen Adresse als der Instanz selbst oder localhost, lehnt der Server ihn ab. So erreicht eine fremde Webseite auch keine Instanz im Firmennetz über den Browser einer Person. Pro Person gelten höchstens 300 Werkzeugaufrufe in der Stunde, für alle ihre Assistenten zusammen.

Jede Änderung steht im Aktivitätsprotokoll unter dem Namen der Person, mit „über“ und dem Namen des Assistenten. Ins Serverprotokoll kommt pro Aufruf eine Zeile mit dem Werkzeug und der Kennung der Person, nie der Inhalt. Der Code ist Open Source unter der AGPL; Ihre IT kann im Ordner lib/mcp nachlesen, was hier steht.

Wie schützt die Anmeldung vor gestohlenen Zugängen?

Bei der Anmeldung im Browser ist Ihre Instanz selbst der Anmeldedienst, nach OAuth 2.1, dem Standard für solche Freigaben. Dazu kommt PKCE (S256), damit ein abgefangener Anmeldecode anderen nichts nützt.

Vor dem Erlauben zeigt die Seite, welcher Assistent für welches Unternehmen fragt und wohin der Browser danach zurückgeht. Den Namen gibt sich der Assistent selbst, prüfen Sie deshalb vor allem die Rücksprungadresse. Eine fehlerhafte Anfrage beantwortet die Instanz auf ihrer eigenen Seite und leitet nirgendwohin weiter.

Ein Refresh Token verlängert eine Anmeldung. Taucht ein schon benutztes mehr als eine Minute später wieder auf, gilt es als kopiert, und die Instanz trennt jeden Assistenten der Person.

Schlüssel und Anmeldung überdauern das Abmelden im Browser. Deshalb verlangen beide eine Anmeldung aus den letzten 15 Minuten, und die Person bekommt eine Mail, sobald ein Assistent in ihrem Namen verbunden wurde. Wie lange beide gelten, steht in unserem Artikel zu Schlüssel oder Anmeldung.

Erfüllt der Server die MCP Spezifikation und OWASP?

Die MCP Spezifikation in der Fassung vom 28. Juli 2026 verlangt vom Anmeldedienst OAuth 2.1 und von Clients PKCE mit S256. Für öffentliche Clients, also solche ohne eigenes Geheimnis, verlangt sie wechselnde Refresh Tokens. Vom Server verlangt sie, Eingaben zu prüfen, Zugriffe zu kontrollieren und Aufrufe zu begrenzen; das tut der Durchgang wie oben beschrieben.

Eine ihrer Empfehlungen erfüllt er nicht: Client ID Metadata Documents, mit denen sich ein Assistent über eine veröffentlichte Kennung ausweist. Der Durchgang registriert Assistenten automatisch (Dynamic Client Registration), was die Spezifikation als veraltet, aber weiter zulässig führt. In Claude wählen Sie deshalb „Register automatically“.

OWASP führt übermäßige Handlungsmacht (Excessive Agency) als Risiko LLM06: zu viele Funktionen, Rechte und Selbstständigkeit. Als Gegenmittel nennt OWASP unter anderem: Ein Mensch billigt Handlungen mit großer Wirkung, Handlungen im Namen einer Person laufen mit deren Rechten, und das Zielsystem prüft die Berechtigung selbst. Im Durchgang sind das die Unterschrift durch Menschen, die Rechte der Person und die Prüfung auf dem Server.

Was bleibt bei Ihrem Unternehmen?

Welchen Assistenten Sie verbinden, entscheiden Sie. Wer in das Konto beim Anbieter des Assistenten kommt, nutzt auch dessen Verbindung zum Durchgang. Halten Sie deshalb in 11.1 fest, ob die Anmeldung dort einen zweiten Faktor braucht, wie bei jedem Programm auf Ihrer Liste.

Die MCP Spezifikation sagt, es solle immer ein Mensch beteiligt sein, der Werkzeugaufrufe ablehnen kann. Lassen Sie im Client die Rückfrage vor dem Ausfüllen an.

Der Server begrenzt, was ein Assistent tun kann, und zeigt, was er getan hat. Fehlerfrei macht er ihn nicht; wie ein fremder Text einen Assistenten in die Irre führen kann, zeigt unser Artikel zu Prompt Injection.

Ein Schlüssel gehört in keine Datei, die andere lesen, etwa in ein gemeinsames Repository. Legen Sie ihn in eine Umgebungsvariable und geben Sie dem Client deren Namen, in Claude Code so:

Art. 21 Abs. 2 Buchst. j NIS 2 · § 30 Abs. 2 Nr. 10 BSIG

claude mcp add --transport http nisd2 https://nisd2.eu/api/mcp --header "Authorization: Bearer $NISD2_MCP_KEY"