Somewhere in the last twelve months the agentic CMS stopped being a pitch and became the default. Sanity, Storyblok and Strapi have all shipped agent capability, and the pattern extends across the category. The marketing for all of it sounds identical, which makes it easy to conclude nothing here needs a decision. That conclusion is wrong, and the reason is narrower than the marketing suggests: these products differ enormously in whose permissions govern the agent once it starts writing. This piece covers what actually shipped, why write access is the only part that matters, the two models the industry has split into, what Strapi got right, what the documentation does not say, and the questions to ask before you turn any of it on.
Read agents were never the interesting part
The first generation of CMS AI was assistive and safe by construction. It suggested a title, drafted alt text, translated a field, summarized an article. A human took the output and decided whether it became content. Whatever it got wrong, a person was standing between the model and the published page.
That property is gone. The current generation writes. Sanity’s Agent Actions "let you programmatically run schema-aware AI instructions to create and modify Sanity documents," and they run from Functions, webhooks and CI pipelines, which is to say from places where no human is present at the moment of execution. Strapi’s MCP server exposes create, update, delete, publish, unpublish and discard-draft as agent-callable tools.
Once an agent can publish without a person in the loop, every question about output quality becomes secondary to a question about authority. Not what can it write, but what is it allowed to write, and who decided.
What Sanity actually ships
Sanity’s Agent Actions break into five operations, and the split between them is instructive.
Generate creates content, and it runs in what the documentation calls mixed mode by default: it "sets non-array fields, overwriting any existing value, and appends new items to arrays." Overwriting by default is a meaningful choice. Transform edits existing documents only and "does not create new fields or add new items to arrays." Translate is a specialized Transform. Prompt sends a request to a model without touching the document. Patch makes schema-aware changes with no model involved at all.
So two of five mutate content directly, one of them overwriting existing field values unless configured otherwise. The introduction documentation does not describe a dry-run or preview mode, and it does not address which identity the action assumes or how permissions apply to it. That may well be documented elsewhere in the reference. It is not where someone deciding whether to enable this would look first, and defaults that overwrite deserve to be adjacent to the permissions discussion rather than a section away from it.
What Strapi got right
Strapi’s answer is the clearest one in the category, and it is worth describing precisely because it is a model other platforms could copy.
The MCP server shipped in v5.47.0 in May 2026, free on self-hosted instances. It exposes up to eight tools for collection types and six for single types. And the authorization design is the part to notice: it uses admin tokens, and per Strapi’s own description, "the token’s permissions determine exactly which content types, fields, and operations the agent can reach."
The consequence is that the tool surface itself changes with the token. A read-only token exposes only listing and reading tools. A full-access token exposes the complete CRUD and publish surface. The agent cannot attempt an action it lacks permission for, because that action is not presented to it.
This is the pattern we argued for in CMS and MCP agent permissions: the agent should not become a new principal with its own rights, it should act through a permission system that already exists and already has answers. Strapi did not invent a parallel authorization model for agents. It pointed the agent at the one the CMS already had.
The agentic CMS label hides how much is now shared
One reason these products sound alike is that underneath, a growing number of them are alike. Strapi and Storyblok both expose their content through Model Context Protocol servers, which means the transport, the tool-description format and the client compatibility are no longer differentiators. An agent that can drive one MCP-exposed CMS can drive another with almost no work.
That is genuinely good for buyers, and it has a side effect worth naming. When the protocol layer converges, vendors compete on the layer above it, and the layer above it is exactly the authorization design this post is about. So the thing that now distinguishes these products is the thing none of them lead with in marketing, because "our agent inherits your role permissions" is a harder sentence to sell than "AI that manages your content."
The label agentic CMS describes a capability every platform has. It says nothing about the part that differs.
The two models, and why the difference is not cosmetic
Across the platforms that have shipped this, the designs fall into two shapes.
In the inherited model, the agent operates under an existing identity with existing permissions, and its capabilities are a projection of that identity. Revoking access is a thing you already know how to do. Auditing is a thing your existing logs already capture. The blast radius of a misbehaving agent is bounded by a boundary you drew for other reasons and probably tested.
In the parallel model, the agent is a new kind of actor with its own credential and its own capability surface, sitting beside the human permission system rather than inside it. This is faster to build and it is where a platform naturally lands when agents are added to a product whose permission model was designed for people clicking buttons. It is also how you end up with an agent that can publish something no editor on your team is allowed to publish.
Neither is inherently wrong. The parallel model is defensible when the agent genuinely needs capabilities no human role has. What is not defensible is not knowing which one you have bought, and the marketing language is close to useless for telling them apart, because both describe themselves as governed, secure and enterprise ready.
What the documentation does not tell you
Three questions are answered inconsistently across the category, and all three matter more than the feature lists.
The first is identity. When the agent writes, whose name is on the revision? If the answer is a generic service account, your version history stops being an audit trail at exactly the point where you would want one.
The second is reversibility. Publishing is a state change with an audience. A draft written badly is a nuisance; a publish action taken wrongly is a live page. Whether the agent’s publish is distinguishable from a human’s, and whether it can be rolled back as a unit, is rarely stated.
The third is scope at the field level. Content models have fields that are safe for an agent to touch and fields that absolutely are not: canonical URLs, redirects, schema markup, anything feeding a downstream system. Strapi’s token model reaches fields explicitly. Most descriptions stop at content types.
We looked at the standards side of this in the CMS agent governance standard, and at the protocol side in headless CMS MCP standardization. The gap this post is pointing at sits between them: the protocol is increasingly settled, and what the protocol is permitted to do on your data is not.
What to ask before enabling any of it
Ask which identity the agent writes as, and go look at a revision it created rather than accepting the answer.
Ask whether the tool surface is derived from permissions or configured separately. Strapi’s behavior, where a read-only token simply does not surface write tools, is the test to apply. If an agent can attempt an action and be refused, that is a different and weaker design than one where the action was never available.
Ask what happens on overwrite. Sanity’s Generate defaults to overwriting non-array fields. That is a reasonable default for a generation tool and a dangerous one for an unattended pipeline, and the difference is entirely in how you invoke it.
Ask whether publish is separable from write. Many teams would happily let an agent draft continuously and never publish. That is only available if the platform treats them as distinct permissions, which most do, and only useful if your token actually reflects that split.
Then start with the narrowest token that does the job, on a content type you would not mind seeing broken, and widen from there. This is unfashionable advice and it is the only kind that survives contact with an agent that has a bad afternoon.
Frequently Asked Questions
What is an agentic CMS?
It is the current label for a content platform whose AI features can take actions on content rather than only suggest them: creating, updating, publishing and unpublishing entries programmatically, often invoked from pipelines or webhooks rather than by a person clicking. The distinguishing feature versus earlier CMS AI is write access without a human necessarily in the loop.
Which platforms have shipped agent capability?
Verified directly from vendor documentation for this piece: Sanity, with Agent Actions and Content Agent; Strapi, with an MCP server in v5.47.0; and Storyblok, which publishes both an MCP server and an agentic experiences product. Other platforms in the category have made similar announcements, but this post names only what was checked against the vendor’s own material, because the comparison content circulating on this subject is largely unverified.
What can Sanity’s Agent Actions actually do?
Five operations. Generate creates content and by default overwrites non-array fields while appending to arrays. Transform edits existing documents without adding fields or array items. Translate is a Transform variant for localization. Prompt queries a model without modifying anything. Patch makes schema-aware changes with no model involved. Generate and Transform are the two that mutate documents.
How does Strapi handle agent permissions?
Through admin tokens, where the token’s permissions determine which content types, fields and operations the agent can reach. The tool surface itself narrows accordingly: a read-only token exposes only listing and reading tools, while a full-access token exposes the full CRUD and publish set. The agent inherits the existing role model rather than getting a parallel one.
Is agent write access actually risky?
It depends entirely on scoping, which is the point. An agent restricted to drafting on one content type is a low-consequence tool. An agent holding a broad token that can publish anything is a single misconfiguration away from a live mistake, and unlike a human operator it will make that mistake at machine speed and repeatedly.
What is the single most useful question to ask a vendor?
Whether the agent’s available tools are derived from an identity’s permissions or configured independently of them. Everything else follows from the answer, including auditability, revocation and blast radius.
Should agents be allowed to publish at all?
Many teams will decide no, and most platforms make that enforceable because publish is usually a separate permission from write. Letting an agent draft continuously while reserving publication for a person keeps the throughput benefit and removes the category of failure that has an audience.
Does open source do this better?
Not by nature, but Strapi’s implementation is the clearest of the ones checked here, and being self-hosted means the token model, the audit log and the failure modes are all inspectable rather than described. That is an advantage of the deployment model rather than of the license, and it matters most when you want to verify a claim instead of accepting it.
