What safeguards should govern KentiCopilot changes to production content and content models?

We're evaluating how far to let KentiCopilot and MCP-driven workflows go beyond suggestions and into actual content or schema changes. The technical capability is moving quickly, but production write access raises governance questions that do not exist when the agent is read-only.

For teams using or planning to use KentiCopilot in production, what guardrails have worked well? I'm especially interested in separation between development, staging, and production; least-privilege access; required human approval for publishing or content-model changes; validation and rollback; and an audit trail that ties each action to the requester and instructions.

Do you allow any autonomous writes in production today? If so, which operations are permitted, and which changes always require an editor or developer to approve?

Tags:
AI Security KentiCopilot MCP

Answers

Accepted answer

Hey Mike!

Great question, and one we discuss internally a lot when designing new KentiCopilot features.

The short answer for today: no autonomous writes in production, because the Management API and Management MCP server are preview features intended for local development only. We call this out explicitly in our docs as well: Enable the management API

The management API authenticates with a single shared secret, with no authorization options for different operation types. There is no user identity in the request, so there is nothing to scope permissions against and nothing to attribute a change to. So on two of the things you asked about, least privilege and an audit trail tied to the requester, we're not there yet.

Some guardrails and safety nets already exist today:

  • No publish operation. The MCP can create, read, update, delete, move and unpublish content items and pages. It cannot publish. Going live still requires a person in the admin UI.

  • Tool filtering. You can restrict the exposed toolset, and we do offer some recommended combinations here. Worth flagging that this is client side config, so it shapes what the agent reaches for rather than preventing anything at the API.

  • Versioning as a rollback layer. With content versioning enabled, every API call that modifies versioned content creates its own version entry. Verbose after a bulk run, but each step is individually revertible.

  • CI as the review gate. CI serialization is automatically disabled during management MCP requests, so you run CI store manually afterwards. In practice that means an agent's schema changes go through your normal PR review before they reach any other environment.

On where this goes next. While I can't share a specific timeline right now, we're looking into supporting content modelling further with agentic tooling, and extending the MCP scope to cover Forms. For both, we asked the same two questions: what's the intended workflow, and how do we make it safe when some actions are destructive.

We are considering a few approaches, and we'd love your feedback:

  • Destructive actions become fully reversible, for example soft deletes only via the tool

  • Block destructive actions when content is affected, for example you can't delete a form that has submissions

  • Instructions in the tooling itself so agents have to seek approval

  • Checks at a more critical point, for example confirming destructive changes before content sync runs between environments

Two things complicate all of that.

First, we don't control how a developer runs their agent. In yolo mode, soft gates could get bypassed and based on Anthropic's findings, developers also often approve destructive actions when they're in the flow.

Second, there is an underlying API, and guardrails meant specifically for agents are not going to necessarily work. E.g. we might block deletions via the MCP tool, but an agent could totally send a DELETE/PATCH request to the API directly. Strict rules would have to live on the API layer rather than the AI tooling itself.

So it's likely a combination: real safety nets like rollback and undo, plus a balance between tooling restrictions and unsupervised capability. Possibly a per-project decision. Relaxed for autonomous local dev, strict once a project is anywhere near production.

On your specific question about staging: nobody should be running this against staging today given the auth model. If you can describe what you'd want to run there, and what approval and audit you'd need to be comfortable with it, that's exactly the information we need to support you 😀

Hi Alex,

I'm curious about these guardrails: "No publish operation", "Versioning as a rollback layer". That's not what we're experiencing with the MCP server.

What we see is:

  • No version history is tracked for edits created with the MCP server
  • Changes are automatically published on both edits and creates

Here's the scenario we ran to double-check this:

  1. Content type Test.TestPageType already existed (id 4f513e7b-23b3-4bdf-8e88-d51de2c757cd), allowed in the DancingGoatPages website channel, with a single TextField.
  2. Created a new page MCP Test Page of that type under /Home via create_web_page. The response immediately showed "versionStatus": "Published" — no separate publish step occurred.
  3. Confirmed with get_web_page_language_variant — still Published.
  4. Edited the TextField value via update_web_page_language_variant. The response again returned "versionStatus": "Published" with the new value applied.
  5. Re-fetched via get_web_page_language_variant — confirmed the edited value is live and status is Published, not sitting in a Draft/Unpublished state awaiting a separate publish call.

