Vesmona
Zur Private Beta

AIOps-Plattform · Private Beta

Die KI schlägt vor. Ein Engineer genehmigt. Ihr Gateway führt aus.

Vesmona macht aus den Monitoring-Tickets, die Sie bereits haben, evidenzbasierte Remediation-Vorschläge. Jede Änderung passiert ein Policy-Gate und eine menschliche Freigabe und läuft dann als Job von Ihrer Allowlist auf einem Gateway, das Sie betreiben. Unsere Control Plane hält keinerlei dauerhafte Zugangsdaten zu Ihrer Infrastruktur. Entwickelt in Deutschland für EU-Betriebsbedingungen: Redaktion sensibler Daten, bevor irgendetwas Ihre Grenze verlässt. Auf Wunsch läuft die gesamte Plattform (Control Plane, Inferenz, Gateways) in Ihrem Rechenzentrum.

Design-Partner werden Zum Sicherheitsmodell

keine agents an tag eins · early access · auf ihren echten incidents

Was es auf Ihrem Stack tut

Ein sicherer Weg, egal in welcher Umgebung. Ein Ticket kommt herein, eine Read-only-Diagnostik sammelt Evidenz über Ihr Gateway, und ein einzelner Fix von der Allowlist läuft erst, nachdem Ihr Engineer ihn freigegeben hat.

Ihre Umgebung über Ihr Gateway · read-only
web-01app-02db-03

Read-only-Signale

  • systemctl status
  • journalctl -p err
  • df · ss
  • deploy log

Szenario 01 / 04 Anwendung über mehrere Hosts

Eine Anwendung, mehrere Hosts, eine Ursache

Incident
Das Monitoring meldet eine Latenzspitze im Checkout-Pfad. Die Anwendung verteilt sich auf web-01, app-02 und db-03.
Evidenz
Über Ihr Gateway sammelt eine Read-only-Diagnostik Service-Status, aktuelle Fehler, Ressourcendruck und den letzten Deploy von jedem Host und korreliert sie auf einer Zeitleiste.
Vorschlag & freigegebener Fix
Sie erhalten einen einzigen Vorschlag: ein Worker auf app-02, den der Rollout um 14:02 hängen ließ, mit angehängter Evidenz und Konfidenzwert. Sie geben frei, ein Neustart von der Allowlist läuft auf app-02, ein Verifikationslauf bestätigt die Erholung.
Ihre Umgebung über Ihr Gateway · read-only
Deploymentpod apipod worker

Read-only-Signale

  • kubectl get pods
  • kubectl describe
  • rollout history
  • resource limits

Szenario 02 / 04 Kubernetes-Workload

Ein Rollout, der nicht ready wird

Incident
Ein Deployment läuft nach einem Rollout in einen Crash-Loop. Ihr Gateway läuft im Cluster, installiert aus dem Helm-Chart.
Evidenz
Read-only-Abfragen im Cluster erfassen Pod-Status, Events, die Rollout-Historie und Resource-Limits, abgeglichen mit dem letzten gesunden Stand.
Vorschlag & freigegebener Fix
Der Vorschlag ist ein Rollback auf die letzte gesunde Revision, als deklarative Änderung, mit der fehlgeschlagenen Readiness-Probe als Evidenz. Nach Freigabe wird der Rollback von der Allowlist angewendet, die Verifikation beobachtet, wie die Pods ready werden.
Ihre Umgebung über Ihr Gateway · read-only
webapicache

Read-only-Signale

  • docker ps
  • container logs
  • image digest
  • df -h

Szenario 03 / 04 Docker-Dienste auf einem Host

Ein schlechter Tag und eine volllaufende Platte

Incident
Ein Container ist unhealthy und startet auf einem Compose-Host immer wieder neu, und die Platte läuft voll.
Evidenz
Das Gateway liest Container-Health, Logs, den laufenden Image-Digest und die Host-Plattenauslastung, alles read-only, und stellt sie gegenüber.
Vorschlag & freigegebener Fix
Der Vorschlag: der neueste Image-Tag ist eine Regression, also den einen Dienst auf den gepinnten guten Tag zurückrollen und das übergroße Log rotieren. Sie geben jeden Schritt frei, Aktionen von der Allowlist laufen, die Verifikation bestätigt den Container wieder als healthy.
Ihre Umgebung über Ihr Gateway · read-only
primaryreplica

Read-only-Signale

  • pg_stat_activity
  • long-running SQL
  • replication lag
  • disk usage

Szenario 04 / 04 Datenbank unter Last

Verbindungen sättigen, eine Replica hängt

