# Wie Rationale schützt, was Ihr Team entscheidet · Rationale

> Was Rationale verschlüsselt, was Ihre Rechner nie verlässt, wie sich Personen und Agenten anmelden, was unsere Mitarbeitenden sehen können und was nicht, wie lange wir Daten aufbewahren, was bei einem Vorfall geschieht, wofür wir zertifiziert sind und wofür nicht, und wie Sie eine Schwachstelle melden.

Source: https://rationalehq.com/de/security
Language: de

Sicherheit

# Wie Rationale schützt, was Ihr Team entscheidet

Rationale bewahrt die Gründe hinter dem Code Ihres Teams und ist deshalb für Code gebaut, der nicht nach außen gelangen darf. Diese Seite sagt klar, was wir mit Ihren Daten tun, was wir nie tun und was noch fehlt. Jede Aussage beschreibt den Dienst, wie er heute läuft; die Datenschutzerklärung trägt die juristischen Details.

Aktualisiert am 6. Oktober 2026

Kurz gesagt

-   Entscheidungsinhalte sind im Ruhezustand verschlüsselt, mit Schlüsseln getrennt von der Datenbank. Der Server fragt nur Kennungen, Zustände und Anker ab, und unsere Admin-Oberfläche läuft mit einem Schlüsselanbieter, der nicht entschlüsseln kann.
-   Transkripte und Repositories verlassen Ihre Rechner nie; Secret-Werte werden beim Schreiben abgewiesen und aus Zitaten entfernt.
-   Nirgends Passwörter: E-Mail-Links, die einmal gelten, Geräte und MCP-Clients mit eigenen widerrufbaren Tokens, Jira und GitHub per OAuth mit dem eigenen Konto jedes Mitglieds.
-   Jeder Lesezugriff und jede Bestätigung werden auditiert, auch jedes Mal, wenn unsere eigenen Mitarbeitenden hineinsehen. Es gibt kein Anmelden als jemand anderes.
-   Ein EU-Unternehmen unter der DSGVO; Server in den USA unter dem Data Privacy Framework und den Standardvertragsklauseln; keine Tracker, keine Analysen Dritter, kein Training mit Ihren Inhalten.
-   Klar gesagt: noch kein SOC-2-Bericht, noch kein SSO und kein SCIM. Der letzte Abschnitt listet auf, was fehlt.

Auf dieser Seite

