Twenty-plus years in, I have learned to watch two things when a new tool arrives. The demo, which is clean light and a presenter who knows where the sharp edges are. And the first Tuesday somebody sits down with it on their own estate, at which point the sharp edges meet shins. The gap between those two states is where the people who do this for a living actually earn it.
I am writing this for a reader who is being told, in a slide or a call, that an AI agent can safely operate an enterprise WordPress site. The platform in question is WordPress VIP, Automattic’s enterprise offer, and the feature is Secure MCP. The pitch is that an agent can read the platform, write content, deploy, purge cache, with an auditable record of every action. The pitch is largely true. It is also quietly shaped by a handful of behaviours that do not appear in the documentation, and if you discover them on production you spend a day finding out which of the obvious explanations is wrong.
So we ran our own sandbox against it, kept a transcript, and reported the gaps back to VIP. What follows is what we found, written for the person signing the contract rather than the person configuring the plugin. The build section at the bottom is the part we would price into any VIP engagement that touches AI operations.
The Pitch and the First Hour Are Different Pieces of Software
Secure MCP shipped to all VIP customers on 2 July 2026, in a Customer Hub announcement that frames it as an auditable, governed endpoint for agents, with a kill switch at the organisation level and “every mutating action logged and attributed to an authorized user.” We applied for the VIP agency partner programme and provisioned a sandbox application (org The WP Clan, app thewpclan-sandbox) specifically to see what happened when an agent actually ran against it. The client was Claude Code, user scope. The log that follows is paired with transcript timestamps in UTC.
Credit where it is due. The setup really is one line. Per the connect-an-mcp-client page: claude mcp add --scope user --transport http vip-platform https://api.wpvip.com/mcp. The OAuth metadata at the well-known endpoints exposes Dynamic Client Registration plus PKCE, so no manual client registration, no copy-pasting a client ID and secret into a config file. For a team that evaluates a lot of these integrations, that first impression lands. Then the seams begin to show.
Once connected, the client reports 66 tools: platform operations under app_*, environment_*, organization_*, plus GraphQL escape hatches (search, execute, introspection), and a WordPress MCP surface that is deliberately thin, just three tools (wordpress_discover_abilities, wordpress_get_ability_info, wordpress_execute_ability) that proxy whatever the site’s WP Abilities API exposes. In the sandbox that resolved to 55 abilities, including core info, pages, posts, tags, media, menus, patterns, theme preset and allowed-blocks, and Jetpack Forms. That is already a wider surface than most enterprise MCPs ship with, and reading it is the moment you decide whether to trust it to write.
Four Things the Documentation Does Not Say Out Loud
Each of these cost us at least an hour of the wrong kind of search, the kind you do when the error message is pointing at the wrong floor. We reported them to Automattic in order of how much they would bite a new team. The order below is ours, not theirs.
One. Plain permalink silently breaks the WordPress MCP connection. Three calls at 11:11:49, 11:12:17 and 11:14:27 UTC on 2026-08-26 all returned WordPress MCP integration error: Failed to connect to WordPress MCP server. The WordPress side was correct: the REST index at ?rest_route=/ listed both mcp and wp-abilities/v1 namespaces. The /wp-json/ route, however, was serving a 301 to a trailing-slash URL and returning HTML. Settings → Permalinks was on Plain, which is the default on a freshly provisioned VIP app. VIP’s WordPress MCP connector addresses the site over /wp-json/, so until permalinks were switched to Post name and the edge cache was purged, it could not reach the endpoint. The WordPress MCP prerequisites page lists Global MCP activation, toolset enablement, matching email addresses and multisite membership. It does not mention permalinks. Every new app will meet this once.
Two. The mapped WordPress user needs 2FA enabled before any write succeeds. Six consecutive calls between 11:43:27 and 11:53:58 UTC returned WordPress’s own permission error: Sorry, you are not allowed to create posts as this user. The identity was correct. core/get-user-info returned 01clan, administrator, and the same account could do anything through wp-admin. The single variable that cleared it was enabling Email 2FA in the user profile. The next call did not fail with the same text; it failed on field validation, which is how you know the permission gate opened. The behaviour is consistent with VIP’s enforcement doc: the 2FA controls page states that the Two-Factor Authentication plugin is active on all VIP sites and that 2FA is enforced for Editor, Administrator and Super Admin roles. No Secure MCP page points to it. The error returned to the agent is standard WordPress permission text, which an administrator will spend an afternoon disproving before anyone thinks to check a 2FA field.
Three. Duplicate emails across WordPress users bind the agent to the wrong one. Early calls to core/get-user-info returned Permission denied. The sandbox had two users sharing [email protected]: 01clan (administrator) and thewpclan (subscriber, created by a WXR demo content import in August). VIP’s mapping went to the subscriber. Changing the lower-privilege user’s email cleared it. The WordPress MCP prerequisites page says emails must match. It does not say what happens if two users on the site match. The answer is that one of them is silently chosen, with an error text that points nowhere near the cause. WXR imports produce this scenario regularly, which means it will land in migrations.
Four. environment_run_wpcli returns a success payload but does not actually run the command over MCP alone. Three commands at 11:40:02, 11:55:21 and 11:57 UTC came back with a successful response shape (the tool queued a session with WebSocket and SSH credentials), but a pull of the command history (AppEnvironment.commands) showed all three with status: preparing and an empty startedAt. Nothing ran. The tool is a session enqueuer: an external client has to attach to the WebSocket or SSH session for the command to execute. The same command via the @automattic/vip CLI (4.1.1) ran on the first try: vip @thewpclan-sandbox.production --yes -- wp eti-sandbox seed_home → Success: Seeded page 34886. An autonomous agent cannot use this tool as advertised: it will report success while the command sits in a queue forever.
Your Audit Trail Does Not Record What Your Auditor Will Ask About
This is the one that matters for a buyer, because it is the gap that shows up in a security review. The Secure MCP overview states: “Every MCP tool call is recorded. The MCP Call Log lists Secure MCP tool calls across all applications in an organization, and a per-environment view lists the calls for a single environment. All MCP activity against the environment is recorded in the MCP audit log, including actions taken by VIP personnel.” The customer-hub announcement repeats the promise: every mutating action logged and attributed.
On 2026-09-15 we ran a controlled dual test on the same app, same user, same minute, same tool. A successful core/get-site-info at 09:25 UTC appeared in the Call Log. A failed vip/pages-update with id 999999999, which WordPress itself answered with Invalid post ID. (so the call did reach the site and return), did not appear. The second call left no trace.
Reading backwards into 26 August, the gap is sharper. Nine failed calls over two hours left no record: three failed wordpress_discover_abilities calls before the permalink fix, plus six failed writes (four pages-create, one tags-create, one pages-update) before the 2FA fix. The tightest window shows the pattern: pages-list at 11:41:18 was logged, pages-create attempts at 11:43:27, 11:45:06 and 11:45:35 were not, deployments at 11:46:30 was logged, then pages-create at 11:53:10 was not, then core/get-user-info at 11:53:18 was, then tags-create at 11:53:49 and pages-update at 11:53:58 were not. Eight seconds between a logged call and a rejected one that left no record. The explanation “it failed before it reached the server” does not fit, because the rejections carry WordPress’s own REST response text. The call reached the site. The site answered. Nothing logged.
The same test showed inconsistency on the success side. app_list was called twice, both successful, neither logged. app_list_environments was logged. The search tool (schema introspection) is never logged. GraphQL introspection against mcpAuditLog, mcpCallLog and auditLog returns no types and no fields, so the Call Log cannot be programmatically exported or shipped to a SIEM. It is readable from the Dashboard UI only.
For a buyer, the practical consequence is specific. “Are rejected access attempts logged?” is a routine line on an enterprise security questionnaire. On Secure MCP today, the honest answer is no. “Can we export the audit log automatically to our SIEM?” is a second routine line. The honest answer today is no. These are soluble; neither is solved yet; and the published promise is strong enough that a buyer could sign expecting both.
What We Would Do Before Letting an Agent Write Production Content
This is the build section. Four things we fold into the provisioning template on any VIP install that will host an AI agent, with rough effort stated honestly rather than rounded for a deck.
- Pretty permalinks on every environment, with a scripted edge cache purge. One line in the provisioning playbook, perhaps 20 minutes to script and test. You will meet the plain-permalink failure once per app otherwise, and never when you have a quiet afternoon.
- 2FA enabled on every WordPress user the agent will write as. Not the Dashboard user’s MFA, which is a different layer. The WordPress user’s own 2FA in the
two-factorplugin. Email is enough for sandbox; TOTP is the right default for production. Enroll before the agent gets a token. Ten minutes per editor. - Toolset split by responsibility. VIP MCP (platform operations) and WordPress MCP (site content) activate independently per application. An AI content tool gets WordPress MCP only; platform mutations stay with a different, higher-trust agent or a human. This is in VIP’s documented model already; it just has to be used.
- A separate record of rejected agent actions in the orchestrator. Whatever runs your agent (a workflow tool, a job queue, your own code) is the place to keep the rejected-attempt log, because the Call Log will not. One line of structured logging per tool call, shipped to the same place the rest of your security events go. Perhaps a day of work, less if the orchestrator already logs attempts.
What we would do differently next time: run the controlled dual test on day one, not three weeks in. Had we called core/get-site-info and vip/pages-update with a nonsense id side by side in the first hour, we would have caught the audit gap before we caught the permalink one, which would have been the better order.
What a Buyer Should Make an Agency Prove Before Signing
Three asks that separate an agency that has read the brochure from one that has operated the platform, for a buyer evaluating a WordPress VIP agency for AI-era operations.
- Ask for the transcript, not the demo. A written record of tool calls, responses and failures against a named sandbox app is a credential. A slide of a chat window is not.
- Ask what has been reported back to Automattic. We filed three findings with VIP: plain-permalink breaking WordPress MCP, 2FA requirement on the mapped user, and the Call Log audit gap. “What have you reported upstream, and when” is a fair question.
- Ask how platform tooling is separated from content tooling. The two toolsets carry different risks. An agency that cannot explain why
WordPress MCPandVIP MCPare activated independently in your deployment is the wrong first call.
Related reading on the cluster: our what-is-WordPress-VIP pillar, the security and compliance page, and the migration page for teams moving onto the platform.
What stays unresolved for us: step-up verification on deploy and rollback, which we did not trigger in this round to avoid breaking the sandbox; region pinning, since the sandbox resolved to datacenter: DFW and VIP has not told us yet whether EU and Turkey regions can be fixed at provisioning; and the agency-sits-under-client-org scenario where the Org admin belongs to the client and the agency sits inside their boundary. Those are the next three questions. If you are evaluating VIP for AI-era operations and want the full transcript, or the three Automattic emails, write to us. We would rather be the people surprised in a sandbox than the people called at midnight when your first production write comes back with a success payload and an empty site.
Last modified: November 8, 2026
