Sicherheit des MCP-Servers

Diese Seite richtet sich an die Person, die die Verbindung eines KI-Agenten mit Docsbook genehmigen muss. Sie beschreibt, was der MCP-Server heute tatsächlich tut – wie sich ein Client authentifiziert, worauf die einzelnen Bereiche zugreifen können, was aufgezeichnet wird, was das Netzwerk verlässt – und nennt anschließend in zwei separaten Abschnitten, in welchen Punkten Docsbook hinter der Spezifikation des Model Context Protocol zurückbleibt und welche Nachweise zur Einhaltung der Vorgaben noch nicht existieren.

Dies ist keine Beschreibung von Zielen oder Vorhaben. Wo eine Kontrolle fehlt, wird dies als fehlend aufgeführt.

Was Sie erhalten#

Ein verbundener Client besitzt ein undurchsichtiges Bearer-Token, das an ein Docsbook-Konto gebunden ist und einen von zwei Berechtigungsumfängen enthält. Der Berechtigungsumfang wird von einem Menschen auf einem Zustimmungsbildschirm ausgewählt – nicht vom Client angefordert. Jedes Tool, das auf einem Projekt agiert, ermittelt dieses Projekt anhand des Eigentümers. Daher erhält ein Token, das eine einer anderen Person gehörende Workspace-ID angibt, nichts zurück – nicht diesen Workspace: Das ist die Grenze zwischen Mandanten, und sie gilt für jedes Tool.

Die Grenze zwischen Lesen und Schreiben ist enger, als die beiden Namen der Berechtigungsumfänge vermuten lassen. Im folgenden Abschnitt wird genau beschrieben, welche Tools sie durchsetzen und welche nicht. Lesen Sie diesen Abschnitt, bevor Sie ein schreibgeschütztes Token als Begrenzungsmaßnahme betrachten.

Jeder abgerechnete Aufruf schreibt eine Zeile in das eigene Aufrufprotokoll Ihres Projekts: welches Tool, welche Eingaben, welche Ausgaben, wie lange der Aufruf dauerte und was er verbraucht hat. Argumente und Ergebnisse werden vor der Speicherung nach Schlüssel redigiert, sodass ein an ein Tool übergebener API-Schlüssel niemals aufgezeichnet wird.

Was Sie nicht erhalten: Token-Ablauf, Refresh-Tokens, Ratenbegrenzung, Rollen innerhalb eines Kontos oder einen Prüfbericht.

Wie die Authentifizierung funktioniert#

Der Autorisierungsablauf#

Docsbook ist sein eigener Autorisierungsserver und sein eigener Ressourcenserver. Es stellt undurchsichtige Tokens für sich selbst aus; ein von jemand anderem ausgestelltes Token wird niemals akzeptiert, weitergeleitet oder wiederverwendet.

Die veröffentlichten Metadaten deklarieren ein Modell für öffentliche Clients — code_challenge_methods_supported: ["S256"], token_endpoint_auth_methods_supported: ["none"], grant_types_supported: ["authorization_code"]. Es gibt kein Clientgeheimnis und keinen Client-Credentials-Grant.

Was das Token ist#

Das Token besteht aus 48 Bytes aus dem plattformseitigen CSPRNG und wird als 96 hexadezimale Zeichen dargestellt. Es enthält keine Ansprüche: Es ist ein Suchschlüssel für eine Zeile, in der das Konto, der Geltungsbereich und ein Widerrufszeitstempel gespeichert sind.

