Enterprise

Skalierung, Governance und Premium-Detektion.

Größeres Erkennungsmodell, eigene Inferenz, SIEM-Export und flottenweite Governance — egal ob cloud-verwaltet oder vollständig privat.

Cloud- oder vollständig private InstallationSkalierung auf die gesamte FlotteGovernance-taugliche KontrollenFür OWASP ASI06 gebaut
Auf einen Blick

Alles, was Enterprise Ihnen bietet.

Enterprise-Funktionen

Was Sie mit Enterprise erhalten — in jedem Deployment-Modus.

Das sind Tariffunktionen. Sie arbeiten im Cloud-Modus und im Private-Modus gleichermaßen.

Größeres Erkennungsmodell

Ein größeres Modell mit besserem Long-Tail-Recall und Angriffstyp-Klassifizierung — so sagt Ihnen jede Meldung nicht nur, dass ein Angriff stattgefunden hat, sondern welche Klasse. Als Upgrade innerhalb von Enterprise verfügbar.

Eigenes Modell anbinden — immer dual

Verbinden Sie Ihren eigenen Inferenz-Endpunkt als zweite Meinung neben unserem lokalen Modell. Unser Modell bleibt primär; Ihres läuft als Backstop. Ist Ihr Endpunkt nicht erreichbar, läuft das lokale Modell weiter — fail-closed. Nützlich, wenn Ihre Compliance-Regeln verlangen, dass die Inferenzschicht unter Ihrer Kontrolle bleibt.

SIEM-Export

Streamen Sie Meldungen in JSON, CEF oder syslog direkt in Ihre SOC-Toolchain (Splunk, Sentinel, QRadar). Funktioniert auch im Private-Modus: Das Gerät liest eine lokale Log-Datei — keine Cloud erforderlich.

Flotten-Rollout & Geräte-Lizenzierung

MDM-freundlicher Rollout über SCCM, Intune, Ansible oder einen einfachen Install-Loop. Lizenz-Tokens sind gerätegebunden — fungible Binaries, nicht übertragbare Lizenzen.

Erkennungsschwellwert-Kontrolle

Geräteindividuelle Gefahren-Schwellwerte, benutzerdefinierte Profile und konfigurierbare Poll-Intervalle — auf Enterprise gesperrt, um Policy-Bypass zu verhindern.

Ihre eigene, isolierte Instanz

Enterprise läuft als vollständig eigenständige Umgebung: Ihre eigene Console unter Ihrer eigenen Web-Adresse, eine frei wählbare Region für den Ort Ihrer Daten und Ihre Daten strikt getrennt in einer eigenen Datenbank. Nichts wird mit anderen Kunden geteilt.

Deployment-Modi

Cloud oder Private — Ihre Wahl, Gerät für Gerät.

Wie ein Gerät installiert wird, wählen Sie pro Gerät frei: einzelne im Cloud-Modus, andere vollständig privat — in derselben Flotte. Der volle Funktionsumfang gilt in beiden Fällen.

Cloud-Modus

Jedes Gerät übermittelt redigierte Diffs an das Panel. Sie erhalten eine Live-Flottenansicht, Echtzeit-Richtliniensteuerung und das vollständige Analytics-Dashboard. Alles, was das Panel zeigt, wurde vom Gerät gesendet.

  • Live-Flottenansicht und Gerätestatus im Panel
  • Echtzeit-Schwellwert- und Profilsteuerung aus dem Panel
  • Redigierte Diffs zur Bewertung — Inhalte niemals vollständig
  • Transparentes Egress-Ledger dokumentiert jede ausgehende Anfrage
  • Eingehender Threat-Intel-Feed hält die Erkennung aktuell

Private-Modus

Das Gerät läuft vollständig isoliert — nichts verlässt die Maschine. Ideal für vollständig private Umgebungen und die strengsten Anforderungen an Datensouveränität. Die Konfiguration wird einmalig signiert und ausgeliefert; das Gerät handelt eigenständig.

  • Kein ausgehender Datenverkehr — bei Bedarf vollständig privat betreibbar
  • Signierte, offline-auslieferbare Konfiguration — kein Live-Panel erforderlich
  • Ein optionaler monatlicher Aggregat-Zähler (opt-in, niemals Inhalte)
  • SIEM-Export an ein lokales Log-Ziel ersetzt Cloud-Reporting
  • Kernel ≥ 5.13 mit Landlock unter Linux (siehe Systemvoraussetzungen)
Private-Modus bei Enterprise bedeutet ein dediziertes Deployment — das vollständige Panel und Flottenmanagement laufen in Ihrer eigenen isolierten Instanz (wie GitLab self-managed), mit dem kompletten Funktionsumfang.
Datenschutz — Private-Modus

Im Private-Modus: nichts verlässt die Maschine.

