Earlier this year we wrote about AI usage and data management, which looked at what happens to your data when staff use AI tools. This post covers AI that’s connected directly to the website.
AI now reaches websites through several routes at once, often without a formal decision being made. Plugins that have been on a site for years can ship updates with AI features switched on, editors install browser extensions that can read everything on the admin screen, and developers connect coding assistants directly to the repository.
CMS platforms have also opened up to AI agents directly through MCP, the open standard agents use to connect to other systems.
WordPress 6.9 added the Abilities API, a standard way for a site to declare what actions it allows and who can run them, which the WordPress MCP adapter uses to expose those actions to agents.
Payload has an official MCP plugin that respects its access rules, and Sanity runs a hosted MCP server that agents can use to query and edit content.
As a result, software that isn’t on anyone’s risk register may now be able to publish to your website.
Why the website needs its own rules
Your website is different from most internal systems in two ways, the first being that it’s public.
An agent with publishing rights can put content on your homepage, and any mistake is public immediately.
The second is that it holds personal data, with form submissions, user accounts, gated content and newsletter sign-ups all sitting in or behind the CMS, where a tool with broad read access can reach all of it.
The other problem is traceability, because if three different AI tools all connect using one admin account’s credentials, your logs will show the admin made every change. When something goes wrong, you may not be able to tell which tool did it.
Seven controls for AI on your website
1. Find everything that’s already connected
Start with a list, which in our experience is always longer than people expect.
- Plugins or modules with AI features, including ones that added them in a recent update
- Browser extensions your editors use while logged in
- API keys for model providers, wherever they’re stored
- Agent and MCP connections to the CMS
- AI tools your agency or developers use on your codebase
- Any chatbot or AI search on the front end of the site
Put a named owner against each one, and review any tool nobody is willing to take ownership of.
2. Sort them by what they can do
Not every tool needs the same scrutiny, so sort them by what they can reach and what they can change.
| Tier | What the tool can do | Review it needs |
|---|---|---|
| Low | Suggests changes to published content and can’t act on its own | A quick check of the provider’s terms |
| Medium | Reads drafts, unpublished pages or internal content | Data review and owner sign-off |
| High | Publishes, changes settings or code, or touches personal data | Full security review before it’s switched on |
A writing assistant that suggests headlines is low risk, while an agent that can publish pages and install plugins is high risk, however helpful it is.
3. Give every agent its own identity and the narrowest access
Limiting what each tool can reach can remove most of the risk, and the simplest way to do that is to treat each AI agent like a new member of staff.
Each agent should have its own account and its own role scoped to the actions it actually needs, so you can see what it did and switch it off without affecting anyone else.
The platforms give you the controls to do this:
In WordPress that’s user roles, plus the permission checks that sit on each ability an agent can call.
In Payload, the same access rules that govern human users apply to anything connecting through MCP, and you can switch MCP off per collection.
In Sanity, give each integration its own API token with a role that matches its job.
If your CMS supports MCP, leave it switched off until you have a specific use for it and these access controls in place.
Then deal with the credentials, which belong in a secrets manager and not in plugin settings or code. Rotate them on a schedule and whenever someone with access leaves, and delete anything that isn’t being used.
4. Decide what data can leave the site
Before any tool sends content to an outside model, decide what it’s allowed to send. A simple split works for most sites:
- Fine to use: published, public content
- Needs approval: drafts, unpublished pages and internal documents
- Off limits: personal data from forms and user accounts, client-confidential material and anything regulated
Then read the provider’s terms, specifically whether they train on your data, how long they keep it and where it’s processed. If personal data is involved, you’ll need a data processing agreement in place.
Our earlier post goes into data classification and contractual cover in more depth.
5. Keep a person on the publish button
For most content, a named person should approve anything AI produces before it goes live, whether that’s a page, a code change or a settings update.
In practice, set agents up so they can create drafts but not publish, and require human sign-off for publishing content, deploying code and changing permissions or settings.
The approval only means something if the reviewer has the time and the authority to say no. A sign-off step that people click through without reading can give false assurance that a check has happened.
6. Log everything and set limits
You need to be able to say which tool did what, when, and under which account, and with separate identities from step 3 in place, this is straightforward.
Monitor for unusual activity, such as a sudden increase in requests, activity outside normal hours, or a tool accessing content it has no reason to.
Set rate limits and spending caps, so a misconfigured agent can’t flood the site with changes or run up a large bill with a model provider overnight, and keep logs for long enough to investigate an incident properly.
If something does go wrong, revisions and tested backups are what let you put things back, so check you have both before you give an agent write access. On our dedicated hosting, every site is backed up daily with at least 14 days kept, and backup frequency can be increased if you can’t afford to lose a day’s changes.
7. Have an owner
As with website security generally, AI governance needs a named owner, which we’ve covered more broadly in who owns website security.
Give one senior person, usually in digital, IT or security, the authority to approve and retire AI tools on the site. Then put three things in writing:
- A AI policy for the website that people can access
- What to do if a tool misbehaves: who revokes access, who rolls back changes, who gets told
- A review schedule, quarterly at the least, plus a check whenever a plugin update adds new AI features
For a formal framework, the NIST AI Risk Management Framework is a good starting point, and OWASP’s Top 10 for LLM applications covers the specific risks, like prompt injection, that apply when AI reads content from the web.
Connecting AI content pipelines to your website
A growing number of teams want AI tools to create content and send it straight into the website, whether that’s news articles, product descriptions or translated pages.
It’s technically straightforward, because WordPress, Payload and Sanity all have APIs and MCP connections that a pipeline can write to.
The seven controls above apply in full, and a pipeline that writes to your CMS should be set up so that:
- It has its own account or API token, limited to creating drafts in the content types it needs
- By default, nothing it produces goes live without a named person reviewing and publishing it in the CMS
- Every piece it creates is labelled as AI-assisted, so editors and auditors can see where it came from
- The source material it draws on follows your data rules, with nothing restricted going into the prompt
- It has rate limits, so a fault can’t flood the site with hundreds of drafts
- Revisions are switched on, so anything published in error can be rolled back quickly
Some teams need agents to publish directly, without a person approving each piece, usually for high-volume, lower-risk content such as event listings, job adverts or data-driven pages. That can work safely if the risk is contained, and we’d put these controls around it:
- Direct publishing limited to specific content types, with everything else still going to draft
- Automated checks before anything goes live, covering broken links, formatting, banned terms and personal data
- A person reviewing a sample of what’s been published, on a set schedule
- Alerts if publishing volume or behaviour changes unexpectedly
- A way to switch the agent’s publishing rights off immediately
Most teams start with drafts only and move individual content types to direct publishing once the agent has built up a track record.
Set up this way, a pipeline can significantly reduce editorial workload while the publishing decision stays with your team.
How we can help
We help clients put these controls in place on existing sites, and we build them in from the start on the AI tools we develop, from AI knowledge assistants grounded in your own content to bespoke integrations with your CMS.
If you’d like a second pair of eyes on what’s already connected to your site, get in touch.
