Kinsta’s September 24, 2026 article explores AI agents as WordPress operators. For an editorial pilot, start with one narrowly defined operation: create a draft that a person can review, without exposing publication or site administration.
1. Design the operation before wiring up an agent
WordPress’s Abilities API is available from version 6.9 and describes functions through inputs, outputs and permissions. An MCP adapter can expose selected abilities to agents. That connection does not replace authorization inside WordPress.
Ask your developer to implement a dedicated operation in staging. It accepts a title and body, creates a draft, and returns the resulting identifier and state. Keep the state under server control instead of allowing the model to supply an arbitrary status.
This is an example contract for a custom integration, not a built-in WordPress ability:
editorial/prepare-draftAccept: title, contentForce on server: draftReturn: post_id, statusDefine length limits and the accepted content format. If the integration converts text into WordPress blocks, make that conversion explicit and test its output. Avoid leaving the connector to guess what the author intended.
2. Test the effective account and every exposed path
Use a dedicated technical account without administrator privileges. The server implementation must check the capabilities required for the operation. If you later support editing existing drafts, also check access to the particular post rather than trusting an identifier from the agent.
Expose only the draft-preparation tool for this pilot. Review the complete tool inventory available to the agent: a separate publishing route would undermine the intended restriction even if this custom operation is narrow.
Run an acceptance exercise with fictional content:
- Valid input produces a draft.
- A request to publish produces no published post.
- Oversized input fails without a partial creation.
- An unauthorized identity cannot create content.
- A post identifier from another author does not grant edit access.
Check actual records in WordPress administration. An assistant saying it “saved a draft” is not enough to establish what the server stored.
3. Hand over an identifiable review item
Require the result to contain the saved post ID and confirmed state. The reviewer can then find the correct object even when several drafts have similar titles. Review factual claims, links and rendering before a person publishes it.
Keep a minimal audit record linking identity, operation and created object. Duplicating the full article in every log is unnecessary for this purpose. Document how to revoke the account’s access and remove the exposed tool.
Expand the integration only after these tests pass. Updating an existing post and publishing a post are separate capabilities that need their own permission design and acceptance cases.
Sources: Kinsta on WordPress operators and WordPress Abilities API.