Detection runs deterministically, around the clock, at zero cost. A model reads the serious incidents in under two minutes and tells you what is real, what is noise and what to do about it — then drafts the repair procedure. Installed on your own infrastructure, calibrated for 72 hours on your traffic, handed over with the documentation.
A single machine or a fleet. No SIEM, no external agent, no data leaving your server.
This is not a feature list you tick off. At install time Sentinel discovers what is on the machine and writes an inventory that you confirm — then the collectors, detection rules and thresholds adjust to it. Try it below.
The panel on the right is what the installer would produce for the selected combination. On your machine the same decisions are made from what it actually finds — not from what you ticked.
You are no longer picked by a human. You are a row in an automatically generated list — scanned, classified and prioritised by programs that work non-stop, at a cost per target close to zero. Company size no longer takes you off the list.
No human can read 20,000 hostile events a day, and none can write at 3am why this particular one matters. Sentinel puts a model on the judgement part — real severity, false positive or not, what to do about it, in plain English — in less than two minutes from the moment the incident opens.
But the decision to block stays deterministic. That is not a limitation: it is the reason you can leave the product running on its own.
Runs 24/7, on every event. Depends on nothing outside the server.
If the model disagrees with the rule, you see both. Nothing is silently rewritten.
An attacker can request an HTTP path that contains instructions. Sentinel treats them as untrusted data, with explicit delimiters, and the transport that actually reads files off the server runs --permission-mode plan — structurally unable to change anything. There is a test that plants IGNORE PREVIOUS INSTRUCTIONS in an access log and checks that nothing was executed.
This is not a notification channel. It is the console. You get the incident with action buttons, block the attacker with one tap, ask for server status and start a patch — no VPN, no SSH, no opening the laptop. Everything you can do from the web dashboard you can do from the chat.
You do not wait to open a dashboard. The incident is pushed to Telegram the moment the rule fires, with the source, country, ASN, number of attempts and the AI verdict in plain English — plus the buttons that resolve the situation on the spot.
Commands run on the server and answer in under a second. The ones that change something ask for a separate confirmation, and the destructive ones ask for a second one that restates the target.
/dashboard/status/incidents
/vulnerabilities/services/health
/events/blocked/patches
/selfcheck
/block/unblock
/resolve/falsepositive
/quiet/panic
Green reads, red changes. Every command also has a Romanian variant, for phones that autocomplete in Romanian.
The bot pulls messages, it does not receive them: there is no open port pointing at it and no public endpoint to forge. If nginx, TLS or the web dashboard go down, the channel stays up — which means it is available in exactly the minute you need it.
Telegram is for the minute an incident happens. The panel is for the rest of the time: what is attacking you, what is open, what deserves fixing first — and, under every finding, the command that resolves it.
“root is target #1 — 12,813 attempts from 938 addresses”, and underneath it grep PermitRootLogin /etc/ssh/sshd_config. Every finding comes with its own action, spelled out. Nothing to infer from a diagram on your own.
812 open does not mean 812 to fix. CISA’s SSVC traffic light orders them by real-world exploitation (KEV, EPSS), vector and asset criticality: five need attention, two are being exploited right now. Grey means the data is missing, not that it is fine.
Not just addresses — operators. When 4,137 events come from two addresses in the same network, that is not a botnet of compromised machines; it is infrastructure rented for the attack, and the next address will come from the same place. You block the range, not the address.
Incidents are gathered by the rule family that produced them. A campaign stays active for as long as it keeps receiving new incidents; if it drops off the list, that front has stopped — it has not stopped being checked.
The services discovered on the machine, each tagged public or protected, with latency and 24-hour uptime. The list refreshes itself, so a service started today shows up today — including the one you left open and forgot.
You see every blocked address, the reason and when it expires, and you can unblock. You cannot block: a compromised dashboard must not be able to block anyone. Blocking stays in Telegram, or in the rule.
A program that guards you and is, at the same time, the only thing that can raise the alarm has a design problem: whoever stops it stops the alarm too. The silence afterwards looks exactly like a night when nobody tried anything.
Every instance sends a heartbeat to a page that runs on a different machine from the monitored servers. That page does nothing but listen. If the signal stops, the alert goes out from there, over Telegram — not from the server that has just gone quiet.
The same page shows each instance’s self-diagnostic, run every five minutes. You do not have to trust the agent to tell you when it falls over. It is not the agent telling you.
The licence is per server. Initial configuration and the 72-hour calibration are included in every tier — without them, an agent that can block traffic is a risk, not a protection.
For teams that already have someone technical and just want the tool, configured properly.
For companies without a dedicated security person. We watch, you decide what gets applied.
For several servers or clients. Per-machine configuration, one unified view.
We look at what is exposed, what is attacking you right now, which vulnerabilities are open and how fast you would find out if someone got in. We install nothing at this stage.
day 1–2 · no obligationDiscovery proposes what it found on the machine; you confirm what is critical, what is never touched automatically and who must always get through — monitors, the office, CI.
day 3One hour on a clean server. Nothing that ran before stops: the installer compares against the previous state and rolls back automatically if something changed.
day 3 · ~1 hour72 hours in which automatic blocking is off and you only get what it would have blocked. This is where the false positives show up: the uptime monitor, certificate validation, your mobile IP.
day 4–6We switch automatic blocking on with the tuned thresholds, hand over access to the dashboard and the bot, plus the operating documentation. From here it runs on its own.
day 7Every vendor tells you what the product does. When software gets root on your server, the question that matters is a different one: what is it not allowed to do, and who stops it.
Your admin address, the private networks and loopback live in a list hard-coded in the source — not in configuration, not in the database. Compromising the database cannot widen it.
The base rule is policy accept. It is a deny-lister, not a firewall. If the process dies, the database goes down or the configuration is wrong, traffic passes.
Deliberate: a reboot is always a way out of a self-inflicted block. Plus a PANIC file that clears everything in under 60 seconds, watched by an independent process.
Generating the plan is automatic. Applying it takes two explicit confirmations on the phone, and the button dies if the plan is regenerated.
The interface is the most exposed component, so it has no path to privileged actions. Compromising it leaks data; it cannot block, unblock or apply anything.
Log lines and HTTP paths are written by the attacker. They are treated as untrusted data, and a test plants IGNORE PREVIOUS INSTRUCTIONS in an access log and checks that nothing was executed.
It is easy to show a round number and a full chart. Harder, and more useful, is to say where the measurement stops. The notes below are in the panel, at customers — not only on this page.
The first 5,000 rows were read; the rest were not counted. Every aggregator has a read ceiling — the difference is whether it tells you. “At least this many” is something you can lean on in one direction. “Exactly this many, probably” is not.
A counter sent halfway through its own hour would read as a drop in traffic that never happened. So the last bar is missing from the chart, and the reason is written underneath it. We have seen enough people make decisions on that bar.
A stopped collector and one working through a quiet day produce the same thing: zero. The silence is proven by the neighbour that uses the same reader and that, exposed to the internet, never goes quiet. No extra components.
Twenty-two vulnerabilities stay declared unassessed, rather than being turned green to make the total look better. The single deviation from the SSVC model is written there too, with its reason.
None of these notes help a sale. All four make the rest of the numbers verifiable — and when you give a program root on your server, that is the only property that counts.
The numbers below come from the repository, not from a slide deck.
The gaps are declared, not hidden: container logs are not collected yet, there is no dedicated file-integrity monitor beyond auditd, and the Debian install is covered by tests but not yet verified on a real Debian host. We say so before the contract, not after.
Thirty minutes, free and with no obligation. You tell us what server you have and what runs on it. We tell you what is exposed, what is attacking you right now and whether Sentinel makes sense for you — including when the answer is “not yet”.
Corporate-grade expertise. Delivered fast. No overhead, no jargon, no surprises.