Identity
Keep staging and production agents separate
The same agent name in two environments stays two distinct records, with two credentials and two permission matrices. This is not duplication — it is the point.
- Agents & identity
- 3 min read
Why environment belongs to identity
If environment were only a label, a staging credential would work against production and a permission granted for a test would silently apply to real customers. Making it part of identity means a boundary proven on staging is promoted deliberately rather than inherited by accident.
Promoting a boundary
- Prove the workflow on staging with a staging agent and a staging credential.
- Write down the permission decisions that ended up being right — which Abilities are allow, which are approval, which stayed blocked.
- Create the production agent, with its own dedicated user and its own credential.
- Apply those decisions deliberately on production, starting narrower if the production data is more consequential.
On the Agency plan, reusable governance standards make step four repeatable across sites without copying decisions by hand.
When staging is a clone of production
A staging site restored from a production backup contains production agents, their permissions, and their audit chain. Before pointing anything at it: revoke the cloned connections, and treat the cloned audit chain as a copy rather than as the record.
The production credentials themselves will not work from the clone if you revoke them there — but they exist in that database until you do.
Agents & identity
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.