Isolation und Souveränität als Architektur
Wo bei Browserberg die Vertrauensgrenzen liegen: was nativ läuft, was in gehärteten Containern läuft und wie EU-Souveränität im Anfragepfad erzwungen wird.
Zuletzt aktualisiert:
Das Vertrauensmodell
Browserbergs eigener Plattform-Code — API, Fleet-Orchestrierung, Tresor — läuft nativ auf dem Host. In gehärteten Containern pro Session läuft ausschließlich das Nicht-Vertrauenswürdige: der Browser, die Seiten, die er lädt, und die code-Blöcke deiner Workflows — dein JavaScript, das mit demselben Misstrauen behandelt wird wie eine Webseite.
Ein Container ist hier eine Sicherheitsgrenze, keine Verpackungsbequemlichkeit: ein Container pro Session, abgeriegelt, zerstört beim Teardown. Um präzise zu sein: Das ist gehärtetes Containment auf Betriebssystem-Ebene, keine virtuelle Maschine, und wir behaupten keine Kernel-Isolation. MicroVM-Isolation steht auf der Roadmap für eine spätere Phase; heute ist die Grenze der gehärtete Container.
Souveränität als Architektur
Souveränität wird dadurch erzwungen, wo Dinge laufen — nicht in einem Richtliniendokument behauptet. Gehostet wird in der EU auf Hardware, die wir selbst betreiben; Inferenz wird zu EU-Endpunkten geroutet; im Produktpfad steckt kein US-CDN. Die Compliance-Details findest du unter EU-Datenresidenz.
Jeder Modellaufruf der Plattform passiert ein einziges Gateway. Dieser Engpass scannt ausgehende Requests auf Geheimnisse und verpackt Seiteninhalte in verpflichtendes Fencing, bevor sie ein Modell erreichen — Seitentext landet nie unumzäunt in einem Prompt.
Hinweis · sovereign stuft nie still herab
Forderst du das Routing-Tier `sovereign` an und kein souveränes Backend kann den Aufruf bedienen, verweigert die Plattform — sie fällt nicht leise auf eine andere Route zurück. Welches Tier jeden Aufruf tatsächlich bedient hat, steht in der Provenienz der Antwort; die Behauptung ist pro Request nachprüfbar.