AgentSOAR overview
AgentSOAR is Jutsu's built-in response automation for your cloud, email, and identity providers. It turns a decision—block this IP, isolate that host, disable that user—into an audited, revertible action against the right provider, whether an analyst runs it by hand or the Response agent executes it under policy.
What AgentSOAR is
AgentSOAR sits between your detections and your providers. You connect provider credentials once, AgentSOAR keeps an inventory of the assets those credentials can act on, and you invoke capabilities—small, named response actions—against that inventory. Every run is recorded as an execution with full context so you can audit it and, in most cases, undo it.
You work with AgentSOAR from the dashboard under /agentsoar/*:
- Inventory — the cloud instances, mailboxes, and users your credentials can reach.
- Playground — run a capability manually against a target.
- Executions — the history of every action, its status, and revert state.
- Containment — active containments currently in effect across your estate.
- Settings → Credentials (
/agentsoar/settings/credentials) — connect and validate provider credentials.
The capability model
A capability is a single response action with a fixed shape: an identifier, the kind of target it applies to, the inputs it needs, and whether it can be reverted. AgentSOAR ships six capabilities across two target kinds:
| Capability | What it does | Target kind |
|---|---|---|
block_ip | Block an attacker IP at the network layer guarding a host | Resource (host) |
isolate | Quarantine a host so it can send and receive no traffic | Resource (host) |
power | Power a host off as containment (revert powers it back on) | Resource (host) |
block_sender | Block an exact sender address into a protected mailbox | Tenant (mailbox) |
block_email_domain | Block an entire sender domain into protected mailboxes | Tenant (domain) |
disable_user | Suspend or disable an identity | Tenant (user) |
Resource capabilities act on a specific inventory asset, such as an EC2 instance. Tenant capabilities act within an email or identity tenant and are routed by the protected mailbox or domain. See Capabilities for the inputs and revert behavior of each.
Supported providers
Each capability is implemented by one or more provider plugins. A capability is only available for a target whose provider supports it.
| Capability | Providers |
|---|---|
block_ip | aws, gcp, azure |
isolate | aws, gcp, azure |
power | aws, gcp, azure, hostinger |
block_sender | google_workspace |
block_email_domain | google_workspace, microsoft_365, agentsoc_mail_block |
disable_user | google_workspace, microsoft_365 |
block_ip and isolate are firewall-backed cloud mutations and are not exposed for Hostinger, which supports power only. Confirm the exact capability set against your deployment's plugin manifest.
How a response runs
A response runs the same way whether a human or an agent triggers it:
- AgentSOAR resolves the target—an inventory asset for resource capabilities, or the credential bound to the mailbox or domain for tenant capabilities.
- It validates the inputs and the credential, then captures revert context (for example, the host's original AWS security groups) before making any change.
- It calls the provider, records the execution, and—for revertible actions—keeps the undo information so you can roll the action back within the revert window.
You can trigger a run two ways:
- Manually, from the Playground, choosing a capability and a target.
- Agent-driven, when the Response agent decides on an action from a triage verdict and executes the matching AgentSOAR capability under your approval policy.
Audit and revert
Every action becomes an execution row with its status, the analyst or agent that ran it, the target, and a log. Most capabilities are revertible: AgentSOAR stores the state it changed and can restore it. Power-off, for instance, is reverted by powering the host back on. See Executions & revert for the lifecycle and revert window.