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. |
| Site mode | Read-only or paused is active. | Emergency controls. |
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.