Der sicherste Ort für Ihre Arbeit ist der Rechner, auf dem sie schon liegt.

1. Unser Ansatz

Zwei Prinzipien prägen alles Folgende. Erstens, standardmäßig local-first: Auf der lokalen Runtime laufen die Inferenz des Agenten, das Gedächtnis und die Dateien auf Ihrem eigenen Rechner, mit von Ihnen gehosteten Modellen. Die Ausnahme ist ein kostenpflichtiges Tool, das Sie ausführen möchten - Web- und X-Recherche, Bild- und Videoerzeugung, Connector-Aktionen -, das verwaltete Anbieterschlüssel benötigt, die wir bereithalten, sodass dieser einzelne Tool-Aufruf von Convira ausgeführt und an Ihr Gerät zurückgegeben wird (und nur, während Sie online sind). Zweitens, die Cloud ist optional und minimal: Wenn Sie die Cloud-Runtime nutzen, wird Ihre Ausführung durchgeführt und an den KI-Modellanbieter weitergeleitet, aber die Inhalte der Ausführung werden nicht auf unseren Servern gespeichert - der Datensatz verbleibt auf Ihrem Gerät. Die einzige Ausnahme ist ein Austausch, den Sie beim Bewerten einer Antwort selbst teilen; diesen bewahren wir bis zu 90 Tage auf, oder bis Sie die Bewertung entfernen. Weniger Daten auf unserer Seite bedeuten weniger, das geschützt werden muss, und weniger, das jemals offengelegt werden kann.

Das Ergebnis ist eine Architektur, in der Ihre sensibelste Arbeit die Hardware, die Sie kontrollieren, nie verlassen muss.

2. Wo Ihre Daten liegen

Convira hat drei Runtimes, und sie unterscheiden sich genau darin:

Auf dem Cloud-Weg werden Ausführungsinhalte - der von Ihnen eingegebene Text, beteiligte Dateien, Tool-Eingaben und -Ausgaben sowie die Antworten des Modells - nicht in unsere Datenbanken geschrieben. Unser Code entfernt sie, bevor irgendetwas gespeichert wird, und automatisierte Tests prüfen diese Invariante bei jedem Build. Die Details finden Sie in der Datenschutzrichtlinie.

Team Hub

Team Hub ist keine vierte Runtime - es führt keinen Agenten aus und erzeugt keinen Ausführungsdatensatz -, aber es ist die Stelle, an der die geteilten Inhalte eines Teams auf unseren Servern liegen. Deshalb steht es neben der Tabelle und nicht darin. Die Nachrichten, Mitteilungen, geteilten Dateien und Unterhaltungsnamen eines Teams werden von uns aufbewahrt. Eine weitere Art von Inhalt kann dort liegen: Wenn Sie die optionale Cloud-Synchronisierung für Skills und Projektwissen einschalten, wird dieser Text auf unserer Seite als gewöhnliche Datenbankzeilen gespeichert, wie der Abschnitt zur Verschlüsselung weiter unten beschreibt.

Aufbewahrt werden sie als Chiffretext, den wir nicht öffnen können. Die Schlüssel stammen aus der eigenen MLS-Gruppe jedes Bereichs (RFC 9420, die OpenMLS-Implementierung, mit einer quantensicheren Cipher Suite): Jedes Mitgliedsgerät hält ein Blatt in dieser Gruppe und leitet daraus das Epochengeheimnis ab, und kein Convira-Server hält ein Blatt oder einen Schlüssel, der eine Nachricht, eine Mitteilung, einen Unterhaltungsnamen oder einen Anhang öffnet. Hat ein Arbeitsbereich eine Wiederherstellungsphrase hinterlegt, ist auch der Leser, den diese Phrase ableitet, Mitglied der gemeinsamen Gruppe. Die Suche läuft auf Ihrem Gerät, weil unsere Server sie für Sie gar nicht ausführen könnten.

