Grant your first permission
The goal of the first grant is not usefulness. It is to see the whole control path work end to end on something that cannot hurt you.
- Abilities & permissions
- 4 min read
Pick the right first Ability
Choose one that is:
- Read-only, or an update to something not publicly visible.
- Single-item, not bulk-capable.
- Reversible.
- Actually useful to the agent, so the test exercises a real request rather than a contrived one.
core/get-site-info is a common starting point. Drafting content the agent cannot publish is another.
Set the decision
Open the agent’s permission matrix, find the Ability, and set it to allow. Leave everything else on default deny — you are not building the final boundary today.
The matrix is per agent. Granting here does not affect any other agent, even one connected as the same WordPress user.
Run one real request
Have the agent make the call. Then, before doing anything else, open the activity timeline and read what was recorded: the identity, the Ability, the gate it reached, the outcome, and the linked evidence.
This is the step people skip, and it is the whole exercise. If you cannot read the record of a call you deliberately made, you will not be able to read the record of one you did not.
Then widen, one decision at a time
Change one decision and retry. Changing several at once means the next result cannot tell you which change was responsible.
When you reach an Ability whose consequence you would not accept unattended, set it to require approval rather than allow. That is what approval is for.
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.