Identity
Agent states: which one to use
Four states, each with a different blast radius. Choosing the right one is the difference between containing a problem and stopping the business.
- Agents & identity
- 4 min read
The four states
| State | What the agent can do | Use when |
|---|---|---|
| Active | Whatever its permission matrix allows, subject to native authority and site mode. | Normal operation. |
| Restricted | A reduced boundary — enough to keep low-risk work moving while consequential work is held. | You have a concern but not an incident. |
| Paused | Nothing. Requests are refused; the identity and credential remain. | You need it to stop now and expect it back. |
| Revoked | Nothing, permanently. Credentials are invalidated and sessions terminated. | This agent should not act again. |
Agent state versus site mode
Agent state affects one agent. Site mode affects every agent at once. If you know which agent is misbehaving, pause that agent — dropping the whole site to read-only stops six integrations to fix one.
If you do not yet know which agent is responsible, use site mode. It is the right tool for exactly that uncertainty.
Every change is recorded
Creation, activation, restriction, pause, and revocation are all administrator lifecycle events in the audit trail, with who did it and when. State changes are decisions, and they are recorded like decisions.
Coming back
Moving an agent from paused back to active restores exactly the permission matrix it had. Pausing does not clear permissions, and unpausing does not re-grant anything.
That is a reason to change the permission before you unpause. See Return to normal after an incident.
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.