Rihuum Sentinel AI Cybersecurity Suite
Cybersecurity capability classified by evidence and operating boundary.
Sentinel AI is a controlled architecture for lawful protection, detection, response, recovery and assurance. Its module register distinguishes product foundations, integrations still required and research directions.
A named module is not proof of a deployed control, certification, customer implementation, SOC or managed detection service.
Request an assessment →- Architecture
- v0.2.0-alpha
- Named modules
- 40
- Adapter required
- 14 modules
- Planned research
- 3 modules
01 / Delivery domains
An accountable security lifecycle, not a wall of product names.
Engagement begins with actual assets, users, threats, obligations and recovery requirements. Product and service scope follows the assessment.
- Device and asset recovery
- SecureTrack requirements for lawful enrolment, approved signals and evidence-preserving recovery.
- Endpoint defence
- Inventory, posture, encryption, policy and security-agent health for supported managed devices.
- Authorised network security
- Asset visibility, availability, configuration review and alerting on customer-owned networks.
- Identity security
- Multifactor authentication, session protection, privileged access and accountable user lifecycle controls.
- Incident operations
- Intake, triage, assignment, evidence preservation, playbooks, communications and reporting.
- Data resilience
- Backup, restoration testing, privacy controls, retention, continuity and recovery evidence.
- Smart-security integration
- Assessed CCTV, access control, alarms, sensors and related authorised infrastructure.
- Governance and assurance
- Risk, policy, supplier, vulnerability, readiness and controlled improvement records.
02 / Capability maturity register
Forty modules, three evidence classes.
Each module must pass requirements, threat modelling, secure engineering, test, evidence, commercial approval and deployment acceptance.
| Class | Evidence boundary | Module register |
|---|---|---|
| Module foundation 23 modules | Named architecture and control boundaries; not proof of a deployed security control. | AI and Model Security · WebShield · API and Mobile Security · SecureTrack AI · Security Orchestration · Container Security · Cloud Security · Cryptographic Governance · Evidence Vault · Deception Defence · Threat Hunting · Endpoint Defence · Security Posture · Vulnerability and Attack Surface · Attack Path Analysis · Digital Risk · Fraud and Abuse Defence · Governance Risk and Compliance · Third-Party Risk · Phishing Defence · Insider Risk · Identity Security · Secrets Security |
| Adapter required 14 modules | Requires approved credentials, collectors, hardware, contracts, certification or production acceptance. | Incident Command · Hospitality Cyber Defence · Managed Detection and Response · Email Security · Mobile Security · Network Defence · Smart and Physical Security · Core Security Services · Privacy Engineering · DevSecOps · Ransomware Resilience · Business Continuity · SaaS Security · Security Operations Centre |
| Planned 3 modules | Research direction only; no operational or commercial availability is represented. | Threat Intelligence · Cyber Range and Readiness · Remote and Distributed-Work Security |
03 / Operating architecture
Controls become real only inside an accepted operating model.
Tools alone do not determine protection. Ownership, access, monitoring, response, recovery and change responsibilities must be explicit.
- Customer scope
- Named assets, identities, networks, data, obligations, threats and recovery objectives.
- Security products
- Versioned endpoint, identity, network, incident, evidence and resilience modules.
- Intelligence
- Approved knowledge and bounded analysis with source, confidence and human review.
- Enterprise controls
- RME identity, tenancy, policy, entitlement, workflow, audit, notification and support.
- Operations
- Commissioned deployment, observability, backup, recovery, change and incident responsibilities.
04 / Lawful operating boundary
Security authority must be established before access.
Rihuum works only on systems, devices and data that the customer is authorised to assess, protect or manage.
- Every device, account, network and asset must be owned, voluntarily enrolled or lawfully managed by the customer.
- No arbitrary person or device can be located from a telephone number, IMEI, email address or IP address.
- No hidden microphone or camera activation, keylogging, credential theft, message interception or covert surveillance.
- Telecom subscriber records, tower data and interception require the relevant operator and lawful authority.
- A module name does not prove operational depth, certification, customer deployment or round-the-clock monitoring.
- A production service requires agreed scope, access, response duties, infrastructure, evidence and acceptance.
Security engagement
Begin with the environment and the evidence you need.
An assessment can define assets, exposure, current controls, operating gaps, priorities and an acceptance plan.