The Agent Has Write Access: Governing SitecoreAI When Software Authors Your Content

The Marketer MCP and Agent API turn your content tree into a set of tools an agent can call, in production, in business-level verbs. The plumbing is real and the guardrails are more thoughtful than most of the market's. The governance model for a non-human author is not finished, and the unfinished part sits at seams the vendor cannot close for you.

I have written twice already about software reading your content. The first non-human consumer was the retrieval agent that reads your pages on a buyer's behalf. The projections piece was about representations of your content that resolve outside your control, that you cannot enumerate or correct. Both were about the read side. This is the write side, and it is a different kind of problem, because now the software is not reading your content. It is authoring it.

The Agent API and the Marketer MCP together mean that an LLM client, Claude Desktop, Cursor, Copilot Studio, can create a page, add a component, or create a personalization variant in SitecoreAI through a natural-language prompt. Not by driving the editor UI, and not through a research spike on a sandbox. Through a REST call, in business-level verbs, in your production environment. That last part is where the governance question starts. An agent writing straight to production is a different animal from a feature you switch on.

What Sitecore actually shipped

Give Sitecore its due first, because the design is not naive. The Agent API exposes the platform as outcome-shaped actions rather than raw item operations. A create_page verb, an add_component_on_page verb, a create_personalization_version verb, each mapping to a business result instead of a sequence of low-level writes. The Marketer MCP sits in front of that, translating a prompt into the right tool call, and it speaks the Model Context Protocol, so any MCP-capable client can drive it.

The guardrails are real and worth naming, and they differ by how the agent connects. On the interactive path, the one this article follows, the Marketer MCP signs the marketer in through Sitecore Identity with an authorization code flow, so the agent acts as that person, bounded by their Sitecore role, with tenant isolation and short-lived tokens. On the direct path, a server calling the Agent API with no human present, authentication is an automation client credential, and the token comes back scoped for the job. Either way, every operation is recorded as a job, and if the agent does something you did not want, you revert the job by its ID. Actions pass through the same built-in security and approval rules the rest of the platform already enforces, and the whole surface carries structured logging and audit. Someone thought hard about reversibility and identity before shipping this, which is more than the broader agent-tooling market can say.

So the honest starting position is that Sitecore built a careful front door. The question this article is about is what happens on the other side of it, in the places the front door does not reach.

Trace one call

Follow a single action end to end, because the abstraction hides most of what matters.

A marketer types "create a French variant of the hero on the homepage and target returning visitors" into their AI assistant. The MCP server, which the marketer authorized by signing in through Sitecore Identity, interprets that, selects create_personalization_version, and calls the Agent API. In SitecoreAI, that one business verb expands into several item writes: a variant definition, a rule against a returning-visitor audience, a bound rendering, possibly a datasource. The writes are attributed to the marketer and bounded by their Sitecore role, and the platform records the whole thing as one job with an ID. The variant is live, in production, resolvable by the next matching visitor.

Now count what you can and cannot see from inside Sitecore. You can see that the marketer, signed in through Sitecore Identity, created a personalization version, and you can revert that job. What you cannot see, from Sitecore's logs alone, is the prompt that produced it, or the model's decision to turn "target returning visitors" into that specific audience rule. The audit answers who acted and what changed. It does not answer what they actually asked for, or whether the model did more than they meant, because that intent-to-action step lived in the MCP client, one layer out, on the other side of a boundary Sitecore does not own. On the direct path the gap is wider still: a server-to-server automation authenticates as an automation client, not a person, so even the who is gone.

Blog post image — On the interactive path the action is attributed to the marketer who signed in, so Sitecore knows who acted and can revert the job. What sits outside the audit is left of the dashed line: the prompt, and the model's decision to turn it into these specific writes. You can see what happened and who did it, not what they asked for or whether the model exceeded it.

Where the governance model actually lives

The front door is well built. The governance model sits behind it, at four seams, and none of them closes by default.

Scope is the real control surface, and how coarse it is depends on the path. On the interactive path the agent inherits the signed-in marketer's Sitecore role, which is exactly as fine-grained as your role model already is. That is the better case, and it is the one most marketers will use. On the automation path, the one you reach for when an agent runs unattended, the credential is an automation client, and the Agent API's own auth example issues it a token scoped xmcloud.cm:admin, a broad CM admin scope preset by credential type. So an unattended agent tends to run with far more reach than its task needs, because the coarse credential types make a genuinely least-privilege automation hard to provision at all. The blast radius is the scope you settled for, and it is tempting to under-think it because the happy path works either way.

