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_document requires the delete right, moves a page to the recycle bin, and refuses outright on a wiki without a recycle bin. It never deletes recursively: a space home with child pages is refused. All translations of the page go with it.
- delete_attachment requires the edit right, not delete (the platform maps attachment deletion to edit), and refuses on a wiki without an attachment recycle bin. The attachment, with its own version history, goes to that bin.
- delete_object removes 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_schema creates or changes an XClass definition. The change applies to every existing object of the class, which makes it the most structural write in the set.
delete_document, delete_attachment, write_attachment, write_schema and the object tools also refuse documents that define access rights or configuration: WebPreferences, XWikiPreferences, the main wiki's wiki descriptors and the MCP server configuration page. Content a write accepts is capped at 1,000,000 characters, for pages and attachments alike, so one call cannot persist an arbitrarily large version.
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 |
| Withhold the delete right where the use case does not need it | Removes the page and attachment deletion surface |
| 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_document requires base_version for 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_document uses 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.
- The sensitive-document denylist refuses the destructive tools on rights and configuration pages, and the recycle-bin and children checks above run before anything is deleted.
