Evaluate Breakwater ASOC
Breakwater ASOC connects evidence across IT, IoT and OT. Use AI to investigate threats and rehearse response options. Your team authorizes change and verifies the outcome.
Evaluation guide (PDF / 5 pages) →
A focused scope. Agreed success measures. A decision your team can defend.
Choose a starting point
Choose one product workflow first. Extend across Discover, Provenance and Response when the asset, service and source relationships are established.
Start with one service or network segment and an agreed set of asset and connection evidence.
An attack-path review: supporting relationships, evidence gaps and the next validation steps.
Start with one repository and a known finding set, including software dependencies or cryptographic uses.
A source-backed review: exact references, validation results and an accountable engineering handoff.
Start with one reproducible investigation, an operations owner and an agreed model configuration.
A reviewed proposal: competing explanations, rehearsal findings, approval scope and verification criteria.
From first question to adoption decision
Agree the scope and acceptance criteria before the first run. Use the same inputs and time basis to compare your current process with the selected ASOC workflow.
Choose the case, evidence, owners and operating boundaries.
Run the case. Review AI contributions and the sources behind them.
Test ambiguity, stale evidence and the approval boundary.
Review the value, operating effort and work needed to expand.
Set the schedule together around data readiness, integrations, reviewers and operating windows.
Agentic AI / Human control
An engineering workstation behaves unusually after maintenance. Use a reproducible case to examine intrusion and legitimate change, then compare the response with its operational consequences.
Operational context
The Council / Multiple AI reasoning roles
From proposal to decision
Each role examines a different part of the same investigation. Compare its rationale with the evidence and the other roles before selecting a response.
Triage the signal
Classifies the activity and identifies a relevant attack technique.
Does the workstation activity warrant an intrusion investigation?
Reason about the attack path
Examines a plausible attack sequence and the attacker’s possible next step.
Where could this access lead, and which relationship needs checking?
Interpret the wider pattern
Assesses whether the activity suggests human-operated intrusion or automated noise.
Does the sequence support a coordinated intrusion?
Test a benign explanation
Proposes an alternative explanation and examines whether it survives the evidence.
Could the authorized rollout explain the same observations?
Prepare the response option
Proposes a specific containment action for review, rehearsal and authorization.
Which host, session or key should the team consider restricting?
Roles use the configured model backend and may share a model or use distinct models. Evaluate the actual reasoning and evidence; your team retains authority over operational change.
Explore the Council / Response solution guide, pages 2–3 (PDF) →Ask whether the rollout explains the activity. Inspect the Council’s rationale, dissent and missing evidence against asset, source and observation records.
Retain role outputs and reviewer corrections.
Compare a scoped connection restriction with broader isolation. Check that the dry run matches the proposed operation and target.
Review service impact, omitted effects and recovery.
Test a changed target or expired approval. On the supported test path, inspect service checks and escalation when recovery is incomplete.
Retain the human decision and actual outcome.
Explore the reasoning and control workflow / Response solution guide (PDF) →
Measure the value / Keep the evidence
Set a baseline and acceptance thresholds with your team. Retain the evidence behind both successful results and cases that need more work.
Check source references, evidence freshness and reviewer corrections against the same case.
A reviewable finding with unresolved gaps recorded.
Compare analyst effort and useful findings. Introduce ambiguity and check how the explanation changes.
Sources, alternatives, corrections and time spent.
Test an altered target or expired approval. In an agreed lab path, check verification and recovery behavior.
Approval scope, observed control behavior and outcome checks.
Review setup effort, model and data boundaries, supported integrations and ownership.
Remaining deployment work and a named owner for each item.
A shared evaluation
No. Start with the workflow that addresses your priority. A combined evaluation should establish how asset identities, services and source evidence map across the products.
Agree demonstration, lab and site activities separately. Any operational execution requires a supported path, explicit scope and your organization’s change process. A demonstration or response proposal does not grant permission to make a live change.
Agree the selected deployment, model provider, permitted data access, retention and network dependencies before connecting inputs. Test restricted or disconnected operation against the workflow you actually need.
Set timing during scoping. Data availability, integration work, review capacity and operating windows determine the schedule. Agree staffing and commercial terms alongside the plan.
Your next step
Use the PoC planner to outline your environment and requirements. Review the draft with your team and Breakwater before starting.