Check the WordPress authority ceiling
RuleFence can only ever narrow what is possible. Understanding that ordering resolves most confusion about why a permission “did not work”.
- Abilities & permissions
- 6 min read
The ordering
Two separate questions are asked, in this order, and only one of them belongs to this plugin:
| Gate | Question | Owner |
|---|---|---|
| Native authorization | Can this WordPress user perform this action at all? | WordPress core roles and capabilities |
| Agent policy | Should this agent be permitted to do it right now, and under what review? | RuleFence |
Native authorization is evaluated independently. It is not something the plugin consults and can choose to override — if it refuses, evaluation stops.
How to check the ceiling
- Find the WordPress user the agent connects as, and its role.
- Open the Ability in the Explorer and read its native permission status — this tells you whether that user could perform it at all.
- If the status is allowed but a specific call was still refused natively, the capability check is object-level. Check that object’s ownership, status, and type.
Object-level checks
Many WordPress capabilities are evaluated against a specific object rather than in the abstract. A Contributor can edit their own unpublished posts. An Author can edit their own published posts but not someone else’s. An Editor can edit others’.
This is why “it worked yesterday” and “it works on this post but not that one” are both common and both correct. The agent’s permission did not change; the object did.
Raising the ceiling, if you must
Sometimes the honest answer is that the connection user is too narrow for legitimate work. If so:
- Raise it on the dedicated user for this agent only, never on a shared or human account.
- Prefer a custom role with exactly the capabilities needed over the next role up the ladder.
- Re-check the agent’s permission matrix afterwards. Raising the ceiling does not grant anything, but it does mean previously impossible actions are now merely blocked — and one grant away.
Once a WordPress user holds a capability, anything authenticating as that user has it — including code paths that never go through a governed request. Policy narrows the governed path only.
Why the ordering is worth the friction
Because it means adding governance cannot accidentally widen access, and removing the plugin cannot leave behind a privilege an agent should not have had. The boundary is a subtraction from what WordPress already permits, never an addition to it.
Abilities & permissions
Keep the boundary while you fix the problem.
A good fix restores intended behaviour without creating a second path around WordPress or the governed request lifecycle.