Provenance is partial, and where it breaks depends on the path. On the interactive path Sitecore records the action under the signed-in marketer, so you know who acted. What it does not record is the prompt, or the model's decision to turn that prompt into this set of writes. For a change that later reads as wrong, or off-brand, or simply disputed, the audit gives you the marketer's identity but not what they asked for, and not whether the model exceeded the ask. On the automation path it is worse: the action is attributed to a broad automation client and the human who triggered it sits entirely outside Sitecore. Either way you can reconstruct the change. Reconstructing the intent means going to the MCP client's history, which the platform does not own.

Reversibility degrades with composition and time. Job rollback is clean for one isolated job. It is much less clean once an agent has chained several jobs, each building on the last, or once the content has published, reached Experience Edge, and been served and cached. Revert is a reactive primitive, an undo. An undo that has to unwind a chain, or reach past a publish, is not the same guarantee as an undo of a single fresh operation, and treating it as one is how a safety net becomes a false sense of security.

The agent inherits your workflow, for better and for worse. Actions pass through the built-in approval rules, which sounds reassuring until you remember that the guardrail is only as strong as the workflow you actually run. Estates that thinned their content workflow for speed, or route around it for urgent changes, have just handed that same thin path to something operating at machine speed and volume. The approval gate is real only where you built one.

Build the gate, and know what it covers

Here is the part where you stop waiting for Sitecore to centralize governance and build the half of it that lives where you can see it. Sitecore Studio gives you exactly the tools for this. The Marketplace SDK lets an app interact with the platform, the ai package exposes the AI skills APIs, Blok gives you a native look without custom design work, and the extension points let the app live inside the authoring surface rather than beside it. You host it yourself, which is a constraint but also means the governance logic is yours, not the platform's.

The worked example is the one I keep coming back to, a Content Compliance Copilot. It is a Marketplace app at a Page builder extension point. When an agent, or a person, proposes content, the app calls ai.skills.generateBrandReview to evaluate the proposed text and assets against the brand kit, records who proposed it and what the agent suggested, and holds the change behind a human approval step before it commits. The pattern reads cleanly: propose, evaluate against the brand kit, capture provenance, approve, commit. The governance layer becomes an app you own, native to the surface, built entirely on extensibility Sitecore already ships. Brand Review is a real, shipped AI skill for exactly this, LLM-powered evaluation grounded in your brand kit, so none of this is speculative.

And now the nuance that separates an honest version of this piece from a naive one. That app governs the in-surface path. It sits in the authoring UI, so it governs authoring that flows through the authoring UI. It does not intercept an Agent API call fired from an external MCP client, a marketer prompting Claude Desktop, that never touches your app at all. That path is still governed only by the scopes the credential holds, the workflow the action inherits, and job rollback after the fact. So the Content Compliance Copilot covers the in-surface half of a two-surface problem, and the entire value of building it well is knowing exactly which half that is. A Marketplace app presented as full agent governance would be selling the same illusion this article exists to puncture.

Where I would not overstate this

Two caveats, because the argument cuts in a direction that invites overreaction.

This is not a case against agent authoring. The productivity is real, the verbs map to genuine work, and Sitecore's guardrails are ahead of most of the market. I would rather have OAuth-scoped, job-reversible, workflow-anchored agent writes than the alternative most platforms offer, which is a raw API and good luck. The point is narrower and entirely about the last mile: the platform gives you a well-built front door and the materials to build the rooms, and the governance model is the part you assemble yourself.

And several of the sharper worries here are properties of the agent pattern industry-wide, not Sitecore-specific failings. Provenance that stops short of the prompt, reversibility that frays under composition, these are true of nearly every system exposing tools to an LLM right now. Sitecore is further along than most for even having job-level rollback and an approval-aware action layer. None of this is an accusation. The seams map the work that stays yours whatever platform you run.

The bottom line

The plumbing shipped, and it is good plumbing. The governance did not ship, because it cannot: the seams that decide it, scope granularity, cross-boundary provenance, reversibility under real conditions, and the strength of the workflow an agent inherits, are seams the vendor does not own on your behalf. What Sitecore can do, it did. It built the door and handed you the toolkit to build the gate. Whether the gate gets built, and whether anyone is honest about which door it stands in, is the architecture's job now.

Two questions worth taking back to your own tenant. What scopes does your automation credential actually hold, as opposed to the ones the task needed. And does anything in your estate treat an agent-authored item differently from a human-authored one before it reaches production. If the answer to the second is no, you do not yet have agent governance. You have agent access, which is a different thing wearing the same name.

What's next

The build is the piece I want to write next: standing up the Content Compliance Copilot as a real Marketplace app, the Brand Review call, the provenance capture, and the approval gate, with the parts that are harder than the walkthrough makes them look. If you have already put a governed layer in front of agent writes on SitecoreAI, especially if you found a way to narrow the scope story or to carry prompt-level provenance across the MCP boundary, I would be interested to compare notes.