1.  [Zwei Arten von Daten, getrennt gehalten](#model)
2.  [Was auf Ihren Rechnern bleibt](#machines)
3.  [Auf dem Weg](#transit)
4.  [Anmeldung](#auth)
5.  [Wer was sehen kann](#access)
6.  [Was unsere Mitarbeitenden sehen können und was nicht](#staff)
7.  [Jeder Lesezugriff ist festgehalten](#audit)
8.  [Der Client](#client)
9.  [Wo der Dienst läuft](#hosting)
10.  [Wie lange wir Daten aufbewahren](#retention)
11.  [Wenn etwas schiefgeht](#incidents)
12.  [Compliance und Zertifizierungen](#compliance)
13.  [Was noch fehlt](#missing)
14.  [Eine Schwachstelle melden](#report)

## Zwei Arten von Daten, getrennt gehalten

Rationale trennt, was es zum Betrieb des Dienstes braucht, von dem, was Ihr Team schreibt. Die erste Art (Kennungen, Zustände, Anker, Zeitstempel, Namen von Repositories, Branches und Dateien, Task-Handles) kann der Server lesen, weil Routing, Warnungen und Audit sie brauchen. Die zweite Art ist in der Datenbank verschlüsselt, mit Schlüsseln in der Umgebung des Deployments, nie in der Datenbank oder im Repository: der Text von Entscheidungen (Frage, Wahl, Kriterien, verworfene Optionen, Annahmen, Bedingungen für eine Überprüfung und Zitate), Notizen, Aufgaben, Übergaben, Zusammenfassungen, Digests und Sitzungstitel; Titel, Beschreibungen und Review-Threads von Pull Requests; Connector-Tokens; und die Namen, Benutzernamen, E-Mail-Adressen und Fotos, die Jira und GitHub zu Personen liefern.

Inhalte der zweiten Art gelangen nie in Spalten, Logs, Ereignisse oder Fehlermeldungen der ersten. Request-Logs filtern Entscheidungstext und Zugangsdaten, und Audit-Ereignisse tragen nur Ids, Zahlen und Zustände. Entscheidungsinhalte werden nur angehängt: eine Bearbeitung fügt eine Version hinzu und überschreibt nichts.

## Was auf Ihren Rechnern bleibt

-   **Transkripte.** Der Client extrahiert Entscheidungen auf dem Rechner der Person, mit dem Agenten, den sie bereits nutzt. Wir erhalten die Entscheidungen, kurze Zitate der eigenen Worte der Person und Metadaten (Sitzungs-Id, Turn-Nummern, Repository, Branch, Commit, Zeit, äquivalente Kosten). Das Transkript selbst geht nirgendwohin außer zum Anbieter des Agenten, wie bisher.
-   **Repositories.** Wir klonen sie nie und speichern keine Dateien. Eine Entscheidung ist an Pfade verankert; nennt eine Entscheidung eine Klasse, eine Tabelle oder einen Ticket-Schlüssel, geschieht der Abgleich mit dem Inhalt einer Datei auf dem Rechner, auf höchstens 512 KB Text, und dieser Inhalt verlässt ihn nie.
-   **Dateipfade.** Liest oder bearbeitet Ihr Agent eine Datei, gleicht der Hook ihren Pfad mit einem lokalen Index verankerter Entscheidungen ab und fragt den Server nur bei einem Treffer. Ein Pfad, an den keine Entscheidung verankert ist, verlässt den Rechner nie.
-   **Secrets.** Der Wert eines Secrets gelangt nie in eine Entscheidung, eine Notiz oder eine Übergabe: Er wird in dem, was Personen und Agenten schreiben, abgewiesen und aus erfasstem Text und Zitaten entfernt. Die Prüfung sucht private Schlüssel, Cloud- und API-Schlüssel, Tokens von GitHub, GitLab, Slack und Stripe, JWTs, Passwörter in URLs und Werte nach Wörtern wie password oder token; der Server speichert nur die Art des abgewiesenen Secrets, nie den Wert. Hosts, URLs und der Ort, an dem ein Secret liegt (ein Vault-Pfad, der Name einer Umgebungsvariablen), sind willkommen.

## Auf dem Weg

-   Jede Verbindung zu Rationale nutzt HTTPS, mit Zertifikaten von Let's Encrypt und HTTP Strict Transport Security einschließlich Subdomains; unverschlüsseltes HTTP wird umgeleitet.
-   Der Client prüft TLS mit dem Zertifikatspeicher Ihrer Plattform; ein Unternehmens-Proxy mit eigenem Root-Zertifikat funktioniert, ohne etwas zu schwächen.
-   Webhook-Zustellungen von GitHub und Jira werden nur mit einer gültigen Signatur des Anbieters angenommen.
-   Die E-Mails, die wir senden, verlassen uns über eine verschlüsselte Verbindung zu unserem E-Mail-Anbieter.
-   Diese Website setzt keine Cookies, lädt keine Skripte Dritter und liefert eine Content-Security-Policy, die nur ihre eigenen, gehashten Skripte erlaubt. Die App setzt nur das signierte Cookie, das Sie angemeldet hält; keine der beiden trägt Tracker.

## Anmeldung

-   **Keine Passwörter.** Rationale speichert keine. Personen melden sich mit einem Link an ihre E-Mail-Adresse an, der einmal gilt, 15 Minuten lang; das Token steht hinter dem `#` der Adresse, das Browser nie an einen Server senden, und erreicht so weder unsere Logs noch irgendeinen Proxy. Eine Browser-Sitzung dauert 30 Tage.
-   **Geräte.** `rationale init` meldet einen Rechner mit einem Gerätecode an: Der Client zeigt einen Code aus acht Buchstaben, Sie geben ihn angemeldet in der App ein, wählen den Workspace und erlauben oder verweigern. Codes verfallen nach 10 Minuten und werden als Hashes gespeichert. Das Token des Geräts wird einmal übergeben, als SHA-256-Hash gespeichert, gilt für einen Workspace, hört nach 90 Tagen ohne Nutzung auf zu funktionieren und kann jederzeit auf der Devices-Seite widerrufen werden; wer ein Mitglied entfernt, widerruft dessen Geräte.
-   **MCP-Clients.** Claude, ChatGPT, Cursor und jeder MCP-Client verbinden sich per OAuth 2.1: dynamische Client-Registrierung, nur öffentliche Clients, PKCE mit S256 verpflichtend, Redirect-Adressen über HTTPS oder Loopback. Autorisierungscodes gelten 5 Minuten und nur einmal, Access-Tokens eine Stunde, Refresh-Tokens rotieren bei jeder Nutzung und gelten 90 Tage. Auf der Zustimmungsseite wählen Sie, welche Workspaces der Client erreichen darf; Ihre Mitgliedschaft wird bei jeder Anfrage erneut geprüft, und die Verbindung wird auf derselben Devices-Seite widerrufen.
-   **Keine API-Schlüssel für Personen.** Es gibt keinen persönlichen Schlüssel, den man in eine Konfigurationsdatei einfügen oder in einem Repository verlieren könnte. Die einzigen Zugangsdaten sind das Token eines Geräts und die Tokens einer MCP-Verbindung, jedes für sich widerrufbar.
-   **Connectors.** Jira und GitHub werden per OAuth mit dem eigenen Konto jedes Mitglieds verbunden, nie mit einem geteilten Token oder einem Passwort. Der Rundweg nutzt einen zufälligen State, der nur einmal gilt, 10 Minuten dauert und an die Browser-Sitzung gebunden ist, die ihn gestartet hat.
-   **Ratenbegrenzung.** Anmeldelinks, Gerätecodes, die OAuth- und MCP-Endpunkte und das Installationsskript sind pro Adresse oder Token ratenbegrenzt.

## Wer was sehen kann

-   **Workspaces.** Jeder Datensatz gehört zu einem Workspace und ist nur über ihn erreichbar: Ein Workspace, dem Sie nicht angehören, ist von einem nicht existierenden nicht zu unterscheiden. Owner verwalten Mitgliedschaft, Connectors und das Audit-Log.
-   **Ihre eigene Sicht auf Jira und GitHub.** Connectors nutzen OAuth mit dem eigenen Konto jedes Mitglieds, nie ein geteiltes Token, sodass jede Person in Rationale nur die Tickets, Projekte, Repositories und Pull Requests sieht, die ihr eigenes Konto sehen kann.
-   **Private Datensätze.** Eine Entscheidung, eine Übergabe, eine in Rationale angelegte Aufgabe oder eine ganze Sitzung kann privat sein: sichtbar für ihre Person und deren eigene Agenten, nie für das Team, Owner eingeschlossen. Die Person entscheidet, per Klick oder mit eigenen Worten über ihren Agenten; ein Agent ändert die Sichtbarkeit nie von selbst.
-   **Agenten handeln als sie selbst.** Ein Agent arbeitet über das Gerät oder die MCP-Verbindung eines Mitglieds, als Agent gekennzeichnet, im Namen dieses Mitglieds. Er sieht nie mehr als die Person, für die er arbeitet.

## Was unsere Mitarbeitenden sehen können und was nicht

Die Mitarbeitenden von Rationale nutzen eine Admin-Oberfläche auf eigenem Host, geöffnet über einen nur für Mitarbeitende gültigen E-Mail-Link in eine 8-Stunden-Sitzung hinter einem auf diesen Host beschränkten Cookie; eine Mitgliedersitzung öffnet sie nie. Sie zeigt die Maschinerie jedes Kunden in Zahlen: Erfassungen, Fehler, Geräte, Hintergrundjobs, Kennzahlen.

-   **Sie kann nicht entschlüsseln.** Jede Admin-Anfrage läuft mit einem Schlüsselanbieter ohne Schlüssel, sodass das Lesen eines verschlüsselten Attributs einen Fehler auslöst, statt etwas anzuzeigen. Ein Test durchläuft jede Admin-Seite mit Sentinel-Inhalten und schlägt fehl, wenn diese erscheinen, im Klartext oder verschlüsselt.
-   **Jeder Blick steht in Ihrem Log.** Jede Admin-Seite, die Daten eines Workspace zeigt, schreibt ein Ereignis `staff.viewed` in das Audit-Log dieses Workspace, wo Owner es unter dem Filter Staff lesen.
-   **Kein Anmelden als jemand anderes.** Mitarbeitende haben keine Möglichkeit, Ihren Workspace als Sie zu öffnen. Keine Seite, keine API und kein MCP-Tool kann den Mitarbeitenden-Status vergeben: Er ändert sich nur aus der auditierten Produktionskonsole.
-   **Konsolen werden aufgezeichnet.** Eine Produktionskonsole kann Inhalte lesen; sie zu öffnen schreibt deshalb ein Ereignis `ops.console_opened` mit dem Operator, bevor sie Eingaben annimmt; kann das Ereignis nicht geschrieben werden, öffnet sich die Konsole nicht. Wir öffnen eine nur für Support, den Sie angefragt haben, eine Datenschutzanfrage oder einen Vorfall.
-   **Auch die Datenschutzwerkzeuge werden auditiert.** Eine Person exportieren oder löschen, einen Workspace exportieren oder löschen läuft über auditierte Werkzeuge, die eigene Ereignisse schreiben, ohne Inhalte; der Export eines Workspace geht nur an einen seiner Owner.

## Jeder Lesezugriff ist festgehalten

Jedes Anlegen, Lesen und Bestätigen einer Entscheidung schreibt ein Audit-Ereignis: eine geöffnete Entscheidung, eine angezeigte Liste oder Suche, Kontext, der einem Agenten übergeben wurde, eine gezeigte Warnung. Ereignisse tragen Ids, Zahlen und Zustände, nie Inhalte, und werden nur angehängt. Owner lesen das Log ihres Workspace in den Einstellungen, mit der Aktivität von Mitgliedern, Agenten und Mitarbeitenden, dem Kanal (Web, Client, MCP) und der IP-Adresse, gefiltert nach Änderungen, Lesezugriffen oder Zugriffen der Mitarbeitenden.

Die Herkunft ist auf jedem Datensatz ausdrücklich vermerkt: beobachtet, abgeleitet, von einem Agenten erschlossen oder von einer Person bestätigt. Ein Datensatz wird nur durch eine menschliche Handlung bestätigt: einen Klick in der App, die eigenen Worte der Person in einer Sitzung (der Client prüft sie vor dem Senden gegen das Transkript und verwirft alles, was ein Agent über eine Bestätigung geschrieben hat) oder den Merge des Pull Requests auf GitHub, der die Entscheidung auf seinem Branch trug. Dass ein Agent sagt, jemand habe bestätigt, ist keine Bestätigung.

## Der Client

-   Eine Binärdatei, keine Laufzeitumgebung. Sie installiert sich ohne sudo in Ihrem Home-Verzeichnis und ändert nie Ihre Shell-Dateien. Die erste Installation vertraut TLS zum Datei-Host, wie jedes `curl | sh`; jedes spätere Update prüft der Client selbst gegen ein signiertes Manifest.
-   Jedes Release ist mit minisign signiert. Zwei öffentliche Schlüssel sind in jede Binärdatei kompiliert: der Release-Schlüssel, der jedes Manifest signiert, und ein Offline-Reserveschlüssel, der nur zum Austausch des ersten dient; die geheimen Schlüssel gelangen nie in ein Repository oder auf einen Server. Ein Update, das keiner der beiden signiert hat, ein wieder eingespieltes Manifest oder ein Downgrade werden abgewiesen; Größe und SHA-256 jeder Datei werden geprüft; eine neue Binärdatei, die ihren Selbsttest nicht besteht, wird zurückgenommen, und `rationale update --rollback` stellt auf Wunsch die vorige Version wieder her.
-   Seine Konfiguration kann nur Ihr Benutzer lesen (Modus 600). Hooks blockieren Ihren Agenten nie: Jeder stellt höchstens eine kurze Anfrage, höchstens zwei Sekunden, und einer, der fehlschlägt, beendet sich still.
-   `rationale uninstall` entfernt die Hooks und den Watcher; das Gerät in der App zu widerrufen macht sein Token ungültig.

## Wo der Dienst läuft

Anbieter

Wofür

Wo

DigitalOcean, LLC

Server, verwaltete PostgreSQL-Datenbank und ihre Backups

USA (Raum New York)

Resend (Plus Five Five, Inc.)

E-Mails für Anmeldung, Einladung, Zugang und Zusammenfassung; Empfang von E-Mails an unsere Adressen

USA und Europäische Union

GitHub, Inc.

Hostet die Downloads und Updates des Clients

USA

Atlassian; GitHub

Nur wenn ein Workspace Jira oder GitHub verbindet, mit dem eigenen Konto jedes Mitglieds

Ihre Regionen

Ein Server und eine verwaltete PostgreSQL-Datenbank bei DigitalOcean, über das private Netz erreicht, mit täglichen Backups und sieben Tagen Point-in-Time-Recovery. Die Firewall erlaubt nur SSH, HTTP und HTTPS; SSH geht nur per Schlüssel; Sicherheitsupdates installieren sich unbeaufsichtigt. Secrets erreichen den Server beim Deployment als Umgebungsvariablen, nur für root lesbar, nie im Repository oder in der Datenbank. Jede Änderung besteht die Tests, Brakeman, bundler-audit und importmap audit in der CI, bevor sie gemergt wird. Unsere Konten bei den Anbietern nutzen Zwei-Faktor-Authentifizierung.

Wir sind in Portugal niedergelassen; Übermittlungen in die USA erfolgen daher nach der DSGVO: die Zertifizierung von DigitalOcean unter dem EU-U.S. Data Privacy Framework (mit seinen Erweiterungen für das Vereinigte Königreich und die Schweiz) und die Standardvertragsklauseln in seinem Auftragsverarbeitungsvertrag; die Standardvertragsklauseln und das Data Privacy Framework bei Resend. Jeder Anbieter steht unter einem schriftlichen Auftragsverarbeitungsvertrag. Die [Datenschutzerklärung](https://rationalehq.com/de/privacy#recipients) führt die maßgebliche Liste.

## Wie lange wir Daten aufbewahren

Workspace-Inhalte (Entscheidungen, Aufgaben, Notizen, Übergaben) bleiben, solange der Workspace besteht, und werden innerhalb von 30 Tagen nach der Anfrage eines Owners oder 90 Tage nach Ende des Dienstes gelöscht; Backups laufen in sieben Tagen aus. Personenbezogene Daten haben veröffentlichte Fristen, die ein täglicher Job durchsetzt:

Daten

Aufbewahrt

Browser-Sitzungen

30 Tage nach der Anmeldung

Gerätecodes

1 Tag nach ihrem Verfall

Geräte und MCP-Verbindungen

Bis zum Widerruf; nach 90 Tagen ohne Nutzung funktionieren sie nicht mehr

Einladungen, die niemand angenommen hat

30 Tage nach Verfall oder Rücknahme

IP-Adressen (Audit-Ereignisse, Geräte, MCP-Verbindungen und -Clients)

12 Monate

Audit-Ereignisse eines Workspace

Die Lebensdauer des Workspace, nur angehängt; die IP-Adresse wird nach 12 Monaten gelöscht

Anmelde-, Mitarbeitenden- und Betriebsereignisse außerhalb jedes Workspace

24 Monate

In Jira oder GitHub gesehene Personen, die keine Mitglieder sind

90 Tage nachdem eine Quelle sie zuletzt gezeigt hat

Zugangsanfragen

Offene verfallen nach 90 Tagen; eine entschiedene verliert ihre Adresse 30 Tage nach der Entscheidung

Fehlgeschlagene Hintergrundjobs

30 Tage

Die [Datenschutzerklärung](https://rationalehq.com/de/privacy#data) ist die maßgebliche Liste. Owner können einen Export des ganzen Workspace (entschlüsselt, nur an einen Owner gesendet) oder seine Löschung verlangen; eine Person kann ihren eigenen Export oder ihre Löschung unter privacy@rationalehq.com verlangen.

## Wenn etwas schiefgeht

Wir führen einen schriftlichen Plan zur Reaktion auf Vorfälle, verantwortet vom Geschäftsführer des Unternehmens. Er deckt ein geleaktes Secret oder Token, einen gestohlenen Laptop oder ein gestohlenes Anbieterkonto, unbefugten Zugriff, an die falsche Person gesendete Daten, verlorene oder beschädigte Daten und eine ausgenutzte Schwachstelle ab. Im Zweifel behandeln wir ein Ereignis als Vorfall und tragen es ins Register ein.

1.  Eindämmen, in der ersten Stunde: rotieren, was geleakt ist, Geräte und Verbindungen widerrufen, einen Connector abschalten, eine Adresse sperren, nötigenfalls einen Server vom Netz nehmen; die Logs kopieren, bevor sie rotieren.
2.  Ins Verletzungsregister eintragen, mit Zeiten in UTC, nur Fakten, mindestens fünf Jahre aufbewahrt.
3.  Bewerten, welche Daten, von wem, und ob sie verschlüsselt waren: Entscheidungsinhalte sind mit Schlüsseln außerhalb der Datenbank verschlüsselt, sodass eine Kopie der Datenbank ohne die Schlüssel nur Kennungen und Zustände offenlegt.
4.  Benachrichtigen: die Owner jedes betroffenen Workspace innerhalb von 48 Stunden, per E-Mail, mit dem, was geschehen ist, welchen Daten, was wir getan haben und was sie tun sollten; die portugiesische Datenschutzbehörde innerhalb von 72 Stunden, wo die DSGVO es verlangt, und betroffene Personen ohne unangemessene Verzögerung, wenn das Risiko für sie hoch ist; Atlassian innerhalb von 48 Stunden, wenn der Jira-Connector betroffen ist; Einwohner der USA nach dem Recht ihres Bundesstaats.
5.  Wiederherstellen aus Backups (sieben Tage Point-in-Time-Recovery), neu deployen, prüfen.
6.  Lernen: Ursache, Behebung, Plan und Verarbeitungsverzeichnis aktualisieren.

Das Register hat zum Datum dieser Seite keine Einträge. Der Plan sieht mindestens einmal im Jahr eine Übung vor, die im Register festgehalten wird.

## Compliance und Zertifizierungen

Rationale ist ein Dienst eines portugiesischen Unternehmens und arbeitet für alle unter der DSGVO, wo immer sie sind. Die Datenschutzerklärung nennt jeden Anbieter, jeden Zweck und jede Aufbewahrungsfrist. Die Nutzungsbedingungen enthalten Bedingungen zur Auftragsverarbeitung, mit Benachrichtigung über einen Sicherheitsvorfall, der personenbezogene Daten betrifft, ohne unangemessene Verzögerung und innerhalb von 48 Stunden, sowie Datenschutzbedingungen für US-Bundesstaaten. Wir verkaufen keine personenbezogenen Daten, zeigen keine Werbung, nutzen keine Analysen Dritter und trainieren keine KI-Modelle mit Ihren Inhalten.

**Zertifizierungen: noch keine.** Wir sind weder nach SOC 2 noch nach ISO 27001 zertifiziert, und kein Audit läuft. SOC 2 ist geplant, sobald Rationale die Verbreitung hat, die es rechtfertigt; diese Seite wird sagen, wann ein Audit beginnt und wann ein Bericht vorliegt. Bis dahin sind diese Seite, die Datenschutzerklärung und die Nutzungsbedingungen der Nachweis, und wir beantworten Sicherheitsfragebögen auf Anfrage unter security@rationalehq.com.

## Was noch fehlt

Klar gesagt, damit Sie nicht fragen müssen:

-   **SOC 2 und ISO 27001.** Kein Bericht und kein laufendes Audit. Geplant mit der Verbreitung.
-   **SSO mit SAML und SCIM-Provisionierung.** Nicht gebaut. Sie gehören zum Business-Plan, der nicht verkauft wird, bevor sie existieren. Heute meldet sich jedes Mitglied mit einem E-Mail-Link an, und Owner fügen Mitglieder von Hand hinzu und entfernen sie.
-   **Export des Audit-Logs.** Owner lesen das Log in den Einstellungen; einen Download gibt es noch nicht. Für den Business-Plan geplant.
-   **Ein eigener zweiter Faktor.** Die Anmeldung läuft über einen E-Mail-Link, der Schutz Ihres Postfachs ist also der Ihres Kontos; Rationale fügt keinen eigenen zweiten Faktor hinzu.
-   **Apple-Notarisierung der macOS-Binärdatei.** Releases sind mit minisign signiert und werden vom Client selbst geprüft, aber noch nicht von Apple notarisiert; installieren Sie deshalb mit dem Befehl oder Homebrew statt per Browser-Download.
-   **Windows.** Der Client läuft auf macOS und Linux; unter Windows sagt das der Installer und hält an.
-   **Hosting außerhalb der USA.** Die Daten liegen in den USA unter den oben genannten Übermittlungsmechanismen; eine EU-Region gibt es noch nicht.

## Eine Schwachstelle melden

Schreiben Sie an security@rationalehq.com. Wir bestätigen den Eingang innerhalb eines Werktags, halten Sie während der Behebung auf dem Laufenden und gehen nicht gegen Forschung in gutem Glauben vor, die die Daten anderer Kunden respektiert. Unsere [security.txt](https://rationalehq.com/.well-known/security.txt) sagt dasselbe, maschinenlesbar.

-   Nennen Sie den Host, die Schritte zur Reproduktion und was Sie beobachtet haben.
-   Greifen Sie nicht auf Daten zu, die nicht Ihre sind, ändern oder behalten Sie sie nicht; hören Sie auf, sobald das Problem nachgewiesen ist.
-   Geben Sie uns angemessene Zeit zur Behebung, bevor Sie es öffentlich machen.

Alles andere: [support@rationalehq.com](mailto:support@rationalehq.com)