I run seven WordPress sites on three hosting providers: two shops, two blogs, two affiliate sites and this one. Since November 2026 an agent maintains them. It updates plugins, improves titles and descriptions, refreshes old articles and watches whether the sites are up. This note describes how it is allowed to do that.
Two parts: an agent and a gateway
The agent has no hosting passwords. They sit in a second container, the gateway, which offers the agent a set of tools and nothing else. The agent can ask the gateway to read a page, list plugins or plan a change. What comes back is checked for anything that looks like a secret and redacted. Every call lands in an audit log.
One of the three hosts offers no shell at all, only file transfer. For that host the gateway uploads a small helper file for each call, addresses it once over HTTPS and deletes it again.
Every change takes the same path
- Plan. The gateway saves the current state of what is about to change and produces a preview.
- Check. At execution time the saved state must still match the live state. If someone changed the page in between, the plan is void.
- Change. The change is applied and the page cache is cleared.
- Test. The gateway fetches the live page. It expects status 200, no PHP error, a check text from the change visible on the page, and a page that has not become more than 30 percent shorter. Shops are also tested on the shop and checkout pages.
- Roll back or report. If the test fails, the saved state is restored automatically. If it passes, I get a short message saying what was changed.
The agent cannot skip a step, because the steps are not instructions to the agent. They are what the gateway does when the agent calls the tool.
What stays blocked
- Legal pages, including imprint and privacy policy
- Checkout, cart and account pages, orders and coupons
- Users, newsletters and security-related settings
- Prices, sales and ads: there are no tools for these at all
- Scripts, iframes and forms inside page text
- Plugins from anywhere but the official directory, and any change beyond updates to payment, security, consent and legal plugins
The agent may write small pieces of theme code. The gateway checks the syntax on the target server first and rejects code that calls system, file, mail or user functions. There is also a cap on the number of changes per day and a hard daily budget for paid keyword data.
From read-only to full rights in two days
On the first day the agent could only read. On the second day it could write, with one condition: for changes to published pages the gateway sent me a preview and a six-digit code, and the change ran only after I passed the code on. The gateway stored only a hash of the code, and the agent never saw it anywhere else.
That lasted a few hours. Each change was already saved and tested, so I changed the rule on the same day: act on your own, tell me afterwards, and if in doubt I have the change rolled back. Control moved from asking before to undoing after. The blocked areas above stayed blocked.
A role change that did not arrive
When I gave the agent write access, a chat with it was already running. That session kept its old instructions. The agent told me it had no write access, and it took my approval codes for login codes from someone else.
Its caution was correct given what it knew. The mistake was mine: new permissions have to reach running sessions, not only new ones. Since then, refreshing the sessions is part of every role change.
What I do not know yet
At the time of writing the agent has been at work for less than a week. In my tests the pipeline held: changes went through, failed tests were rolled back and the blocked areas stayed untouched. Whether its work brings more visitors and sales is a separate question, and I will write about it when there are numbers worth showing.