Incident
Auf dem Primary sättigen sich die Verbindungen und eine Replica beginnt hinterherzuhängen.
Evidenz
Read-only-Abfragen erfassen Verbindungszahlen, die am längsten laufenden Statements und den Replikationsstatus, ohne etwas zurückzuschreiben.
Vorschlag & freigegebener Fix
Der Vorschlag benennt eine einzelne ausufernde Query, die Verbindungen offen hält, und schlägt vor, genau diese Session zu beenden, ein reversibler Schritt von der Allowlist. Ihr Engineer gibt frei, der Schritt läuft über das Gateway, die Verifikation bestätigt die Erholung der Verbindungen.
dauerhaft hinterlegte Zugangsdaten in der Control Plane, keine Schlüssel, Tokens oder Shells zu Ihren Hosts
0
Engineer-Freigabe für jede Änderung, ohne Ausnahme in v1
1
unabhängige Kontrollebenen: unser Policy-Gate, dann die eigene Allowlist Ihres Gateways
2
der Ausführung läuft in Ihrer Infrastruktur, auf einem Gateway, das Sie betreiben
100 %

Warum es sich rechnet

Die Kosten von Incidents senken, nicht das Team, das sie behebt

Jeder Incident stellt Ihnen zwei Rechnungen: eine für die Ausfallzeit und eine für die Senior-Stunden bis zur Entscheidung. Die Plattform greift die zweite an. Sie übernimmt die Vorarbeit (Untersuchung, Korrelation, Dokumentation und das erneute Lösen bereits gelöster Probleme), damit die Stunden Ihrer Engineers dort landen, wo sie am meisten wert sind: bei der Entscheidung und bei der Engineering-Arbeit, die hinter der Queue gewartet hat.

Untersuchungen kommen fertig vorbereitet an

Der teure Teil eines Incidents ist selten der Fix; es sind die Stunden Evidenzsammlung, bevor irgendjemand etwas entscheiden kann. Hier läuft die Diagnostik, sobald das Ticket eintrifft. Ihr Engineer beginnt bei der Entscheidung, mit der Evidenz im Anhang.

Wiederholte Incidents kosten nicht mehr den vollen Preis

Wenn ein freigegebener Fix verifiziert, kann er zu einem geprüften, parametrisierten Runbook befördert werden, verknüpft mit der Signatur des Incidents. Das nächste Auftreten kommt als vorgeprüfter Vorschlag an. Die Stückkosten wiederholter Incidents sinken, und die Abhängigkeit vom Modell sinkt mit.

Wachstum abfangen, ohne die Rufbereitschaft auszubauen

Mehr Hosts und mehr Alerts müssen nicht proportional mehr Unterbrechungen bedeuten. Die Plattform absorbiert das Triage-Volumen; Ihre Leute treffen die Entscheidungen. Und eine Rufbereitschaft, die niemanden ausbrennt, ist auch ein Retention-Faktor; Fluktuation und Neubesetzung sind Betriebskosten.

fig. 02 · wohin die Stunden gehenStruktur, keine Messung
Heute trägt ein Engineer jede Phase eines Incidents. Mit der Plattform konvergiert der Anteil des Engineers auf die Entscheidung; bei wiederholten Incidents macht ein befördertes Runbook ihn noch kleiner. HEUTE jede Stunde ist eine Engineer-Stunde Triage Untersuchen Korrelieren Beheben Doku ERSTES AUFTRETEN die Plattform übernimmt die Vorarbeit Evidenz & Triage Entscheiden & Freigeben Ausführen Verifizieren & Doku ein verifizierter Fix ⤷ befördert zum geprüften Runbook, verknüpft mit der Incident-Signatur JEDE WIEDERHOLUNG dieselbe Incident-Klasse, jedes Mal günstiger geprüfter Runbook-Treffer Freigeben Ausführen Verifizieren die Stunden Ihres Engineers die Plattform Ihr Gateway

die dunklen Zellen sind die Stunden Ihres Engineers; mit jedem beförderten Runbook konvergieren sie auf die Entscheidung selbst

Die Pipeline

Vom Ticket zum verifizierten Fix, ein auditierbarer Pfad