Was unsere Server sehen, ist das, was die Zustellung braucht: welcher Arbeitsbereich und welche Unterhaltung, eine Sequenznummer, eine Epoche, ein Inhaltstyp, eine Größe, ein Hash, welches Konto es hochgeladen hat, und wann. Vier weitere Angaben liegen im Klartext, weil die Funktionen, die sie nutzen, sonst nicht möglich wären: welche Konten an einer Direktnachricht oder Gruppe beteiligt sind, wer von ihnen die Gruppe verwaltet, dass ein namentlich bekanntes Mitglied auf eine bestimmte Nachricht reagiert hat - nie mit welchem Emoji - und wer eine Mitteilung, die eine Bestätigung verlangt hat, als gelesen bestätigt hat, und wann.

Das Löschen einer Nachricht entfernt unsere Kopie und die Kopien auf den Geräten Ihrer Teammitglieder, überall dort, wo die App sie hält. Ein neuer Computer tritt einem Arbeitsbereich erst bei, wenn er freigegeben wurde: Einer der eigenen Computer dieser Person signiert für ihn, oder, falls die Person alle ihre Computer verloren hat, gibt ihn jemand mit den 24 Wiederherstellungswörtern des Arbeitsbereichs oder eine Inhaberin oder ein Administrator des Arbeitsbereichs frei, und alle im Arbeitsbereich werden benachrichtigt.

3. Wie die Agentenausführung isoliert wird

Jeder Tool-Aufruf auf dem Desktop wird von Conviras Berechtigungsrichtlinie geprüft. Die native Prozessisolation fügt darunter eine zweite, unabhängige Schutzebene hinzu. Sie nutzt folgende Primitive:

• Linux: ein bubblewrap-Namespace-Jail. Das Tool erhält ein frisches Dateisystem-Root, das nur die ihm zugewiesenen Verzeichnisse enthält, dazu die schreibgeschützten Systempfade, die es zum Starten braucht - alles andere ist nicht bloß unlesbar, es ist gar nicht vorhanden. Es bekommt einen eigenen Prozess-ID-Namespace, und ein Tool, das ohne Netzwerkzugriff läuft, bekommt einen eigenen Netzwerk-Namespace, dessen einziges Gerät Loopback ist - es gibt also keinen Weg vom Rechner hinaus, auf dem es einen Socket öffnen könnte.
• macOS: ein Seatbelt-Profil (sandbox-exec), das standardmäßig alles verweigert.
• Windows: pro Start ein frischer AppContainer, angelegt ohne Capability-SIDs - was ausgehenden Netzwerkverkehr standardmäßig verweigert und auch das Dateisystem standardmäßig verweigert, denn ein Verzeichnis, das dem Tool nicht gewährt wurde, trägt keinen Eintrag für die Identität dieses Containers. Ein Job Object auf demselben Prozess begrenzt Speicher, Prozesse und CPU.

Auf Ihrem eigenen Computer geprüft. Wenn ein Tool zum ersten Mal eine Sandbox benötigt, prüft Convira auf Ihrem Computer, ob die Sandbox des Betriebssystems verfügbar ist, und erprobt ihre Ressourcenlimits in einer echten Ausführung. Code, den die KI schreibt, läuft ausschließlich in dieser Sandbox: Kann die Sandbox nicht starten, wird der Code abgelehnt, statt ohne sie ausgeführt zu werden. Jede Aktion hält fest, unter welcher Isolation sie tatsächlich lief, und die App zeigt Ihnen das an.

Open Source. Die oben beschriebene Isolationsschicht ist unter Apache 2.0 als convira-sandbox veröffentlicht - die Seatbelt-Profile für macOS, die bubblewrap-Namespace- und Mount-Argumente für Linux, der AppContainer- und Job-Object-Code für Windows sowie die Prüfungen, die entscheiden, ob eine Kontrolle als durchgesetzt gemeldet wird. Sie können genau nachlesen, was diese Prüfungen tun, die Testsuite selbst ausführen und beobachten, dass sich Ihr eigener Rechner so verhält, wie diese Seite es beschreibt.

