Write Tools Risk
Explanation
Detailed explanation of the security implications of enabling the MCP server's write tools. Eight tools are write tools: edit_document, write_document, delete_document, write_attachment, delete_attachment, write_object, delete_object and write_schema.
Script execution risk
Content an agent saves has the user of the MCP Server as its content author. If that content contains {{groovy}} or {{velocity}} script macros, those macros execute with the MCP user's rights when the page is viewed.
This is not an MCP-specific vulnerability: it is XWiki's normal edit semantics. MCP widens who can trigger it: any content the agent ingests (a web page, a file, another wiki page) could carry a prompt injection that causes the agent to write a page containing a script macro.
Prompt injection amplification
The MCP server's design makes the agent read content from the wiki and from external sources, then potentially write that content back. A malicious actor who can place content the agent will read (by editing any page the agent searches, for example) can inject instructions into the agent's context that tell it to craft a page containing a script macro.
If the MCP user holds script rights, this is already a code-execution vector: {{velocity}} executes with that right alone, when any user views the page. {{groovy}} additionally requires programming rights. Admin and programming rights both imply script, so withholding those two is not enough on a wiki that grants script separately - and many do, to all registered users.
Destructive and structural operations
Script execution is not the only risk. The write set also lets an agent remove and restructure content:
delete_documentmoves a page to the recycle bin, from which an administrator can restore it.delete_attachmentmoves the attachment, with its own version history, to the attachment recycle bin, from where it can be restored. On a wiki with no attachment recycle bin the tool refuses the deletion rather than performing an unrecoverable one.delete_objectremoves one object from a page. It does not pass through any recycle bin; the object is recoverable only by reverting the page to an earlier revision.write_schemacreates or changes an XClass definition. Removing or retyping a field affects every existing object of that class, and undoing a page revision does not undo it.
The prompt-injection path above applies to these just as it does to script macros: content the agent reads can instruct it to delete or restructure rather than to write a script.
Mitigations
| Mitigation | Effectiveness |
|---|---|
Withhold script, programming and admin rights from the MCP user | Prevents script macro execution |
| Enable only the write tools the use case needs | Removes the delete and schema surface |
| Keep write tools off (default) | Eliminates the write surface unless explicitly needed |
| Use space filters to restrict agent edits | Contains agent writes to a controlled area |
Audit through [AI] history stamps | Enables detection and rollback |
| Run agents as a dedicated, scoped user | Limits potential damage to that user's rights |
Built-in protections
write_documentrequiresbase_versionfor overwrites: the agent must have read the page first and supply the version it read. Omitting it is refused without disclosing the current version, so an agent cannot overwrite a page it never opened; supplying a stale one is refused with a version conflict that does name the current version, so the agent can re-read and retry.edit_documentuses exact string matching for edits. If the page changed between reading and editing, the edit fails cleanly with "re-read and retry".- Every save is a single version in the history, stamped
[AI], allowing for easy version comparison.
