User Access decides which WordPress accounts may use NIBWP at all. It starts closed: no account can connect an agent until you say so, including administrators.
This is deliberately stricter than WordPress capabilities. Being an administrator means you can do anything through the admin screens; it does not mean an AI client signed in as you should be able to. Those are different questions and this answers the second one.
Deny by default. Open NIBWP, go to User Access, and switch on the specific accounts allowed to connect. Everyone else is refused at the door, whatever their role.
Closed until you open it
Access is a separate decision from role, and separating them buys you a few things:
- Deny by default — A new account cannot connect an agent until someone deliberately enables it.
- Per person, not per role — Grant it to the two people who need it, not to everyone who happens to be an editor.
- Refused at the door — A disallowed account fails before any ability runs, not part-way through one.
- Independent of scopes — Access says who may connect; scopes say what that connection may do.
- Revoked instantly — Switch someone off and their next call fails, without touching their WordPress account.
- Auditable — Who was allowed, and when, is visible rather than inferred from roles.
What a refusal looks like
An account without access does not get a partial result. It gets a clean refusal:
nibwp/wp-list-posts (run)
✗ refused · this account is not enabled for NIBWP
Enable it under NIBWP → User AccessThe message names the fix, because the most common cause is simply that nobody has been switched on yet.
What you can build
A few ways teams use it:
One connected account
Give access to a single account and connect every client as that one.
Per-person access
Let each teammate connect as themselves, so the audit log names a person.
Contractor windows
Switch access on for the length of an engagement and off at the end.
Client sites
Keep access to yourself on a site you maintain for someone else.
How it stays safe
- It is the outer gate — Access is checked before scopes, so a disallowed account never reaches an ability.
- Roles still apply — An enabled account can still only do what its WordPress role permits.
- Scopes still apply — Enabling access does not grant write, delete, files or code. Those are separate.
- Turning it off is immediate — There is no cached grant to wait out.
Getting started
- Open User Access — In WordPress, go to NIBWP and open User Access.
- Enable the accounts you mean — Switch on the specific people who will connect agents.
- Connect as that account — The agent signs in as a WordPress user, so use one you enabled.
- Check the audit log — Confirm the calls you expect are arriving under the account you expect.