Die Codeausführung in der Cloud hat eine andere Grenze: Sie läuft in einer bubblewrap-Namespace-Sandbox innerhalb des API-Worker-Containers - mit eigener Dateisystemwurzel, eigenem Prozess-ID-Namespace und eigenem Netzwerk-Namespace. Ist diese Sandbox auf dem Host nicht verfügbar, verweigert das Tool die Ausführung, statt auf einen unbeschränkten Prozess zurückzufallen. Tool-Ergebnisse legen die Herkunft der Isolation offen, damit Agent und Oberfläche sehen können, unter welcher Isolation jeder Aufruf tatsächlich gelaufen ist.

Ausgehender Netzwerkverkehr. Der größte Teil des ausgehenden Netzwerkzugriffs aus einer Ausführung wird über einen HTTP-CONNECT-Proxy vermittelt, der eine mehrschichtige Domain-Zulassungsliste durchsetzt (eine explizite Sperrliste, dann alles, was Sie während der Sitzung genehmigt haben, dann die in Ihrem Plan und Arbeitsbereich erlaubten Domains, dann eine kleine integrierte Grundmenge von Modell- und Paket-Endpunkten). Er blockiert außerdem direkte IP-Verbindungen, private und Link-Local-Bereiche sowie Cloud-Metadaten-Endpunkte. In der lokalen Runtime steht der Webzugriff standardmäßig auf der eingeschränkten Stufe, der Offline-Modus trennt das Netzwerk vollständig, und der Proxy kann im Audit-Modus (alles protokollieren) oder im Erzwingungsmodus (blockieren und Sie optional fragen) laufen.

Git über das Netzwerk (Klonen, Fetch, Pull, Push und das Öffnen von Pull Requests) und die Installation der Abhängigkeiten Ihres Projekts nutzen eigene Tools, die sich direkt verbinden statt über den Proxy. Sie richten sich nach dem Offline-Modus statt nach dem Schalter für den Webzugriff, denn ein Push in Ihr eigenes Repository ist kein Surfen, und ein Push oder das Öffnen eines Pull Requests fragt Sie immer zuerst.

Wenn Sie ein kostenpflichtiges Web-, Medien- oder Connector-Tool aktivieren und aufrufen, wird dieser einzelne Aufruf an Convira weitergeleitet, um mit verwalteten Schlüsseln ausgeführt zu werden; alles andere bleibt auf Ihrem Rechner, und offline sind die kostenpflichtigen Tools schlicht nicht verfügbar.

Freigaben. Eine Policy-Engine klassifiziert, was jede Tool-Aktion gleich tun wird. Sensible Aktionen geschehen nicht einfach - die Ausführung pausiert und stellt eine Anfrage, die Sie genehmigen oder ablehnen müssen, bevor sie fortfährt. Für einige Aktionen können Sie „für diese Sitzung erlauben“ oder „immer zulassen“ wählen; andere fragen immer nach. Ihre Berechtigungsregeln werden auf Ihrem Gerät erstellt und auf die Ausführung angewendet; auf dem Cloud-Weg werden sie mit der Ausführung gesendet, nicht auf unserer Seite gespeichert.

4. Verschlüsselung

Bei der Übertragung. Der gesamte Datenverkehr zwischen den Apps und unserer API läuft über TLS, und unsere API verbindet sich über TLS mit ihrer Datenbank.

Im Ruhezustand. Unsere Datenbank ist im Ruhezustand verschlüsselt. Darüber hinaus werden bestimmte sensible gespeicherte Werte - zum Beispiel die Zugangsdaten und die Konfiguration der von Ihnen verbundenen Integrationen - zusätzlich auf Anwendungsebene mit AES-256-GCM verschlüsselt, mit zweckgebundenen Schlüsseln, die per HKDF-SHA256 aus einem Hauptschlüssel abgeleitet werden, samt Unterstützung für dessen Rotation. Der extrahierte Text von Skills und Projektwissen, die Sie für die Cloud-Suche synchronisieren, wird als gewöhnliche Datenbankzeilen gespeichert, damit der Abruf ihn lesen kann - abgedeckt durch die Verschlüsselung der Datenbank im Ruhezustand, nicht durch diese zusätzliche Schicht. Es gibt keine Kontopasswörter, also auch keinen Passwort-Hash, den wir aufbewahren müssten. Sitzungstokens, die Einmalcodes, die wir Ihnen per E-Mail senden, und ähnliche Geheimnisse werden nur als Hashes gespeichert, sind - wo zutreffend - nur einmal verwendbar und laufen ab. Ein Passkey hinterlässt bei uns nur seinen öffentlichen Schlüssel, und ein öffentlicher Schlüssel kann nichts signieren. API-Schlüssel von Drittanbieter-Modellanbietern liegen in unserer Serverumgebung, nicht in der Datenbank.