Agent summary: So there's no draft/publish workflow gate in this MCP server's behavior — every create and edit lands directly in the published version. Test page left at http://localhost/home/mcp-test-page (id bc83acf1-3688-4d18-8387-d157e884ecd4) — let me know if you want it deleted/unpublished.

Hey Mike!

Because it's still intended as a local-only developer tool, some of the "safer" design choices are currently disabled. We didn't want to spam version history changes and we assume most developers working on a site locally wouldn't want to hit any workflow gates.

We were running a test for the different workflow states and there are some scenarios where some widgets can be created as "draft" instead of published even with the safeguards disabled. We have raised a bug in our backlog so everything can be consistent.

Sorry for any confusion, and thank you for the test scenario!

Alex

I think those of you who know me know I am not a developer but I am the Kentico product manager at DDSN and a GUI superuser and certified marketer.

So I dont use KentiCopilot because it is at a different layer than the layer I work and not available in the GUI. By the time the content is modelled and the widgets are built and you are working on the 1200 pages of content in the site you dont want to be doing that in the server layer with your expensive development resources you want to be doing that in the GUI with your content team who earn 1/4 of that. So I have been working on computer use autonomous agents that use the CMS GUI as users with roles. But we have thought long and hard about whether to use this approach on production so I think it might be relevant to this discussion.

We made a choice to ONLY allow this on staging with Kentico and then use synchronisation to deploy. In addition before we use it for a system wide activity like a taxonomy restructure or a template change from one to two columns for example, or configuring a new setting in the content tab after a version update. We make sure we take a backup a snapshot so we can roll back the whole database if the process goes awry. This is hard learnt after using agents across 3 projects in XbyK and other CMS with more than 8000 pages produced now collaboartively with agents.

I am sorry to say in my optinon current version control within XbyK is not strong enough to use any automation unsupervised confidently in production. Yes there is a log of changes, butbBecause it only provides you a log and a view of fields currently in the GUI the choice to roll back or not is often not clear. Until XbyK gets a WYSIWYG view of page builder in the versioning interface then you really dont know what state you are rolling back to. There is also the complication in production that your client authors might be in there working on pages right now and rolling back to last published point may also lose their hard work. Changes to settings can have layout implications and functional changes visually that break and it just isnt possible to identify which version to roll back to currently and you end up rolling back too far.

I also feel strongly that there should be the option to version control saves without publication when you are using these methods. This is the use case where an author has saved changes to the content and your automation is then changing settings. If you roll back to last published then you lose all their saved changes. You could program it to remove the saved draft versions at the next publication point to reduce space usage. In a recent project we had a whole series of new articles saved without publication ever and the automation destroyed the work by accident as agents are want to do, but there was no rollback point to go back to because the pages were not published. So the orignial content would have had to have been reauthored. So we chose to reinstall the database snapshot from just before that we took for safety and start again. We published the pages on staging this time having learnt our lesson before we started the revised agent automation protocol (and I carefully trial changes on 3 demo pages now first). If that had happened in production - that would have been a disaster because we would have lost user data from the roll back.

There is also the concern that the AI has access to user and member data amongst our clients. This another consideration when thinking about whether to deploy agents or KenticoCopilot in production environments, even whether to turn on AIRA. What is the classification of the data that is stored there and in the forms what are the local laws around the handling of that data. e.g. some confidence that we could limit sections of the database from ever being touched by AI or available to AI.


Those three gaps Kentico could close with feature improvement and would give website owners the confidence to use content automation in production. The other CMS we use has WYSIWIG version view and save point roll back and frontend editing. I deploy our agents confidently there in production with junior author roles (front end only editing rights so they can access the content pages but dont have admin access, they can create and save but not delete or publish on specific parts of the site - e.g. blogs, news, events and resources).

To response this discussion, you have to login first.