From infrastructure alerts to controlled resolution.

CyberSentry detects problems across supported servers, explains what matters, and helps your team resolve routine issues through approved, checked and recorded fixes.

Built first for MSPs and lean IT teams handling recurring server incidents.

See CyberSentry in action

Ask our AI companion

21:15 · 9 servers watchedIllustration

web-01
db-01
mail-01
app-01
backup-01
files-01
api-01
web-02
vpn-01

✓ Resolved · verifiedbackup-01

backup-compress was stopped and checked

It waited for approval: it is not on the known-bad list.

AICould be a stuck job or legitimate heavy work. Apply Fix stops it and reads the server back.

Apply FixDismissPreview✓ Not running after apply (read back from the server)

Watch the real recording 25 s

An illustration of one real lab run, not a product screen.

Runs on your infrastructure
No agent on each server
Fixes on Linux, monitoring on Windows
Self-healing off by default

You’ve seen what it does. Ask how it fits your environment.

Put your questions about automation, access, your existing tools and the pilot to our AI technical companion, in a live conversation.

What it is: A voice and video conversation with an AI, run by Tavus. It is separate from the product. A question you pick goes in as your first message; if the companion misses it, ask it aloud.
What you need: A microphone. Your camera stays off unless you turn it on.
Going further: If you ask, it passes your question or a pilot request to our team.
If it cannot start: It is sometimes busy or unavailable. Use the contact form instead: our team reviews every enquiry. The short answers cover the same questions in writing.

What happened in a real lab demonstration.

One runaway job on a Linux lab server, recorded on 13 October 2026. The summary is ours, written from that recording and its audit record.

Lab summary, written by us · not a product screen

Resolved and verified.

Problem found
Fix applied after approval
Stop confirmed
Follow-up required

In a scripted lab run, a runaway job held a full CPU core on a Linux server. After Apply was pressed through the operator account, CyberSentry stopped it, read the server back to confirm and recorded both.

Next, for a person: find out why the job was stuck. CyberSentry does not look for the cause or restart it.

View lab-run details

What happened: A process was using a full CPU core on a Linux lab server.
Approval: Required: the process was not on the known-bad list. Apply Fix was pressed in the dashboard under the operator account (in this recording, by our script).
What CyberSentry did: Stopped the process through the guarded helper on the server.
Did it work: Yes. It checked the server afterwards: the process was no longer running.
On the record: The action, who it was applied as and the check, with times, in the audit record.
Still with a person: Why the job was stuck. CyberSentry did not look for the cause or restart it, and unsaved work in the process was lost.

Watch the real recording 25 s

The recording shows each step in the real dashboard, ending on the audit entry. Transcript and recording notes are in the player.

Every screen of a second recorded run: an untrusted port, in six steps

We opened an untrusted port on a Linux server in our lab and approved the fix with Apply (pressed by our capture script, signed in as the operator). Every screen below comes from that one run on 13 October 2026, in order: alert at 21:34:02, fix applied and recorded at 21:34:25. Real product screens, not mock-ups. Confidence values are covered.

Active Alerts with one row: untrusted ports detected: 9999 on the lab host, at 21:34:02 on 13 October 2026. — Real product screen · lab
An untrusted port starts listening.
CyberSentry compares each server’s listening ports with your trusted list and raises one finding per port: here, port 9999 on the lab host.

The fix card for port 9999: a rule-based recommendation and a note labelled AI saying that Apply finds the process listening on the port, stops it, blocks the port at the host firewall and reports whether anything is still listening. The confidence column is covered. — Real product screen · lab
It says what it is and why it matters.
Every finding carries a plain-language note. This one was written by the optional AI layer, so it is labelled AI and should be checked before acting. Without a model, a rule-based note appears instead.

The buttons under the suggestion: Apply Fix, Trust ports, Dismiss and Preview. — Real product screen · lab
Your team chooses what happens.
Apply the fix, trust the port (add it to the trusted list), dismiss the finding, or preview the fix as a recorded dry run. Port fixes always wait for a person, even when self-healing is switched on.

Fix Summary Timeline entry marked Manually Applied, 21:34:25, for untrusted open ports 9999 on the lab host. — Real product screen · lab
On Apply, the fix runs through a guarded helper.
CyberSentry ends the listener and adds a firewall rule on the host, using the restricted SSH key and short sudo allow-list set up at onboarding. The timeline marks it as manually applied, because a person approved it.

