Architektur & Request-Flow

GovBridge besteht aus zwei klar getrennten Bausteinen, die sich genau eine Datenbank (Supabase, EU) und einen Verschlüsselungsschlüssel teilen.

Diese Trennung ist bewusst: Der Bridge-Dienst kennt keine SovrGPT-Sessions, keine Chat-Inhalte und keine Benutzer — er sieht nur einen Endpunkt-Slug, ein Token und einen JSON-RPC-Aufruf. Das hält den Wirkungsradius (Blast-Radius) klein.

Datenfluss auf einen Blick

┌──────────┐   MCP (JSON-RPC)    ┌──────────────┐   CMIS (JSON/HTTP)  ┌────────────────┐
│ SovrGPT  │ ──────────────────▶ │  GovBridge   │ ─────────────────▶ │ Fachverfahren  │
│  (EU)    │ ◀────────────────── │   (EU, RW4)  │ ◀───────────────── │ DMS (Ihr Haus) │
└──────────┘   Tool-Ergebnis     └──────────────┘   API-Antwort       └────────────────┘

Alle drei Stationen liegen im EU-Raum. Es gibt keinen Hyperscaler im Datenpfad und keine Zwischenspeicherung von Fachinhalten. Beim Protokoll FIT-Connect ist das Backend statt eines DMS die FITKO-Submission-API, und die Nutzlast verlässt die Bridge zusätzlich Ende-zu-Ende-verschlüsselt (JWE).

Ein Tool-Call, Schritt für Schritt

1. SovrGPT entscheidet im Chat, ein Werkzeug aufzurufen, und sendet POST https://govbridge.sovrgpt.com/<slug>/<protocol> mit Authorization: Bearer <bridge-token> und einem JSON-RPC-2.0-Body.
2. Routing. Der Dienst parst die Route (genau zwei Segmente /<slug>/<protocol>), akzeptiert nur POST und prüft, ob <protocol> in der Instanz-Allowlist liegt (GOVBRIDGE_PROTOCOLS, z. B. cmis, fit-connect).
3. Zwei-Faktor-Auflösung (siehe unten). Schlägt sie fehl → generisches 401, ohne zu verraten, welcher Faktor fehlte.
4. Body-Limit. Der JSON-RPC-Body wird mit harter 1-MB-Grenze gelesen (Einzelaufruf oder Batch).
5. Dispatch. Der MCP-Dispatcher behandelt initialize, tools/list, tools/call, ping. Bei tools/call wird das zum Protokoll passende Plugin gewählt.
6. Backend-Aufruf in Echtzeit. Das zum Protokoll passende Plugin baut den Backend-Auth-Header und ruft das Backend über fetch mit hartem Timeout auf: das CMIS-Plugin zieht/legt Akten und wendet die Größen-Policy an; das FIT-Connect-Plugin verschlüsselt die Einreichung Ende-zu-Ende (JWE) und durchläuft announce → Anhänge → finalize. Beide geben MCP-content-Teile zurück.
7. Antwort & Logging. Der Dienst protokolliert nur Metadaten (Org-/ Endpoint-IDs, Tool, Dauer, Status) und antwortet mit der JSON-RPC-Response (bzw. 202 bei reinen Notifications).

Zwei-Faktor-Mandantenauflösung

Jeder eingehende Aufruf trägt zwei unabhängige Faktoren, die beide auf dieselbe Endpunkt-Zeile zeigen müssen:

1. Slug (im URL-Pfad, opak) — identifiziert den Endpunkt.
2. Bearer-Token (im Authorization-Header) — beweist die Berechtigung.

Der Ablauf ist konstant-zeitig und verrät bei Fehlschlag nie, welcher Faktor nicht passte:

1. Kein Token → unauthorized.
2. Endpunkt per Slug nachschlagen (nur aktive, nicht widerrufene Zeilen).
3. SHA-256(token) konstant-zeitig gegen den gespeicherten Hash vergleichen. Mismatch → unauthorized.
4. URL-<protocol> muss exakt dem gespeicherten Protokoll entsprechen (keine protokollübergreifende Wiederverwendung).
5. Backend-Credentials werden transient entschlüsselt — nur im RAM für die Dauer dieses einen Calls, nie geloggt.

Der Token-Klartext existiert nur einmalig bei der Provisionierung; gespeichert wird ausschließlich sein Hash — dasselbe Muster wie bei den API-Keys.

Zustandslosigkeit

Der Dispatcher ist stateless: Jeder Request trägt seinen eigenen aufgelösten Mandantenkontext, es gibt kein Sitzungsobjekt pro Verbindung. Gecacht werden nur zwei unkritische Dinge im Prozess-RAM, rein zur Round-Trip-Ersparnis:

• das OAuth-Backend-Token pro Endpunkt (bis kurz vor Ablauf),
• das CMIS-Repository-Service-Dokument (5 Minuten).

Fachinhalte werden nie zwischengespeichert.

Weiter

• Werkzeuge & Schnittstellen — die cmis_*- und fit_*-Tools.
• Sicherheit & Compliance — Crypto und DSGVO.
• Betrieb — Hosting, Limits, Fehlerverhalten.