How to Limit What an AI Agent Can Change in WordPress
Define an AI agent's WordPress targets and fields, review proposed writes and distinguish client controls from restrictions enforced by the server.
Limit an AI agent’s WordPress changes by defining the exact records and fields it may edit, requiring review before consequential writes and using server-enforced permissions where a technical boundary is required. Client tool filters and instructions help control a session, but the server must reject anything the credential is not allowed to do.
With Niwa MCP, distinguish those layers before assigning work. Niwa’s generated MCP token grants administrator access. Its optional options-reading scope does not turn the remaining connection into a restricted writer.
Write a task boundary the owner can inspect
Avoid open-ended assignments such as “improve the website” when you intend one page edit. Define the environment, record IDs, permitted fields, approved replacement and final status.
For a staging delivery page, the boundary could be:
Edit the delivery paragraph on draft page 123 using the approved text. Preserve the remaining content and draft status. Do not change the URL, template, images or other pages. Show the proposal before saving and read the same page afterward.
Use your actual ID. This gives the assistant and reviewer a concrete contract. It does not create a new permission rule inside WordPress. If a credential still allows other changes, the server remains capable of accepting them.
For a product task, use an exact product or variation ID and the approved field. A short-description update should not include price, stock or categories merely because the writer supports those fields.
Separate discovery from permission to execute
MCP tool discovery describes available operations and their input schemas. Calling a tool requests execution. The MCP tools specification also defines annotations, including read-only hints. A hint is metadata; authorization belongs to the server.
Ask an assistant to prepare a proposal without calling a writer. Review the target and actual arguments before permitting execution. A direct Niwa write-tool call can complete the internal preview/action flow, so do not invoke a writer simply to inspect the likely outcome.
For a whole task handed to Niwa’s configured agent, inspect the discovered niwa_agent_run schema and its allow_writes argument. That setting controls the requested agent job. It is not a general read-only property of the MCP credential or every other tool available through it.
Use client controls for the client you manage
Codex supports enabled_tools, disabled_tools and server-level or tool-level approval modes. Claude Code provides its own MCP and permission controls. Apply the mechanism supported by the actual client version and verify its behavior in the active session.
For example, you can start a client with only the page-reading operation available while gathering information. Later, enable the necessary writer for a reviewed task. Keep separate configurations clearly named so an agent does not connect to the wrong environment.
The Codex configuration reference describes those options. A client allow list restricts that client’s exposed tools. It does not prevent someone holding the same token from requesting another tool directly from the server.
Check the server’s actual authorization model
WordPress has roles and capabilities that determine what users may do. The WordPress permissions reference explains those building blocks. A connector must map its authentication and operations to the appropriate checks for those permissions to become a useful boundary.
Niwa’s current generated administrator token is broad. Expiry and revocation control its lifetime. The read_options scope specifically controls the WordPress-options reader; leaving it off does not disable page or product writers.
Other connectors may expose individual registered abilities with capability checks, as described in the WooCommerce MCP documentation. If you need an enforced restriction to a particular class of operations, choose and verify a server configuration that implements it. Do not assume a dedicated user’s role automatically makes every connector narrower.
Verify the boundary with an isolated test
Use a staging environment and disposable records. Check that the permitted read succeeds, the intended permitted edit succeeds and a forbidden operation is rejected by the layer you expect to enforce it.
Distinguish a client declining to call a tool from the server rejecting a direct request. They establish different facts. Do not test a forbidden deletion on a live business page to prove that a production token is powerful.
Save the target ID, before/after values and rejection result. If a write times out, inspect the record before retrying. For queued work, retain the job handle and check its final result.
Review the completed scope
After the authorized edit, retrieve the record again and inspect the page or product preview. Verify the requested field and consequential unchanged fields, such as status and URL. An assistant’s completion message is useful only when it matches saved state.
Use a bounded credential lifetime and retain a way to revoke the connection. Existing WordPress owners can install Niwa’s standalone plugin and configure workflows around the tasks they actually need. Discuss your permitted WordPress changes with Niwa, including whether you need owner review or a server-enforced restriction. The Niwa setup guide explains the site’s connection settings.
