The bridge dispatches an operation through WordPress’s REST system as the authenticated user. The target endpoint’s permission callback still runs. A conversational interface is not a substitute for these checks and should not be treated as a way to bypass them.
Choose a dedicated user for the workflow. When you see a permission denial, first ask whether the user is supposed to have that capability. A denied settings request may be the correct result for a content-focused account.
A read-only workspace omits the write tool from its advertised tools. The companion’s read-only option also blocks non-read dispatch. This allows a site owner to approve a content inventory or draft review without automatically permitting publication.
Once writes are enabled, the native WordPress user still needs the relevant capability. Turning off read-only does not turn a subscriber into an administrator.
Core posts, pages and users expose familiar REST endpoints, but additional plugins define their own routes and controls. Discover the route list and parameter schema on the actual site before invoking a plugin-specific task.
A plugin interface visible in the WordPress dashboard does not necessarily mean that the same action is available through a REST endpoint. When compatibility matters to a purchase, validate it on staging rather than rely on a broad “works with everything” statement.
Application passwords can be revoked without sharing the main WordPress login. Disconnect the client when it should no longer use the workspace, and ask the operator to suspend an account when required.
For important changes, use a staging site, backups and precise instructions. Permission checks limit what an account may do, but they do not decide whether an allowed edit is editorially correct.
Review the security page for account boundaries and the onboarding steps for a concrete verification flow.