Sicherheit und Compliance

Unter BYOK liegen API-Schlüssel nur im Speicher des Gateways — nie persistiert oder übertragen.

Anfragen laufen über das Gateway direkt an Anbieter-APIs; Daten bleiben durchgängig in Ihrem privaten Netzwerk.

GateLLM selbst speichert, trainiert auf oder cached keine Anfrageinhalte.

TLS 1.3 durchgängig.

Schlüssel nur im Speicher; bei einem Neustart werden sie aus Ihren Secrets injiziert — nie auf der Festplatte.

Client-Zulassungskontrolle: Gating nach User-Agent mit differenzierten Richtlinien.

DSGVO / CCPA / DPA bereit.

Ausgerichtet an SOC-2-Type-II-/ISO-27001-Kontrollen (Zertifizierung in Vorbereitung).

SSO (OIDC: Azure AD / Okta / generisch, plus SAML 2.0 + SCIM 2.0).

Audit-Logs auf Anfrageebene, exportierbar in interne Ops- und Abrechnungssysteme.

Absturzsichere Abrechnung: Vorabzug → Abrechnung → Rückerstattung; die Abrechnung bleibt über Prozessabstürze hinweg durch ein In-Flight-Ledger und Audit pro Anfrage korrekt.

Management-API zur programmatischen Verwaltung von Kontingenten, Budgets, Nutzung und Kosten.

Netzwerkschicht: Der Gateway-Prozess wird in Ihrer VPC / Ihrem On-Premises-Rechenzentrum bereitgestellt; eingehender/ausgehender Datenverkehr wird durch die von Ihnen konfigurierten Sicherheitsgruppen / Netzwerkrichtlinien gesteuert; Anfragen gehen direkt an die offiziellen APIs nachgelagerter Modellanbieter, ohne einen Relay-Server eines Auftragsverarbeiters zu durchlaufen.

Gateway-Prozessschicht: zustandsloses Design; Schlüssel werden aus verschlüsselter Konfiguration in den Speicher geladen und nie persistiert; jede Replik kann jede Anfrage bedienen, was horizontale Skalierung und sofortiges Failover unterstützt; bei einem Neustart werden Schlüssel aus Ihren Secrets neu injiziert.

Schlüsselschicht: BYOK-Modellanbieter-Schlüssel liegen nur im Prozessspeicher des Gateways, werden nie in persistenten Speicher geschrieben und können vom Betriebspersonal nicht im Klartext gelesen werden; die Client-Zulassungskontrolle filtert nach User-Agent mit differenzierten Richtlinien.

Datenschicht: Laufzeit-Prompts / -Completions werden nicht in den Systemen des Auftragsverarbeiters persistiert (im Speicher weitergeleitet, nicht persistiert); Konto- und Lizenzdaten at rest sind AES-256-verschlüsselt; die Aufbewahrungsrichtlinie für Audit-Logs bestimmt Ihr Betriebsteam.

Abrechnungsschicht: absturzsichere Abrechnung (Vorabzug → Abrechnung → Rückerstattung), bleibt über Prozessabstürze hinweg durch ein In-Flight-Ledger und Audit pro Anfrage korrekt.

Bedenken wegen übermäßigem KI-Zugriff: GateLLM adressiert dies mit vollständig selbst gehostetem Deployment + BYOK — Schlüssel und Prompts verlassen nie Ihre Netzwerkgrenze; Sie kontrollieren vollständig, welche Modelle genutzt und an welchen Anbieter geroutet wird, ohne Shadow AI und ohne versteckte Unterauftragsverarbeiter (siehe Liste der Unterauftragsverarbeiter).

Für Training verwendete Daten: Der Auftragsverarbeiter kommt mit Prompt-Daten nicht in Berührung; ob ein nachgelagerter Modellanbieter trainiert, bestimmt dessen Richtlinie, die Sie vor dem Onboarding in der Datenverwendungsmatrix der Liste der Unterauftragsverarbeiter prüfen können — vollständig opt-in.

Grenzüberschreitende Compliance: Kontodaten des Auftragsverarbeiters werden über SCCs / IDTA grenzüberschreitend übertragen; grenzüberschreitende Übertragungen an nachgelagerte Anbieter gehen Sie direkt mit geeigneten Garantien ein (DPA Abschnitt 11).

Schlüssellecks: Schlüssel liegen nur im Speicher, werden nie persistiert oder übertragen; SSO delegiert MFA und Sitzungsverwaltung an Ihren bestehenden IdP, sodass Zugangsdaten nicht fragmentiert werden.

Unabhängige Penetrationstests von GateLLM durch Dritte sind in Vorbereitung (Geltungsbereich und Rules of Engagement liegen bereit) und decken den Gateway-Prozess, Authentifizierung und Autorisierung, Edge Functions, das API-Gateway und Schlüsselverwaltungspfade ab; eine Zusammenfassung wird nach Abschluss in Abschnitt 7 der Richtlinie zur Offenlegung von Schwachstellen veröffentlicht.

Richtlinie zur verantwortungsvollen Offenlegung von Schwachstellen: Meldung über security@gatellm.io (PGP unterstützt), Bestätigung innerhalb von 24 Stunden, Behebung nach CVSS-Schweregrad (Critical 7 Tage / High 30 Tage / Medium 60 Tage / Low 90 Tage).

Eine Software-Stückliste (SBOM) wird bereitgestellt; Abhängigkeiten werden regelmäßig auf bekannte Schwachstellen gescannt, und Sicherheitspatches werden im Changelog mit CVE-IDs annotiert.