MCP-Serversicherheit

Diese Seite richtet sich an die Person, die die Verbindung eines KI-Agenten mit Docsbook genehmigen muss. Sie beschreibt, was der MCP-Server derzeit tatsächlich tut – wie sich ein Client authentifiziert, worauf jeder Bereich zugreifen kann, was aufgezeichnet wird, was das Netzwerk verlässt – und benennt anschließend in zwei separaten Abschnitten, in welchen Punkten Docsbook hinter der Spezifikation des Model Context Protocol zurückbleibt und welche Compliance-Artefakte noch nicht existieren.

Hier geht es nicht um Wunschvorstellungen. Wo eine Kontrolle fehlt, wird dies als fehlend aufgeführt.

Was Sie erhalten#

Ein verbundener Client hält ein undurchsichtiges Bearer-Token, das an genau ein Docsbook-Konto gebunden ist und einen von zwei Berechtigungsumfängen enthält. Der Berechtigungsumfang wird von einer Person auf einem Einwilligungsbildschirm ausgewählt – nicht vom Client angefordert. Jedes Tool, das auf einem Projekt arbeitet, ermittelt dieses Projekt über den Eigentümer. Daher erhält ein Token, das eine Workspace-ID nennt, die jemand anderem gehört, keine Daten zurück – und 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 Maßnahme zur Begrenzung betrachten.

Jeder abgerechnete Aufruf schreibt eine Zeile in das eigene Aufrufprotokoll Ihres Projekts: welches Tool, was hineinging, was zurückkam, wie lange es dauerte und was es verbrauchte. Argumente und Ergebnisse werden vor der Speicherung anhand ihrer Schlüssel redigiert, sodass ein an ein Tool übergebener API-Schlüssel niemals aufgezeichnet wird.

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

Funktionsweise der Authentifizierung#

Der Autorisierungsablauf#

Docsbook ist sein eigener Autorisierungsserver und sein eigener Ressourcenserver. Es stellt undurchsichtige Token für sich selbst aus; ein von einer anderen Stelle 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 plattformeigenen CSPRNG und wird als 96 hexadezimale Zeichen dargestellt. Es enthält keine Claims: Es ist ein Nachschlageschlüssel für eine Zeile, in der das Konto, der Bereich 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 Bedienfeld wird die Zeile markiert, und jeder nachfolgende Aufruf schlägt bei der Suche fehl — es gibt keinen vorgeschalteten Cache.
• Es wird im ausgestellten Zustand gespeichert, nicht gehasht. Behandeln Sie ein Docsbook-MCP-Token wie ein Passwort: Wenn die Maschine, auf der es gespeichert ist, kompromittiert wird, widerrufen Sie es, anstatt davon auszugehen, dass es abgelaufen ist. (Was im Ruhezustand verschlüsselt wird, ist unter was Ihren Workspace verlässt aufgeführt.)
• Die letzte Verwendung wird aufgezeichnet bei jedem Aufruf, sodass ein ungenutztes Token in der Tokenliste des Bedienfelds sichtbar ist.

Was jeder Scope kann#

Der Scope ist eine einzelne Zeichenfolge, die exakt verglichen wird. Alles, was nicht dem Schreib-Scope entspricht, wird als schreibgeschützt behandelt — ein nicht erkannter Wert wird standardmäßig abgelehnt.

Die Scope-Prüfung deckt derzeit nicht jeden Schreibvorgang ab, und du solltest dies bei deiner Planung berücksichtigen. Sie wird genau bei vier Tools durchgesetzt: write_docs, create_issue, connect_source und configure_source. Diese lehnen ein schreibgeschütztes Token ab, bevor sie irgendetwas tun.

Jedes andere statusä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 sowie create_workspace — wird nur durch den Projektbesitz eingeschränkt, nicht durch den Scope. 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 weiterhin keine Seite veröffentlichen, kein Issue erstellen, keine Quelle verbinden und keinen Agenten aktivieren.

Behandle den schreibgeschützten Scope als „kann nichts veröffentlichen oder neue Funktionen verknüpfen“, nicht als „kann nichts ändern“. Wenn eine stärkere Eingrenzung 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. Dieselbe Struktur gilt, wenn das Guthaben eines Projekts aufgebraucht ist (INSUFFICIENT_BALANCE, mit Angabe des Projekts, des Preises und des verbleibenden Betrags) und wenn ein Plan die Funktion nicht umfasst (PLAN_RESTRICTION, mit Angabe der Stufe).

