How to Give an AI Agent Read-Only WordPress Access
Give an AI assistant only the server-enforced reading permissions it needs, then verify that a staging write is denied.
Give the agent a connection whose server rejects write operations, allow only the reading tasks it needs and test the restriction on staging. A prompt saying “do not edit anything” or a tool’s readOnlyHint is not an access-control boundary. The credential and the server’s permission checks must enforce the rule.
Niwa MCP provides supported owner operations, but its documented generated tokens grant administrator access. They should not be described as strict read-only credentials. Niwa can be useful for your broader owner and customer workflows; a mandatory no-write external connection needs controls that actually provide that boundary.
Define what the assistant is allowed to read
List the task’s objects and fields before configuring access. An assistant summarizing published pages does not need private orders, customer contact details or WordPress configuration. A report reader may need a protected aggregate result rather than access to every underlying record.
If the task only needs public content, start with public sources instead of granting an administrator credential. You may not need an authenticated WordPress connector at all. For protected content, identify exactly which permission will authorize the read.
Read-only does not mean privacy-safe by itself. A credential may be unable to edit orders while still retrieving sensitive information. Limit the data path as well as the write path, including what the external client sends to its model provider.
Use documented server controls where available
For an eligible WordPress.com or Jetpack-connected site, WordPress.com documents Read and Write tool controls. Its authorization flow includes a Read only choice, which turns off Write tools in the account settings. Review the effective controls for the intended site and keep only the necessary reading tools enabled.
Account-level preferences are shared, and site-level overrides can change the effective selection. Review both rather than assuming one authorization screen describes every site and client. A later Full access authorization can change account settings, so recheck the boundary when another assistant is connected.
For other servers, look for an explicit enforced policy: a restricted role, per-token scopes or a configured allowlist checked during execution. Confirm which objects that policy covers. A tool being absent from a displayed list does not establish that the server would reject a direct invocation.
Treat custom WordPress permissions as implementation work
The official MCP Adapter bridges registered abilities and their permission checks. A developer can expose the required reading abilities and ensure write abilities are inaccessible to the connection. The bridge itself is not evidence that the complete permission policy has been built.
For a REST-backed integration, authentication identifies the WordPress user; the endpoint’s capability checks determine the allowed action. The REST authentication handbook and permission callback guidance describe those responsibilities.
A separate application password provides a separately managed credential, but does not automatically narrow that user’s privileges to reading. Likewise, a low-privilege WordPress role may not be able to read the private data you need. Have the implementation checked against both the permitted read and the forbidden write rather than choosing a role by its name.
Understand Niwa’s current external-token boundary
Niwa’s MCP settings guide explicitly describes generated tokens as administrator-level credentials. It provides lifetimes, client configuration and revocation. Those controls are useful for an owner connection, but token expiry is a time limit rather than an operation limit.
The wp_option_get checkbox controls whether that token can use the option-reading tool. Disabling it does not make the rest of the catalog read-only. WordPress options can contain private configuration, so that choice also matters independently of write permissions.
You can start a Niwa session with a small reading request and review later changes carefully. Describe that as cautious operation with administrator authority. If your policy requires the server to reject every unwanted write, do not treat this workflow as a substitute for a supported restriction.
Verify both an allowed read and a denied write
Use staging with a non-sensitive test object. First, request the intended protected read and confirm the result against WordPress. A successful request for a public page does not prove that the credential or its protected-reading permission works.
Then test an operation that must be forbidden, such as changing the title of a designated test draft. Have the test supervised and record the original value. The expected result is an authorization rejection and an unchanged record. If the operation succeeds, withdraw the credential and fix the permission policy before using it on production.
The MCP specification treats annotations as tool metadata. Do not accept a reassuring label instead of this execution check. Retest when the connector’s roles, scopes or exposed abilities change.
Keep the boundary after the first setup
Record the client, issuer, allowed reading tasks and the place where the policy is enforced. Use a separate credential for each client where supported, so one connection can be retired independently. Review active credentials and revoke those no longer needed.
If a new tool group is enabled, review its actual authority before continuing. Reading requirements can expand gradually until a once-narrow connection retrieves much more than intended. Keep the allowed-data list tied to the business task.
For an existing WordPress site, Niwa’s standalone plugin can provide its configured business workflows. Describe your task and strict access requirement to Niwa. State whether you need public-page research, protected reports or owner operations. The right next step should respect that boundary rather than merely ask the assistant to behave cautiously.
