Agent governance is the question every CMS vendor is now answering in prose and almost none is answering in code. The claim I set out to test: no content management system meets a credible standard for agent governance, and Drupal has published the sharpest articulation of the problem in the CMS space. After reading the primary sources rather than the coverage, the first half holds comfortably. The second half holds too, but not in the post most people are citing, and emphatically not in the words most people are quoting.
What a credible standard would actually have to enforce
An agent that can change a production site needs three things to be governable, and each has to be enforced by the platform rather than recommended in a blog post. Scoped identity: the caller is a principal with a bounded set of grants, not a shared admin key. A declared action surface: the operations an agent can attempt are discoverable and typed, so "what can this thing do to my site" has an answer you can read. An independent record: a durable trace of what was attempted, by which agent, under whose authority, and whether a human signed it off.
The distinction that matters throughout is enforcement versus description. A platform enforces something when a request that violates it fails with a status code. It describes something when a documentation page says you should not do it. Almost all of the current CMS governance story sits in the second category.
The sharpest statement of the problem is in a post most coverage skipped
Drupal did publish the strongest articulation. It is not the widely shared July 31, 2026 initiative post, whose governance section resolves to "We build trust directly into the architecture through branch-based content versioning, strict governance workflows, and deep audit trails." That post lists Fully Autonomous Agents under "Coming Soon", still being refined in sandbox environments.
The sharp document is "Outside AI: The State of Agent Experience in Drupal", published July 23, 2026 by Scott Falconer, Product Lead for Outside AI. It walks five stages, from starting and connecting, through acting through governed interfaces, to rebuilding and migrating, and it is unusually honest about identity: "An agent can act as a delegate, carrying a scoped slice of the authority of the person it works for."
Two lines beat anything else I found in CMS vendor writing. On volume: "Human review alone does not survive that volume." On self-reporting: "The agent’s own summary should not be held as proof". And Falconer concedes the actual gap: "What is missing is declaration, not governance."
The agent governance phrase everyone quotes is not Drupal’s
The formulation circulating as Drupal’s own standard, that assisted changes must remain "permission-aware, repeatable, and independently reviewable", is not Drupal’s wording. It appears in TheDropTimes coverage dated July 27, 2026, unquoted, as a staff reporter’s summary of two initiative posts.
Attributing a trade outlet’s paraphrase to a project gives the project credit for a rigor it did not publish. And the paraphrase is genuinely good, arguably a tighter three-part test for agent governance than the vendor prose it summarizes. A reporter wrote the crispest one-line definition, and Falconer the crispest diagnosis. Neither is a standard, and neither is enforced by shipping code.
What WordPress actually enforces today
WordPress is further along on enforcement than its public narrative suggests, because the Abilities API turned a soft convention into a required argument. In wp_register_ability(), added in 6.9.0 in wp-includes/abilities-api.php, permission_callback is a required member of the $args array alongside label, description, category and execute_callback. You cannot register an ability without declaring who may run it. That enforces the shape of a check, not its correctness: a callback returning true unconditionally satisfies the API perfectly.
Exposure is conservative by default. Per the Abilities REST documentation, registered abilities are not exposed via REST by default, all endpoints under the wp-abilities/v1 namespace require an authenticated user, and a caller who fails the permission callback gets ability_invalid_permissions with status 403. The core abilities merge proposal of July 2, 2026 keeps the first batch narrow: read-settings, read-content and read-users, where "The proposed abilities are read-only and carry read-only annotations", with management abilities deferred. Our write-up of the WordPress Abilities API covers registration in more depth.
The record is the missing leg. Abilities API improvements in WordPress 7.1, published July 31, 2026 by Milana Cap, adds a wp_ability_invoked action at the beginning of WP_Ability::execute(), described as suitable for "auditing, telemetry, tracing, and invocation accounting". That is a hook, not a log. Core fires the event; somebody else stores it and makes it reviewable.
What Drupal actually enforces today
Drupal’s enforcement lives in a contributed module rather than in the initiative posts. The MCP Server module, at 2.0.0-beta1 released July 29, 2026, implements Simple OAuth 2.1 with two authentication modes per tool: Required, where a bearer token carrying the specified scopes is mandatory, returning HTTP 401 without authentication and HTTP 403 with insufficient scopes, and Disabled, documented as suitable only for public read-only tools. Because tools are managed through Drupal’s configuration system, the permission surface is exportable and reviewable like any other config, a structural advantage we noted when surveying CMS agent permissions across platforms.
The aspiration lives elsewhere. The Drupal AI initiative 2026 roadmap is explicit that "This document serves as an internal product strategy for 2026. It may be shared publicly, but it’s not a marketing document." Its background agents capability states that "Agents propose changes; humans approve them" and that every proposed change can be rolled back individually. Its governance capability asks contributors to "Record every AI action, decision, and approval with full logging or observability", and sensibly proposes shipping high-volume logs to external platforms rather than Drupal’s database. Those are goals in a strategy document, not a shipped enforcement layer, and the AI Agents module, at 1.3.3 on August 5, 2026, does not document approval gating or action logging on its project page.
Two headless platforms enforce more than they advertise
The platforms making the least noise about agent governance are enforcing the most at runtime. Strapi’s built-in MCP server, available from version 5.47.0, is disabled by default. Once on, "Each MCP session is scoped to the permissions of the token used to connect", and enforcement is layered: tool visibility based on token access, field filtering that narrows the input and output schemas themselves, locale filtering, and runtime enforcement on specific documents. Schema narrowing beats a permission check, because the agent never sees fields it may not touch. What the documentation does not describe is any link between MCP activity and Strapi’s separate audit logs feature.
Sanity’s MCP server uses OAuth by default rather than a pasted token, and where tokens are used, "Tool calls will use the API token in accordance with its role and scoped to its permissions." Its personal tokens do something the others do not: they "share your role and permissions, as well as link you to any changes in the revision history", producing attribution as a side effect of the content model. The tool list includes publish_documents, unpublish_documents and deploy_schema, with no dry-run or approval step described before any of them.
The protocol layer is not going to supply the missing piece
If you were waiting for the transport to standardize agent governance, the Model Context Protocol 2026-07-28 revision settles it. It removes protocol-level sessions and the Mcp-Session-Id header, removes the initialize handshake, and adds a mandatory server/discover RPC. It tightens authorization at the edges, requiring clients to validate a present iss parameter per RFC 9207 and keying persisted credentials by issuer, and it deprecates OAuth 2.0 Dynamic Client Registration in favor of Client ID Metadata Documents.
What it does not add is any governance primitive. There are no permission scopes attached to tools in the specification. There is no audit record. The revision deprecates the Roots, Sampling and Logging features, which stay functional during the deprecation window, and suggests stderr or OpenTelemetry in place of Logging. A protocol that has just deprecated its own logging feature is not the layer that will make agent actions independently reviewable, which pushes the entire burden back onto the CMS, as we found when tracing the WordPress 7.1 AI client.
So the roadmap claim survives, with one amendment. No CMS enforces scoped identity, a declared action surface and an independent record together. WordPress requires the check and gives you a hook instead of a record. Drupal enforces per-tool scopes in a beta module while its clearest thinking remains a status report. Strapi quietly enforces the most and says the least. The sharpest articulation of agent governance really is Drupal’s, but it belongs to Falconer’s July 23 post, not to the phrase a trade outlet wrote about it. What returns a 403 is checkable today. Who reviewed the change is not, and on every platform here that answer still rests on somebody’s own logging stack and their own credential hygiene.
Frequently Asked Questions
Did Drupal say agent changes must be “permission-aware, repeatable, and independently reviewable”?
No. That phrasing appears as unquoted summary prose in TheDropTimes coverage dated July 27, 2026, written by a staff reporter. No named Drupal contributor is quoted using it. It is a good three-part test, but it belongs to the outlet, not the project.
Which CMS currently comes closest to enforcing agent governance?
On runtime enforcement specifically, Strapi. Its MCP server is off by default, each session is scoped to the connecting token’s permissions, and field filtering narrows the input and output schemas themselves rather than only rejecting unauthorized calls.
Is permission_callback optional in the WordPress Abilities API?
No. The wp_register_ability() reference lists permission_callback as a required member of the $args array, added in 6.9.0. The API enforces that a check exists. It cannot enforce that the check is meaningful, so a callback returning true unconditionally is still valid registration.
Does WordPress log what an agent did?
Not on its own. WordPress 7.1 added a wp_ability_invoked action at the start of WP_Ability::execute(), described as suitable for auditing, telemetry, tracing and invocation accounting. That is an event you can subscribe to. Storing and reviewing those events is left to a plugin or an external observability stack.
What does Drupal’s MCP Server module actually enforce?
Per-tool OAuth scopes. Version 2.0.0-beta1, released July 29, 2026, offers two authentication modes per tool. Required means a bearer token with the specified scopes is mandatory, returning 401 without authentication and 403 when scopes are insufficient. Disabled means no checks, and the module documents it as appropriate only for public read-only tools.
Does the Model Context Protocol define permissions or audit logging?
No. The 2026-07-28 revision attaches no permission scopes to tools and defines no audit record. It deprecates the Roots, Sampling and Logging features, suggesting stderr or OpenTelemetry instead of Logging. Its authorization work concerns client registration and issuer validation, not what an agent may do once connected.
Are agents already publishing content without human approval?
They can be, depending on configuration. Strapi’s MCP tools include publish and unpublish operations, and Sanity’s include publish_documents and deploy_schema, with no dry-run or approval step described in either set of docs. Drupal’s 2026 roadmap states the intended model as agents proposing and humans approving, but that is a goal in a strategy document rather than a shipped default.
What should I check before letting an agent into a production site?
Three things, in order. Whether it authenticates as its own scoped principal rather than reusing an admin key. Whether the operations it can attempt are declared and narrow, ideally read-only to start. And where the record of its actions is written and who reads it. If that last answer is a hook you have not wired up, the agent should not have write access.
