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 abrechenbares 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 Ihr Durchlauf ausgeführt und an den KI-Modellanbieter weitergeleitet, aber die Inhalte des Durchlaufs werden nicht auf unseren Servern gespeichert - der Datensatz verbleibt auf Ihrem Gerät. Weniger Daten auf unserer Seite bedeuten weniger, das geschützt werden muss, und weniger, das jemals offengelegt werden kann.

Wir behaupten nicht, unknackbar zu sein. Wir können aber sagen: Die Architektur ist so gebaut, dass Ihre sensibelsten Arbeiten die von Ihnen kontrollierte Hardware nie verlassen müssen.

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 Laufzeitumgebung - 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, Boards, geteilten Dateien und Kanalnamen 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. Inhaltsschlüssel entstehen auf Mitgliedsgeräten und werden für das Gerät jedes Teammitglieds verpackt; kein Convira-Server hält einen Schlüssel, der eine Nachricht, ein Board-Update, einen Kanalnamen oder einen Anhang öffnet. Die Suche läuft auf Ihrem Gerät, weil unsere sie für Sie gar nicht ausführen könnte.

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

Drei Grenzen, ausgesprochen statt angedeutet. Das Löschen einer Nachricht entfernt unsere Kopie und die Kopien auf den Geräten Ihrer Teammitglieder; was es nicht erreicht, ist eine Kopie, die die App bereits verlassen hat - ein Export oder ein Screenshot. Eine Direktnachricht hält fest, welche zwei Konten an ihr beteiligt sind - das speichern wir im Klartext, damit wir sie zustellen können, und nichts davon, was gesagt wurde. Und beim aktuellen Schlüsselformat akzeptiert ein Gerät eine vorwärts gerichtete Schlüsselrotation auf unser Wort hin - sollte das je geschehen, löst die App eine Vertrauenswarnung aus und behandelt die Identität nicht mehr als verifiziert, statt den neuen Schlüssel stillschweigend zu übernehmen.

3. Wie die Agentenausführung isoliert wird

Desktop-Tool-Aufrufe werden immer durch Conviras Berechtigungsrichtlinie geprüft. Native Prozessisolierung ist eine separate, mehrstufige Verteidigungsebene, die immer dann angewendet wird, wenn der Host sie bereitstellt. Die dabei verwendeten Primitive sind:

• 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 Werkzeug 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.

Das meiste davon prüfen wir auf Ihrem Rechner - und wir benennen den Teil, den wir nicht prüfen. Wenn ein Werkzeug zum ersten Mal einen abgeschotteten Prozess braucht, führt Convira die Ressourcenkontrollen auf Ihrem echten Rechner aus - eine Shell meldet die Grenzen zurück, die sie geerbt hat, eine echte Prozessgruppe wird beendet und das von ihr abgezweigte Hintergrundkind muss mit ihr sterben, und unter Linux muss eine Zuweisung oberhalb der Obergrenze fehlschlagen, während eine kleinere unter einer großzügigen Grenze gelingt - und eine Kontrolle, deren Prüfung nicht besteht, wird für den Rest dieser Sitzung als nicht vorhanden gemeldet. Datei- und Netzwerkabschottung werden auf dieselbe Weise nur unter Windows geprüft, indem ein echter abgeschotteter Prozess dagegen gestartet wird; unter macOS und Linux werden diese beiden aus dem Vorhandensein der betriebssystemeigenen Sandbox übernommen, statt ausgeübt zu werden. Wo ein Werkzeug eine Isolation braucht, die der Host nicht bieten kann, wird das Werkzeug zurückgehalten, statt ohne sie zu laufen: Vom Modell verfasster Code wird rundweg abgelehnt, statt ohne Abschottung ausgeführt zu werden. Die Ausnahme ist eine kurze Liste von Hilfsprogrammen, die Convira selbst aufruft und die das Modell nicht verfassen kann - git, das Entpacken von Archiven, OCR -, die einen engeren Kompatibilitätspfad behalten, falls die standardmäßig alles verweigernde Sandbox auf Ihrem Rechner nicht lädt.

