Agent Authentication
Explanation
When you connect an AI assistant to the MCP server, the assistant authenticates as a real wiki user. Everything the assistant does, it does as that user, with that user's permissions. The assistant can read exactly what your user can read and edit exactly what your user can edit. There is no separate "AI permission" that adds power. The document history records your user as the author of any changes.
How the assistant comes to act as your user:
Guest access
Guest access is off by default. Where a wiki administrator allows it, an assistant that connects without signing in is served as the anonymous guest user: it can call the read tools, and it never receives a write tool, whatever the wiki enables. A request that carries credentials which fail to authenticate is still refused with a 401, so an expired token never silently falls back to guest.
Sign-in requirements
The browser sign-in above needs the XWiki OIDC Provider on the wiki; the administrator sets it up as part of Set Up MCP Authentication. Without it, there is no sign-in flow to follow: an unauthenticated caller gets a bare 401 unless the wiki allows guest access, and the client must send credentials itself, for example HTTP Basic where the wiki accepts it.
Practical consequences
- If your user can edit a space, the assistant can edit that space.
- Rights are the hard boundary. Configuration settings (tool enablement, space filters) can only narrow what the assistant can do below your rights, never widen it.
Cross-wiki reach
When cross-wiki reach is enabled, the assistant can access documents on other wikis in the farm. Access is still governed by the rights of the account the assistant acts as on those target wikis.