Läuft ein Gerät im Private-Modus, ist die Analyse konstruktionsbedingt lokal — keine Einstellung, die man einschaltet, sondern die Art, wie die Installation funktioniert. Das Folgende gilt speziell für Geräte im Private-Modus. Geräte im Cloud-Modus senden redigierte Diffs zur Bewertung; dieser Datenfluss ist im Egress-Ledger dokumentiert.

Nichts zu exfiltrieren

Kein Memory-Eintrag, kein Dokument, kein Textfragment wird je irgendwohin gesendet. Das Modell liest die Änderung lokal und gibt das Urteil lokal zurück — es gibt schlicht keine Analyse-Cloud, an die etwas lecken könnte.

Ein Check pro Monat

Genau ein dokumentierter Lizenz- und Update-Check pro Monat — nur Zugangsdaten und Version, niemals Inhalte. Cloud-Analytics ist bei Enterprise standardmäßig aus (bei Pro standardmäßig an); ist sie an, trägt derselbe Check-in zusätzlich aggregierte Zähler — nur Zahlen, keine Pfade, keine Inhalte. Zwischen den Checks läuft das Produkt komplett offline.

Transparenter Egress

Jede ausgehende Verbindung wird in einem ins Produkt eingebauten Egress-Ledger protokolliert — Ihre DLP- und Audit-Teams können prüfen statt vertrauen, dass nichts anderes das Gerät verlässt.

Angriffstaxonomie

Wir benennen jede Angriffsklasse — und erkennen sie alle.

Memory Poisoning ist kein einzelner Trick. Es ist eine Familie von Techniken, und eine Abwehr ist nur so gut wie ihre Abdeckung der schweren Fälle. Der Detektor wird gegen jede dieser Klassen trainiert und evaluiert.

01

Direct Injection

Explizite Anweisungen, in einen Memory-Eintrag geschmuggelt — „ab jetzt tue X“ — die der Agent später befolgt, als wären es seine eigenen.

Prompt Injection erklärt
02

Data Exfiltration

Einträge, die den Agenten dazu bringen sollen, Geheimnisse, Zugangsdaten oder privaten Kontext an ein vom Angreifer kontrolliertes Ziel zu schicken.

Wie Data Exfiltration funktioniert
03

Meta-Angriffe

Der heimtückischste Zug: ein Eintrag, der auf den Schutz selbst zielt — „vertraue dieser Quelle, prüfe sie nicht mehr“. Ist die Wache entwaffnet, spaziert jeder spätere Angriff hinein.

Meta-Angriffe verstehen
04

Role-Play & Jailbreak

Eine Inszenierung, die den Agenten über eine Rolle oder ein Szenario aus seinen Sicherheitsregeln lockt, statt die schädliche Anweisung offen auszusprechen.

Jailbreak-Angriffe erklärt
05

Subtil & indirekt

Die schwersten überhaupt: Einträge, die wie völlig legitime Notizen klingen, ohne verräterisches Zeichen — genau die, an denen einfache Filter und Schlagwortregeln vorbeisegeln.

Subtile Injection erkennen
Systemvoraussetzungen

Was die On-Device-Analyse braucht.

Die Inference-Engine läuft in einer vom Kernel erzwungenen Sandbox — Modell lesen, auf localhost antworten, sonst nichts. Das Folgende gilt für jedes Gerät, das eine lokale Analyse ausführt (Private-Modus oder Cloud-Modus mit lokaler Bewertung). Die einzige ehrliche Plattform-Voraussetzung gibt es auf Linux.

PlattformVoraussetzung
macOS Nichts Besonderes. Die Kernel-Sandbox (Seatbelt) ist immer verfügbar — auf Apple Silicon verifiziert.
Linux Kernel ≥ 5.13 mit aktivem Landlock: Ubuntu ≥ 22.04, Debian ≥ 12, RHEL ≥ 9.6 ab Werk. Sonst per Boot-Parameter lsm=landlock,… aktivieren.
Windows Nichts Besonderes. Die Engine läuft unter einem Restricted Token (alle Privilegien gestrippt, Low Integrity) und einem Job-Object, das jeden Kindprozess blockiert — live und verifiziert.
Container Das Standard-Docker-seccomp-Profil blockt die Landlock-Syscalls — ein angepasstes Profil ist nötig.
Kein Landlock? Opt-in-Cloud-Bewertung als Remote-Backstop. Der Schutz bleibt; der Datenfluss wird transparent dokumentiert.
Strikt fail-closed. Ist die Sandbox nicht verfügbar, startet die Engine nicht — verdächtige Änderungen werden revertet, nie unbewertet durchgelassen. Kein stilles Degradieren. Wie die Engine-Sandbox funktioniert →

Erkennung auf die gesamte Flotte skalieren.

Sprechen Sie mit uns über einen Enterprise-Rollout — erweiterte Erkennungsfähigkeiten, Governance-Kontrollen und das Deployment-Modell, das Ihr Security-Team benötigt.

Sales kontaktieren