Risks and permissions

An assistant can do exactly what the abilities you expose allow, acting as the account behind its application password. Here's what that means in practice.

Built-in safeguards

• Off by default, read-only when turned on. Changes are only possible after you expose write abilities.
• Administrator only. The connection requires an administrator account, and every VX ability checks it again when it runs.
• Destructive actions are marked, so well-behaved clients ask for confirmation before deleting.
• Other plugins' abilities are never exposed by default.
• No account administration. Nothing in VX creates or deletes users, or changes roles, passwords or email addresses.
• Everything is logged with a way to undo it. See Activity log and undo.

Risks to weigh

• A leaked credential is an administrator's access to your model and content. Anyone with the application password can do whatever the exposed abilities allow. Use a dedicated account, and revoke its password when you stop using it.
• Read-only still means reading content, including the earlier values stored in the activity log.
• Assistants bypass per-post permissions and post locks. Changes run with administrator rights, and a person editing the same post isn't warned.
• Parallel changes are serialized, not coordinated. VX prevents simultaneous changes from corrupting data, but steps sent separately can still land in an order nobody chose. Ask the assistant to send related changes as one task.
• Some deletions are permanent. See Changes that cannot be undone.

Recommended setup

Site	Suggested exposure
Local or staging	Level 2 is fine. Experiment freely, and keep the undo information.
Production, assistant for questions	Level 1 (read-only). Consider Custom without content reads if the assistant only needs the structure.
Production, assistant makes changes	Custom with only the writes the task needs, on a dedicated account, for as long as the task takes. For structural changes, prefer building on staging and deploying with config as code.

The MCP settings aren't the only way in

The AI screen controls what the MCP connection offers. VX's abilities are also part of WordPress's Abilities API, which WordPress publishes at /wp-json/wp-abilities/v1. Any administrator can run them there, with or without MCP. That's the same power they already have in wp-admin, but it means turning MCP off doesn't make the abilities unreachable. To remove an ability completely, a developer can unregister it.

Technical details for LLMs

• Endpoint and every VX ability require manage_options; foreign abilities use their own permission callbacks (core reads may only require read).
• Annotations: destructiveHint on deletes, file overwrites, vx-framework/reset-config, vx-framework/detach-config, vx-framework/undo-change, vx-framework/set-block-document; idempotentHint on final-state writes.
• Content writes have no object-level capability or post-lock checks.
• Remove from all surfaces: add_action( 'wp_abilities_api_init', fn() => wp_unregister_ability( 'vx-framework/delete-post-type' ), 20 );