Auf Ihrem Gerät. Die Desktop-App bewahrt die maßgebliche Kopie Ihrer Ausführungen und Sitzungen in einer lokalen SQLite-Datenbank auf, die mit SQLCipher verschlüsselt ist. Der Verschlüsselungsschlüssel ist selbst durch den sicheren Speicher Ihres Betriebssystems geschützt (Keychain auf macOS, DPAPI auf Windows, libsecret auf Linux); ein paketierter Build verweigert den Start, wenn dieser Schutz nicht verfügbar ist, anstatt auf Klartext zurückzufallen. Die Desktop-App speichert keine API-Schlüssel von Modellanbietern. Die Drittanbieter-Zugangsdaten, die sie aufbewahrt - Ihr GitHub-Anmeldetoken sowie die Anmeldetokens und Einstellungen der von Ihnen verbundenen MCP-Server -, werden unter demselben Betriebssystemschutz verschlüsselt gespeichert.

Private Box. Eine selbst gehostete Private Box wird mit kurzlebigen, Ed25519-signierten Tokens lizenziert. Das Transport-Credential der Box erreicht Convira nie in einer Form, die Convira lesen kann: das Installationsprogramm druckt einen Übertragungscode auf der Konsole der Box, und eine Person mit Einstellungsverwaltung im Workspace tippt ihn auf einer Maschine in Convira ein, die diese Box schon festgelegt hat. Wenn Sie Teammitglieder hinzufügen, versiegelt ein Desktop mit Einstellungsverwaltung für jedes Mitglied einen eigenen Mitgliedsschlüssel an dessen Geräteschlüssel (X25519-Schlüsselvereinbarung + XChaCha20-Poly1305), und Convira leitet und speichert nur diesen Chiffretext weiter; das Kuvert einer zweiten Person mit Einstellungsverwaltung enthält das Transport-Credential selbst, ebenso versiegelt, weil nur sie für die anderen neu versiegeln kann. Convira besitzt keinen Schlüssel, der eines davon öffnet. Was Convira im Klartext behält, sind die Adresse der Box und ihre TLS-Fingerabdrücke, damit das Gerät eines Teammitglieds prüfen kann, dass es sich mit der richtigen Maschine verbindet.

Wenn Ihr Bedrohungsmodell verlangt, dass Ausführungsinhalte auf Hardware bleiben, die Sie kontrollieren, verwenden Sie die lokale Runtime oder eine Private Box, rufen Sie keine verwalteten Online-Tools auf und aktivieren Sie keine Aufgabe für die Ausführung bei ausgeschaltetem Computer - eine aktivierte Aufgabe ist der eine Fall, in dem Conviras eigene Server den Prompt zusammenstellen und an Ihre Box senden.

5. Authentifizierung und Zugriff

Sitzungen sind serverseitig hinterlegt: Das Token in Ihrem Browser-Cookie wird gegen einen gespeicherten Hash geprüft, das Cookie ist HttpOnly, in der Produktion Secure und SameSite=Lax, und Sitzungen laufen ab. Fehlgeschlagene Anmeldungen sind ratenbegrenzt. Die Desktop-App authentifiziert sich mit kurzlebigen, asymmetrisch signierten (Ed25519) Offline-Tokens, die Schutzmechanismen gegen Rollback enthalten, damit eine zurückgestellte Uhr sie nicht verlängern kann. Cross-Site Request Forgery wird mit einem Double-Submit-Token plus einer Origin-Prüfung blockiert, verglichen in konstanter Zeit.

