Sicherheit & Betrieb

Der MCP-Endpoint ist von außen erreichbar und führt Aktionen im Namen eines Backend-Benutzers aus. Er bringt daher eigene Schutzmechanismen mit, die unabhängig von den TYPO3-Rechten greifen. Durchgesetzt werden sie in der MCP-Middleware und in den OAuth-Endpoints.

• HTTPS ist produktiv Pflicht. Ausgenommen sind localhost und *.ddev.site. Übersteuern lässt sich das nur mit mcpAllowHttp = 1, was produktiv nicht in Frage kommt, weil Bearer-Tokens dann im Klartext übertragen werden.
• Die Größe des Request-Bodys ist standardmäßig auf 1 MB pro Anfrage begrenzt, einstellbar über mcpMaxRequestBodyMb (etwa für Base64-Uploads).
• Rate-Limit von 100 Anfragen pro Minute und Token. Danach antwortet der Server mit 429 und Retry-After: 60. Die OAuth-Endpoints für Autorisierung, Token und Registrierung sind zusätzlich pro Client-IP begrenzt und antworten ebenfalls mit 429.
• OAuth 2.1 mit PKCE. Implicit- und Password-Grants gibt es nicht.
• Dynamic Client Registration ist erlaubt, wird aber durch mcpAllowedClientIds und mcpAllowedRedirectUris eingegrenzt.
• Eine Passwortänderung widerruft alle Tokens des betroffenen Backend-Benutzers.
• Der Status des Backend-Benutzers wird bei jeder Anfrage frisch geprüft. Deaktivierte oder gelöschte Benutzer werden abgewiesen, auch wenn ihr Token noch gültig wäre.
• Scope und Berechtigung werden doppelt geprüft. Ein OAuth-Scope allein genügt nicht: Wo ein Scope oder ein Tool an ein Feature-Recht gebunden ist, muss die Backend-Gruppe es zusätzlich besitzen.

Fehlkonfigurationen meldet der Statusbericht unter System → Berichte → AI Suite MCP Security (ab TYPO3 14: Verwaltung → Berichte), etwa erlaubtes HTTP oder leere Allowlists im Produktivkontext.

Diese Optionen aus der Extension-Konfiguration wirken direkt auf die Sicherheit. Die übrigen Einstellungen sind unter Konfiguration beschrieben.

ChEddi übernimmt mcpWriteMode, mcpAllowRawHtmlWrite, mcpExcludedTables, mcpLogVerbose und mcpLogRedactionPatterns standardmäßig und hat dafür eigene Einstellungen. Rohes HTML und die Tabellen-Sperrliste kann ChEddi dabei nur verschärfen, nie lockern. Details siehe ChEddi: Konfiguration.

Seit Version 0.9.0 fließt jeder Schreibvorgang eines MCP-Tools in das Transparenzregister der AI Suite ein. Alles, was ein Tool während eines Aufrufs speichert, wird als KI-generiert erfasst, mit der Funktion „MCP-Server“ und dem verwendeten Client. Schreibt ChEddi über den Server, wird die Funktion „Redaktions-Chat“ vermerkt. Rein lesende Aufrufe hinterlassen keinen Eintrag. Die so erfassten Datensätze erscheinen im Bereich „KI-Inhalte“ der AI Suite und tragen im Backend die übliche Kennzeichnung, siehe KI-Inhalte (EU AI Act).

Steht mcpMaxCreditsPerSession auf einem Wert größer als 0, führt der Server mit, wie viele KI-Credits über ein Token verbraucht wurden. Drei Eigenschaften solltest du kennen, bevor du ein Budget setzt:

• Gezählt wird der tatsächliche Verbrauch. Grundlage ist der Wert, den der AI-Suite-Server für den Aufruf zurückmeldet, nicht die am Tool hinterlegte Kostenangabe. Beides kann auseinandergehen.
• Die Prüfung greift vor jedem KI-Aufruf. Der Aufruf, der das Budget überschreitet, wird noch ausgeführt und abgerechnet, sein Ergebnis kommt mit einem Hinweis zurück. Jeder weitere KI-Aufruf mit diesem Token wird abgelehnt, bevor etwas an den AI-Suite-Server geht. Die Meldung weist darauf hin, dass erst ein neu ausgestelltes Token mit frischem Budget startet.
• Der Zähler hängt am Token, nicht an der Verbindung. Er wird am Token-Datensatz gespeichert und überlebt damit einen Neustart des Servers und das Ende einer Unterhaltung. Eine neue Unterhaltung hilft deshalb nicht: Mit demselben Token bleibt der Zähler stehen. Zurückgesetzt wird er erst, wenn der Client ein neues Token erhält. Bei OAuth-Clients gehört dazu auch jede automatische Token-Erneuerung (Refresh), denn das neue Token startet wieder bei null. Wirklich pro Zugang gilt das Budget nur bei einem statischen Token.