Das anonyme search ist das einzige Tool ohne Token, das ein Projekt liest, und es wird auf drei Arten abgelehnt: bei einem Endpoint, der an kein Projekt gebunden ist, bei einem Projekt, dessen Sichtbarkeit privat ist (was auch einen abgelaufenen Plan umfasst), und wenn das Projekt kein Guthaben mehr hat, um die Abfrageeinbettung zu bezahlen. Es akzeptiert kein Projektargument und kann daher immer nur die Website lesen, an die es gebunden ist.

Was ein einzelnes Token nicht erreichen kann#

Jedes Tool ermittelt seinen Zielarbeitsbereich anhand des expliziten workspace_id, des Arguments repo oder der eigenen Zuordnung 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 Abrechnungsauflöser wendet denselben Filter an, sodass die Angabe der Projekt-ID einer fremden Person ebenfalls nicht das Guthaben einer fremden Person belasten kann.

Zwei weitere Grenzen sind erwähnenswert, weil sie viele Menschen überraschen:

• write_docs führt Commits am von Docsbook gehosteten 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, statt dort einen Commit durchzuführen. Ein MCP-Token ist daher keine Möglichkeit, in Ihre GitHub-Organisation zu pushen.
• Ein Skill im Audit-Modus kann keine Änderungen vornehmen. Solange ein Skill im audit-Modus aktiv ist, wird eine explizite Liste von Schreibvorgängen sowie jedes Tool, dessen Name mit update_, set_, register_webhook_, enable_ oder disable_ beginnt, vor der Ausführung abgelehnt. Der Runner, der diesen Modus früher für einen gesamten serverseitigen Durchlauf festlegte, wurde am 12.09.2026 entfernt, sodass die Schutzmaßnahme nun einen Turn schützt, bei dem ein audit-Skill vorab geladen wurde und sonst nichts.

Was aufgezeichnet wird#

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, das der Eigentümer des Projekts im Feeds-Bereich lesen kann.

Für die Überprüfung sind zwei Details der Bereinigung wichtig. Sie sucht nach dem Schlüssel, unabhängig von Groß- und Kleinschreibung und als Teilzeichenfolge, nicht nach der Form des Werts – die Vermutung, wie ein Geheimnis aussieht, hat eine Form, die sie verfehlt. Außerdem wird sie sowohl beim Ausgang als auch beim Eingang ausgeführt, sodass ein Tool, das seine eigene Eingabe zurückgibt, keinen Schlüssel über sein Ergebnis preisgeben kann. Jede Seite wird bei 8.000 Zeichen abgeschnitten, mit einem Hinweis darauf, wie viele Zeichen entfernt wurden.

Analysen auf Leserebene übermitteln niemals eine Identität an einen MCP-Client. Ein Besucher ist ein Pseudonym: sha256(salt | repository | ip), auf 16 hexadezimale Zeichen gekürzt, 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 Tool gibt eine IP-Adresse, einen Namen oder eine E-Mail-Adresse zurück. Das Pseudonym ist auf ein Repository begrenzt, sodass derselbe Leser auf zwei Ihrer Websites zwei voneinander unabhängige IDs hat.

Was deinen Arbeitsbereich verlässt#

Zwei Aussagen, die die Sicherheitsseite eines Dokumentationsanbieters normalerweise macht, richtiggestellt:

• „Deine Inhalte verlassen niemals dein Repository“ trifft hier nicht zu. Docsbook speichert eine durchsuchbare Kopie deines Seitentexts und seiner Vektoreinbettungen und sendet Seitentext an einen Modellanbieter, um diese Einbettungen zu erstellen und Chat- sowie Agentenaufrufe zu beantworten. Was stimmt, ist, dass GitHub die maßgebliche Quelle bleibt. Wenn du die Zahlung einstellst, werden daher die nutzungsabhängigen Vorgänge beendet, ohne dein Markdown zu löschen.
• Ausgehende Abrufe werden abgesichert, nicht einfach nur 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 URL umleiten kann. robots.txt wird berücksichtigt und die Antwort begrenzt. Der Skill-Abruf 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 verwandelt 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 Discord- oder Slack-Incoming-Webhook-URL wird vor der Signierung für die jeweilige Plattform angepasst, sodass die Signatur immer das abdeckt, was dein 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 laufen nach 15 Sekunden ab, und die Antwort wird gekürzt gespeichert.

