euvyra
EnglishSelbst betreiben

Sicherheit und Souveränität

Ihre Daten bleiben, wo Sie es entscheiden.

EUVYRA läuft auf Infrastruktur Ihrer Wahl und kontaktiert nichts, was Sie nicht erlaubt haben. Es telefoniert nicht nach Hause und belegt das mit einem Bericht, der aus der laufenden Konfiguration entsteht.

Selbst betreiben

Was unter Ihrer Kontrolle bleibt

Wo es läuft
Docker Compose oder Helm auf Ihren Servern oder in jeder europäischen Cloud, mit PostgreSQL und S3-kompatiblem Speicher, den Sie betreiben und verschlüsseln.
Was hinausgeht
Nichts, solange ein Host nicht auf der Allowlist steht. Leer heißt: gar keine ausgehenden Verbindungen. Das Helm-Chart setzt dieselbe Liste als Network Policy durch.
Was gespeichert wird
Personenbezogene Daten werden im SDK vor dem Senden geschwärzt und beim Eingang noch einmal. Kennungen von Endnutzern werden pseudonymisiert. Projekte können sich auf Metadaten beschränken.
Wie lange
Aufbewahrungsfristen pro Projekt für Traces, Runs und Evaluierungen und Löschung nach DSGVO, bei der nur ein Hash der Kennung übrig bleibt.
Wer was getan hat
Ein Audit-Log, an das nur angehängt wird, per Hash verkettet und durch einen Datenbank-Trigger geschützt, mit jeder Änderung durch Menschen, API-Schlüssel und KI-Assistenten.
Was Sie belegen können
Mit Ed25519 signierte Nachweispakete, die sich offline prüfen lassen, ohne Verbindung zu EUVYRA oder sonst jemandem.

EUVYRA bindet keine Analyse, kein Fehler-Tracking und keinen E-Mail-Dienst ein, und die Konsole bringt ihre Schriften selbst mit. Diese Website hält es genauso.

Eigenbetrieb

Docker Compose startet PostgreSQL 17, einen S3-kompatiblen Objektspeicher mit Verschlüsselung im Ruhezustand, die API, einen Hintergrund-Worker und die Konsole. Der API-Port lauscht nur lokal; nach außen bringt ein TLS-Proxy Ihrer Wahl die Konsole.

Auf Kubernetes installieren Sie das Helm-Chart. Geheimnisse kommen aus einem bestehenden Kubernetes-Secret, Migrationen laufen als Hook vor Installation und Upgrade, Pods laufen ohne Root-Rechte mit schreibgeschütztem Root-Dateisystem, und eine NetworkPolicy lässt API und Worker nur DNS und die von Ihnen genannten Adressbereiche erreichen.

Trainingsjobs und Modell-Endpunkte laufen dort, wo der Agent läuft. Job-Pods verzichten auf alle Capabilities, können keine Rechte ausweiten, nutzen das Standard-Seccomp-Profil und binden kein Service-Account-Token ein. Jeder Job bekommt einen API-Schlüssel nur für sein Projekt, der mit dem Job abläuft.

Bericht zur Datenresidenz

Die Seite zur Datenresidenz entsteht aus der laufenden Konfiguration: wo jede Komponente läuft, die Allowlist und die letzten ausgehenden Verbindungsversuche, auch die blockierten. Auch Nachweispakete tragen die Region der Installation. Manches sieht sie nicht, das bewerten Sie selbst:

  • wo Ihr Anbieter für PostgreSQL und Objektspeicher Daten und Backups tatsächlich ablegt;
  • Ihren Ingress, Ihr CDN und die TLS-Terminierung;
  • die Unterauftragsverarbeiter externer Modellanbieter, die Sie zulassen;
  • Support-Zugriffe Ihres Hosting-Anbieters.

Personenbezogene Daten, doppelt geschwärzt.