Sie können Ihrem Konto einen Passkey hinzufügen - Ihren Fingerabdruck, Ihr Gesicht oder einen Hardware-Schlüssel, gehalten vom Gerät vor Ihnen. Er meldet Sie an, ohne dass Sie auf einen Code warten, und er ist der stärkste Nachweis, den das Konto akzeptiert: damit erfüllt er auch die zusätzliche Bestätigung, die wir vor einer sensiblen Änderung verlangen. Convira speichert nur den öffentlichen Schlüssel des Passkeys, der allein nichts signieren kann. Ihr Fingerabdruck und Ihr Gesicht verlassen Ihr Gerät nie: sie werden uns nie übermittelt und wir halten sie nie.

Der Zugriff auf Kundendaten innerhalb von Convira ist rollenbasiert. Mitarbeiter haben Plattformrollen (getrennt von jedem Kundenkonto), die bestimmen, was sie sehen und tun können; innerhalb eines Arbeitsbereichs haben Mitglieder Rollen (Owner, Admin, Operator, Viewer), die festlegen, was sie dort tun können. Jede privilegierte Mitarbeiteraktion wird in ein Audit-Log geschrieben, das nur angehängt werden kann - mit Akteur, Ziel, Grund und Quelle. Die Support-Identitätsübernahme ist, wenn sie nötig ist, auf die höchste Mitarbeiterrolle beschränkt, erfordert eine getippte Bestätigung und einen schriftlichen Grund, ist zeitlich begrenzt und wird im Audit-Log erfasst. Nur für die Entwicklung gedachte Authentifizierungs-Abkürzungen sind in Produktions-Builds fest deaktiviert.

6. Anwendungshärtung

Web. Die API und die Website senden gängige Hardening-Header - HSTS (mit Preload auf der Marketing-Website), eine Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, eine restriktive Referrer-Policy und eine Permissions-Policy, die Kamera, Mikrofon und Standortbestimmung deaktiviert. Die API akzeptiert Cross-Origin-Anfragen nur von einer expliziten Zulassungsliste unserer eigenen Origins. Öffentliche Formulare sind durch Cloudflare Turnstile und Honeypot-Felder geschützt und ratenbegrenzt.

Desktop. Die Electron-App führt die Oberfläche mit aktivierter Kontextisolierung, deaktivierter Node-Integration und eingeschalteter Renderer-Sandbox aus. Der Renderer kommuniziert mit dem Rest der App nur über eine schmale Preload-Brücke, deren Nachrichten gegen ein Schema validiert werden, und läuft unter einer strikten Content-Security-Policy (default-src 'self', keine Plug-ins, kein Framing, Trusted Types für Skripte). Berechtigungsanfragen aus Webinhalten werden abgelehnt, bis auf eine kurze Zulassungsliste.

7. Signierte Builds und Updates

Die Installationsprogramme für macOS und Windows sind code-signiert - Apple-Notarisierung unter macOS, Authenticode unter Windows - und der Auto-Updater der Desktop-App prüft die Signatur eines Updates, bevor es installiert wird, sodass ein manipuliertes Update abgelehnt wird. Die Update-Prüfungen respektieren die Netzwerkrichtlinie: Ist eine Runtime als offline konfiguriert, kontaktiert die App den Update-Server nicht.

8. Überwachung und Reaktion auf Vorfälle

Wir setzen auf der API und im Web-Dashboard Werkzeuge zur Fehlerüberwachung ein, die so konfiguriert sind, dass sie Authentifizierungs-Header, Cookies sowie Werte, die wie Passwörter, Tokens oder Secrets aussehen, ausschließen. Eingehende Webhooks (zum Beispiel von Stripe) werden per Signatur verifiziert und dedupliziert, um Replays abzuwehren. Wir untersuchen Sicherheitssignale, und im Falle einer Verletzung des Schutzes personenbezogener Daten benachrichtigen wir betroffene Nutzer und die zuständigen Behörden innerhalb der gesetzlich vorgeschriebenen Fristen.