Chat-Hooks tragen keine Signatur. Die Pre-, Post- und Streaming-Hooks des Dokumentationsassistenten sind einfache JSON-POST-Objekte mit einem Timeout von 5 Sekunden und ohne HMAC-Header. Verwende dort nicht deinen Webhook-Verifizierungscode und gehe nicht davon aus, dass damit etwas verifiziert wurde. Der Pre-Hook kann außerdem inject_context zurückgeben, dessen Text in den Prompt des Assistenten gelangt — ein Endpunkt, auf den du einen Chat-Hook verweist, kann daher beeinflussen, was der Assistent sagt. Behandle ihn also als vertrauenswürdige Infrastruktur, authentifiziere ihn auf andere Weise und verweise nicht auf eine URL, die du nicht kontrollierst.

Warum dies der richtige Weg ist (Belege)#

Ein weiterer Punkt betrifft Ihren Client und nicht 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 Schreibrechten ist genau der Fall, der diesen Menschen erfordert.

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

Diese werden an der Revision 2026-07-28 gemessen. Jede davon ist eine Lücke in Docsbook, keine Abweichung von der Spezifikation.

Was Docsbook noch nicht bietet#

Aufgeführt, 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 Tarif durch ein Passwort oder über update_access durch Ihren eigenen OIDC-Provider geschützt werden. Das ist Single Sign-on für die Leser Ihrer Dokumentationswebsite. Es ist nicht Single Sign-on für die Mitglieder Ihres Docsbook-Kontos und gewährt keinen MCP-Zugriff.

Wenn Ihre Organisation einen bestimmten Nachweis benötigt — einen DSGVO-AV-Vertrag, eine BAA, einen ausgefüllten Fragebogen — schreiben Sie an support@docsbook.io und fragen Sie, was vorhanden ist. Die heutige Antwort könnte durchaus lauten, dass es ihn nicht gibt.

Einschränkungen und offene Fragen#

• Ungeklärt: Hosting-Regionen. Auf dieser Seite wird bewusst keine Region für die Datenbank oder den Analytics-Speicher genannt. Beide sind verwaltete Dienste, deren Region eine Bereitstellungseinstellung ist und nicht etwas, das Leser anhand des Verhaltens von Docsbook überprüfen können. 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 mit Salt versehener Hash einer auf 64 Bit gekürzten IP-Adresse. Jeder, der sowohl das Salt als auch den unverarbeiteten Ereignisspeicher besitzt, könnte sie erneut ableiten; die Garantie besteht darin, dass das Salt nicht in den Daten enthalten ist und keine API eine IP-Adresse zurückgibt. Ob das den Anforderungen Ihrer Aufsichtsbehörde entspricht, ist eine Frage für Ihre Aufsichtsbehörde.
• Ein Lese-/Schreib-Token ist ein vollständiges Administrationsmerkmal. Es gibt keine Möglichkeit, „darf Seiten bearbeiten, aber keine Einstellungen ändern“ oder „darf Analytics lesen, aber keine Chat-Transkripte“ zu gewähren. 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, und in den eigenen Beschreibungen einiger dieser Tools wird behauptet, dass sie ein Lese-/Schreib-Token erfordern, obwohl nichts dies prüft. Solange diese Lücke nicht geschlossen ist, besteht die verlässliche Grenze im Kontobesitz, nicht im Berechtigungsbereich – isolieren Sie daher nach Konto und orientieren Sie sich an der oben aufgeführten durchgesetzten Liste statt an der Beschreibung eines Tools.
• Nichts davon wurde unabhängig bestätigt. Jede obige Aussage lässt sich anhand des Verhaltens von Docsbook überprüfen – stellen Sie ein Nur-Lese-Token aus und beobachten Sie, wie ein Writer die Anfrage ablehnt; verbinden Sie ein Projekt, das Ihnen nicht gehört, und beobachten Sie, wie es nicht aufgelöst wird –, aber kein Dritter hat dies geprüft. Betrachten Sie diese Seite als eine Spezifikation, die Sie testen können, 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
• Agent-fertige Inhalte — die vier maschinenlesbaren Oberflächen und wie sie zusammenspielen
• Dokumentationsfähigkeiten — was eine Fähigkeit während ihrer Ausführung tun kann und was nicht
• Webhooks — das vollständige Ereignisschema und die Signaturüberprüfung
• KI-Chat-Hooks — die unsignierten Pre-, Post- und Streaming-Hooks
• Quellen — was ein Agent in Ihrem Namen lesen darf