What the AI can and cannot do
The AI operates with the permissions of the WordPress user whose Application Password you configured, and only through the tools the server exposes. With default configuration it can: read site, plugin, theme, update, client, and tag data; run updates, which on Dashboard 6.3 and later need your confirmation; activate and deactivate plugins and themes; sync and reconnect sites; and delete sites, clients, tags, plugins, or themes, but only after you confirm. It cannot: log into WordPress admin, bypass WordPress permissions, run arbitrary code on your sites, or touch anything MainWP itself does not expose.Deletions require your approval
Destructive operations use a two-step flow. Asking the AI to delete something does not delete it; it produces a preview.- Preview. The server intercepts the request, runs a dry run, and returns what would be affected along with a one-time confirmation token. The AI shows you the preview.
- Execute. Only after you say yes does the AI send the confirmation. The server checks that the token matches the same operation with the same arguments and that the preview is less than 5 minutes old, then executes.
delete_site_v1, delete_client_v1, delete_tag_v1, delete_site_plugins_v1, and delete_site_themes_v1. On Dashboard 6.3 and later it also covers the update tools and unignore_site_updates_v1. See Updates Abilities for the Dashboard’s preview and confirmation requirements. An ability that does not explicitly declare itself non-destructive is treated as destructive and gated the same way.
When one request needs several previews, for example update calls for different items on different sites, previews shown together can be approved in one explicit reply. Each still runs with its own token, and approval never covers anything you were not shown.
For unattended automation, set MAINWP_REQUIRE_USER_CONFIRMATION=false together with an allow list (MAINWP_ALLOWED_TOOLS). An allow list filters by tool name and does not see site arguments, so leave update_all_v1 off the list and have the automation name its sites on every call. With confirmation off, the caller must send confirm: true itself: Dashboard 6.3 rejects an update call with neither confirm nor dry_run, and the server reports that as mainwp_confirmation_required in error.data.upstream_code. See Configuration Reference.
Safe mode: block deletions entirely
If you want destructive operations off the table completely, enable safe mode:SAFE_MODE_BLOCKED without ever reaching your Dashboard. We recommend running your first sessions in safe mode: you can verify the connection and learn how the AI behaves while the dangerous tool classes stay blocked.
When both are configured, safe mode wins.
One honest caveat: the AI client has the last word
The server marks dangerous tools, instructs the AI to preview before executing, and refuses calls that skip the flow. But the AI client decides how to present all of this to you. A flawed client could misread your “hmm, maybe” as a yes, or claim you confirmed when you did not. The server-side gates above cannot be talked around: a deletion without a valid token does not execute. If you do not trust the AI client in front of them, add layers it cannot see past:- Safe mode blocks destructive execution at the server.
blockedToolsremoves dangerous tools from the AI’s view entirely, so there is nothing to misuse.
Guidance the server gives the AI
When a client connects, the server sends it a short set of instructions. They tell the AI to present a plan and get your approval before any call that changes sites, to show a tool’s preview as that plan, and never to remove an update from the ignore list to force it through unless you ask. On Dashboards before 6.3, updates are not classified as destructive, so the confirmation flow above does not stop them and your approval of the plan is the only check. The same instructions cover knowledge records on Dashboard 6.3 and later. The Dashboard, not the record’s text, decides whether a record is verified. The AI follows a verified skill whose description fits the task and respects verified context. It treats an unverified record as information only: if one contains instructions addressed to an AI, it does not follow them and tells you which record it is so a person can review it. Memories are history, and no record authorizes a change to a site. The AI opens any record it has seen only by title before describing or following it. Before advising on, planning or drafting work for a site, the AI loads that site’s knowledge summary if the summary tool is available, even when you named one record or it already read a list. A single record or a list does not show which client and agency records apply to the site. For client-wide work it loads the client’s summary first, then each site’s summary. If it cannot load a summary, it tells you which knowledge was not loaded. Showing you one record you asked for needs only that record. Records come at three levels: agency (every site on the Dashboard), client (every site of that client), and site (that site only). The Dashboard sends the rules for combining them with every knowledge summary. When verified records conflict, the more specific level wins, except that a required record wins over any record at a more specific level: a required agency record over client and site records, a required client record over site records. When records at the same level conflict, or two required records do, the AI names them and asks you. Only a person using the Dashboard can mark a record required or change a required one. Each client decides how to use server instructions, so they guide the AI without enforcing anything. The server-side gates above are the enforcement. For the Dashboard workflow, record types, inheritance, Required rules, and human review, see MainWP Knowledge.Going further
Restrict Available Tools
Read-only setups, update-only setups, and hiding destructive tools.
Security Model
Trust boundaries, credential handling, logging, and the pre-production checklist.