Vier Stufen, vom Alert über die Root-Cause-Analyse bis zum verifizierten Fix. Die Ausgabe des Modells wird auf jeder davon als nicht vertrauenswürdige Daten behandelt, und nur die letzte berührt Ihre Systeme.

  1. 01

    Ein Ticket trifft ein

    Ihr Monitoring meldet den Incident, den es heute schon meldet. Die Plattform konsumiert das Signal, das Sie bereits haben; keine neuen Agents an Tag eins.

    läuft · control plane
  2. 02

    Die KI untersucht die Ursache und schlägt vor

    Read-only-Diagnostik sammelt Evidenz über Ihr Gateway. Das Modell liefert einen Vorschlag mit Konfidenz und angehängter Evidenz, und es darf „Ich weiß es nicht“ sagen.

    läuft · control plane
  3. 03

    Policy prüft, ein Mensch gibt frei

    Jeder Vorschlag passiert ein auditierbares Policy-Gate und landet dann bei einem Engineer. Nichts, was das Modell schreibt, erreicht die Ausführung von selbst.

    läuft · control plane + ihr engineer
  4. 04

    Ein deterministischer Workflow führt aus

    Die freigegebene Aktion (eine Operation von der Allowlist, nie ein Freitext-Kommando) läuft über Ihr Gateway, in beide Richtungen signiert, und meldet sich mit einem Verifikationslauf zurück.

    läuft · ihre infrastruktur

Stufen 01–03 berühren Ihre Hosts nie · Stufe 04 überquert die Grenze: signiert, befristet, gegen Ihre Allowlist re-validiert

Die Einordnung

Die dritte Position: Ausführung mit struktureller Eindämmung

Die Kategorie hat sich auf zwei Muster eingependelt, und beide lassen die harte Frage offen: Wer hält die Schlüssel, und was begrenzt einen Fehler?

muster der kategorie · der read-only-assistent

Hört bei der Diagnose auf

Untersucht, korreliert, schreibt eine solide Zusammenfassung und übergibt dann. Den Fix tippen weiterhin Sie, zu welcher Uhrzeit auch immer der Pager ging.

muster der kategorie · der autonomie-regler

Tauscht Eindämmung gegen Geschwindigkeit

Führt mit eigenen Zugangsdaten aus, gesteuert von einem Schwellwert. Sicherheit wird zur Einstellung, und eine Einstellung kann falsch konfiguriert sein. Der Blast-Radius ist alles, was diese Zugangsdaten erreichen.

diese plattform

Führt aus, innerhalb von Grenzen, die sie nicht überschreiten kann

Modell-Ausgabe ist Daten, nie Kommandos, und das Policy-Gate sitzt auf dem einzigen Weg zur Ausführung. Was ausgeführt wird, läuft auf einem Gateway, das Sie betreiben, gegen eine Allowlist, die Sie veröffentlichen, ohne dauerhafte Zugangsdaten in unserer Control Plane. Selbst ein signierter Job unserer eigenen Control Plane wird verweigert, wenn er nicht auf Ihrer Liste steht.

In Produktion führt dieser Weg standardmäßig über die Freigabe eines Engineers; in v1 bei jeder Änderung.

Die Plattform

Zwei Lanes. Ein Gateway. Ihre Regeln.

Betriebs-Incidents und Security-Findings sind verschiedene Probleme, und die Plattform weigert sich, sie zu vermischen. Beide laufen über dasselbe Gateway ohne hinterlegte Zugangsdaten, aber nur die Ops-Lane ist überhaupt für mehr als eine menschliche Entscheidung vorgesehen.

Lane 01 · Ops: überwachen & beheben

Monitoring, zuerst ohne Agents

  • Tag eins: die Plattform konsumiert Tickets aus dem Monitoring, das Sie bereits betreiben, über Bare Metal, VMs und Kubernetes hinweg. Nichts muss über die Flotte ausgerollt werden, bevor der erste Vorschlag ankommt.
  • Tier 1, der Standard, begrenztes Sampling: das Gateway verbindet sich per SSH, nimmt eine kurze eBPF/perf-Stichprobe gegen eine gelernte Baseline und lässt nichts auf dem Host zurück.
  • Tier 3, opt-in, residenter Sensor: ein Sensor der Falco/Tetragon-Klasse für kontinuierliche Sichtbarkeit und In-Kernel-Verteidigung, genau auf den Hosts, auf denen Sie ihn wollen.

sensoren sind ein upgrade, keine voraussetzung

Lane 02 · Security: scannen, priorisieren, eindämmen

Eine Security-Lane, die Autopilot verweigert

  • SBOM-basiertes Schwachstellen-Scanning über die Flotte, abgeglichen mit öffentlichen Feeds: NVD, OSV, Distro-Advisories.
  • Priorisierung, die Sie verteidigen können: Signale zu bekannter Ausnutzung und Exploit-Wahrscheinlichkeit (KEV, EPSS) schärfen die Queue. Exploit-Datenbanken sind ein Read-only-Signal; nichts wird je heruntergeladen oder ausgeführt.
  • Breach-Detection-Signale speisen dieselbe Incident-Engine, als security markiert und in eine beweissichernde Containment-Lane geroutet, in der ein Mensch jeden Schritt führt.