The read-back line of the entry: port 9999, no listener after apply; firewall rule added by the host helper; connection from the server now refused or dropped. — Real product screen · lab
Then it checks again, and says how.
Read back from the host: nothing listens on port 9999, and a connection from the CyberSentry server is refused or dropped. The firewall rule itself is not read back.

The audit record of this fix, from the product's JSON export: action apply, actor user, finished 13:34:25 GMT, port 9999 closed with the process terminated, the verification text and verified true, recorded at 21:34:24 local time (UTC+8). The confidence value is covered. — Real product export · lab
The audit record, as exported.
An audit row opens before the action and records its outcome. This is that row from the product’s JSON export: approved by the user role (there is one login today), what ran, the read-back and the time. Export it as CSV or JSON.

With self-healing switched on, this port would still wait for a person. Only processes on the known-bad list are stopped automatically. Request a live technical demo

Alerts say something is wrong. Someone still has to work out the rest.

CyberSentry is built first for MSPs and lean IT teams handling recurring server incidents. Monitoring, RMM and security tools raise alerts, and many already automate parts of the response. What often remains is the investigation and the safe fix, done by whoever is on call. That is the work CyberSentry takes on, on supported servers.

What CyberSentry takes on

Explained findings on supported servers: which server, what changed and since when.
One proposed fix for each finding, ranked against the rest.
Supported fixes on Linux, after approval, checked afterwards and recorded.
Watching Windows servers, read-only.

What stays with your tools

Your RMM, EDR, antivirus, backups and monitoring keep their jobs. CyberSentry replaces none of them.
Running alongside does not mean connected: there are no RMM, ticketing or SIEM integrations today; they are planned.
Network devices, laptops, Kubernetes objects and SaaS applications are not covered.

It fits best where Linux web, application, database, file or backup servers have problems that keep coming back: at MSPs, and in small teams where one person looks after the servers.

Managed service providersRecurring incidents, technician time and fitting alongside your RMM and EDR. Business owners and executivesWhat it means for uptime, specialist dependence and control, in plain terms. Technical evaluatorsDeployment, data path, permissions, detection and current limitations.

These are design goals. We will measure them with pilot partners and publish results only with their approval.

What it does today, and what is planned.

Lab-demonstrated means shown working in our lab, not yet at a customer. Pilot, by agreement means switched on only if you agree to it in a pilot.

Lab-demonstrated
Watches supported servers: Linux, and Windows read-only. How it connects
Lab-demonstrated
Detects sustained changes against each server’s normal range, runaway processes, untrusted listening ports and changed system files.
Lab-demonstrated
Explains each finding in plain language. AI-written notes are optional and labelled; the AI never chooses or runs a fix.
Lab-demonstratedLinux only
Fixes, after approval: stop a process, close an untrusted port, restore a changed /etc file from your backup. Each waits for your team by default. Windows is never changed. Stopping a process is immediate, so unsaved work in it is lost.
Lab-demonstrated
Checks the result after a fix and says how it checked. Records findings, decisions and actions with times: CSV and JSON export, and a printable proof-of-value report that counts them.
Pilot, by agreement
Self-healing for processes on the known-bad list only; off by default. Who switches it on

PlannedScheduled service checks and expiry alerts, disk capacity forecasting, self-healing switched on one fix type at a time, a multi-tenant MSP console with roles, a packaged installer with updates, RMM and ticketing integrations.

Technical scope of each capability, and typical findings

Monitor. Linux: CPU, memory, disk, processes, listening ports, failed logins, network loss and a fixed list of system files in /etc. Windows: CPU, memory and disk, read-only.
Detect. Per-host, per-metric baselines with repeated readings before an alert. Runaway processes per CPU core and sustained, a process anomaly model, ports not on your trusted list, changed /etc files, failed logins, network loss. Service checks (web, API, TCP, MySQL-compatible database, mail, certificate expiry, the CyberSentry server’s own filesystem) run on demand; scheduled checks are planned. Thresholds are configurable; we do not publish them.
Investigate. Each finding carries the host, the evidence behind it and a likely cause. Log search and correlation across many systems are not part of the product.
Explain. Without a model the note is rule-based. With the optional AI layer (off by default) a language model writes it, labelled AI, with a reminder to verify before acting: local models made factual mistakes in our tests. The operator assistant answers single questions about findings and fixes.
Prioritise. Ranked by urgency, impact, risk and confidence. We do not publish the scoring values.
Recommend. Apply, Preview (a dry run, recorded) or Dismiss (snoozes the finding). For ports, Trust adds the port to your trusted list instead.
Respond. Three fix types on Linux: stop a process; close an untrusted port (end the listener and add a firewall rule); restore a changed /etc file from a backup you placed, checked against the baseline. They run through the access set up at onboarding (see where it runs). No fixes on Windows. No automatic rollback.
Verify. Process: read back from the host. Port: the host listener list plus a connection probe from the CyberSentry server. File: hashed again after the restore. The firewall rule itself is not read back.
Record. An audit row opens before any action and records the outcome. Previews, dismissals and switch changes are recorded too. The record names a role, not a person, because there is one login today.

