Not an alert. A case with evidence.
HCCA, Hybrid Causal-Contextual Analysis, is the core of SENTINEL AI. It does not raise an alert for every suspicious signal. It gathers evidence, weighs it against what is known about your organisation, and reports only when the evidence is sufficient.
What happens to every event
Signal
91 behavioural rules covering 63 MITRE ATT&CK techniques across all 12 tactics. A rule produces evidence with a weight, not an alert: how much more often the behaviour appears during an attack. Reading the memory of the process that holds passwords is ×2,500; bulk file encryption is ×60,000.
Context
The weight is adjusted to facts about the organisation: which program is an approved security agent, which server is a domain controller, who is an administrator, whether a change window is open, whether the account has done this before. Every adjustment is recorded with its reason and factor.
Link
Evidence sharing a process, a logon session, an account or an address becomes one case with an ordered story. Nobody has to assemble forty scattered alerts in their head.
Score
A case starts at 1 in 1,000. Each piece of evidence adds its weight, repeats count for less, and evidence resting on one shared explanation is counted once. A case is raised when the probability crosses the threshold, 60% by default.
How confidence grows
Five real pieces of evidence from a ransomware case. Add them one at a time and watch the moment the platform decides the evidence is enough.
Ransomware
Critical- Document started a command toolT1204.002×40028.6%
- Hidden command textT1027.010×22098.9%
- Reading the password store in memoryT1003.001×2,500>99.9%
- Recovery points destroyedT1490×4,000>99.9%
- Files being encrypted in bulkT1486×60,000>99.9%
No evidence yet: the estimate is the prior, 1 in 1,000.
The product's real rules and weights. Simplified: no context adjustments, repeat discounting or bonuses for linked stages.
What the conventional approach mistakes for an attack
These are not invented examples. This legitimate traffic is built into the model organisation the platform is tested on, because it is exactly what breaks conventional tools.
One case, four readers
The same facts are written for four audiences in any of six languages. Re-rendering years later produces the same words, and the decision fingerprint proves the explanation belongs to its evidence.
- Ransomware on bkp-01. Confidence: 100%. Severity: Critical. Linked steps: 12, over 88.5 s. Raw events: 11.
- Kill-chain stages covered: 2–12. Steps in the chain: 12.
- Step 3: Recovery points destroyed (T1490 Inhibit System Recovery) on ws-013. Weight: decisive. Base ratio 4000, context ×1.
- Step 5: Files being encrypted in bulk (T1486 Data Encrypted for Impact) on ws-013. Weight: decisive. Base ratio 60000, context ×1.
- Ransomware. Computers affected: 2. Accounts affected: 1. It began 88.5 s before the latest activity.
- The platform is 100% certain this is a real attack; it reports only above 60%.
- Separate alerts a conventional tool would have produced here: 12. Contextual checks SENTINEL applied: 4. It reports one incident.
- Proposed next steps await a named person's approval.
- Incident classified Ransomware, severity Critical, confidence 100%. Decision fingerprint 2ec1958896e83c64897c0c1908f0587bab88fef18e77543958f018631d2e821e, rule set 2026.09.1, engine 1.0.0.
- The conclusion rests on the listed evidence, each with its base ratio, contextual adjustment and resulting contribution: 0.1% before the evidence, 100% after.
- No containment was carried out by the platform: every action requires a named person's approval, recorded in the signed ledger. Re-running the engine on the same evidence reproduces this fingerprint exactly.
- Something that looks like Ransomware was detected involving the computer bkp-01 and the account b.lebedev.
- How sure are we: 100 out of 100.
- Why we do not think this is a false alarm. Checks made against what is normal here: 4. Observations set aside as routine: 0. What remained had no innocent explanation.
- What we suggest doing. Nothing happens until a responsible person approves it.
Excerpts of the platform's real output for a ransomware case. The text has not been edited.
The decision stays with a person
For every case the platform proposes ordered actions: what to do, how urgent it is, how it will affect work and whether it can be undone. Nothing runs by itself. The responsible person approves or rejects each action with a reason, and the decision goes into the signed ledger.
Each action is mapped to NIST CSF 2.0 and ISO/IEC 27001:2022.
- Isolate the computer
Cuts the computer off from the network but keeps it running for investigation. The person using it loses access to shared resources.
- Stop the program
Ends the running program immediately. Unsaved work in it is lost and the evidence in its memory disappears.
- Capture the memory
Saves the computer's memory before anything is stopped, preserving proof.
Where the events come from
A one-file agent
A Python script with no third-party libraries. It reads the Security, Sysmon, PowerShell and System logs, remembers where it stopped, and buffers to disk when the platform is unreachable.
Syslog
UDP and TCP. Lines are accepted only from networks named in advance: syslog has no other proof of who sent it.
API
Anything that can send JSON. The platform understands its own format and the Windows event format that Winlogbeat and nxlog produce.
Where it runs
One server covers a few hundred workstations with servers among them. Beyond that, PostgreSQL. An unprivileged Docker image, a Windows service or a systemd unit.
Test it on your own data
A pilot runs on one server inside your network. You see what the platform finds there, and how many alerts stop reaching your analysts.
Request a pilot →