Skip to main content Skip to page footer

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-Endpunkten.

  • 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 auf 1 MB pro Anfrage begrenzt.
  • Rate-Limit von 100 Anfragen pro Minute und Token. Danach antwortet der Server mit 429 und Retry-After: 60.
  • 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, der Backend-Benutzergruppe muss zusätzlich das passende Feature-Recht zugewiesen sein.

Fehlkonfigurationen meldet das TYPO3-Reports-Modul unter System → Berichte → AI Suite MCP Security, etwa erlaubtes HTTP oder leere Allowlists im Produktivkontext.

Sicherheitsrelevante Einstellungen

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

EinstellungStandardFunktion
mcpAllowHttp0Erlaubt den Endpoint über unverschlüsseltes HTTP. Nur für lokale Entwicklung ohne TLS, produktiv niemals aktivieren.
mcpExcludedTables(leer)Tabellen, die MCP-Tools weder lesen noch schreiben dürfen. Gilt zusätzlich zu den TYPO3-Rechten und blockiert auch Administratoren. Sinnvoll etwa für be_users, fe_users oder sys_log.
mcpTrustedProxies(leer)IPs oder CIDR-Bereiche der eigenen Reverse Proxies. Nur wenn gesetzt, wird die echte Client-IP aus X-Forwarded-For für das Audit-Log aufgelöst. Ist der Wert leer, wird der Header ignoriert.
mcpLogVerbose1Schaltet das ausführliche INFO-Log ein oder aus. Das Warnungs-Log bleibt in jedem Fall aktiv.
mcpLogRedactionPatterns(leer)Zusätzliche Regex-Muster, deren Treffer im Log durch [REDACTED] ersetzt werden. Die eingebauten Muster gelten immer.
mcpMediaAllowUrlFetch1Erlaubt uploadMedia den Download von entfernten URLs. Ausschalten wirkt als kompletter Riegel, Base64 und Online-Media-Links bleiben möglich.
mcpMediaHostDenylist(leer)Zusätzliche Hostnamen oder IP-Bereiche, von denen uploadMedia nie laden darf.

Medien-Upload absichern

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- und Link-Local-Adressen sind gesperrt (einschließlich des Cloud-Metadaten-Endpoints 169.254.169.254, in IPv4 und IPv6). 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.

Logging und Aufbewahrung

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 Methode, Pfad und Statuscode jeder MCP-Anfrage samt der ersten rund 300 Zeichen des Request-Bodys sowie Tool-Fehler mit vollem Stacktrace. Der Body-Auszug enthält 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 überhaupt nicht im MCP-Log auf, hat die Anfrage die Middleware nie erreicht. Dann hilft nur das Access-Log des Webservers, siehe Produktivbetrieb.

Datenbanktabellen

Die Erweiterung legt drei eigene Tabellen an. Alle drei gehören zur OAuth-Schicht, Inhalte werden dort nicht gespeichert.

TabelleInhalt
tx_aisuite_oauth_codesKurzlebige Authorization Codes mit PKCE-Challenge und Redirect-URI
tx_aisuite_oauth_tokensAccess- und Refresh-Tokens, Client-Metadaten, letzte genutzte IP, Credit-Verbrauch
tx_aisuite_oauth_consentsGemerkte Scope-Zustimmungen pro Benutzer und Client

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