Risiko = Kritikalität × Exposition × Schweregrad × Exploit-Wahrscheinlichkeit

auto-remediation hier: per design verweigert

Deployment & Auslieferung

Dieselbe Plattform, ausgeliefert für Ihren Betrieb und geeignet für ein segmentiertes Netz.

Control Plane

Von uns betrieben oder selbst gehostet in Ihrem eigenen Rechenzentrum. Dieselbe Plattform, innerhalb Ihres Perimeters.

Ausgeliefert als

Eine Kubernetes-Installation per Helm, ein produktiver Docker-Compose-Stack oder native OS-Pakete mit gehärteten systemd-Diensten. Die Images sind multi-arch, jedes mit angehängter SBOM und Signatur.

  • Kubernetes · Helm
  • Docker Compose
  • rpm · deb · systemd

Gateways

Eines pro Netzsegment, wo Ihre Topologie es verlangt. Jedes wählt sich von innen nach außen ein, jedes erzwingt seine eigene lokale Allowlist, damit ein stark segmentiertes Netz segmentiert bleibt.

Inferenz

Ein gehostetes Frontier-Modell oder vLLM auf Ihrer eigenen Hardware. Wahl pro Tenant.

beide Lanes führen gleich aus: signierte Jobs von Ihrer Allowlist auf dem Gateway, das Sie betreiben, innerhalb Ihrer Infrastruktur

Das Sicherheitsmodell

Gebaut für die Frage, die Ihr CISO stellen wird

Freigabe ist hier Architektur, keine Einstellung: Die Control Plane hält keinerlei dauerhafte Zugangsdaten, es gibt keinen Ausführungspfad am Policy-Gate vorbei, und nichts auf unserer Seite kann erweitern, was Ihre Allowlist erlaubt. Wenn sich eine Aussage in dieser Tabelle je ändert, hat sich zuerst die Architektur geändert.

fig. 01 · die Grenze ohne Credentialswie ausgeliefert
Wie die KI-gestützte Plattform Remediation ohne hinterlegte Zugangsdaten ausführt: eine Control Plane ohne Credentials, eine Vertrauensgrenze und ein vom Kunden betriebenes Gateway, das die Verbindung ausgehend aufbaut und jeden Job gegen die eigene lokale Allowlist re-validiert. CONTROL PLANE 0 Credentials Ingress Tickets rein KI-Reasoning schlägt nur vor Policy-Gate OPA · jeder Vorschlag Freigabe · Engineer ohne sie geht nichts raus Audit jeder Schritt JobSpec signiert ↓ befristet · idempotent das Gateway verbindet · nur ausgehend ↓ JobSpec · signiert, befristet ↑ JobResult · Evidenz, geschwärzt VERTRAUENSGRENZE mTLS · beidseitig signiert IHRE INFRASTRUKTUR Credentials leben hier, nur hier Gateway · Sie deployen und betreiben es Credential-Store versiegelt, nur hier Lokale Allowlist von Ihnen gepflegt Executor deterministisch re-validiert jeden Job gegen die lokale Allowlist: eine gültige Control-Plane-Signatur erlaubt keine Aktion außerhalb der Liste web-01 db-02 k8s-node-7 nur Aktionen von der Allowlist
Was die Control Plane tut
Was sie nie kann
Orchestriert Incidents, urteilt über Evidenz, signiert Job-Specs.
Ein Credential, einen Schlüssel oder eine Shell zu einem Ihrer Hosts halten.
Erzeugt Remediation-Vorschläge mit Evidenz und Konfidenzwert.
Selbst etwas ausführen; Modell-Ausgabe ist Daten, in Quarantäne bis zum Gate.
Prüft jeden Vorschlag gegen Ihre Policy, bevor ein Engineer ihn sieht.
Den Engineer überspringen; in v1 wird jede Änderung von einem Menschen freigegeben.
Sendet signierte, befristete, idempotente Jobs an Ihr Gateway.
Eine Aktion ausführen, die Ihre lokale Allowlist nicht enthält; selbst ein signierter Job unserer eigenen Control Plane wird verweigert, wenn er nicht auf Ihrer Liste steht.
Meldet „Ich weiß es nicht“, wenn die Evidenz keinen Fix stützt.
Eine unsichere Vermutung als Antwort verkleiden.

Security-Incidents werden nie automatisch remediert

Security-Findings werden in eine menschengeführte, beweissichernde Containment-Lane geroutet. Automatische Eingriffe auf Signale, die ein Angreifer beeinflussen kann, zerstören Forensik und sind vom Angreifer auslösbar; deshalb ist das ein Pfad, den wir nicht bauen, kein Schalter, den wir ausgeschaltet ausliefern.