Typical findings

Runaway processLab-demonstrated
A process holds most of a CPU core for a sustained period. CyberSentry explains it and proposes stopping it.
Untrusted listening portLab-demonstrated
A port that is not on your trusted list starts listening. Close it, always with approval, or trust it.
Changed system fileLab-demonstrated
A file on the fixed /etc list changes. Restore it from a backup you placed, or accept the change.
Disk above its normal rangeLab-demonstrated
Flagged with the numbers. No automatic clean-up; forecasting the days until full is planned.
Certificate close to expiryLab-demonstratedOn demand
Shown when you run service checks from the dashboard. Scheduled checks and expiry alerts are planned.

More product screens: the dashboard, a busy process, the operator assistant, the self-healing switch

The CyberSentry dashboard in the lab build: a sidebar with system selection, filters and alert thresholds (values covered), tabs across the top, an active alert for untrusted port 9999, a fix suggestion with Apply Fix, Trust ports, Dismiss and Preview, and the start of the fix timeline. — Real product screen · labThe dashboard, in context.Systems and filters on the left; alerts, fix suggestions and the fix timeline on the right. Some tabs lead to early views; this page claims only what the capability list below describes.

Dashboard showing an alert for a process called backup-compress using 100 percent of the CPU, with a rule-based recommendation and an AI note explaining it could be a stuck job or legitimate heavy work. The confidence column is covered. — Real product screen · labA busy process that is not on the known-bad list.The note says it could be a stuck job or legitimate heavy work, so a person decides. Even with self-healing on, CyberSentry does not stop it by itself.

The operator assistant panel inside the CyberSentry dashboard, answering a question about the port fix: process terminated, port blocked at the firewall, nothing listening on it now. A confidence value is covered. — Real product screen · labThe operator assistant inside the dashboard.It answers single questions about findings and fixes. It explains; it never chooses or runs a fix on its own. This is part of the product, not the AI companion on this website.

System settings showing the Auto-Heal Mode switch turned on and a hidden threshold box, and Alert Confidence Filtering switched off. — Real product screen · labThe self-healing switch, turned on here for the demo.A fresh install starts with it off. In the current build it acts only on processes on the known-bad list; ports and files always wait for a person. Threshold values are hidden.

Automation your team controls.

Who decides what changes on your servers, and what can run without a person.

01
CyberSentry proposes
Always
It raises findings and proposes one fix for each. Proposing changes nothing on your servers.
Nothing changes on its own
02
Your team approves
The default for every fix
Someone on your team applies the fix, previews it as a recorded dry run, or dismisses it. Approving one fix never switches self-healing on.
Each fix approved separately
03
Self-heal Off by default
Only if your team switches it on
Stops processes on the known-bad list by itself. Port and file fixes still wait for approval. It is one switch, off on a fresh install, and every change to it is recorded.
Known-bad processes only

The AI never chooses or runs a fix. It writes notes and answers questions; a deterministic engine runs only what your team approved, or what self-healing covers once switched on. CyberSentry does not roll fixes back automatically; if you undo a fix by hand, you can record that.

Where it runs, what it touches, and what can leave your network.

CyberSentry runs on your infrastructure and stores monitoring and audit data there. A local AI model can keep analysis inside your network. Optional external AI and notification services send selected information outside it only if your team sets them up, and a default network-loss check pings a public address.

