Permission denied
This is the single most common support question, and almost every wrong fix for it starts by widening something that should have stayed narrow.
- Abilities & permissions
- 5 min read
First: which gate refused?
Open the activity record for the request. It names the gate. There are only a few possibilities and they have different fixes:
| Gate | Meaning | Fix lives in |
|---|---|---|
| Identity | The agent was not resolvable. | The connection. See Agent not recognized. |
| Native authorization | WordPress said no. | WordPress roles and capabilities. |
| Agent policy | The Ability is blocked, or needs approval. | The permission matrix. |
| Agent state | The agent is paused, expired, or revoked — or read-only, and the request writes. | The Agents screen. See Agent states. |
| Site mode | Read-only or paused is active. | Emergency controls. |
What the agent receives
The response the agent gets already says which side answered:
| Code | HTTP | Meaning |
|---|---|---|
rest_ability_cannot_execute | 403 | WordPress refused. The user this connection is mapped to lacks the capability the Ability needs — expected on a least-privilege user. The fix is in roles and capabilities, never in RuleFence. |
rulefence_ability_blocked | 403 | RuleFence refused. The credential and the capability were fine, but no decision allows the request, or the agent’s state or the site mode refuses it. The activity record gives the reason. |
rulefence_approval_required | 409 | Not refused — held. Once a person approves it, the agent retries the same Ability with exactly the same input before the approval expires. |
None of these means the password is wrong. A wrong or revoked credential fails earlier, with an authentication error.
If it was a native denial
No allow rule, approval, or plan will override it. Ask the real question: should the connection user be able to do this at all?
If no, the agent has been asked to do something outside its remit and the integration is what needs changing. If yes, check that the capability applies to the specific object, not only in general — object-level checks are the usual reason an action succeeds on one post and fails on another.
If it was an agent policy decision
The record says whether the Ability is blocked, requires approval, or has no permission record at all. See Understand a blocked Ability for what each one means and the correction it implies.
The fix to avoid
Every other integration using that WordPress user inherits the new capability, and the change is invisible from the agent screen where you made the decision. If you genuinely must widen access, widen it on a user dedicated to this one agent.
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.