Demo: SOC agent guided Review — drift → exact cut → Verified

The primary CISO demo (sv0-platform#1800 / #1825). One agent, one material drift, one supported change, one verified outcome — in under three minutes, with zero clicks to reach the answer.

The sentence the audience should leave with (Sergey's pitch):

"Can this automation isolate production machines, and what would break if we removed that authority?"

What this demo is (Sergey's 2026-07-17 acceptance). The finding proves a new high-impact capability was gained relative to the prior observed configuration — the product says review required; it never claims the authority is unauthorized (no policy/approval provenance is displayed). The demo stays on the finding page: the existing Rehearse revocation → What breaks / What survives experience shows, by default, which workloads lose the isolation capability (with observed-use evidence) and what investigation access survives. One click on the agent shows its full Blast Radius — the graph walks from sv0-soc-responder through the stitched playbook to the isolation permission.

Explicitly EXCLUDED from this demo (Sergey NO-GO on PR #1839, tracked in sv0-platform#1840): the Finding → Entity Review tab path and its compact rehearsal result. Do not click "Review this finding" during the demo.

What this demo is NOT — required disclosure, say it verbatim:

"This is a deterministic synthetic fixture showing the SecurityV0 Review workflow. It is not a live Azure scan and does not claim the Defender action executed."

(The live x2/contoso counterpart exists and is code-ready; it is presented only after its own rehearsals pass — see the engineering runbook.)

---

Environment — dev, not localhost

Everything runs on https://dev.securityv0.com, tenant demo-microsoft-soc. The tenant is re-seeded to the drift state automatically on every main deploy — the demo's opening state is standing by default.

State	What Review shows	How to set it
drift (default)	Five guided blocks, action = remove Machine.Isolate	automatic on deploy, or the workflow below
remediated	Verified leads the page	workflow below with seed_phase=remediated
baseline	No drift finding (before/after contrast)	workflow below with seed_phase=baseline

State switching is one GitHub Actions dispatch (Actions → PR Preview Admin):

gh workflow run pr-preview-admin.yml --repo SecurityV0/sv0-platform \
  -f instance=main -f action=seed-demo-sentinel -f seed_phase=remediated

One-time per environment (idempotent, safe to re-run): enable the guided-surface flags for the tenant:

gh workflow run pr-preview-admin.yml --repo SecurityV0/sv0-platform \
  -f instance=main -f action=enable-rehearsal -f rehearsal_tenant=demo-microsoft-soc

Pre-demo checklist (10 minutes before)

1. gh run list --repo SecurityV0/sv0-platform --workflow deploy-dev.yml --limit 1 — latest deploy green.
2. Flags workflow run once (above).
3. Open https://dev.securityv0.com/t/demo-microsoft-soc/findings → the critical Action capability gained finding. Confirm the finding page renders the drift description and the Rehearse revocation control, run it once, and check the What breaks / What survives rows render — the two dependent callers with recent-execution evidence, and the retained getMachine investigation path. (Do NOT plan the demo around "Review this finding" — the Entity Review path is excluded, sv0-platform#1840.)
4. Open sv0-soc-responder in Graph Explorer and click "Blast from here" — confirm the blast reaches past the playbook to the managed identity, the role, and the endpoint-isolation permission (not "1 reachable": if it dead-ends at the connection record, the stitch didn't form — re-run the seed workflow).

The three-minute script

Start on the finding (Findings → the critical Action capability gained row) — the analyst's natural entry point, and the page the WHOLE demo stays on (plus one Graph Explorer beat). Speak the disclosure, then:

1. What was detected. The critical finding: "The identity 'Isolate-Machine-Playbook MI' gained 1 action-capable permission(s) since baseline: 'Defender endpoint isolation (isolateMachine)' (escalation)." Say it the way the evidence supports it: "A new high-impact capability requires review." — the platform proves this authority is NEW against the observed baseline; it does not claim the SOC responder should not have it.
2. What would this agent reach? One click. Open the agent sv0-soc-responder in Graph Explorer and click "Blast from here" — the write-reach view opens unbounded for agents, no tuning. The Foundry connection and the Logic App are stitched as one operational resource (legend: "One resource, two system views"), so the route runs straight through: agent → playbook → managed identity → role → the endpoint-isolation permission. "The whole chain, from the agent, in one click."
3. What would break if we removed it? Back on the finding page, run Rehearse revocation for the recommended grant. The verdict answers in rows, visible by default:
   • What breaks — one row per affected workload: the capability/path it loses, its observed-use status, and the last observed execution (time / action / count) where evidence exists. The two dependent callers — Incident-Commander-Playbook and Triage-Escalation-Playbook — show recent executions: these paths are provably active, not just configured.
   • What survives — the retained read-only investigation access (getMachine) and any surviving parallel path. "Read-only simulation — against the modeled access, never against your systems. This is the decision: what stops, what keeps working, with the execution evidence behind each row."
4. Close on the operator's question, not a verdict: the platform showed what the automation can do, what is new, and exactly what removing the authority would cost — the removal decision belongs to the customer's policy owner, with evidence instead of guesswork.

Close with the pitch sentence.

Hard questions, honest answers

• "Was isolation ever actually used?" — Execution evidence is recorded per workload, not per access path (the caveat is on screen). We say "configured, not observed" — never "unused, therefore safe."
• "Would removing it break my SOC?" — That's the rehearsal, and it answers in rows: which workloads lose the isolation capability (the dependent callers Incident-Commander-Playbook and Triage-Escalation-Playbook carry recent execution evidence proving those paths are active), and what survives — the retained read-only investigation path. Proven from the rehearsal verdict, not inferred.
• "Should this automation have isolation authority at all?" — The product does not decide that: it proves the capability is NEW against the observed baseline and shows exactly what removing it would cost. The policy call — approved business purpose or not — stays with the customer, now with evidence.
• "Is this my live Azure?" — No (disclosure). The identical pipeline runs against a live Sentinel/Defender lab; the live path ships behind its own rehearsal gate. Where live evidence can't prove a single causal cut, the product says Requires design instead of guessing.

Engineering reference

Local reproduce-from-scratch, the five-leg Verified gate definition, and the live x2/contoso path: SOC guided review — engineering runbook.