Five gates between an AI assistant and your content
Giving an AI assistant write access to your content platform sounds like a risk. With most integrations it is one: a technical user, an API key with full access, and a second permission system nobody keeps in sync with the first.
The Sulu MCP Bundle takes the opposite approach. It adds no permission model of its own. An agent connected to Sulu works as the person who logged in, with exactly the rights that person has in the admin interface.
This is part 3 of our series on the Sulu MCP Bundle. Part 2 showed how to connect claude.ai, ChatGPT, Claude Code, Codex, and Mistral Vibe. This one walks through the five gates a request passes before anything changes in your content.
Prerequisites
- A Sulu 3.0 project with the MCP Bundle 1.0.0-RC4 or later
- At least one assistant connected (see part 2)
Gate 1: A person logs in and says yes
There is no MCP user and no API key. When an assistant connects, Sulu opens its normal admin login, then a consent page that names the client and what it asks for. A token exists only after a person approves.
From then on, every request runs as that user. Revoke the user's access in the admin interface, and the assistant loses it too. This means the question "what can the agent do?" has the same answer as "what can this editor do?", and you already manage that answer in Sulu's roles.
Gate 2: Know which client is asking
The consent page shows the client's name together with the host it came from. Assistants from claude.ai and chatgpt.com are shown as they are. Every other one is marked not verified, because anyone can publish a document that calls itself "Claude".
You also decide how clients may register. Client ID Metadata Documents and Dynamic Client Registration each have their own switch. Turn off one, or both, and only clients you create by hand with sulu:mcp:create-client can connect.
Gate 3: The token covers the request
All MCP traffic goes through one endpoint, so a valid token alone says little about what a request wants. Sulu checks the scopes on every request: calling a tool needs the mcp:tools scope, reading a resource needs the mcp:resources scope. Without that check, any valid token could call tools with the user's full rights.
Gate 4: The editor may do it
Every tool declares the Sulu permission it needs, and Sulu checks it before the tool runs.
- Tools a user can't use are hidden. The assistant never learns they exist.
- The checks follow Sulu's own rules. Deleting content requires the delete permission in every locale of that content, not just the current one.
What this means for you: give the editor who connects an assistant the role you would give them anyway. If a shared workspace needs one identity, create a dedicated Sulu user with a narrow role instead of reusing an admin.
Gate 5: Risky tools don't exist until you want them
Deleting, publishing, removing blocks, and uploading media from a URL are disabled by default. Moving and reordering pages count as publishing. A disabled group is not just hidden: its tools are removed entirely, so no assistant can call them.
Turn on only what fits the environment. For an editorial workflow where the agent may publish but not delete:
# config/packages/sulu_mcp.yaml
sulu_mcp:
dangerous_tools:
publish: trueLeave everything at the defaults for read-only or staging setups: agents prepare drafts, and publishing stays a human decision. The full list of groups and tools is in the configuration guide.
Bonus: Assistants know what a tool does
Every tool tells the assistant whether it only reads, changes, or deletes. Assistants that ask before risky actions use this to decide when to ask.
The five gates above are the security boundary. This is a courtesy: one more prompt in front of the person at the keyboard.
Tips
- Start read-only. Turn on publishing once your team trusts the drafts. Turn on deleting last, if at all.
- Read the consent page like a login prompt. "Not verified" means the name is whatever the client's owner wrote.
- Test with a real editor account. An admin sees every tool. Your editors won't.
What's next
Five gates, all built on what Sulu already knows about your users. Every action remains subject to Sulu's permissions, and high-risk operations such as publishing and deleting stay disabled until you explicitly enable them.
The bundle is MIT licensed and built as a standard Symfony bundle, so you can read every one of these checks in the source. How we made gate 2 safe, fetching a URL someone else chose, is a story of its own: Fetching a stranger's URL safely.
Questions or a gap we missed? Tell us in GitHub Discussions or in the Sulu Slack.