• Es läuft nicht ab. Es wird kein expires_in zurückgegeben und kein Refresh-Token ausgestellt. Ein Token ist gültig, bis es widerrufen wird.
• Der Widerruf erfolgt sofort. Beim Widerruf über das Panel wird die Zeile mit einem Zeitstempel versehen, und jeder nachfolgende Aufruf schlägt bei der Suche fehl – davor befindet sich kein Cache.
• Es wird wie ausgestellt gespeichert, nicht gehasht. Behandeln Sie ein Docsbook-MCP-Token wie ein Passwort: Wenn das Gerät, auf dem es gespeichert ist, kompromittiert wird, widerrufen Sie es, anstatt davon auszugehen, dass es automatisch ungültig geworden ist. (Was im Ruhezustand verschlüsselt ist, wird unter was Ihren Arbeitsbereich verlässt aufgeführt.)
• Die letzte Verwendung wird bei jedem Aufruf aufgezeichnet, sodass ein nicht verwendetes Token in der Tokenliste des Panels sichtbar ist.

Was die einzelnen Berechtigungsbereiche ermöglichen#

Der Berechtigungsbereich ist eine einzelne Zeichenfolge, die exakt verglichen wird. Alles, was nicht dem Schreibbereich entspricht, wird als schreibgeschützt behandelt — ein nicht erkannter Wert führt zu einer sicheren Ablehnung.

Die Bereichsprüfung deckt heute nicht jeden Schreibvorgang ab, und du solltest dies bei deiner Planung berücksichtigen. Sie wird genau bei acht Tools erzwungen: write_docs, create_issue, connect_source, configure_source, enable_agent und den drei run_docs_*-Läufen, die Schreibvorgänge ausführen. Diese lehnen ein schreibgeschütztes Token ab, bevor irgendetwas ausgeführt wird.

Jedes andere zustandsändernde Tool — die Einstellungs-Schreibvorgänge update_* und set_*, update_access, die Registrierung und Entfernung von Webhooks, die Erstellung von Zielen und Trichtern, der Upload, die Genehmigung und Löschung von Übersetzungen, create_workspace — wird nur durch den Projekteigentumsschutz und nicht durch den Berechtigungsbereich eingeschränkt. Ein schreibgeschütztes Token kann daher die Einstellungen eines Projekts ändern, einen Webhook aktivieren oder eine Übersetzung in einem Projekt löschen, das dem Konto gehört. Es kann jedoch weiterhin keine Seite veröffentlichen, kein Issue erstellen, keine Quelle verbinden und keinen Agenten aktivieren.

Behandle den schreibgeschützten Bereich als „kann nichts veröffentlichen oder neue Funktionen anbinden“, nicht als „kann nichts ändern“. Wenn eine stärkere Begrenzung wichtig ist, verwende ein separates Docsbook-Konto, dem nur das Projekt gehört, das du freigeben möchtest. Dies ist ein Fehler, der unter Einschränkungen erneut aufgeführt wird, und kein Design.

Ein Tool, das die Prüfung durchsetzt, antwortet auf ein schreibgeschütztes Token mit einem strukturierten READ_ONLY_TOKEN-Fehler, der das Tool nennt und angibt, wie die Autorisierung erneuert werden kann — nicht mit einem einfachen 403 und auch nicht mit einem stillen No-op. Dasselbe Format gilt, wenn das Guthaben eines Projekts aufgebraucht ist (INSUFFICIENT_BALANCE, mit Angabe des Projekts, des Preises und des Restbetrags) und wenn ein Tarif die Funktion nicht umfasst (PLAN_RESTRICTION, mit Angabe der Tarifstufe).

Das anonyme search ist das einzige tokenlose Tool, das ein Projekt liest, und es wird auf drei Arten abgelehnt: bei einem Endpunkt, der keinem Projekt zugeordnet ist, bei einem Projekt, dessen Sichtbarkeit auf privat gesetzt ist (was auch einen abgelaufenen Tarif umfasst), und wenn das Projekt kein Guthaben mehr hat, um für das Abfrage-Embedding zu bezahlen. Es akzeptiert kein Projektargument und kann daher immer nur die Website lesen, der es zugeordnet ist.

Was ein einzelnes Token nicht erreichen kann#

