The most common reaction to "AI that manages your WordPress sites" is a flat no, and it is the correct instinct. A client's live store is not a place to find out what an autonomous agent does when it is confused.
So it is worth being precise about what Vibery actually is, because the fear and the product are describing different things.
Vibery is not an autonomous agent
Nothing in Vibery decides to do anything. There is no background loop watching your sites and taking initiative.
The flow is always the same: your assistant proposes an action, you approve it, Vibery executes it, and the result comes back. Every change on your sites traces to something you asked for. In the beta, the count of unattended actions is zero, and that is a design property rather than a current statistic.
What Vibery provides is the execution layer: a safe, well-defined set of operations an agent can call. It is infrastructure for agents, not an agent.
What access does it actually get?
For a site you already own, exactly one thing: a WordPress application password that you generate from that site's own wp-admin.
That has some useful properties:
- We never receive hosting credentials, SFTP access, or database credentials
- Nothing is installed on the site for the standard tier, so there is no plugin to trust and no code of ours running inside your client's WordPress
- You revoke it from wp-admin in seconds, and access stops immediately with nothing left behind
The application password is a WordPress core feature. This is the same mechanism a mobile app or a desktop editor uses, and it is scoped to the user you create it as.
What stops one customer seeing another's sites?
Tenant isolation. Your token resolves to your tenant, and queries are scoped to it at the data layer rather than filtered in application code after the fact. Your token sees your sites. There is no request shape that widens that.
What about the risky operations?
The genuinely destructive actions are the ones worth pairing with a restore point, and that pairing is the habit worth building:
- Back up before you update plugins, not after something breaks
- Restore to a point in time rather than to "the last nightly, probably"
- Export a bundle before a migration, so the rollback exists off-platform
None of that is specific to AI. It is ordinary operational care. The difference is that when taking a backup costs one sentence instead of ten minutes, you actually do it every time.
Start where the stakes are low
The honest advice: do not connect the client store that pays your rent on day one. Deploy a hosted site from a template, or connect your own blog, and watch what the tools do. The model is easy to trust once you have seen the approval step fire a few times on something you do not mind breaking.
No comments yet