Least privilege sounds simple: give each identity only the access it needs. The hard part is deciding what “needs” means on a live WordPress site where work, people and integrations change.
Treat it as a repeatable workflow, not a one-time role cleanup. Start with a task, define the allowed action, apply the rule, and prove that the intended person can work while others cannot.
Write the task before the permission
Begin with a sentence a teammate can verify: “The editorial contractor can update assigned drafts, but cannot publish or change site settings.” That is more useful than “give them an Editor role.” The sentence names a purpose and a boundary.
For each sensitive task, capture four things:
| Question | Example |
|---|---|
| Who needs it? | The editorial contractor |
| What action is required? | Edit assigned drafts |
| What must stay outside their reach? | Publishing and site settings |
| When should this be reviewed? | At the end of the contract |
Do this for integrations too. An Application Password is an authenticated route into WordPress; it should have an owner, a purpose and a removal point. The user account behind it is part of the access decision.
Apply the narrowest workable rule
Use WordPress capabilities and AAM controls to express the task. AAM can help manage access for roles, individual users, content, admin areas, URLs and API routes. Where several sites need the same rule, a documented AAM access policy can make the intent easier to carry and review.
Avoid creating an exception merely because it fixes one screen. Check whether the rule affects another route to the same resource. If your code registers a custom REST endpoint, its permission callback still needs to authorize the requested action. AAM controls and application code should tell the same story.
Verify both sides of the boundary
Test with an identity that should be allowed and one that should be denied. Confirm the real action, not only whether a menu item appears. For content, try the target object; for an API, test the endpoint; for a credential, test the integration’s actual workflow.
Keep a small record: what changed, why, who approved it and which tests passed. This makes later reviews faster and helps explain why a permission exists. If a rule cannot be explained in one or two sentences, it may be too broad or too tangled.
Make review part of the work
Revisit access when a contractor leaves, a client changes staff, a plugin adds a new capability, an integration rotates credentials or a site changes owner. These events are more useful review triggers than a calendar reminder alone.
You can use AAM’s Security Audit guidance to find areas worth checking, then validate the resulting decisions in the site itself. The goal is not a perfect permission spreadsheet. It is a permission model that stays understandable as the site changes.
Next: Make governance your advantage. Back: Think beyond roles.