Jedes Tool ermittelt seinen Zielarbeitsbereich anhand des expliziten workspace_id, des repo-Arguments oder der eigenen Verknüpfung des Endpunkts – und in allen drei Fällen wird die Suche nach dem Konto des Tokens gefiltert. Ein Arbeitsbereich, den das Konto nicht besitzt, wird nicht gefunden, und das Tool antwortet mit „Arbeitsbereich nicht gefunden“. Der Abrechnungs-Resolver wendet denselben Filter an, sodass die Angabe der Projekt-ID eines anderen Benutzers ebenfalls nicht das Guthaben eines anderen Benutzers belasten kann.

Zwei weitere Grenzen sollten erwähnt werden, da sie viele überraschen:

• write_docs führt Commits in das von Docsbook gehostete Repository mit den eigenen GitHub-Anmeldedaten von Docsbook durch. Eine von einem Repository in Ihrem eigenen GitHub-Konto bereitgestellte Website wird mit NO_GITHUB_ACCESS abgelehnt, anstatt in das Repository übernommen zu werden. Ein MCP-Token ist daher kein Mittel, um in die GitHub-Organisation Ihres Unternehmens zu pushen.
• Ein im Prüfmodus ausgeführter Skill kann keine Änderungen vornehmen. Während ein Skill im audit-Modus aktiv ist, werden eine explizite Liste von Schreibvorgängen sowie jedes Tool, dessen Name mit update_, set_, register_webhook_, enable_ oder disable_ beginnt, abgelehnt, bevor es ausgeführt wird. run_docs_analyze aktiviert diesen Modus für den gesamten Lauf, weshalb es mit einem schreibgeschützten Token sicher ist.

Was wird aufgezeichnet#

Jeder MCP-Aufruf – unabhängig davon, ob er abgerechnet wird oder nicht und ob er erfolgreich ist oder nicht – schreibt eine Zeile in das Aufrufprotokoll des Projekts, und der Eigentümer des Projekts kann sie im Bereich „Feeds“ lesen.

Zwei Details der Schwärzung sind für die Überprüfung wichtig. Sie wird anhand des Schlüssels vorgenommen, ohne Berücksichtigung der Groß- und Kleinschreibung und als Teilzeichenfolge, nicht anhand der Form des Werts – wer versucht, ein Geheimnis anhand seines Aussehens zu erkennen, kann es übersehen. Außerdem wird sie sowohl beim Ausgeben als auch beim Eingeben durchgeführt, sodass ein Werkzeug, das seine eigene Eingabe zurückgibt, keinen Schlüssel über sein Ergebnis preisgeben kann. Jede Seite wird bei 8.000 Zeichen mit einem Hinweis darauf abgeschnitten, wie viele Zeichen entfernt wurden.

Analysen auf Leserebene übermitteln niemals eine Identität an einen MCP-Client. Ein Besucher wird durch ein Pseudonym dargestellt: sha256(salt | repository | ip), gekürzt auf 16 hexadezimale Zeichen, wobei das Salt serverseitig gespeichert wird. get_top_visitors, get_page_journeys und get_visitor_activity geben dieses Pseudonym, ein Land und Ereignisse auf Seitenebene zurück; kein Werkzeug gibt eine IP-Adresse, einen Namen oder eine E-Mail-Adresse zurück. Das Pseudonym ist auf ein Repository beschränkt, sodass derselbe Leser auf zwei Ihrer Websites zwei voneinander unabhängige IDs hat.

Was verlässt Ihren Arbeitsbereich#

Zwei Behauptungen, die die Sicherheitsseite eines Dokumentationsanbieters normalerweise aufstellt, richtiggestellt:

