CMS agent permissions became a real operational question in the last week of July 2026, because the plumbing that makes them necessary finally stabilised. The Model Context Protocol reached its 2026-07-28 specification, and Drupal’s contributed MCP Server module moved to beta the following day, joining shipped MCP servers from Strapi and Payload. The result is that a coding agent can now create, edit and publish content in production systems through a standard interface.
Most coverage of this has been about capability. The more useful question is the boring one, and it is where CMS agent permissions stop being an abstraction: when an agent can publish, what is the permission model, what is the audit trail, and who reviews the change before it goes live?
Why this became real in one week
Three things had to be true before agent-driven content management was more than a demo, and all three landed at once.
The protocol had to be deployable. The 2026-07-28 MCP specification is the largest revision since launch: it moves the protocol core to a stateless architecture, removing the initialize handshake and the session header so a remote server can sit behind an ordinary round-robin load balancer instead of requiring sticky sessions and a shared session store. It adds a mandatory discovery call, cacheable tool lists, and a formal extensions framework.
The authorisation story had to be enterprise-shaped. The same revision aligns MCP servers with OAuth 2.1 resource server patterns, which means a server can connect to an identity provider like Entra or Okta without custom glue. The change most likely to affect a CMS integration is easy to miss: Dynamic Client Registration is now deprecated in favour of Client ID Metadata Documents, so anything built against DCR needs a migration path.
And the platforms had to ship. Drupal’s MCP Server module reached 2.0.0-beta1 on 29 July, following its 2.0.0-alpha1 on 11 June. Strapi’s built-in MCP server ships from v5.47.0. Payload ships one too. Beyond the platforms exposing MCP directly, the positioning has shifted across the tier: Sanity now describes itself as a content operating system for the AI era, and Webflow frames itself in agentic marketing terms rather than as a visual site builder. Salesforce’s agreed acquisition of Contentful in early June points the same direction. Those last three are repositioning rather than a shipped agent interface, and the distinction is worth holding onto when a vendor’s language runs ahead of its API.
Stateless plus OAuth 2.1 is what turns "an agent can call your CMS" from a prototype into something an infrastructure team will actually approve.
CMS agent permissions are genuinely different per platform
This is where the platforms diverge, and it is the part worth comparing before you choose.
Drupal draws the boundary per tool. The MCP Server module implements OAuth 2.1 with per-tool scopes. Each tool configuration has two authentication modes: Required, meaning an OAuth 2.0 bearer token carrying the specified scopes is mandatory, or Disabled, intended only for public read-only tools. A request without authentication gets HTTP 401; a request with a token lacking sufficient scope gets HTTP 403. Tools are managed through Drupal’s configuration system, which means the permission surface is version-controlled and reviewable like any other config, a consequence of the architecture we cover in our introduction to Drupal. The module is built on the official modelcontextprotocol/php-sdk, a collaboration between the PHP Foundation and the Symfony project, and discovers tools through Drupal’s Tool API.
Strapi draws it at the token. The MCP server is opt-in and off by default: server.mcp.enabled is false until you turn it on. Once enabled, it automatically exposes a set of CRUD tools per content type, including find, create, update, publish and unpublish, authenticated with an admin API token. Architecturally it is stateless in a specific and useful way: each POST to the /mcp endpoint spins a fresh ephemeral server instance scoped to that token’s permissions, with no session persistence between requests.
Those are different philosophies. Drupal lets you say "this agent may read taxonomy but not create nodes" at the level of the individual tool. Strapi gives you a global switch plus whatever the admin token can do, which is coarser but considerably simpler to reason about, and the ephemeral-instance design means a compromised session cannot persist.
Neither is wrong. They are different bets about where the complexity of CMS agent permissions should live, and the right answer depends on whether your risk sits in over-broad access or in misconfigured fine-grained rules.
The word to look for is "publish"
Here is the detail that should shape how you evaluate any of these, and it is not what the marketing leads with.
Strapi’s automatically exposed tool set includes publish and unpublish. That is not content drafting. That is production state change, executed by an agent, through an API. The equivalent question applies to every platform in this category.
So the useful evaluation question is not "can an agent edit content," which is now broadly yes. It is:
- Can the agent’s credential publish, or only draft?
- Is there a review step between agent output and live content, or does the platform treat an agent write like any other authenticated write?
- Does the audit log distinguish an agent-originated change from a human one, or does everything appear under one service account?
That third question is the one most likely to bite. If agent writes land under a single admin token, your revision history tells you what changed but not which agent, running which prompt, made the change. That is a meaningfully worse forensic position than a human editor’s account gives you, and it matters most in exactly the situation where you need it.
Drupal is doing this in public, which is unusual
Whatever you make of Drupal’s market position, its AI programme is the most legible public effort in the CMS space right now. There is no single roadmap document, but there is a stated structure and a published cadence, which is more than the rest of the tier offers.
The AI Initiative set out two workstreams in June: Inside AI, which "brings AI tools into the Drupal interface to assist the people using it," and Outside AI, which "makes Drupal the platform external AI agents reach for and act on." Both explicitly place permissions, structured configuration and review workflows at the centre, and a follow-up post in July laid out the Outside AI stages in more detail, naming execution principal, OAuth behaviour and MCP scope enforcement directly. The AI Dashboard module maintains an ecosystem tracker, which as of its 24 July generation lists 209 modules and 34 recipes with a hard dependency on the AI module. That page regenerates in place, so the figure you see will differ from the one quoted here. Drupal 11.4, released 1 July, adds an experimental extensible dr command line interface as the technical foundation.
For context on how these platforms differ underneath, our explainer on what a content management system is covers the structural split that determines how much of this surface a given platform even has. The point is not that Drupal is winning. It is that permissions and review workflows are stated as first-class design concerns in public, with a published cadence. Most of the headless tier and effectively every visual site builder has said far less about the same questions, and the gap is worth noticing when you are the one who has to answer for what an agent published.
What to do before you enable any of this
Five things, in order.
Check the default. Strapi ships MCP disabled. Do not assume every platform does, and check after upgrades rather than once.
Give the agent its own credential. Not a shared admin token. If the platform supports per-tool scopes, use them; if it only supports token-level permissions, create a token that cannot publish.
Decide the review boundary explicitly. Draft-only with human publish is the conservative default and it is the right starting position for anything customer-facing. Moving to agent-publish should be a deliberate decision with a named owner, not something that happens because the tool allowed it.
Test what your audit trail actually records. Make an agent write a change, then look at the revision history and ask whether you could reconstruct what happened from it in six months.
Treat the MCP endpoint as production attack surface. It is authenticated, internet-reachable, and holds write access to your content. Our look at the WP2Shell WordPress flaw is a reminder that ordinary infrastructure with network reach is where real intrusions start, and our overview of the headless CMS landscape covers the architectural differences underneath these platforms.
Frequently Asked Questions
What are CMS agent permissions?
They are the controls determining what an AI agent can do inside your content management system when connected through a protocol like MCP. In practice this covers which content types the agent can read or write, whether it can change publication state, which credential it authenticates with, and whether a human reviews its output before it goes live.
What is MCP and why does it matter for a CMS?
The Model Context Protocol is a standard interface letting AI clients call tools on external systems. It matters for a CMS because it turns content operations into agent-callable tools. The 2026-07-28 specification made this deployable at scale by moving to a stateless core, so servers no longer need sticky sessions, and by positioning MCP servers as OAuth 2.1 resource servers.
Can an AI agent publish content without a human reviewing it?
On some platforms, yes. Strapi’s MCP server automatically exposes publish and unpublish tools per content type once enabled. Whether that is acceptable is a policy decision you make, not a technical limit the platform imposes. Draft-only access with human publish is the conservative default for anything customer-facing.
How do Drupal and Strapi differ on permissions?
Drupal implements OAuth 2.1 with per-tool scopes, so each tool is individually set to Required or Disabled and returns 401 without authentication or 403 with insufficient scope, with tool config managed through Drupal’s version-controlled configuration system. Strapi is opt-in globally, off by default, and scopes access to an admin API token, spinning an ephemeral server instance per request. Drupal is finer-grained; Strapi is simpler to reason about.
Is MCP secure enough for production content systems?
The 2026-07-28 specification substantially improved the authorisation story by aligning with OAuth 2.1 and OpenID Connect, which lets servers integrate with existing identity providers rather than relying on custom credential handling. That addresses authentication. It does not decide your permission scoping, your review workflow, or your audit trail, which remain your design decisions.
Will our audit log show which agent made a change?
Often not, and this is the most commonly missed problem. If agent writes authenticate through a single shared token, the revision history records what changed but not which agent or which prompt produced it. Test this before enabling agent writes: make a change, then try to reconstruct it from the audit trail alone.
Which CMS platforms currently ship MCP servers?
Drupal ships a contributed MCP Server module, at 2.0.0-beta1 as of 29 July 2026 after an alpha on 11 June. Strapi ships a built-in MCP server from v5.47.0. Payload ships an official MCP plugin. Sanity, Webflow and others have repositioned around agentic workflows without necessarily exposing the same interface, so check what a given platform actually implements rather than relying on its marketing language.
Should we enable MCP on our CMS at all?
Only with a specific use case and a decided review boundary. The capability is real and the protocol is now mature enough to deploy, but enabling write access for an agent without scoped credentials, a review step, and an audit trail that identifies agent-originated changes creates a governance problem before it creates value.
