OBSERVE
Collect approved security events and build context around assets, identities and behaviour.
CYBERSECURITY
Qavirio Sentinel
AI-assisted defensive cyber detection, evidence and controlled response.
Sentinel is being developed as a defensive platform that observes security events, analyses relationships, makes risk explainable and places response under explicit policy and authority boundaries. The goal is not more alerts, but better-supported action while preserving evidence.
STATUSPILOT RC 2.1.0
REAL INTERFACE
Real Sentinel interface: command, fusion, endpoint boundaries and audit evidence.
Large product views show how information, roles and actions actually work together.
FROM PROBLEM TO WORKFLOW
A security signal is only useful when context, authority and evidence come together.
Modern environments produce large volumes of telemetry and alerts. Sentinel explores a model where observation, AI-assisted analysis, policy and human control remain separated. The platform is explicitly defensive and is not designed as a black box allowed to make unrestricted production changes.
- Too many isolated alerts without operational context
- Hard to reconstruct why a response was initiated
- Automation without clear policy or authority boundary
- Evidence can be lost during containment
THINK
Analyse correlations, deviations, confidence and alternative explanations.
GUARD
Evaluate possible response against policy, role, severity and explicit authority.
ACT
Only permitted, bounded response; high-impact actions remain policy- and authorisation-driven.
CAPABILITIES
What the system actually does.
A capability only matters when it makes a real task, decision or hand-off simpler and controllable.
Event & asset context
Relate security events to identities, endpoints, services and network context.
AI-assisted analysis
Use confidence, alternative explanations and correlation without giving AI authority policy does not grant.
Severity & policy
GREEN, YELLOW, ORANGE and RED structure severity; response remains separately bounded by policy.
Incident evidence
Preserve timeline, actor, policy, outcome and relevant hashes/references for reconstruction.
Controlled containment
Containment is designed to be bounded, authorised and reversible where possible.
Private deployment direction
On-premise/private cloud remains the primary design model for sensitive enterprise and public environments.
PEOPLE & ROLES
The interface follows responsibility.
Security operations
Investigates alerts, incident context, severity and evidence.
CISO / security lead
Governs policy boundaries, authority and assurance requirements.
IT / infrastructure
Assesses deployment, integrations, endpoints and operational recovery.
Audit / governance
Reviews timeline, controls and rationale without operating security controls.
USE CASESDETECTION CONTAINMENT EVIDENCE
Designed for real scenarios.
Contextualised abnormal behaviour
An event is not merely marked “suspicious”; the analyst sees involved assets, earlier events and the basis for severity.
Policy before action
A possible containment action is allowed only when configured policy, role and severity explicitly permit it.
Post-incident reconstruction
A team can review which signals, decisions, overrides and actions led to the outcome.
INSIDE THE PRODUCT
An observe-only pilot core with provable release and authority boundaries.
Sentinel 2.1.0 separates detection, policy, evidence and qualification. The LIVE_LOCAL runtime observes; operational connectors remain zero and ACT remains blocked in the qualified pilot line.
Local control plane
The pilot UI/API operates locally with per-runtime browser session plus CSRF, Host/Origin and cross-origin boundaries.
Qualification as separate evidence
Installed core, clean-machine evidence, external pilot qualification and independent review are treated as separate assurance planes.
Integrity without destructive testing
Tamper tests operate on a temporary staging copy of the installed release; the real installation is not modified to prove a negative test.
VERIFIED TECHNOLOGY
We only name components that are demonstrably used in this product line or implementation.
Local installable pilot line and lifecycle qualification.
Automation for clean-machine, install, acceptance, tamper and lifecycle checks.
Release, qualification and support evidence as structured review data.
Hash references for installer, release and review bundles.
Publisher identity is a separate trust gate from byte integrity.
The pilot control plane stays local and is not published by default as a remote administration surface.
ENGINEERING & TRUST
Technology is strongest when its boundaries are visible.
Detection core and authority model remain separated.
Sentinel follows a layered design: connectors/events provide observations; analysis/correlation produces hypotheses and severity; policy determines what is allowed; audit preserves what happened. Failure of an external connector must not take down the detection core.
Security & data
- Least privilege and strong RBAC
- Tamper-evident / verifiable incident evidence where implemented
- No employee productivity monitoring as product purpose
- No unrestricted black-box autonomy
- Human override and emergency release in governance design
- Data minimisation and configurable retention as design principles
Integrations are privileged boundaries, not marketing checkboxes.
A connector is only described as integrated after contract, authentication, failure handling, rate/abuse controls and relevant vendor or customer acceptance are actually complete. Researched or planned connectors are labelled accordingly.
Deployment & operations
On-premise / private cloud
Primary enterprise/public-sector direction so raw telemetry can remain under customer control.
Hybrid
Controlled external intelligence/update channels where explicitly permitted, without automatic telemetry export by default.
Sovereign / restricted
Local analysis, external AI optional/off and controlled update bundles as a deployment direction for stricter environments.
PRODUCT STATUS
PILOT RC 2.1.0
External Pilot Qualification & Deployment Assurance R1. A pilot release candidate is not a claim of broad production readiness; external pilot, independent assurance, signing and customer-specific acceptance remain separate gates.
Pilot qualification
A Pilot RC is not the same as broad production readiness. External pilot qualification, publisher signing, independent security review and customer-specific acceptance remain separate gates.
DISCUSS THE USE CASE
Pilot / technical review →Does this fit the problem you need to solve?
An initial discussion is about goals, users, existing systems, risks and outcomes — not about selling as much software as possible.