The short version.
- Authenticating an agent and limiting its tools is necessary. It does not review what a multi-step plan changes.
- Have the agent say what it will do before it does it, and put a person in front of anything that cannot be undone.
- Read the System Log back against the plan. A change outside the plan is the signal that matters.
- Suspend, don’t delete, and cap how many accounts one run may touch.
1. Who is calling is not what will change
An agent that is allowed to remove users from groups is allowed to remove every user from every group. Each call is permitted; the plan as a whole is the problem. A prompt hidden in a ticket or a calendar invite can steer a permitted agent into exactly that.
2. Three steps
- Rehearse. Before any call that is not a read, the agent sends the list of calls it intends to make. Each is sorted: a read, a change, or a change that cannot be undone. The answer is allowed, needs approval, or refused.
- Approve. A person approves exactly those calls, for a limited time. Anything that cannot be undone goes to someone senior.
- Verify. Afterwards, the agent’s changes in the System Log are compared with the plan: as planned, did less, or did more.
A plan, as the reviewer sees it. An agent is asked to remove twelve contractors whose end date has passed from a group.
| Calls | What the agent would send | What it does | Answer |
|---|---|---|---|
| 1 | GET /api/v1/groups/{groupId}/users | Reads the members of the group | Allowed: a read |
| 2 to 13 | DELETE /api/v1/groups/{groupId}/users/{userId} | Removes one person from the group, twelve times | Needs approval: a change |
| 14 | DELETE /api/v1/users/{userId} | Deletes a user | Refused: cannot be undone |
Afterwards the System Log shows twelve removals that match the plan. If it also shows two removals from a different group, those are listed as done outside the plan.
3. Rules worth setting
- Suspend, don’t delete. A deleted user’s accounts in downstream systems do not come back with a click.
- Cap the count. No single run may change more than a set number of accounts without a person.
- No direct writes. Where you can, let the agent start a reviewed flow, not call the API itself.
- Limit the token too. A check the agent can skip is not a control. Scope the token in Okta so the worst case is bounded.
4. Try it with Assay
Assay’s agent safe mode does the three steps. Agents reach it over the Model Context Protocol or plain HTTPS: they rehearse a plan, wait for the answer, act, and report. You upload the System Log, or a flow sends it, and each registered agent’s changes are set against its plans; a change outside a plan raises an alert. Assay holds no Okta credential and makes no call itself, so it cannot stop an agent that does not ask. That agent’s changes show up as changes with no plan.
Sources
- The Model Context Protocol specification.
- Okta developer documentation: API tokens, OAuth 2.0 scopes for Okta APIs, and the System Log API.
- Assay: AI agents, on the Features page.
Okta and Okta Workflows are trademarks of Okta, Inc. Assay is independent of Okta. Card names and limits change: check Okta’s current documentation and test in a preview org before you rely on any pattern here.