Guardrails for AI agents in a CMS

If you decided that an AI agent may help with your website, the next question is how much it may do. Write the answer down before the first connection, because the day of the first mistake is a poor time to decide. This guide turns the MCP security guidance and the CMS vendors' own controls into a short set of guardrails a small business can apply without a developer on staff.

If you haven't decided yet, start with should an AI agent run your website.

Guardrail 1: a separate, limited account

Never connect the agent with the owner's admin login. Create a separate user for it, with the lowest role that still lets it do the job.

This works because the platforms enforce their own permissions. Webflow says an agent can do through the MCP server only what you can do in the Designer, and nothing more (Webflow, how the MCP server works). The WordPress MCP Adapter checks that the user is logged in and has the required capability before it runs an ability (WordPress MCP Adapter, default server). Payload filters its MCP tools by its normal access rules (Payload, MCP plugin).

So the role you choose is the ceiling. An editor account that can write posts but not install plugins or change users limits the damage from any wrong instruction.

The MCP security guidance explains why this matters: a token with broad scopes widens the blast radius if it leaks, makes revocation harder and hides what the user meant in the audit trail (MCP, security best practices).

Guardrail 2: expose only the tools you need

Each platform lets you narrow what the agent can call.

• WordPress. Abilities are not available over MCP by default. Each must be marked public explicitly, and an ability can be opted out of MCP even if it is public elsewhere (WordPress MCP Adapter, default server). Expose reading and drafting abilities first.
• Payload. Per collection, you can switch off built-in tools such as create or delete while keeping find and update (Payload, MCP plugin). A blog collection without delete is a sensible start.
• Webflow. You authorise specific sites and workspaces during the OAuth step (Webflow Help, connect your AI tools). Authorise one site and leave the rest of the workspace out.

Don't rely on the agent to stay away from a dangerous tool because the tool calls itself safe. The MCP specification says clients must treat tool annotations as untrusted unless they come from a trusted server (MCP specification, tools). If a tool shouldn't be used, it shouldn't be exposed.

Guardrail 3: drafts first, a person publishes

The most effective rule is also the simplest: the agent writes drafts, a person publishes. A draft that is wrong costs a minute. A live page that is wrong can cost a customer.

The MCP specification expects this. Applications should show which tools are exposed, indicate when they are called and present confirmation prompts so a human stays in the loop (MCP specification, tools). Most agent tools let you require approval for each tool call; leave that on for anything that writes.

In WordPress, an agent account with a role that can't publish enforces this for you. In Webflow, ask the agent to stage changes and publish the site yourself.

One Webflow detail is easy to misread. Most connections work directly, without your site open.

Only actions that depend on what you have selected or open on the canvas need the MCP Bridge App, which runs in an open Webflow tab (Webflow Help, connect your AI tools). So don't assume the agent can only work while you watch. CMS items, pages and assets can change while you are elsewhere, which is one more reason to keep the drafts rule.

Guardrail 4: write the house rules where the agent reads them

An agent follows instructions better when they live next to the work. Webflow supports Agent Instructions: markdown rules for a site that the MCP server gives to connected agents automatically (Webflow, how the MCP server works).

Good house rules for a small business site are short:

• Never change prices, legal pages or contact details without asking.
• Write in the language of the page you are editing.
• Keep headings and button labels under the current length.
• Add alt text to every image you upload.
• Report what you changed, with links.

On other platforms, keep the same list in a document you paste at the start of each session, or save it in your agent tool's project instructions.

Guardrail 5: watch for instructions hidden in content

An agent that reads your site also reads what visitors wrote on it: comments, form entries, reviews. Any of these can contain text meant to steer the agent. OWASP ranks prompt injection as the first risk for applications built on language models and notes that indirect injection can come from websites or files the model processes (OWASP, LLM01 Prompt Injection).

Practical consequences:

• Don't give the agent tools to read form submissions or comments unless the job needs them.
• Never let content the agent read decide what it does next without your confirmation.
• Be suspicious when the agent suggests a change you didn't ask for.

Guardrail 6: prefer official, remote servers

Where the platform offers an official remote server with OAuth, use it. Webflow runs its server remotely to enable OAuth authentication (Webflow, how the MCP server works), and the WordPress adapter is the official package from the WordPress project (WordPress.org, MCP Adapter).

Community servers that you download and run on your own computer deserve more caution. The MCP security guidance describes local servers as attractive targets, because they may have direct access to your system and can be reached by other processes (MCP, security best practices). It also warns against servers that pass your tokens straight through to another API without checking them.

Shopify's Dev MCP is a useful example of reading the small print. It runs locally without authentication, and its published builds send usage events that can include tool inputs and results (npm, @shopify/dev-mcp). That is fine for development work, and worth knowing before you paste anything sensitive.

Guardrail 7: a way back

Every agent setup needs a rollback plan that works on a bad day:

• Daily backups of the site and its database, tested by an actual restore.
• Revision history switched on, so a wrong edit can be reverted page by page.
• A log of agent sessions: what was asked and what changed.
• A way to switch the connection off quickly, by revoking the key, the OAuth grant or the user.

Write down who does each step. In a small business it is often the owner, so make sure it doesn't depend on someone who is on holiday.

Once a quarter, practise the off switch. Revoke the agent's access, check that the connection really stopped working, then switch it back on. Ten minutes of practice on a quiet day saves an hour of stress on the day something goes wrong. While you are at it, restore one page from the backup to be sure the backup is usable.

Guardrail 8: keep it maintained

MCP and the plugins around it move quickly. The WordPress adapter's 0.7.0 release changed which protocol versions it serves, and since 0.6.0, released on 12 August 2026, abilities marked public are exposed unless they opt out (WordPress.org, MCP Adapter). A change like that can widen what the agent sees after a routine update.

Put a monthly check in the calendar: update the plugin, read its changelog, list the tools the agent can see and compare with last month.

A one-page setup sheet

• Agent account: name, role, which sites or collections.
• Exposed tools: read, draft, update; delete and publish off.
• Approval: required for every write.
• House rules: where they live.
• Backups: frequency, last tested restore.
• Off switch: who revokes access and how.
• Review date: monthly.

The same thinking applies to a site built with AI tools before it goes live; see our checks before launch.

If you would like this set up and checked for your platform, it is part of our web and digital presence work.