Open Source. Die oben beschriebene Isolationsschicht ist unter Apache 2.0 als convira-sandbox veröffentlicht - die macOS-Seatbelt-Profile, die Linux-Bubblewrap-Namespace- und Mount-Argumente, der Windows-AppContainer- und Job-Object-Code sowie die Prüfungen, die entscheiden, ob eine Kontrolle überhaupt als aktiv gemeldet wird. Die Veröffentlichung des Quellcodes beweist nicht, dass die von Ihnen installierte Version ihn enthält; sie gibt Ihnen die Möglichkeit, zu lesen, was diese Prüfungen tun, die Testsuite selbst auszuführen und auf Ihrem eigenen Rechner zu beobachten, ob es sich so verhält.

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 und lässt sich vollständig abschalten, und der Proxy kann im Audit-Modus (alles protokollieren) oder im Erzwingungsmodus (blockieren und Sie optional fragen) laufen.

Zwei Dinge laufen nicht darüber, und wir benennen sie lieber, als sie vom Absatz darüber mit abdecken zu lassen. Git über das Netzwerk - clone, fetch, pull, push, das Öffnen eines Pull Requests - und das Installieren der Abhängigkeiten Ihres Projekts nutzen ihre eigenen Tools, die sich direkt verbinden: kein Proxy, keine Domain-Zulassungsliste. Sie unterliegen dem Offline-Modus und nicht dem Webzugriff-Schalter, denn ein Push in Ihr eigenes Repository ist kein Surfen. Convira meldet sich ausschließlich bei github.com an, aber git selbst akzeptiert jede https-Adresse, auf die es gerichtet wird - ein Repository, das Sie nicht gelesen haben, kann also einen Host nennen, den wir nicht prüfen. Push und das Öffnen eines Pull Requests fragen Sie, bevor sie ausgeführt werden.

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 - der Durchlauf pausiert und stellt eine Anfrage, die Sie genehmigen oder ablehnen müssen, bevor er 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 den Durchlauf angewendet; auf dem Cloud-Weg werden sie mit dem Durchlauf 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. Passwörter werden niemals in umkehrbarer Form gespeichert oder verschlüsselt - sie werden mit Argon2id gehasht (einem modernen, speicherintensiven Verfahren). Sitzungstokens, E-Mail-Bestätigungscodes, Tokens zum Zurücksetzen von Passwörtern und ähnliche Geheimnisse werden nur als Hashes gespeichert, sind - wo zutreffend - nur einmal verwendbar und laufen ab. 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. Bei der einmaligen Kopplung sendet die Box ihr Bearer-Credential über TLS an Convira; Convira versiegelt es im Arbeitsspeicher an Ihren Geräteschlüssel (X25519-Schlüsselvereinbarung + XChaCha20-Poly1305) und speichert nur den Chiffretext. Wenn Sie Teammitglieder hinzufügen, versiegelt Ihr eigener Desktop dieses Credential neu an den Geräteschlüssel jedes Mitglieds, sodass diese Zustellungen den Klartext niemals gegenüber Convira offenlegen.

Wenn Ihr Bedrohungsmodell erfordert, dass Ausführungsinhalte auf von Ihnen kontrollierter Hardware bleiben, nutzen Sie die lokale Runtime oder eine Private Box und rufen Sie keine verwalteten Online-Tools auf.

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.

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 Dienstanbieter - Zahlungen (Stripe), API-Hosting (Railway), Datenbank (Supabase), Bot-Schutz (Cloudflare), Website-Hosting und cookiefreie Analyse (Vercel), Fehlerüberwachung (Sentry) und die KI-Modellanbieter (Anthropic, OpenAI, Google, xAI). Die vollständige aktuelle Liste - einschließlich Such-, E-Mail-, Warteschlangen- und Connector-Infrastruktur -, was jeder Anbieter tut und wo er ungefähr betrieben wird, finden Sie auf unserer Seite zu den Unterauftragsverarbeitern.

10. Ihr Part

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

• Verwenden Sie ein starkes, einzigartiges Passwort für Ihr Convira-Konto.
• 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 Agent die Erlaubnis erteilen; lesen Sie die Freigabe-Prompts.
• Für Ihre sensibelsten Arbeiten verwenden Sie die lokale Runtime oder eine Private Box und lassen Sie verwaltete Online-Tools deaktiviert, 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 auf Wunsch namentlich. Ein bezahltes Bug-Bounty-Programm betreiben wir derzeit nicht.
• 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.