Runs on a Linux server you provide. There is no cloud version.
No monitoring agent on each server: SSH for Linux, WinRM over HTTPS for Windows (read-only).
Fixes run on Linux only, through access set up at onboarding: an admin credential used once, a pinned host key, then a restricted SSH key, a short sudo allow-list and a guarded helper.
The dashboard uses plain HTTP today, so put it behind an SSH tunnel or TLS proxy. One login, no roles yet.
Lab-tested on a small number of hosts. Not yet validated at customer scale; hardening continues.

Where your data goesDiagram

Stays inside your networkLeaves only for what you configure, plus the default ping

All technical details: deployment, data, environments, existing tools, limitations

Deployment model

Self-hosted on a Linux server you provide, inside your network. There is no cloud version.
During a pilot we install it with you. There is no packaged installer yet.
Stack: Python (Flask, Socket.IO), MongoDB and Redis.
The dashboard is served over plain HTTP today. Put it behind an SSH tunnel or a TLS proxy.

Data path and privacy

CyberSentry connects out to your servers over SSH or WinRM. No monitoring agent runs on them.
Metrics, findings and audit records are stored in the database on your CyberSentry server.
The product sends no monitoring data or telemetry to CyberSentry AI.
Optional, off by default, only if your team sets them up: a hosted AI provider (it receives finding text) and email or Telegram alerts.
On by default: to detect network loss, the CyberSentry server and each monitored Linux server ping a public address (8.8.8.8). The ping carries no monitoring data. One setting turns it off, together with every optional service outside your network.

Supported environments

Linux servers reachable over SSH: monitoring and supported fixes.
Windows servers over WinRM (HTTPS): CPU, memory and disk, read-only.
Built for servers. Network devices, laptops, Kubernetes objects and SaaS applications are not covered.
Tested in our lab on Linux virtual machines and containers, with a small number of hosts. Not yet validated at customer scale.

How it fits your stack

CyberSentry complements your EDR or antivirus, SIEM, RMM, backups and specialist controls. Keep them; many already automate parts of detection and response.
Its role: plain-language findings across operational and security-relevant signals, plus a few controlled, checked fixes on supported servers.
No RMM, ticketing or SIEM integrations yet. They are planned.

Limitations today

Early-stage: not production-ready and not generally available. No customer deployment yet; the first controlled pilots are being prepared.
One organisation per installation and a single login. No roles, no MSP tenant isolation yet.
Hardening is in progress, including key custody and HTTPS for the dashboard.
No certifications (such as ISO 27001 or SOC 2) and no compliance pack.

Early-stage, and open about it.

Results so far come from our lab and live demos. We are formalising our first controlled pilots with companies in Malaysia, and will publish customer results only when pilot partners approve them.

InvestorsSee the live demo and talk to our team.

Talk to our team

What you can check for yourself

A team you talk to directly.
A real lab recording of the product, and a live demo on request.
Where we are: preparing the first controlled pilots. No customer deployment yet.
Pilots start watch-only, on systems you select.
A status label on every capability on this page, including what is not built.
Release notes, the demo runbook and test records behind those labels: available on request, not public.

Explore a controlled pilot.

Supported by our team, limited in scope and agreed in writing. A pilot starts watch-only on a few systems you select, so you can judge CyberSentry on your own servers before anything changes.

A first callWe hear how you run your servers and check together whether CyberSentry fits.
Terms in writingScope, duration, data access, confidentiality, data protection, security, responsibilities, how the pilot ends, and the outcomes we will review. Nothing is connected before they are agreed.
Install togetherOn a server you provide, connected to the systems you select. Watch-only to start. Self-healing stays off unless you ask for it.
About 8 weeksA 30-minute check-in every two weeks. You see findings, explanations and suggested fixes on your own systems.
ResultsA written summary from the stored records, reviewed against the agreed outcomes. Then you decide whether to continue.

What a pilot measures, with you

Investigation time for supported incidents, compared with how your team handles them today.
Manual steps needed per supported incident.
Verification outcomes, and the recommendations your team dismissed or that failed.

We agree these measures and how to collect them in the written terms. They are not results we have shown, and not all are counted automatically: some come from the product’s records, some from your team.

Cost and terms

Pilot: Free. No purchase commitment.
After the pilot: Production pricing is not published. We plan monthly subscription plans for market release. Terms for continuing are agreed in writing.
Support: Hands-on support from our team during the pilot. No SLA yet.

What a pilot works best with