Ein Budget eignet sich deshalb als Obergrenze pro Token, nicht als Tageskontingent. Wer ein Budget setzt, sollte den Wert eher großzügig wählen und die Statistiken im Blick behalten, statt eine enge Grenze zu ziehen und im Alltag ständig ins Leere zu laufen.

Der empfindlichste Teil des Medien-Uploads ist der Download aus entfernten Quellen. Er ist gegen SSRF abgesichert. Erlaubt sind nur http und https, jede aufgelöste IP muss öffentlich sein. Private, Loopback-, Link-Local- und reservierte Adressen sind in IPv4 und IPv6 gesperrt, einschließlich des Cloud-Metadaten-Endpoints 169.254.169.254. Weiterleitungen werden Schritt für Schritt neu geprüft, und der Download läuft als Stream gegen eine harte Größengrenze. Blockierte Ziele landen als Warnung im Log.

Zusätzlich zum Scope mcp:media und dem Recht enable_mcp_media_upload gelten die FAL-Dateimount-Rechte auf dem Zielordner unverändert. Über die Extension-Konfiguration steuerbar sind Zielordner (mcpMediaDefaultFolder, Standard 1:/user_upload/), maximale Dateigröße (mcpMediaMaxSizeMb, Standard 50) und die erlaubten Dateiendungen (mcpMediaAllowedExtensions). SVG ist bewusst nicht dabei, weil damit Skripte eingeschleust werden könnten. Große Videos sollten über eine URL oder als Online-Media-Link kommen, nicht als Base64.

AI Suite MCP schreibt in zwei eigene Log-Dateien.

• var/log/aisuite_mcp.log mit allem ab INFO, also der vollständigen Spur. Gut für die Fehlersuche und zum Nachvollziehen einzelner Anfragen. Über mcpLogVerbose abschaltbar. In einer eingespielten Produktivumgebung darf das Log aus bleiben, das senkt Schreiblast und die Menge personenbezogener Daten.
• var/log/aisuite_mcp_warnings.log mit allem ab WARNING. Immer aktiv, bleibt klein. Ist die Datei nicht leer, lohnt ein Blick hinein, denn dort stehen Rate-Limit-Treffer, fehlgeschlagene Tool-Aufrufe und OAuth-Fehlkonfigurationen. Diese Datei ist der richtige Ort für Monitoring.

Protokolliert werden OAuth-Ereignisse (Token ausgestellt, erneuert, widerrufen) mit Client-ID, Backend-Benutzer-UID und Client-IP, außerdem für jede MCP-Anfrage Statuscode, HTTP- und JSON-RPC-Methode, Tool-Name und die ersten 500 Zeichen der Tool-Argumente sowie die ersten 500 Zeichen der Antwort. Ist der Request-Body kein JSON, landen stattdessen seine ersten 300 Zeichen im Log. Dazu kommen Tool-Fehler mit vollem Stacktrace. Argumente und Antworten enthalten regelmäßig Prompts, Inhaltsauszüge und Metadaten. Das ist bei der Aufbewahrungsdauer und in der Datenschutzdokumentation zu berücksichtigen. Bearer-Tokens, 64-stellige Hex-Hashes und E-Mail-Adressen werden vor dem Schreiben automatisch maskiert.

Taucht ein Problem nicht im MCP-Log auf, hat die Anfrage die Middleware entweder nie erreicht oder wurde dort schon wegen fehlenden HTTPS (400) oder eines zu großen Bodys (413) abgewiesen, ohne Log-Eintrag. Ist mcpLogVerbose aus, fehlt die INFO-Spur ohnehin. Dann hilft das Access-Log des Webservers, siehe Produktivbetrieb.

Die Extension legt zwei eigene Tabellen an. Beide gehören zur OAuth-Schicht, Inhalte werden dort nicht gespeichert.

Aufgeräumt werden die Tabellen nicht von allein. Das übernimmt der Befehl ai-suite-mcp:cleanup, siehe CLI-Befehle.