Ein Assistent, der Ihre Compliance-Daten über MCP abfragt, ist ein Konto. Was die MCP-Autorisierungsspezifikation garantiert, was eine Nur-Lese-Grenze schützt und was nicht, und welche Fragen der Kontoverwaltung Sie klären sollten, bevor Sie einen solchen Client verbinden.
Ein Assistent, der Ihre Compliance-Daten über MCP abfragt, ist ein Konto. Was die MCP-Autorisierungsspezifikation garantiert, was eine Nur-Lese-Grenze schützt und was nicht, und welche Fragen der Kontoverwaltung Sie klären sollten, bevor Sie einen solchen Client verbinden.
Das Model Context Protocol erlaubt einem Server, jedem seiner Tools Hinweise mitzugeben, und einer davon bedeutet, wie es im Schema heisst, «das Tool verändert seine Umgebung nicht». Der Tools-Abschnitt der Spezifikation sagt dann jedem Client, was dieser Hinweis wert ist: «Clients MÜSSEN Tool-Annotationen als nicht vertrauenswürdig betrachten, sofern sie nicht von vertrauenswürdigen Servern stammen.» Der Abschnitt zur Autorisierung beginnt mit einem Satz, der ebenso viel Gewicht hat: «Autorisierung ist für MCP-Implementierungen OPTIONAL.»
(Die MCP-Spezifikation und NIST SP 800-53 liegen nur auf Englisch vor; Zitate daraus sind eigene Übersetzungen, die Links führen auf die englischen Originale. Die Schlüsselwörter MUST, SHOULD und OPTIONAL sind als MUSS, SOLLTE und OPTIONAL wiedergegeben.)
Zusammen heisst das: Wenn ein Anbieter erklärt, sein MCP-Server sei nur lesend, beschreibt er den Server, ohne irgendetwas einzuschränken. Das Control ist das, was der Server durchsetzt und was der Grant erlaubt, und ob es beides überhaupt gibt, hängt vom Server ab, den Sie verbinden.
Für Compliance-Teams zählt das, weil die Daten, die solche Server freigeben, das ISMS selbst sind: Risiken, offene Audit-Feststellungen, Lieferantenbewertungen, die Liste der Controls, die Sie noch nicht abgedeckt haben. Einen KI-Client an diese Daten anzuschliessen, ist eine Zugriffsentscheidung. Sie verdient dieselben Fragen wie jede andere.
Um einen KI-Client zu steuern, brauchen Sie kein neues Framework. Die Kataloge zur Zugriffskontrolle decken ihn bereits ab. Ich zitiere hier NIST SP 800-53, weil der Text frei zugänglich ist; die Controls zu Zugriffsrechten in Annex A der ISO/IEC 27001 stellen dieselben Fragen.
NIST SP 800-53 Rev. 5, AC-6 Least Privilege:
«Das Prinzip der minimalen Rechte anwenden und nur solche autorisierten Zugriffe für Benutzer (oder Prozesse, die im Auftrag von Benutzern handeln) zulassen, die zur Erfüllung zugewiesener organisatorischer Aufgaben notwendig sind.»
Ein MCP-Client ist ein Prozess, der im Auftrag eines Benutzers handelt; das Control gilt also für ihn, so wie es dasteht. Den Rest des Lebenszyklus liefert AC-2 Account Management, das von der Organisation verlangt:
Zwei Erweiterungen schärfen das. AC-2(3) verlangt, Konten zu deaktivieren, die nach Punkt (d) «seit [Zeitraum] inaktiv sind». AC-6(7) verlangt, «[Häufigkeit] die den [Rollen und Klassen] zugewiesenen Rechte zu überprüfen, um die Notwendigkeit dieser Rechte zu bestätigen».
Auf einen KI-Client angewendet, werden aus diesen Klauseln vier Fragen:
Wenn Sie eine dieser Fragen für einen heute verbundenen Assistenten nicht beantworten können, ist die offene Frage die Lücke, die Sie schliessen müssen.
Setzt ein Server Autorisierung um, ist die Spezifikation dazu präzise. Der Server «agiert als OAuth-2.1-Resource-Server». Der Client durchläuft einen OAuth-Flow gegen einen Autorisierungsserver, auf den der MCP-Server ihn verweist. Für eine Zugriffsüberprüfung tragen diese Klauseln das meiste Gewicht.
Audience-Bindung. «MCP-Clients MÜSSEN Resource Indicators for OAuth 2.0 gemäss RFC 8707 implementieren», und «MCP-Server MÜSSEN prüfen, dass Access Tokens spezifisch für sie als vorgesehene Audience ausgestellt wurden». Ein Token, das für Ihr Compliance-Tool ausgestellt wurde, lässt sich nicht gegen einen anderen Dienst wiederverwenden, und der Server «DARF keine anderen Tokens akzeptieren oder weiterreichen».
Abgefangene Codes. Aus den Sicherheitshinweisen: «MCP-Clients MÜSSEN PKCE implementieren». Ein gestohlener Authorization Code ist ohne den Verifier, den der Client behalten hat, nutzlos.
Token-Lebensdauer. «Autorisierungsserver SOLLTEN kurzlebige Access Tokens ausstellen, um die Folgen geleakter Tokens zu begrenzen. Bei Public Clients MÜSSEN Autorisierungsserver Refresh Tokens rotieren». Derselbe Abschnitt nennt den Grund: «Angreifer, die vom Client gespeicherte Tokens oder auf dem Server zwischengespeicherte oder protokollierte Tokens erlangen, können mit Anfragen auf geschützte Ressourcen zugreifen, die für Resource Server legitim erscheinen.»
Scope. Server «SOLLTEN einen scope-Parameter im WWW-Authenticate-Header mitgeben», was die Spezifikation damit begründet, dass so «dem Prinzip der minimalen Rechte gefolgt und verhindert wird, dass Clients übermässige Berechtigungen anfordern». Eine Anfrage, die mehr braucht, erhält einen 403 mit error="insufficient_scope", und von einem Client, der für einen Benutzer handelt, wird erwartet, dass er den Benutzer für die weitergehende Berechtigung erneut durch die Autorisierung schickt.
Auf die vier Fragen abgebildet:
| Zugriffsfrage | Was die MCP-Spezifikation liefert | Was bei Ihnen bleibt |
|---|---|---|
| Wer hat genehmigt? | Ein OAuth-Autorisierungsschritt, den der Benutzer sieht | Ob die richtige Person genehmigt hat |
| Worauf kann er zugreifen? | Scopes, an die Audience gebundene Tokens | Welche Scopes der Server definiert und vergibt |
| Wann endet der Zugriff? | Kurzlebige Tokens (SOLLTE), rotierende Refresh Tokens (MUSS, Public Clients) | Widerruf beim Offboarding, Ablauf bei Inaktivität |
| Wer überprüft ihn? | Nichts | Die periodische Zugriffsüberprüfung |
Lesen Sie die letzte Spalte zuerst. Die Spezifikation sichert den Handshake ab. Zu Offboarding, Inaktivität und Überprüfung sagt sie nichts, weil das Eigenschaften des Kontomodells des Servers sind und ein Protokoll sie nicht vorschreiben kann. Genau dort sollten Sie beim Anbieter nachhaken.
Ein Server, der nur liest, schützt die Integrität Ihrer Compliance-Aufzeichnungen. Der Assistent kann keine Feststellung schliessen, keinen Risikowert senken und keine Richtlinie als genehmigt markieren. Für ein ISMS zählt das: Ein Auditor, der eine Änderungshistorie liest, sollte nie auf einen Eintrag stossen, den ein Modell geschrieben hat, weil es einen Prompt falsch verstanden hat.
Für die Vertraulichkeit leistet Nur-Lesen nichts. Jeder Datensatz, den das Modell liest, wird zur Eingabe für das Modell und geht damit an denjenigen, der das Modell betreibt, zu den Bedingungen Ihres KI-Clients. Ihre offenen Feststellungen, Ihr Risikoregister, die Namen auf Ihrer Lieferantenliste reisen mit der Abfrage mit. Das ist eine Entscheidung darüber, welche KI-Anbieter Sie für welche Datenklassen freigegeben haben, und keine Servereinstellung nimmt sie Ihnen ab.
Die Tools-Spezifikation legt zwei weitere Pflichten auf den Client, nicht auf den Server. Clients SOLLTEN «Tool-Eingaben dem Benutzer zeigen, bevor sie den Server aufrufen, um böswilligen oder versehentlichen Datenabfluss zu vermeiden», und sie SOLLTEN «die Tool-Nutzung für Auditzwecke protokollieren». Auf derselben Seite heisst es zudem: «es SOLLTE immer ein Mensch beteiligt sein, der Tool-Aufrufe ablehnen kann». Das sind Verhaltensweisen des Clients. Wenn Ihr KI-Client nicht anzeigt, was er gleich aufrufen wird, oder nicht festhält, was er gelesen hat, kann der Server das nicht ausgleichen.
Die Alternative zu einem Grant ist ein statischer API-Key, der in die Konfiguration des Clients kopiert wird. An den vier Fragen gemessen, geben Key und Grant unterschiedliche Antworten.
Ein statischer Key ist ein langlebiges Geheimnis in einer Konfigurationsdatei auf einem Laptop. Sofern der Anbieter ihn nicht einschränkt, reicht er so weit wie die Rechte der Person, die ihn erstellt hat, und er endet erst, wenn er abläuft oder jemand ihn löscht. Nichts am Key bindet ihn an einen Client, einen Mandanten oder einen Zweck. Die Inaktivitätsklausel von AC-2(3) hat nichts, woran sie greifen kann, es sei denn, der Key läuft zufällig ab.
Ein OAuth-Grant ist ein Objekt anderer Art. Er benennt einen Client, er trägt die Scopes, denen der Benutzer zugestimmt hat, das Access Token, das er erzeugt, ist kurzlebig, und die Erneuerung, die ihn am Leben hält, lässt sich serverseitig kappen. Ihn zu widerrufen, ist ein administrativer Akt mit Zeitstempel, und genau das will eine Zugriffsüberprüfung sehen.
Bevor irgendein MCP-Server an Daten angeschlossen wird, die in Ihrem ISMS liegen, würde ich diese Fragen beantwortet haben wollen:
Dieselben Fragen mussten wir für den eigenen MCP-Server von devguard beantworten, angekündigt am 9. September 2026, und einige der Antworten haben ihren Preis.
Der Server liest nur: Ein KI-Client kann abfragen und einzelne Records lesen, aber nichts ändern oder löschen. Das setzt der Server selbst durch, unabhängig davon, was der Hinweis am jeweiligen Tool sagt, und jede Verbindung sieht genau eine Organisation.
Clients, die die Anmeldung im Browser unterstützen, brauchen nur den Endpunkt. In Claude Code:
claude mcp add --transport http devguard https://app.devguard.ch/api/mcp/In VS Code, in .vscode/mcp.json:
{
"servers": {
"devguard": {
"type": "http",
"url": "https://app.devguard.ch/api/mcp/"
}
}
}Beim ersten Einsatz öffnet der Client einen Browser. Sie melden sich mit Ihrem eigenen Konto an, wählen die Organisation, die er lesen darf, und der Zustimmungsbildschirm nennt diese Organisation, bevor Sie zustimmen. In keine Konfigurationsdatei wird etwas geschrieben.
Die vier Fragen, wie das Produkt sie beantwortet:
Zwei Dinge lässt devguard bewusst weg, und einen Preis nimmt devguard in Kauf.
Einem KI-Client lässt sich keine Schreibberechtigung erteilen, auch kein eng gefasster Scope; die einzige Schreibberechtigung, die devguard über diese Anmeldung vergibt, gehört der eigenen CLI, zum Hochladen von Nachweisen. Jeder MCP-Client kann eine Verbindung anfragen, und ein Assistent, der einen Prompt falsch versteht, soll nichts vorfinden, was er ändern könnte.
devguard protokolliert nicht jeden einzelnen Lesezugriff. Das Audit Log zeigt, dass eine App verbunden wurde, von wem und wann sie getrennt wurde; Verbundene Apps zeigt, wann sie zuletzt genutzt wurde. Ein Protokoll pro Abfrage darüber, was das Modell gelesen hat, liegt in Ihrem KI-Client, und genau dort verortet die MCP-Spezifikation diese Pflicht.
Der Preis: Claude Desktop erreicht Remote-Server über die Bridge mcp-remote, und diese Verbindung hat devguard mit einem API-Token statt mit der Anmeldung im Browser eingerichtet. Dieses Token ist genau der statische Key, der oben beschrieben ist. Am MCP-Server ist es trotzdem nur lesend, ausserhalb davon kann es jedoch alles, was Sie können, in jeder Organisation, der Sie angehören. Wenn Sie Claude Desktop nutzen, behandeln Sie diese Konfigurationsdatei als Geheimnis und geben Sie dem Token ein Ablaufdatum.
Welchen Server Sie auch verbinden: Führen Sie den KI-Client im selben Register wie jedes andere Konto, mit den Angaben, wer ihn genehmigt hat, welche Organisation und welchen Scope er hält, was ihn beendet und wann er als Nächstes überprüft wird. Wenn der Server Ihnen für eine dieser Spalten keine Antwort liefern kann, ist genau das die Feststellung.
Der MCP-Server von devguard liest Ihre Compliance-Daten und ändert nichts; die Ankündigung beschreibt die Einrichtung, und unter Einstellungen → Integrationen gibt es für jeden Client ein Snippet.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.