Security & Operation
The MCP endpoint is accessible from the outside and performs actions on behalf of a backend user. Therefore, it comes with its own protection mechanisms that operate independently of TYPO3 rights. They are enforced in the MCP middleware and in the OAuth endpoints.
- HTTPS is mandatory in production. Exceptions are localhost and *.ddev.site. This can only be overridden with mcpAllowHttp = 1, which is not an option in production because bearer tokens would then be transmitted in plain text.
- The size of the request body is limited to 1 MB per request.
- Rate limit of 100 requests per minute and token. After that, the server responds with 429 and Retry-After: 60.
- OAuth 2.1 with PKCE. Implicit and password grants are not available.
- Dynamic client registration is allowed but is restricted by mcpAllowedClientIds and mcpAllowedRedirectUris.
- A password change revokes all tokens of the affected backend user.
- The status of the backend user is checked fresh with each request. Deactivated or deleted users are rejected, even if their token would still be valid.
- Scope and permission are checked twice. An OAuth scope alone is not sufficient; the backend user group must also be assigned the corresponding feature right.
Misconfigurations are reported by the TYPO3 Reports module under System → Reports → AI Suite MCP Security, such as allowed HTTP or empty allowlists in the production context.
Security-Relevant Settings
These options from the extension configuration directly affect security. The other settings are described under Configuration.
| Setting | Default | Function |
|---|---|---|
mcpAllowHttp | 0 | Allows the endpoint over unencrypted HTTP. Only for local development without TLS, never activate in production. |
mcpExcludedTables | (empty) | Tables that MCP tools are not allowed to read or write. Applies in addition to TYPO3 rights and also blocks administrators. Useful for be_users, fe_users, or sys_log. |
mcpTrustedProxies | (empty) | IPs or CIDR ranges of your own reverse proxies. Only if set, the real client IP from X-Forwarded-For is resolved for the audit log. If the value is empty, the header is ignored. |
mcpLogVerbose | 1 | Enables or disables the detailed INFO log. The warning log remains active in any case. |
mcpLogRedactionPatterns | (empty) | Additional regex patterns whose matches in the log are replaced with [REDACTED]. The built-in patterns always apply. |
mcpMediaAllowUrlFetch | 1 | Allows uploadMedia to download from remote URLs. Turning it off acts as a complete block; Base64 and online media links remain possible. |
mcpMediaHostDenylist | (empty) | Additional hostnames or IP ranges from which uploadMedia is never allowed to load. |
Secure Media Upload
The most sensitive part of media upload is downloading from remote sources. It is secured against SSRF. Only http and https are allowed; any resolved IP must be public; private, loopback, and link-local addresses are blocked (including the cloud metadata endpoint 169.254.169.254, in IPv4 and IPv6). Redirects are rechecked step by step, and the download runs as a stream against a hard size limit. Blocked targets are logged as warnings.
In addition to the scope mcp:media and the right enable_mcp_media_upload, the FAL file mount rights on the target folder remain unchanged. The target folders (mcpMediaDefaultFolder, default 1:/user_upload/), maximum file size (mcpMediaMaxSizeMb, default 50), and allowed file extensions (mcpMediaAllowedExtensions) are controllable via the extension configuration. SVG is deliberately excluded because it could be used to inject scripts. Large videos should come via a URL or as an online media link, not as Base64.
Logging and Retention
The MCP writes to two separate log files.
var/log/aisuite_mcp.logwith everything from INFO, thus the complete trace. Good for troubleshooting and tracking individual requests. Can be turned off viamcpLogVerbose. In a well-established production environment, the log can be turned off, reducing write load and the amount of personal data.var/log/aisuite_mcp_warnings.logwith everything from WARNING. Always active, remains small. If the file is not empty, it is worth taking a look inside, as it contains rate limit hits, failed tool calls, and OAuth misconfigurations. This file is the right place for monitoring.
OAuth events (tokens issued, renewed, revoked) are logged with client ID, backend user UID, and client IP, as well as the method, path, and status code of each MCP request along with the first approximately 300 characters of the request body, as well as tool errors with full stack trace. The body excerpt regularly contains prompts, content excerpts, and metadata. This must be taken into account regarding retention period and in the data protection documentation. Bearer tokens, 64-character hex hashes, and email addresses are automatically masked before writing.
If a problem does not appear in the MCP log at all, the request never reached the middleware. Then only the access log of the web server helps, see Production Operation.
Database Tables
The extension creates three of its own tables. All three belong to the OAuth layer; no content is stored there.
| Table | Content |
|---|---|
tx_aisuite_oauth_codes | Short-lived authorization codes with PKCE challenge and redirect URI |
tx_aisuite_oauth_tokens | Access and refresh tokens, client metadata, last used IP, credit consumption |
tx_aisuite_oauth_consents | Saved scope consents per user and client |
The tables are not cleaned up automatically. This is handled by the command ai-suite-mcp:cleanup, see CLI Commands.
Don't Forget Maintenance
In production, ai-suite-mcp:cleanup is not an option but a requirement and should run at least hourly. Without the command, the authorization codes table grows indefinitely, session and task directories fill up, and revoked or expired tokens remain in tx_aisuite_oauth_tokens. For setup via scheduler or cron, see CLI Commands.