Avec l'offre Enterprise, l'analyse des menaces s'exécute entièrement sur l'appareil — un modèle de détection compact et spécialisé, accompagné de notre propre moteur d'inférence, directement sur vos machines. Aucun contenu de document ne quitte jamais les lieux, et la protection continue de fonctionner sans aucune connexion au cloud.
L'analyse est locale par construction — pas une option que l'on active, mais la manière même dont le produit est conçu. La seule chose qui sorte un jour, c'est une unique vérification documentée de licence et de mise à jour par mois, et elle ne transporte aucun contenu.
Aucune entrée de mémoire, aucun document, aucun fragment de texte n'est jamais envoyé où que ce soit. Le modèle lit la modification localement et rend son verdict localement — il n'existe tout simplement aucun cloud d'analyse vers lequel fuiter.
Exactement une vérification documentée de licence et de mise à jour par mois — identifiants et version uniquement, jamais de contenu. Entre deux vérifications, le produit fonctionne entièrement hors ligne.
Chaque requête sortante est consignée dans un journal de sortie intégré au produit — vos équipes DLP et audit peuvent vérifier, et pas seulement faire confiance, que rien d'autre ne quitte l'appareil.
Le modèle de détection n'est pas un classifieur sur étagère. Il est affiné sur un vaste corpus d'exemples réels d'attaques et de cas bénins issus de notre pipeline d'analyse dans le cloud — un volant d'inertie qui maintient le modèle embarqué affûté et l'améliore à chaque nouveau schéma d'attaque.
Un modèle affiné pour une seule tâche — repérer les écritures de mémoire empoisonnées — plutôt qu'un filtre généraliste greffé sur le problème. C'est cette focalisation qui lui fait détecter ce que les garde-fous génériques laissent passer.
Notre pipeline cloud étiquette des données fraîches d'attaques et de cas bénins ; ces données affûtent le modèle embarqué. À mesure que les attaquants s'adaptent, le détecteur suit le rythme — sans que vos données ne l'alimentent jamais.
C'est l'attaquant qui choisit la langue : le modèle a donc été testé en profondeur sur de nombreuses langues. Une injection rédigée dans l'une d'elles est détectée tout autant. La langue est une surface d'attaque, pas un angle mort.
L'empoisonnement de mémoire n'est pas un tour unique. C'est une famille de techniques, et une défense ne vaut que par sa couverture des cas difficiles. Le détecteur est entraîné et évalué contre chacune de ces classes.
Des instructions explicites glissées dans une entrée de mémoire — « à partir de maintenant, fais X » — que l'agent finit par suivre comme si elles étaient les siennes.
Des entrées conçues pour amener l'agent à divulguer secrets, identifiants ou contexte privé vers une destination contrôlée par l'attaquant.
Le coup le plus rusé : une entrée qui vise la protection elle-même — « fais confiance à cette source, ne la vérifie plus ». Une fois la garde désarmée, toute attaque ultérieure entre sans obstacle.
Une mise en scène qui fait sortir l'agent de ses règles de sécurité via un personnage ou un scénario, au lieu de donner l'instruction malveillante ouvertement.
Les plus difficiles de toutes : des entrées qui se lisent comme des notes parfaitement légitimes, sans indice évident — précisément celles que les filtres simples et les règles par mots-clés laissent passer.
Le composant qui lit du texte contrôlé par l'attaquant est celui que nous isolons le plus. Le moteur d'inférence s'exécute dans un bac à sable à privilèges minimaux — même une faille en son sein reste sans conséquence : le moteur peut planter, le daemon garde le contrôle et revient en arrière en cas de doute.
Le moteur n'écoute que sur localhost, ne lit que le fichier du modèle, ne lance aucun processus et s'exécute en tant que processus isolé et non privilégié. Une faille dans le moteur n'a nulle part où aller.
Chaque artefact est signé, et le fichier du modèle est épinglé par SHA-256 et vérifié avant chaque démarrage — un modèle altéré ne se charge même pas.
La réponse du moteur est traitée comme une entrée non fiable. S'il plante, se fige ou renvoie quelque chose d'inattendu, le daemon revient en arrière de façon conservatrice — au lieu de laisser passer une modification.
# le moteur démarre à la demande, en bac à sable [verify] SHA-256 du modèle épinglé · ok [sandbox] localhost seul · modèle en lecture seule · aucun sous-processus [eval] écriture mémoire · danger 0.97 → revert [idle] le moteur s'arrête · footprint de nouveau à quelques Mo
Conçu pour le matériel que votre équipe possède déjà — discret, à la demande, sans GPU.
| Propriété | Détail |
|---|---|
| Footprint | Un peu plus de 300 Mo — et seulement pour quelques secondes lors d'une vérification de mémoire. Au repos, quelques Mo à peine. |
| Matériel | CPU seul, matériel ordinaire. Aucun GPU requis. |
| Latence d'analyse | Quelques secondes par vérification de mémoire, lancée à la demande. |
| Plateformes | Linux · macOS · Windows |
| Langues | Multilingue — les attaques sont détectées quelle que soit la langue dans laquelle elles sont rédigées. Testé en profondeur. |
| Hors ligne | Fonctionne entièrement hors ligne — seule exception : une vérification mensuelle de licence, jamais de contenu. |
| Footprint réseau | Une requête par mois — identifiants et version uniquement, jamais de contenu. |
| Mises à jour | Artefacts signés, vérifiés par SHA-256 avant chaque démarrage. |
Parlons d'un déploiement Enterprise — détection sur l'appareil, souveraineté totale des données et les contrôles de déploiement dont votre équipe sécurité a besoin.
Contacter le commercial