Contain an Agent from an Incident

Tasks

When an incident shows an agent doing something you do not trust, cut it off from the incident drawer. AIControls blocks the agent at the gateway, records who did it, and leaves a one-click way back.

Before you start

Only administrators see the action. It works for an agent or service account, for an agent acting on behalf of a person (including a Cross-App Access or Okta governed agent), and for a workload. It never blocks a person's own account: use Notify user on the finding instead. For how incidents and actors are formed, see Security posture.

Revoke the agent's access

1. Open the incident or finding. Go to Security → Activity → Correlated findings and select a row. The action sits under the triage actions in the incident drawer, and under the verdict in the finding drawer.
2. Select Revoke agent access... The button appears only when the incident's actor resolves to an agent the deployment can block. Otherwise one line under the actions says why, for example that the actor is a person's own account.
3. Review what is cut off. The dialog names the agent and its cluster, every MCP, LLM and HTTP call it makes in that cluster, the active virtual keys that will stop working, and how many sessions are active. For an agent acting for a person it says whose agent it is and that the person's own access does not change. For a workload it lists the agents bound to it. The block is scoped to the incident's cluster: the same agent id in another cluster keeps working.
4. Decide about the virtual keys. When the agent has active virtual keys, the dialog offers Also revoke N virtual keys, unchecked by default. Checking it revokes those keys together with the block. A revoked virtual key cannot be undone, and Unblock does not bring it back: issue a new key instead. Each revoked key has its own configuration audit event.
5. Add a reason (optional) and confirm. Select Revoke access. The reason is shown to the blocked agent; without one it sees a generic message that does not name you. The block takes effect on this replica at once. In a multi-replica deployment other replicas apply it on their next policy sync, 60 seconds by default.

The incident's Triage history records revoked agent access with the policy name, and the change is in Security → Activity → Configuration as one event.

Restore access

1. Open the identity. Use the link in the dialog or in the drawer, or find the agent on Inventory → Identities. It shows a Blocked tag. A workload block has no identity page of its own: delete its policy under Security → Policies instead; the dialog names it.
2. Select Unblock identity. This deletes the generated policy. The agent's traffic is governed by ordinary policy again, and its credentials work as before. Virtual keys revoked with the block stay revoked.

The block is the same one the Identities page creates with Block, so both pages show the same state. You can also delete the identity-block- policy under Security → Policies; see Manage identity lifecycle.

What you can and cannot revoke

The incident's actor	Result
A service account or agent with a virtual key, a Kubernetes service-account token or a service-account session	Revocable. The block matches the agent id in both spellings (runner and prod/runner), so it covers every credential the agent uses, in the incident's cluster.
An agent acting for a person	Revocable. Only the agent is blocked, not the person.
A Cross-App Access (Okta) governed agent	Revocable. The block matches the agent's client id for that person only, so the person's own access, their other governed agents and other people using the same client keep working.
A workload	Revocable when agents seen in the last 24 hours are bound to it in its cluster. One policy blocks all of them, in that cluster only. A workload with no recently seen bound agent, with an agent shared with another workload or namespace, or recorded without its cluster, is not offered: contain it from its Workloads page.
A person acting directly (a developer's own token or SSO session)	Not offered. Revoking it would lock the person out entirely. Use Notify user.
An agent with no recorded cluster whose id also runs in a cluster	Not offered. Without a cluster the block would reach that cluster too. Revoke that cluster's virtual key under Setup → Settings, on the Virtual Keys tab, instead.
The bare agent name also used in another namespace of the same cluster	Not offered, for the same reason.
An agent that already has a partial block (for example MCP only) from the Identities page	Not offered. Widening it here would make Unblock delete your earlier block. Widen or replace it on the Identities page.
An agent whose Identities-page block is switched off	Not offered. Switch it on or remove it there; this action never takes over a block it did not create.
An agent whose identity row does not record the incident's cluster	Not offered. The agent id could belong to another cluster; the row records its cluster on the agent's next request.
No recorded identity	Not offered.

By default credentials are not deleted or revoked. A revoked virtual key or personal access token cannot be restored, but a block can, which is why the block is the lever used here; the virtual key option is for when you also want the keys gone for good.

Other replicas apply the block on their next policy sync, 60 seconds by default (policy.cacheTTLSeconds); there is no push. A revoked virtual key stops working at once on the MCP path and within about 5 seconds on the LLM path.

For the routes, errors and audit events, see Revoke agent access.

Agent-owned active session counts follow the session list’s lifecycle and idle setting. A session owned by a person cannot be attributed to one XAA client, so client previews explain this instead of showing a zero count. A matching legacy identity with no recorded cluster refuses the action until its cluster is recorded.