9. Dienstleister

Convira setzt auf eine kleine Gruppe geprüfter Dienstleister - Zahlungen (Stripe), Hosting für API, Datenbank, Dateispeicher und Job-Warteschlangen (Amazon Web Services, in Frankfurt), Bot-Schutz (Cloudflare), Website-Hosting und cookiefreie Analyse (Vercel), Fehlerüberwachung (Sentry) und die KI-Modellanbieter (Anthropic, OpenAI, Google, xAI, Meta). Die vollständige aktuelle Liste, einschließlich Such-, E-Mail- und Connector-Infrastruktur, mit der Aufgabe und dem Standort jedes Anbieters finden Sie auf unserer Seite zu den Unterauftragsverarbeitern.

10. Ihr Part

Sicherheit ist gemeinsame Verantwortung. Ein paar Dinge, die wichtig sind:

• Fügen Sie einen Passkey hinzu, und halten Sie das Gerät, das ihn hält, gesperrt.
• Halten Sie die App aktuell - sie aktualisiert sich automatisch, aber bleiben Sie nicht bei einem monatealten Build.
• Überlegen Sie bewusst, was Sie verbinden und wozu Sie dem Agenten die Erlaubnis erteilen; lesen Sie die Freigabe-Prompts.
• Für Ihre sensibelsten Arbeiten verwenden Sie die lokale Runtime oder eine Private Box, lassen Sie verwaltete Online-Tools aus und starten Sie diese Ausführungen selbst, statt sie zu aktivieren, damit Ausführungsinhalte auf Hardware bleiben, die Sie kontrollieren.
• Wenn Ihnen etwas seltsam vorkommt - ein Fehler, eine verdächtige E-Mail, die vorgibt, von uns zu sein, ein Konto, das Sie nicht kennen - sagen Sie uns Bescheid.

11. Eine Schwachstelle melden

Wenn Sie glauben, eine Sicherheitslücke in Convira gefunden zu haben, melden Sie diese bitte an security@convira.ai. Geben Sie genügend Details an, um das Problem zu reproduzieren - betroffene Komponente oder URL, Schritte und Auswirkung -, und wenn möglich einen Proof of Concept.

Worum wir Sie bitten:

• Geben Sie uns ein angemessenes Zeitfenster, um das Problem zu untersuchen und zu beheben, bevor Sie es öffentlich machen.
• Greifen Sie nicht auf Daten zu, die nicht Ihnen gehören, und ändern oder löschen Sie diese nicht; verwenden Sie nur Testkonten und Daten, die Sie kontrollieren.
• Führen Sie keine Angriffe durch, die den Dienst für andere beeinträchtigen (Denial of Service, Spam, Brute-Force gegen echte Konten), und setzen Sie kein Social Engineering gegen unsere Mitarbeiter oder Benutzer ein.
• Fordern Sie keine Zahlung als Gegenleistung dafür, dass Sie nichts offenlegen.

Was Sie von uns erwarten können:

• Wir bestätigen den Eingang Ihrer Meldung und halten Sie auf dem Laufenden, während wir daran arbeiten.
• Sobald das Problem behoben ist, nennen wir Sie gern namentlich, wenn Sie das möchten.
• Wir gehen nicht rechtlich gegen gutgläubige Sicherheitsforschung vor, die diese Richtlinien befolgt.

Unsere vollständige Richtlinie zur Offenlegung von Sicherheitslücken legt den Geltungsbereich, die von uns zugesagten Reaktionszeiten und die Safe-Harbor-Bedingungen für gutgläubige Forschung fest.

12. Fragen

Sicherheitsfragen oder alles rund um diese Seite: security@convira.ai. Für alles andere, unsere Hilfeseite. Wir aktualisieren diese Seite, wenn sich das Produkt und unsere Vorgehensweisen ändern, und passen das Datum oben an.