Unsere Regeln, schriftlich festgehalten, damit Sie sie prüfen können

Die Regeln, nach denen wir arbeiten

1. 1

   Mandantentrennung

   Die Daten eines Unternehmens sind aus der Sitzung eines anderen Unternehmens nicht erreichbar.

   • Jeder Zugriffspfad prüft Organisation und Verbindung, und jede Operation hat ihre eigene ausdrückliche Berechtigung.
   • Ein Verkäufer sieht Inventar, Preise, Kunden oder Mappings eines anderen Verkäufers nur, wenn die Berechtigung erteilt wurde.
   • Für mandantenübergreifenden Zugriff gibt es eigene automatisierte Tests, die vor jedem Release bestanden sein müssen.

   Kestrel-Sitzung

   Die Mappings von Alpine Distribution sind von hier aus nicht erreichbar.

   OrganisationStimmt nicht überein

   BerechtigungNicht erteilt

2. 2

   Secrets

   Gespeicherte Zugangsdaten werden nie wieder angezeigt.

   • Zugangsdaten der Verkäufer liegen in einem dedizierten Secrets-Vault. Alles andere enthält nur eine versionierte Referenz.
   • Kein Bildschirm und keine API gibt einen Secret-Wert zurück, sobald er gespeichert ist.
   • Rohwerte bleiben aus Logs, E-Mails und KI-Prompts heraus, und die Schwärzung läuft, bevor etwas protokolliert wird.

   // All a connection record holds about a credential
   {
     "secret_ref": "ref:alpine/sandbox",
     "credential_version": 3,
     "rotated_at": "2027-01-14",
     "last_tested_at": "2027-02-02"
   }

3. 3

   Audit

   Jede Freigabe und Änderung lässt sich auf eine Person, eine Version und einen Grund zurückführen.

   • Veröffentlichte Mapping-Versionen lassen sich nicht bearbeiten. Eine Korrektur erzeugt eine neue Version.
   • Der Audit-Trail lässt sich nur ergänzen, und Manipulationen sind erkennbar.
   • Aktionen mit großer Tragweite erfordern mehr als eine Person, und bei Freigebenden bleibt die damalige Rolle dokumentiert.

   {
     "action": "mapping.approved",
     "actor": "priya@corvane.example",
     "actor_org": "Corvane Travel",
     "role_at_action": "mapping analyst",
     "resource": "c100-0001",
     "revision": { "from": 6, "to": 7 },
     "reason": "Same address, 38 m apart",
     "evidence": "ev_5512",
     "occurred_at": "2027-02-02T09:41:00Z"
   }

4. 4

   Buchungssicherheit

   Eine unbekannte Buchung wird abgeglichen, bevor irgendetwas anderes mit ihr geschieht.

   • Ein Timeout während der Buchung bedeutet nicht, dass die Buchung fehlgeschlagen ist. Wiederholungen werden je Verkäufer gesteuert und setzen einen bekannten Status voraus.
   • Eine doppelte Anfrage wird der ursprünglichen zugeordnet und kann so keine zweite Reservierung erzeugen.
   • Jede Buchung behält die nativen Codes und Bedingungen des Verkäufers, und ein Mapping kann sie nicht überschreiben. Ein nicht freigegebenes Hotel wird bei Angebot oder Buchung nie ersetzt.

   Buchungsstatus unbekannt

   Wir prüfen die Lieferantenreferenz. Senden Sie noch keine weitere Buchungsanfrage.

   ReferenzCT-48213

   WiederholungBlockiert bis zum Abgleich

5. 5

   Lasttests

   Das Traffic-Limit eines Verkäufers ist eine harte Grenze, auch für uns.

   • Externe Lasttests sind standardmäßig ausgeschaltet.
   • Zum Einschalten braucht es die schriftliche Autorisierung des Verkäufers, ein vereinbartes Zeitfenster, ein Limit für Rate und Parallelität sowie eine zentrale Notabschaltung.
   • Alle Schreibtests bleiben in freigegebenen Sandboxes, Simulatoren oder vereinbarten Testunterkünften, und Testziele stammen aus einer Allowlist, sodass niemand einen Runner auf eine beliebige Adresse richten kann.

   Externer Lasttest

   Aus

   Genehmigung des VerkäufersNicht hinterlegt

   Limit und ZeitfensterNicht festgelegt

   NotausschalterErforderlich