Three ways to connect AI to a WordPress fleet

1. A plugin that serves AI on each site

The site itself answers the AI client. You install a plugin, authorize a connection to that site, and the assistant works on it directly. Nothing new sits in the middle of the request.

This is the right answer for one site. It’s also where the deepest per-site feature work lives — page-builder editing, layout manipulation, content design. If what you want is an AI that rebuilds a landing page inside your builder, that work is being done in this pattern and it is genuinely good.

What it costs at fleet scale is repetition. Authorization is per site, so twenty sites is twenty connections; governance is per site, so a policy change is a change you make twenty times; and a job across the fleet is the assistant switching sites in a loop, one at a time, with no shared record of what happened.

2. A dashboard — or a local connector — holding an application password

You already have a management dashboard for your fleet. It gains an AI connector, and it reaches each site the way it always has — with a stored WordPress credential, usually an application password.

The 2026 version of this puts the connector on your laptop: a small server that runs beside your AI client, holds an application password for the dashboard, and calls it over the network. It’s a genuinely clever way to ship AI onto an existing fleet tool without changing the fleet tool, and if you’re a single operator it works well.

One pane of glass is a real advantage, and this pattern usually costs nothing extra because you’re already paying for the dashboard. If your risk register doesn’t have credential custody on it, this is a reasonable place to land.

The cost is the credential itself, and it’s worth being precise rather than dramatic about it. A WordPress application password is not a scoped API key. It carries every capability of the user it belongs to, it works against the whole REST API rather than only the actions you meant to allow, and it never expires — it stops working when someone remembers to revoke it. Running a fleet this way means one of those exists for every site you own, sitting at rest in one place. Whatever the AI layer does or doesn’t do, that pile is now the thing an attacker wants.

The local variant adds a second cost that has nothing to do with credentials: the safety limits move onto the machine of the person being limited. Which tools are available, whether destructive ones are blocked at all — these are settings on the operator’s own computer, set by the operator. That is fine when the operator is you. It stops being fine the moment you have staff, contractors, or anyone you’d want to answer “who approved that?” about. There is no org admin in that picture, and no central record that the limits were ever switched on.

3. One place signs, and every site verifies

This is what Portcullis is, and the mechanism is one line: we sign, your site verifies.

Your site holds our public key and nothing else — there is no password on either side to steal, leak or rotate. When something needs to happen, Portcullis signs a pass that is good for one site, one action, about a minute, bound to that single request so a copy captured in flight is inert. Your site checks the signature offline and does the work. Nothing is left switched on between requests.

And because the authorization is held in one place rather than at each site, it covers the fleet. You approve access once; every call still re-checks, per site, that this person may reach that site. One sentence can move across up to 1,000 sites in a single job, with live per-site progress and one audit trail over all of it.

The trade is honest: there is a service in the middle, and you have to be willing to have one. What that service holds is the point — it can’t log into anything.

The part that isn’t architecture: what drives the model

Everything above is about custody. This isn’t, and it may be the difference you feel first.

Patterns 1 and 2 hand your AI client a translation layer: it turns a sentence into an API call and hands the result back. That is genuinely all an MCP server has to do, and for one site it’s enough — the model can see the whole thing.

A fleet breaks that, quietly and in the worst possible way. Ask a general-purpose assistant “which of my sites need this?” across 200 of them and it does what it can: it looks at a few, and it answers about all of them. You don’t get an error. You get a confident, partial answer that reads like a complete one — a plan you approve, and a third of your sites silently untouched. We know because we shipped that bug and had to go find it.

So the assistant is the part we build, not just the plumbing under it. It’s told exactly how many of your sites can perform an action and how many can’t — counts, not a sample. Past a few dozen sites it summarises instead of half-listing. A targeting query that would overflow fails rather than trims, because a truncated list that looks complete is worse than no list. Multi-site work runs as a plan you approve once — check, act, then verify, per site — and a write is read back afterwards and reported as verified, unchanged, or unknown, rather than trusting what the write returned. You can write standing instructions for the fleet or for one site, and the assistant reads them. Runs can be scheduled to happen with nobody watching — either a digest mode that structurally cannot write at all, or a specific plan an admin approved when the schedule was created.

None of this is exotic. It’s just the difference between exposing tools to a model and operating a fleet with one — and it’s work that has to happen somewhere. If it isn’t in the product, it’s in your prompt, every time, and you find out which sites it missed afterwards.

You can also skip our assistant entirely and point your own MCP client at us — the fleet tools, the per-call checks and the audit trail are the same either way. The harness is what you get when you’d rather not build it yourself.

Side by side

Last row, literally: open our public keys. That’s the whole secret we ship to your sites. If we stored a password for your WordPress, that endpoint would not be the only thing we could show you.

The things you currently do by hand, and by tab

Custody is the axis a security review asks about. There is a second one, and it decides more of your week: what the work actually looks like once it is more than one site. Each of these is a sentence somebody types, and each maps to something that ships — version targeting, the can’t-run count, check → act → verify, the audit record.

• Which sites are still on an old WordPress?
• How many of these can actually run that action?
• Run it on everything tagged retail, then check it took.
• What ran on the Acme sites this month, and who approved it?

They are questions and instructions, not promised outcomes — which is the honest way to read any of the three patterns. The difference is how many tabs each answer costs you.

Which one you should actually pick

• One site, and you want AI to design pages in your builder. Pattern 1. Portcullis governs the actions a site registers; it is not a page-builder editor, and we’d rather say so than lose your afternoon.
• A fleet, an existing dashboard, one operator, and no custody requirement. Pattern 2 is already installed and probably free. Take it, and set a reminder to rotate.
• A fleet where the fleet is the unit of work — you think in “every site on an old version”, not in site names — or more than one person will be pointing an AI at client sites, or anyone has asked you what an AI vendor stores. That’s us.

And these are not either/or. Portcullis is not a maintenance dashboard: we don’t do backups, uptime, vulnerability scanning or white-label client reports, and we’re not planning to. If you run a fleet tool for that work, keep it — it costs a fraction of what we do because it is doing a different job. What we replace is not your dashboard. It’s the standing admin login you’d otherwise hand to an AI, times the number of sites you own.

The part we expect to be wrong about

Per-site tool depth is the strongest argument for pattern 1 today, and we are not trying to match it. Our bet is that the actions themselves belong to WordPress — that’s what the Abilities API is, it’s in core from WordPress 7.0, and every site that adopts it exposes its capabilities the same way. If that bet is right, hand-built tool catalogues converge and the question left over is the one this page is about: who holds what, and what does one approval cover. If it’s wrong, pattern 1 keeps a real advantage and we’ll say so here.