per design verweigert

FAQ

Die Fragen, die wir selbst stellen würden, klar beantwortet

Wie unterscheidet sich das von anderen AI-SRE-Tools?

Die meisten Tools dieser Kategorie hören bei der Diagnose auf (Untersuchung und Zusammenfassung, der Fix bleibt Handarbeit) oder sie führen mit eigenen Zugangsdaten hinter einem konfigurierbaren Autonomie-Schwellwert aus. Diese Plattform nimmt eine dritte Position ein: Sie führt aus, aber nur über ein Gateway, das Sie betreiben, gegen eine Allowlist, die Sie veröffentlichen, ohne dauerhafte Zugangsdaten in der Control Plane und mit Policy-Gate plus menschlicher Freigabe auf dem einzigen Weg zur Ausführung. Die Eindämmung ist die Architektur, keine Einstellung.

Führt die KI Kommandos auf unseren Systemen aus?

Nein. Das Modell erzeugt Vorschläge: strukturierte Daten mit Evidenz und Konfidenzwert. Die Ausführung ist ein separates, deterministisches System, das ausschließlich Operationen von einer Allowlist ausführt, die Sie kontrollieren, nach Policy-Prüfung und menschlicher Freigabe.

Welche Zugangsdaten halten Sie zu unserer Infrastruktur?

Keine. Die Control Plane hält keinerlei dauerhafte Zugangsdaten zu Kunden-Infrastruktur. Secrets liegen nur im Gateway, das innerhalb Ihrer Infrastruktur läuft; es baut die Verbindung von innen nach außen auf, einen eingehenden Pfad gibt es nicht.

Was ist mit Prompt Injection über Log-Inhalte?

Wir setzen sie voraus. Logs und Tickets gelten als vom Angreifer beeinflussbar, deshalb bleibt Modell-Ausgabe in Quarantäne, bis sie das Policy-Gate und die menschliche Freigabe passiert hat. Findings der Security-Lane werden grundsätzlich nie automatisch remediert.

Was passiert, wenn die KI falsch liegt?

Sie sagt es, oder ein Mensch fängt es ab. Vorschläge tragen Konfidenz und Evidenz; das Modell darf mit „Ich weiß es nicht“ antworten. Ohne die Freigabe eines Engineers wird nichts ausgeführt, und jeder Schritt landet im Audit-Trail.

Ersetzt das unser Operations-Team?

Nein. Die Plattform übernimmt den repetitiven Teil der Incident-Arbeit: Evidenzsammlung, Korrelation, Dokumentation und das erneute Lösen bereits gelöster Probleme. Die Entscheidungen bleiben bei Ihren Engineers: In v1 wird nichts ohne ihre Freigabe ausgeführt. Was sich ändert, ist, wofür ihre Stunden eingesetzt werden.

Reduziert das unsere MTTR?

Es greift den Teil der MTTR an, den Sie wirklich bezahlen: die Stunden bis zur Entscheidung. Untersuchungen kommen fertig vorbereitet an, Ihr Engineer beginnt also bei der Entscheidung, mit der Evidenz im Anhang, und wiederholte Incidents können zu geprüften Runbooks befördert werden, die als vorgeprüfte Vorschläge ankommen. Wir nennen keine Schlagzeilen-Prozente; was sich ändert, ist der Mechanismus, keine erfundene Zahl.

Kann die gesamte Plattform in unserem Rechenzentrum laufen?

Ja. Die Control Plane gibt es von uns betrieben oder bereitgestellt in Ihrem eigenen Rechenzentrum. Die Inferenz ist OpenAI-API-kompatibel und läuft auf Wunsch gegen Ihr eigenes vLLM-Deployment auf Ihrer Hardware. Und die Gateways sitzen in Ihrem Netz: in stark segmentierten Umgebungen eines pro Segment, jedes wählt sich von innen nach außen ein, jedes erzwingt seine eigene lokale Allowlist. Nichts muss Ihren Perimeter verlassen.

Testen Sie es an Ihren echten Incidents, als Design-Partner

Vesmona ist in der Private Beta. Wir suchen eine kleine Gruppe von Teams, die die Plattform an echten Incidents betreiben und uns sagen, wo sie zu kurz greift. Sie bekommen frühen Zugang, einen direkten Draht zum Engineering-Team und ein echtes Mitspracherecht bei der Roadmap. Wir bekommen die betriebliche Realität (und, wo sie verdient ist, die Referenz), die eine Plattform produktreif macht.

Design-Partner werden