• „Ihre Inhalte verlassen niemals Ihr Repository“ trifft hier nicht zu. Docsbook speichert eine durchsuchbare Kopie Ihres Seitentexts und seiner Vektoreinbettungen und sendet Seitentext an einen Modellanbieter, um diese Einbettungen zu erstellen sowie Chat- und Agentenaufrufe zu beantworten. Was zutrifft, ist, dass GitHub die maßgebliche Quelle bleibt. Wenn Sie die Zahlung einstellen, wird die kostenabhängige Verarbeitung beendet, ohne Ihr Markdown zu löschen.
• Ausgehende Abrufe werden abgesichert, nicht lediglich als vertrauenswürdig vorausgesetzt. Vor jedem Abruf wird das Schema geprüft, der Hostname aufgelöst und eine aufgelöste Adresse in einem privaten oder reservierten Bereich abgelehnt — und die Prüfung wird bei jedem Weiterleitungsschritt erneut durchgeführt, sodass eine öffentliche URL nicht auf eine interne umleiten kann. robots.txt wird berücksichtigt und die Antwort begrenzt. Der Skill-Fetcher ist noch restriktiver: Er ruft nur vom eigenen Host und mit dem Pfadpräfix des Katalogs ab und kann daher nicht in einen Proxy für beliebige URLs umgewandelt werden.

Webhooks und Chat-Hooks sind nicht dasselbe#

Ausgehende Webhook-Zustellungen werden signiert. Die Signatur ist ein HMAC-SHA256 über die exakt gesendeten Bytes, in X-Docsbook-Signature-256: sha256=<hex>, zusammen mit X-Docsbook-Event. Eine eingehende Webhook-URL von Discord oder Slack wird vor der Signierung für die jeweilige Plattform angepasst, sodass die Signatur immer das abdeckt, was Ihr Endpunkt tatsächlich empfängt. Das Geheimnis wird bei der Registrierung festgelegt, ist mindestens 16 Zeichen lang und wird danach niemals im Klartext zurückgegeben. Zustellversuche werden nach 15 Sekunden abgebrochen und die Antwort wird gekürzt gespeichert.

Chat-Hooks tragen keine Signatur. Die Pre-, Post- und Streaming-Hooks des Dokumentationsassistenten sind einfache JSON-POSTs mit einem Timeout von 5 Sekunden und ohne HMAC-Header. Verwenden Sie dort nicht Ihren Webhook-Verifizierungscode und gehen Sie nicht davon aus, dass er etwas verifiziert hat. Der Pre-Hook kann außerdem inject_context zurückgeben, dessen Text in den Prompt des Assistenten gelangt — ein Endpunkt, auf den Sie einen Chat-Hook verweisen, kann daher beeinflussen, was der Assistent sagt. Behandeln Sie ihn daher als vertrauenswürdige Infrastruktur, authentifizieren Sie ihn auf andere Weise und verweisen Sie nicht auf eine URL, die Sie nicht kontrollieren.

Warum dies der richtige Weg ist (Belege)#

Ein weiterer Punkt liegt in der Verantwortung deines Clients und nicht bei uns: Die MCP-Spezifikation weist Clients an, „Tool-Anmerkungen als nicht vertrauenswürdig zu betrachten, sofern sie nicht von vertrauenswürdigen Servern stammen“, und „einen Menschen in den Prozess einzubeziehen, der Tool-Aufrufe ablehnen kann“ (MCP-Tools). Ein Docsbook-Token mit Lese- und Schreibzugriff ist genau der Fall, der diese menschliche Kontrolle verdient.

Wo Docsbook die MCP-Spezifikation derzeit nicht erfüllt#

Diese Punkte werden anhand der Revision 2026-07-28 bewertet. Jeder Punkt stellt eine Lücke in Docsbook dar, keine Abweichung von der Spezifikation.

Was Docsbook bisher noch nicht bietet#

Aufgelistet, damit eine Prüfung Docsbook innerhalb einer Stunde statt erst in der dritten Woche ausschließen kann.

Eine Funktion wird regelmäßig mit der zweiten und vierten Zeile verwechselt: Ein privater Arbeitsbereich kann bei jedem Plan durch ein Passwort oder über Ihren eigenen OIDC-Anbieter mittels update_access geschützt werden. Das ist Single Sign-on für die Leser Ihrer Dokumentationswebsite. Es ist kein Single Sign-on für die Mitglieder Ihres Docsbook-Kontos und gewährt keinen MCP-Zugriff.