Bevor ein Span Ihren Prozess verlässt, maskiert oder hasht das SDK E-Mail-Adressen, IBANs, Kartennummern, Telefonnummern, Steuer-IDs und Krankenversichertennummern, IP-Adressen und gängige Zugangsdaten-Formate, dazu eigene Muster. Der Server wendet beim Eingang noch einmal die Richtlinie des Projekts an. Ein falsch eingestellter Client führt so nicht zu einem Datenabfluss.

Das Gateway macht dasselbe für Anfragen an Endpunkte mit Schwärzung, bevor sie EUVYRA verlassen. Kennungen von Endnutzern werden zu Pseudonymen, abgeleitet mit dem geheimen Schlüssel der Installation.

Mustererkennung findet keine Namen und keine Gesundheitsangaben in Freitext. Projekte mit solchen Daten können nur Metadaten speichern: Zeiten, Tokens und Kosten ohne Ein- und Ausgaben.

import euvyra

euvyra.configure(
    project="support-bot",
    redact=True,
    redaction_mode="mask",  # oder "hash"
    custom_patterns=[
        {"name": "patient", "pattern": r"PAT-\d{6}"},
    ],
)

Zugriff und Verantwortlichkeit

  • Rollen in der Organisation: Owner, Admin, Member, Auditor (liest alles und exportiert Nachweise, ändert nichts) und Viewer. Rollen im Projekt: Admin, Editor, Viewer; Mitglieder sehen nur ihre Projekte.
  • Governance-Funktionen wie Entwicklung, Datenschutz, Compliance und Risiko legen fest, wer welchen Freigabeschritt abzeichnen darf.
  • Single Sign-on über OIDC oder SAML und Benutzerverwaltung über SCIM.
  • API-Schlüssel gelten für ein Projekt oder die Organisation, tragen die Berechtigungen ingest, read, write oder invoke, laufen ab und werden nur als SHA-256-Hash gespeichert.
  • Browsersitzungen nutzen ein HttpOnly-Cookie, und zustandsändernde Anfragen brauchen einen Header, den Formulare fremder Seiten nicht setzen können.
  • Zugangsdaten für Cloud-Konten, LLM-Richter und Webhooks werden mit einem aus dem Installationsgeheimnis abgeleiteten Schlüssel verschlüsselt und nie von der API zurückgegeben.

KI-Assistenten

Assistenten verbinden sich per MCP mit OAuth 2.1: Authorization Code mit PKCE, Tokens an die MCP-Ressource gebunden, Access-Tokens mit einer Stunde Laufzeit und rotierende Refresh-Tokens; ein doppelt verwendetes Token widerruft die ganze Verbindung. Ein Assistent handelt mit den Rechten der Person, die ihn verbunden hat, jede Änderung steht unter seinem Namen im Audit-Log, und was eine Person entscheiden muss, bleibt in der Konsole: Freigaben, Einstufung von Vorfällen, Löschungen, Rechteänderungen und Ausgaben.

Fragen aus Sicherheitsprüfungen

Sendet EUVYRA Telemetrie an den Hersteller?

Nein. Das Produkt enthält weder Analyse noch Fehler-Tracking. Mit leerer Allowlist baut der Server keine ausgehenden Verbindungen auf, und die Seite zur Datenresidenz listet jeden Versuch.

Braucht der Cluster für Jobs eingehenden Zugriff?

Nein. Der Agent verbindet sich nach außen und holt sich die Arbeit. Eingehend braucht EUVYRA nur den Weg zu Modell-Endpunkten, die das Gateway aufruft.

Wie prüfen wir ein Nachweispaket, ohne dem Hersteller zu vertrauen?

Mit euvyra evidence verify package.zip --public-key installation.pem. Der Befehl prüft offline jeden Datei-Hash und die Ed25519-Signatur. Hinterlegen Sie eine Kopie des öffentlichen Schlüssels der Installation bei Ihren Prüfern.

Kann ein Admin das Audit-Log bearbeiten?

Jeder Eintrag speichert den Hash des vorigen, jede Änderung oder Löschung bricht also die Verifikation ab diesem Eintrag. Auf PostgreSQL weist ein Trigger Änderungen und Löschungen in der Tabelle von vornherein ab.