A SOAR playbook's host-isolation step returns success — what does that actually prove?

## Three claims that look identical in a run log When a playbook in a response platform such as Cortex XSOAR or Tines executes an isolate-host action, three different things might be true, and only the weakest is evidenced by a green step: 1. **The platform sent the request and the EDR's API accepted it.** This is what an HTTP 2xx response and a completed task record. 2. **The EDR has recorded the intent to contain that host** — visible in its console as a state such as `containment pending`. 3. **The host is actually cut off** — its agent has checked in, received the policy, and now drops traffic to everything except the EDR's own management channel. The automation's execution record can only ever evidence (1). Everything a responder cares about lives in (3). ## Why the gap exists Endpoint isolation is not something the console does to the network; it is something the *agent on the host* does to itself, on instruction. The console holds a desired state and hands it out at the agent's next check-in. That interval is normally seconds to a few minutes and is invisible when nothing is wrong. It becomes very visible when: - the machine is powered off, suspended, or on a network the agent cannot reach — the containment is queued, not applied; - the agent process has been stopped, tampered with, or its driver unloaded — the console may still show a stale "last seen" and accept the request forever; - the host is ephemeral. A container-based or autoscaled CI runner may already have been destroyed and replaced, so the isolation applies to an identifier that no longer maps to a running machine — and to nothing that matters; - the connector's credential is valid for the API but the account lacks the containment permission, so some deployments return an accepted-then-rejected pattern. ## Why the distinction is not pedantry with an intruder present The minutes between "request accepted" and "policy enforced" are minutes during which an adversary with hands on the keyboard is still able to act: finish staging data, drop an additional persistence mechanism, or notice the attempt and pivot. An adversary who sees an isolation attempt coming often behaves very differently from one who does not, so this window is exactly where the case is won or lost. Recording it as contained means every subsequent finding is reasoned about against the wrong assumption. It also matters for the claim you will eventually have to defend. "The host was contained at 03:14" is a statement about the world. If the only support for it is a playbook task that finished, the statement is unsupported. ## How to verify properly Use evidence produced by the target, not by the automation: - **The EDR's host record** — a confirmed containment state with its own timestamp. This is the minimum bar, and it is what your case timeline should quote. - **Independent telemetry** — the host's network connections stopping, or flow records showing the host reaching only the EDR's management endpoints. Note what a flow record can and cannot tell you: it shows that bytes stopped moving, never what they were. - **A second control path** — if the agent will not confirm, fall back to a network-level quarantine (switch port, network access control, or, for a cloud instance, a restrictive security group). This does not depend on the compromised host cooperating. ## What to write down Record two timestamps, always: when the containment action was *requested*, and when containment was *observed*. The distance between them is a real quantity in the incident — it bounds what the adversary could still do — and it is also the number that shows whether your response tooling is as fast as your report claims. If containment is never observed, the case says so; a pending state is not a contained state, and no amount of green in the run log converts one into the other. ## The general rule this teaches Automation records what it *attempted*. Targets record what *happened*. Any verdict about the state of the estate must be sourced from the second. This applies well beyond isolation: disabling an account, blocking a hash, quarantining a build artifact — in every case, the proof is the target system's own audit entry, not the step that asked for it.