Containment at machine speed, limited to what you authorised
Response measured in seconds rather than in how long it takes to reach someone. Blast radius is a function of that interval more than of any other single factor.
SOC 2 Readiness
24/7 Security Monitoring
Canadian-Based SOC
GuardsArm Platform · Respond
SOAR — Automation & Active Response
Respond in seconds, with guardrails.
Automation that fires without oversight eventually causes an outage and gets switched off. GuardsArm pairs rule-triggered response with approval gates and safelists so it stays enabled.
- Approval gates
- Same-cycle response
- Reboot-survivable
What is at stake
The gap between detection and containment is where damage happens, and no staffing model closes it at three in the morning.
Automation you can safely leave switched on
Approval gates, safelists and tiering are the reason this does not get disabled after the first bad containment. Most teams who abandoned automation did so because it fired on a single ambiguous alert.
Fewer escalations that did not need a human
Routine, high-confidence responses handled without waking anyone preserves attention for the decisions that genuinely require judgement.
Who carries this
The SOC lead owns the policy. The gating model is usually what makes it acceptable to risk and change management.
The problem
Everyone wants automated response until the first bad one
The case for automation is simple arithmetic. Containment that happens in seconds limits an intrusion in a way containment that happens in forty minutes does not, and no staffing model produces a human response in seconds at three in the morning.
The case against it is experiential. Most teams who have run aggressive automation have a story about the night it isolated something load-bearing on the strength of one ambiguous alert. After that, the automation gets switched off, and the capability is written off as unusable.
Both are right, and the resolution is in what triggers the action. GuardsArm triggers response from correlated incidents rather than from individual alerts. A multi-stage sequence that the correlation engine assembled is a far better basis for an automatic decision than any single signal, however severe it looked on its own.
Response triggered by one alert is a liability. Response triggered by a correlated attack sequence is a control.
Capabilities
What the response engine does
Tiered, rule-triggered active response
Isolate an endpoint, block an address, disable an account, kill a process or quarantine a file — triggered by rule rather than by hand.
Approval gates and safelists
Nothing high-impact fires without sign-off unless explicitly allowed, and safelists keep known-good activity out of the blast radius. SLA escalation covers what is not acted on.
A closed loop inside one cycle
A finding written in one detection cycle can correlate, notify and trigger a response within the same roughly 60-second tick.
Response that survives a reboot
Windows and Linux response actions are proven to persist across endpoint restarts, so containment is not undone by a user power-cycling the machine.
How it fits the platform
Response draws on incidents rather than raw alerts, which means containment is triggered by a correlated attack sequence rather than by a single noisy signal.
How it works
From a correlated incident to an executed action
Six stages, and three of them exist purely to stop the wrong thing happening.
An incident is assembled, not an alert fired
Response is triggered from correlated incidents rather than from raw alerts. This is the single most important design choice on the page: a single noisy signal cannot contain a host, because a single signal does not constitute an incident.
The playbook selects an action tier
The automation engine is playbook-driven with tiered response. The tier reflects both confidence and blast radius — killing a process and isolating a server are not the same decision, and the engine does not treat them as one.
Safelists are consulted
Assets, accounts and addresses on a safelist are exempt. This is how a domain controller, a jump host or a service account stays out of reach of automation that would otherwise be correct to act on it.
The approval gate holds, unless policy says otherwise
Nothing high-impact fires without sign-off unless you have explicitly allowed it to. The default is a gate; removing it for a given action is a decision you make deliberately, per action.
The action executes on the endpoint
Response flows down the same authenticated agent channel that telemetry came up. Windows and Linux actions are both supported, and they are proven to survive an endpoint reboot.
And SLA escalation runs behind it
Where an incident waits on a human, escalation keeps it from sitting. Automation that only fires unattended has no answer for the case where the gate is working as intended and nobody is looking.
The actions
What response can actually do
Graded by blast radius, because that is what determines whether an action should ever run unattended.
| Action | Scope | Detail |
|---|---|---|
| Isolate an endpoint | Host | Cuts the host off the network while leaving the agent channel up, so the investigation continues on a machine the attacker can no longer reach. On Windows this uses WFP-based network isolation. |
| Block an IP address | Host or perimeter | Stops communication with a specific external address. Frequently the right first move when containment of the whole host would be more disruptive than the threat. |
| Disable an account | Identity | One of the nine identity response actions. High impact and almost always a candidate for an approval gate rather than unattended execution. |
| Kill a process | Host | Terminates the specific process rather than the machine. Precise, reversible in effect, and the lowest-disruption option when the malicious process is clearly identified. |
| Quarantine a file | Host | Removes the file from reach while preserving it for analysis. Driven by Malware Center verdicts and YARA hits. |
Guardrails
The four things that make this safe to leave on
A response engine is only as good as its brakes. These are the brakes.
Approval gates
High-impact actions wait for a person by default. The gate is the feature, not an obstacle to it — unattended containment is appropriate for some actions in some environments and for very few actions in most.
Safelists
Explicit exemptions for assets and accounts that must never be touched automatically. Every team has a short list of machines where the cure is worse than the disease; this is where that list lives.
Tiering
Actions are graded by impact, and the trigger threshold differs accordingly. Low-impact, high-confidence responses can run unattended while high-impact ones require the gate.
Reboot survival
A containment that lifts when the user restarts the machine is not a containment. Response actions persist across reboot, which is a tested property rather than an assumption.
Latency
The closed loop, inside one cycle
Detection runs on a roughly sixty-second cycle. A finding written in one cycle can correlate, notify and trigger response within the same tick — so detect-to-respond latency is measured in seconds rather than in the interval between scheduled jobs.
That number is a property of the architecture rather than a service commitment. The detection engine, the correlation engine and the response engine run in the same deployment, on your hardware, reading the same index. There is no queue to a vendor cloud and back in the middle of it.
Background
Understand the concept first
Plain explainers on the underlying ideas, written for someone evaluating rather than buying.
Questions
Common questions
What can it actually do to contain something?
Isolate an endpoint, block an address, disable an account, kill a process or quarantine a file — triggered by rule rather than by hand, on both Windows and Linux.
How do we stop automation causing an outage?
Approval gates mean nothing high-impact fires without sign-off unless explicitly allowed, and safelists keep known-good activity out of the blast radius. SLA escalation covers what is not acted on.
What triggers a response — an alert or an incident?
Response draws on incidents rather than raw alerts, so containment is triggered by a correlated attack sequence rather than by a single noisy signal.
Works with
The modules next to this one
Every module runs in the same self-hosted stack and shares the same telemetry, severity model and response engine.
XDR — Detection & Correlation
Turn raw events into severity-graded, ATT&CK-mapped alerts — then connect them into real attacks.
ExploreFlagship
AI SOC Analyst
An on-prem AI analyst that triages, correlates and explains — using a local LLM, so your data never leaves your network.
ExploreEDR — Endpoint Detection & Response
Deep endpoint visibility and on-box response, from a lightweight native agent.
ExploreSee SOAR running on your own infrastructure
We will walk through the console, the deployment model and what it takes to stand it up in your environment.
24/7 SOC Monitoring Available