Linux servers the CyberSentry server can reach over SSH. Windows servers can be watched over WinRM (HTTPS), read-only.
A Linux server inside your network to run CyberSentry.
Accounts for monitoring and, for Linux fixes, a restricted key and short sudo allow-list.
Someone who can join a short check-in every two weeks and tell us honestly what works.

We plan setup with you instead of quoting a standard duration, and confirm fit on the first call.

Discuss a pilot Our team reads every request and replies within two working days.

Short answers.

Something else? Email info@datamobility.com.my, use the form below, or ask CyberSentry.

What is CyberSentry?

Self-hosted software for IT and security operations on servers. It watches supported Linux and Windows servers without an agent on each one, explains problems in plain language, ranks them, and runs a small set of Linux fixes that your team approves, with a check afterwards and an audit record. It is early-stage and offered through controlled pilots.

Is CyberSentry a security product?

It works across infrastructure resilience, IT operations and security operations. It watches server health and security-relevant signals such as unexpected listening ports, changed system files, failed logins and known-bad processes, explains them, and handles supported fixes under your control. It complements your EDR, SIEM, RMM, backups and specialist controls.

Does CyberSentry replace NinjaOne, Microsoft Defender or our monitoring tools?

No. RMM platforms such as NinjaOne, ConnectWise, Datto or Kaseya, and EDR such as Microsoft Defender, may already automate parts of detection and response. CyberSentry runs alongside them on your own infrastructure, adding explained findings and a few controlled, checked fixes on supported servers. It has no integrations with them today; RMM and ticketing integrations are planned.

What can CyberSentry automate today?

With your team’s approval, three Linux fixes: stop a process, close an untrusted port, and restore a changed /etc file from a backup you placed. Without approval, only one thing, and only if your team switches self-healing on: stopping processes on the known-bad list. Everything else waits for a person, and approving one fix never switches self-healing on. Windows servers are monitored, not fixed.

What access would CyberSentry need?

A Linux server inside your network to run it, SSH access to Linux servers and WinRM over HTTPS to Windows servers. No monitoring agent runs on each server. For Linux fixes, onboarding uses an admin credential once, pins the host key, and leaves a restricted SSH key, a short sudo allow-list and a guarded helper.

Where does our data go?

CyberSentry runs on your infrastructure and stores monitoring and audit data there. The product sends no monitoring data or telemetry to CyberSentry AI. Optional services send selected information outside your network only if your team sets them up: a hosted AI provider, which receives finding text, and email or Telegram alerts. One check is on by default: to detect network loss, the CyberSentry server and each monitored Linux server ping a public address. The ping carries no monitoring data, and one setting turns it off. A local AI model keeps analysis inside your network.

What does the AI do?

In the product, an optional AI layer (off by default, local model possible) explains findings and answers questions in the operator assistant. It never decides on or runs a fix.

Is the AI companion on this website part of the product?

No. It is a website assistant, run by Tavus, that answers questions about CyberSentry. It is separate from the operator assistant inside the product.

How does a controlled pilot work?

It is free, supported by our team and lasts about 8 weeks. After a first call we agree written terms, then install CyberSentry with you on a server you provide, connected to a few systems you select. It starts watch-only, with a check-in every two weeks and a written results summary at the end. We review each request individually.

How long does setup take?

It depends on the systems you select, network connectivity to them, the access you can grant and where the CyberSentry server runs. We plan it with you during the pilot instead of quoting a standard duration.

What does it cost?

The pilot is free. Production pricing is not published. We plan monthly subscription plans for market release.

How mature is the product?

Early-stage. The core runs end to end in our lab and we can demonstrate it live. It is not production-ready or generally available, and it has not yet been validated at customer scale. A market-release candidate is targeted for May 2027.

Talk to our team.

Discuss a pilot, ask for a guided technical demo, ask about investing or partnering, or just ask a question. Our team reads every message and replies within two working days.

Pilot: free for about 8 weeks
Selected systems, watch-only to start
Written terms before we connect anything
A written results summary against agreed outcomes

Prefer email? info@datamobility.com.my

From infrastructure alerts to controlled resolution.

You’ve seen what it does. Ask how it fits your environment.

What happened in a real lab demonstration.

Resolved and verified.

An untrusted port starts listening.

It says what it is and why it matters.

Your team chooses what happens.

On Apply, the fix runs through a guarded helper.

Then it checks again, and says how.

The audit record, as exported.