Wenn Ihre Organisation ein bestimmtes Dokument benötigt – ein DSGVO-DPA, ein BAA, einen ausgefüllten Fragebogen –, schreiben Sie an support@docsbook.io und fragen Sie, was vorhanden ist. Die Antwort kann heute durchaus lauten, dass es nicht vorhanden ist.

Grenzen und offene Fragen#

• Hosting-Regionen sind ungeklärt. Diese Seite nennt bewusst keine Region für die Datenbank oder den Analytics-Speicher. Beide sind verwaltete Dienste, deren Region eine Bereitstellungseinstellung ist und nicht etwas, das ein Leser anhand des Verhaltens von Docsbook überprüfen kann. Außerdem nannte eine frühere Version dieser Seite Regionen ohne Quellenangabe. Fragen Sie den Support schriftlich nach der aktuellen Antwort, wenn die Datenresidenz Teil Ihrer Prüfung ist.
• Die pseudonyme Besucher-ID ist ein Pseudonym, keine Anonymisierung. Sie ist ein gesalzener Hash einer auf 64 Bit gekürzten IP-Adresse. Jeder, der über das Salt und den unaufbereiteten Ereignisspeicher verfügt, könnte sie erneut ableiten. Die Zusicherung besteht darin, dass das Salt nicht in den Daten enthalten ist und keine API eine IP-Adresse zurückgibt. Ob dies den Anforderungen Ihrer Aufsichtsbehörde genügt, ist eine Frage für Ihre Aufsichtsbehörde.
• Ein Lese-/Schreib-Token ist ein vollständiges administratives Zugangstoken. Es gibt keine Möglichkeit zu gewähren: „Darf Seiten bearbeiten, aber Einstellungen nicht ändern“ oder „Darf Analysen lesen, aber keine Chatprotokolle“. Die Berechtigungsstufen haben zwei Ebenen.
• Der Nur-Lese-Bereich wird nicht vollständig durchgesetzt. Acht Tools prüfen ihn; die Writer für Einstellungen, Webhooks, Ziele und Übersetzungen tun dies nicht. Außerdem behaupten die eigenen Beschreibungen einiger dieser Tools, dass sie ein Lese-/Schreib-Token erfordern, obwohl nichts dies prüft. Bis dies behoben ist, ist die zuverlässige Grenze der Kontobesitz und nicht der Berechtigungsbereich – isolieren Sie daher nach Konto und lesen Sie die oben aufgeführte durchgesetzte Liste statt der Beschreibung eines Tools.
• Nichts hiervon wurde unabhängig bestätigt. Jede obige Aussage kann anhand des Verhaltens von Docsbook überprüft werden – stellen Sie ein Nur-Lese-Token aus und beobachten Sie, wie ein Writer die Aktion ablehnt; verbinden Sie ein Projekt, dessen Eigentümer Sie nicht sind, und beobachten Sie, wie es nicht aufgelöst wird –, aber kein Dritter hat dies geprüft. Betrachten Sie diese Seite als eine testbare Spezifikation, nicht als eine Zertifizierung.
• Verfügbarkeit und Preis finden Sie auf der Preisseite. Hier wird keine Zahl genannt, da ein in die Dokumentation kopierter Preis unbemerkt veraltet.

Verwandte Themen#

• MCP-Server — die Tools selbst und worauf ein Aufruf zurückgreift
• Für Agenten geeignete Inhalte — die vier maschinenlesbaren Schnittstellen und wie sie zusammenpassen
• Dokumentations-Skills — was ein Skill während seiner Ausführung tun kann und was nicht
• Webhooks — das vollständige Ereignisschema und die Signaturüberprüfung
• KI-Chat-Hooks — die unsignierten Pre-/Post-/Streaming-Hooks
• Quellen — was ein Agent in Ihrem Namen lesen darf