SiteGround pushed an AI-powered plugin to hosted WordPress sites without requesting permission. The backlash was immediate and public. But for agencies operating client fleets, the incident is not a PR story: it is a concrete demonstration that a host can bypass your approval process and land software directly on client sites. The operating question it raises is who controls what gets installed, and when.
SiteGround deployed an AI-powered plugin to WordPress sites hosted on their platform. Site owners who had not requested it found the plugin installed and active in their WordPress admin. The plugin’s WordPress.org listing quickly accumulated a near-one-star average rating, with reviewers objecting to the forced install as much as to the product itself.
The press framed it as a trust violation. That framing is accurate but incomplete. What the incident actually exposed is a class of risk that exists for every agency running a client fleet: a hosting provider can push software to your client sites without going through you. Your clients may encounter it before you do.
If you learned about this plugin because a client sent you a screenshot asking what the new item in their admin was, the incident already cost you something. Not catastrophically, but enough to matter: the client’s first contact was confusion, not a proactive briefing from you. That is the operational consequence worth examining.
An agency managing a single site can absorb a surprise install with a quick explanation. An agency operating dozens or hundreds of client sites faces a different equation. A single host action can touch every site on that platform simultaneously.
The exposure compounds at the fleet level in three ways. First, the surface area is large. If fifteen of your sixty client sites are on the same provider, one host decision affects a quarter of your fleet at once. Second, you may not have visibility. Without a current inventory of what is installed on each site, you cannot know whether a host-pushed plugin is present, active, or conflicting with existing software. Third, client trust is stacked on your awareness. Clients hire agencies in part because someone is watching. A surprise install that the client discovers before you do inverts that expectation.
The SiteGround incident is a useful stress test for your current posture. Ask: if a host installed something on every site in your fleet tonight, how long would it take you to know? Running a site audit across your fleet answers that question before it becomes urgent.
Update governance is not a setting in WordPress. It is a policy that covers three questions: what is installed on each site, who has authority to approve changes to that inventory, and how those changes are communicated to clients.
Most agencies answer these questions informally. An experienced lead knows roughly what is on which sites. New installs go through whoever handles the ticket. Clients are told when they ask. That works until it does not, and a host-pushed AI plugin is exactly the kind of event that reveals the gap between informal knowledge and a documented policy.
A basic governance structure has three layers:
Agencies that have answered all three questions operate differently from those that rely on WordPress default auto-update behavior or assume hosts will ask before acting. A monthly WordPress maintenance routine is the recurring heartbeat that keeps the inventory layer current.
A runbook formalizes what experienced teams already do informally. The goal is to make plugin decisions repeatable and auditable so that when something unexpected appears on a client site, you have a documented standard to compare against and a clear record of who reviewed what.
A plugin vetting runbook for agency WordPress plugin management covers five checkpoints:
The SiteGround incident would have failed checkpoint one immediately: the source was a host acting outside your approval process. A runbook gives you the language to document that failure and apply consistent criteria across every site it touched.
Running this vetting process as part of a regular WordPress site audit is also the foundation of a credible maintenance offering. Clients who see a structured review of what is installed and why tend to understand the value of an ongoing retainer more clearly than those who only see a periodic invoice.
WordPress.org has updated its plugin directory standards, with particular attention to AI-enabled plugins. The direction is toward stronger disclosure requirements: plugins that use AI processing, collect user data, or connect to external services are expected to declare those behaviors explicitly in their directory listing.
For fleet operators, these standards serve two purposes. First, they give you a baseline for your own vetting criteria. If a plugin would not meet the directory’s disclosure expectations, it should not be on your clients’ sites without a documented exception and explicit client sign-off. Second, they provide a practical audit trigger. When new standards take effect, it is a natural moment to run an inventory across your fleet, identify AI or data-handling plugins already installed, and verify that each one meets your agency’s criteria.
The broader pattern in the WordPress AI plugins release cycle is that more functionality is moving toward AI-assisted features, and hosts, page builders, and commercial plugins are all competing to ship them. Some will do so with clear disclosure. Others will not. The SiteGround incident occurred before these standards were in place. Similar incidents will follow as more vendors push AI features into existing install bases.
Fleet operators who have a vetting runbook, a current inventory, and a communication protocol in place will process those incidents as routine. Those who do not will process them as surprises, with clients in the loop before the agency is.
An agency running dozens or hundreds of client sites on the same hosting provider can have every one of those sites affected by a single host action at the same time. A solo site owner handles one conversation. An agency handles that same conversation multiplied across every affected client, plus the compliance and contractual questions that attach to each relationship.
The post identifies three: what is currently installed on each site, who has authority to approve changes to that inventory, and how those changes are communicated to clients. Most agencies answer these informally rather than through a written policy, which is where the exposure lives.
A runbook formalizes the decisions experienced team members already make informally, making them repeatable and auditable. The post describes five checkpoints: source (is the plugin listed on WordPress.org), data handling, external service connections, update history, and client approval requirements. The purpose is to have a documented standard so any unexpected install can be compared against an established record.
The updated standards move toward stronger disclosure requirements. Plugins that use AI processing, collect user data, or connect to external services are expected to declare those behaviors explicitly in their directory listing. For fleet operators the post notes two practical uses: the declarations give a consistent signal to check during vetting, and they create a baseline against which actual plugin behavior can be compared after install.
200 free credits. Just describe what you need.
See It In Action