La détection tourne de façon déterministe, en continu, à coût nul. Un modèle lit les incidents sérieux en moins de deux minutes et vous dit en langage clair ce qui est réel, ce qui est du bruit et ce qu’il faut faire — puis rédige la procédure de réparation. Installé sur votre propre infrastructure, calibré 72 heures sur votre trafic, livré avec sa documentation.
Une seule machine ou une flotte. Pas de SIEM, pas d’agent externe, aucune donnée qui quitte votre serveur.
Ce n’est pas une liste de fonctions à cocher. À l’installation, Sentinel découvre ce qui se trouve sur la machine et écrit un inventaire que vous confirmez — ensuite les collecteurs, les règles de détection et les seuils s’ajustent dessus. Essayez ci-dessous.
Le panneau de droite correspond à ce que l’installation produirait pour la combinaison choisie. Chez vous, les mêmes décisions se prennent à partir de ce qu’elle trouve réellement sur la machine — pas de ce que vous avez coché.
Vous n’êtes plus choisi par un humain. Vous êtes une ligne dans une liste générée automatiquement — scannée, classée et priorisée par des programmes qui travaillent en continu, à un coût par cible proche de zéro. La taille de l’entreprise ne vous sort plus de la liste.
Aucun humain ne lit 20 000 événements hostiles par jour, et personne n’écrit à 3 h du matin pourquoi celui-ci compte précisément. Sentinel confie à un modèle la part de jugement — sévérité réelle, faux positif ou non, ce qu’il faut faire, en langage clair — en moins de deux minutes après l’ouverture de l’incident.
Mais la décision de bloquer reste déterministe. Ce n’est pas une limite : c’est la raison pour laquelle vous pouvez laisser le produit tourner seul.
Tourne 24/7, sur chaque événement. Ne dépend de rien hors du serveur.
Si le modèle contredit la règle, vous voyez les deux. Rien n’est réécrit en silence.
Un attaquant peut demander un chemin HTTP contenant des instructions. Sentinel les traite comme des données non fiables, avec des délimiteurs explicites, et le transport qui lit réellement les fichiers du serveur tourne en --permission-mode plan — structurellement incapable de modifier quoi que ce soit. Un test plante IGNORE PREVIOUS INSTRUCTIONS dans un journal d’accès et vérifie que rien n’a été exécuté.
Ce n’est pas un canal de notifications. C’est la console. Vous recevez l’incident avec des boutons d’action, vous bloquez l’attaquant d’une pression, vous demandez l’état du serveur et lancez un correctif — sans VPN, sans SSH, sans ouvrir le portable. Tout ce qui se fait depuis le tableau de bord se fait depuis la conversation.
Vous n’attendez pas d’ouvrir un tableau de bord. L’incident est poussé sur Telegram au moment où la règle se déclenche, avec la source, le pays, l’ASN, le nombre de tentatives et le verdict IA en langage clair — plus les boutons qui règlent la situation sur place.
Les commandes s’exécutent sur le serveur et répondent en moins d’une seconde. Celles qui changent quelque chose demandent une confirmation séparée, et les destructrices une seconde qui redit la cible.
/dashboard/status/incidents
/vulnerabilities/services/health
/events/blocked/patches
/selfcheck
/block/unblock
/resolve/falsepositive
/quiet/panic
Le vert lit, le rouge modifie. Les commandes existent en anglais et en roumain — l’affichage suit la langue du bot.
Le bot tire les messages, il ne les reçoit pas : aucun port ouvert ne pointe vers lui et il n’y a pas d’endpoint public à falsifier. Si nginx, TLS ou le tableau de bord tombent, le canal tient — donc il est disponible à la minute exacte où vous en avez besoin.
La licence est par serveur. La configuration initiale et le calibrage de 72 heures sont inclus dans toutes les formules — sans eux, un agent capable de bloquer du trafic est un risque, pas une protection.
Pour les équipes qui ont déjà quelqu’un de technique et veulent seulement l’outil, bien configuré.
Pour les entreprises sans responsable sécurité dédié. Nous surveillons, vous décidez de ce qui s’applique.
Pour plusieurs serveurs ou clients. Configuration par machine, vue unifiée.
Nous regardons ce qui est exposé, ce qui vous attaque en ce moment, quelles vulnérabilités sont ouvertes et à quelle vitesse vous sauriez que quelqu’un est entré. Nous n’installons rien à ce stade.
jour 1–2 · sans engagementLa découverte propose ce qu’elle a trouvé sur la machine ; vous confirmez ce qui est critique, ce qui n’est jamais touché automatiquement et qui doit toujours passer — sondes, bureau, CI.
jour 3Une heure sur un serveur propre. Rien de ce qui tournait avant ne s’arrête : l’installation compare avec l’état précédent et revient en arrière automatiquement si quelque chose a changé.
jour 3 · ~1 heure72 heures pendant lesquelles le blocage automatique est coupé et vous recevez seulement ce qu’il aurait bloqué. C’est là que sortent les faux positifs : la sonde de disponibilité, la validation des certificats, votre IP mobile.
jour 4–6Nous activons le blocage automatique avec les seuils ajustés, nous vous donnons l’accès au tableau de bord et au bot, plus la documentation d’exploitation. À partir de là, il tourne seul.
jour 7Chaque fournisseur vous dit ce que fait le produit. Quand un logiciel obtient les droits root sur votre serveur, la question qui compte est autre : ce qu’il n’a pas le droit de faire, et qui l’arrête.
Votre adresse d’administration, les réseaux privés et la boucle locale figurent dans une liste codée en dur dans le source — pas dans la configuration, pas dans la base. Compromettre la base ne peut pas l’élargir.
La règle de base est policy accept. C’est une liste de refus, pas un pare-feu. Si le processus meurt, si la base tombe ou si la configuration est fausse, le trafic passe.
Délibéré : un redémarrage est toujours une sortie d’un blocage qu’on s’est infligé. Plus un fichier PANIC qui vide tout en moins de 60 secondes, surveillé par un processus indépendant.
La génération du plan est automatique. L’application demande deux confirmations explicites sur le téléphone, et le bouton meurt si le plan est régénéré.
L’interface est le composant le plus exposé : elle n’a donc aucun chemin vers les actions privilégiées. La compromettre fait fuiter des données ; elle ne peut ni bloquer, ni débloquer, ni appliquer quoi que ce soit.
Les lignes de log et les chemins HTTP sont écrits par l’attaquant. Ils sont traités comme des données non fiables, et un test plante IGNORE PREVIOUS INSTRUCTIONS dans un journal d’accès puis vérifie que rien n’a été exécuté.
Les chiffres ci-dessous viennent du dépôt, pas d’une présentation.
Les manques sont déclarés, pas cachés : les journaux des conteneurs ne sont pas encore collectés, il n’y a pas de moniteur d’intégrité de fichiers dédié au-delà d’auditd, et l’installation Debian est couverte par des tests mais pas encore vérifiée sur un hôte Debian réel. Nous le disons avant le contrat, pas après.
Trente minutes, gratuites et sans engagement. Vous nous dites quel serveur vous avez et ce qui tourne dessus. Nous vous disons ce qui est exposé, ce qui vous attaque en ce moment et si Sentinel a du sens pour vous — y compris quand la réponse est « pas encore ».
Une expertise de niveau grand compte. Livrée vite. Sans surcouche, sans jargon, sans surprises.