Executions & revert
Every AgentSOAR action becomes an execution—a record of what was run, against which target, by whom, and what happened. This page covers the status lifecycle, why an action fails, where to find execution history, and how revert restores what an action changed.
The execution lifecycle
An execution moves through a defined set of statuses from the moment AgentSOAR accepts the request to its final outcome.
| Status | Meaning |
|---|---|
pending | The execution is accepted and queued; AgentSOAR has captured its id before any provider call. |
running | AgentSOAR is calling the provider to perform the action. |
succeeded | The action completed and is in effect. |
failed | The action did not complete; see the failure reason. |
reverted | A previously succeeded action was successfully undone. |
revert_failed | A revert was attempted but did not complete; it can be retried. |
awaiting_reauth | The credential is invalid or expired and must be re-authenticated before the action can proceed. |
expired_awaiting_reauth | The re-authentication window passed without action; the run is closed out. |
A run flagged awaiting_reauth waits for you to re-authenticate the credential (see Credentials & domains). If you don't act within the cutoff window, it becomes expired_awaiting_reauth.
A run shown as failed with an internal "superseded" marker is a deduplicated run, not a real failure—the same action was already applied by another execution, which holds the effect. Confirm how your deployment surfaces deduplicated runs.
Failure reasons
When an execution fails, AgentSOAR attaches a reason so you can tell a credential problem from a provider problem from a bad input:
| Reason | What it means |
|---|---|
credential_invalid | The provider credential was rejected—rotate or re-authenticate it. |
cloud_api_error | The provider's API returned an error while performing the action. |
inventory_not_found | The target resource could not be resolved in inventory. |
input_invalid | The action's inputs failed validation. |
Viewing execution history
Open Executions at /agentsoar/executions for the full history. Each row shows the capability, the target, the status, who ran it (an analyst or the Response agent), the timestamps, and the action log. You can filter by status—for example, to find everything awaiting_reauth—to focus on runs that need attention. Active containments currently in effect are also summarized on the Containment page.
How revert works
Most capabilities are revertible. Before changing anything, AgentSOAR captures revert context—the exact state it is about to modify, such as a host's original AWS security groups, the deny entries it added, or a user's prior account state. Revert uses that stored context to put things back:
block_ipremoves the deny rules it added.isolaterestores the host's original network configuration.powerbrings the host back online.block_senderandblock_email_domaindelete the filter or blocklist entry.disable_userrestores the user's prior state.
A succeeded action can be reverted while it is within its revert window and the revert context is still available. A revert_failed run can be retried.
Revert depends on the original state being captured. AWS isolate is not revertible when the host was already isolated at run time, because the original security groups were no longer there to record. Plan isolation and revert deliberately.