Security & privacy

GovBridge for public authorities: where case file content is processed, how credentials, tenants and write access are protected, and what is logged.

The facts your authority's data protection and IT security teams need: data location, credential protection, tenant separation, write rights and logs.

Where the data is processed

A tool call touches four stations:

Station	Role	Location	Provider headquarters
SovrGPT	chat, chat history, encrypted credentials	Frankfurt (Vercel `fra1`, Supabase `eu-central-1`)	USA (Vercel), Singapore (Supabase)
GovBridge adapter	translates between MCP and CMIS or FIT-Connect	Netherlands (Railway, `europe-west4`)	USA
DMS / line-of-business system	holds the case files	your infrastructure	your authority
AI model	reads the content, writes the answer	depends on the chosen model, see model overview	depends on the model

The adapter stores no business content. SovrGPT stores the chat history like any chat, including the tool results. Owners and admins decide which models your organisation may use under Settings → Models. More on providers and locations: privacy policy.

Backend credentials

The password or OAuth2 client secret for the DMS or FIT-Connect is never stored in plaintext:

Method: AES-256-GCM, format v1:<base64-iv>:<base64-ct||tag>, byte-compatible between the platform (lib/secret-crypto.ts) and the adapter (services/govbridge/src/crypto.ts).
Key: GOVBRIDGE_ENCRYPTION_KEY (32 bytes, base64), only as a server environment variable, never in the code or the browser.
Decryption: only in RAM, only for one tool call (resolver.ts), never logged.

Two-factor tenant resolution

Every call needs two factors that point to the same active, non-revoked endpoint: the slug in the URL path (/<slug>/<protocol>) and the bearer token in the Authorization header. The adapter compares SHA-256(token) in constant time (timingSafeEqual) against the stored hash; a length mismatch returns false instead of throwing. <protocol> must match the endpoint exactly, so a token is not valid across protocols. Only then does it decrypt the credentials.

Every failure, including a missing token, returns a generic 401 without naming the failed factor. Only the hash is stored; you see the plaintext once, at setup (same pattern as API keys).

Write access and least privilege

The model can only call the curated cmis_* and fit_* tools. There is no raw CMIS SQL pass-through and no arbitrary access to the FIT-Connect API.
CMIS SQL is built only from escaped string literals; model text never reaches the query verbatim.
cmis_dokument_ablegen, cmis_dokument_verschieben and fit_antrag_senden only exist with allow_writes (off by default). Otherwise they are missing from tools/list and are rejected.
When connected through the Marketplace template, SovrGPT asks for approval in the chat before every call of a write tool (confirm_writes): each action individually, with the details shown, valid for one hour. It runs exactly once and with exactly these details; text in the chat is not an approval (Approvals in the chat). Approvals and declines are recorded in the audit log. When added as a custom MCP server, SovrGPT does not ask (Setup).

FIT-Connect end-to-end encryption

Application data, attachments and metadata.json leave as compact JWE (RSA-OAEP-256 + A256GCM), encrypted with the destination's public key. The submission API only sees ciphertext.
No compression (zip header), as required by v2.
Integrity through SHA-512 hashes per content part in the contentStructure of the metadata.json.
A submitted application cannot be withdrawn. fit_antrag_senden therefore needs allow_writes and the approval in the chat.

Logging

The adapter (logger.ts) logs metadata only: org and endpoint IDs, tool, protocol, status, duration, byte counts, correlation ID. Document content, bridge tokens, backend credentials and the Authorization header are never logged. A redaction list also strips sensitive keys (authorization, token, password, client_secret, credentials, content, body, …).

SovrGPT records the creation and revocation of endpoints and every approval and every decline of a write tool in the audit log, without the details themselves. The details, the decision and the result are kept in a record that only the person whose chat it is can see; it is deleted after 90 days. It also logs every tool call per organisation with status, duration and a shortened preview of input and result (up to 1,800 characters each). The preview can contain excerpts from documents. It appears in the Marketplace under "Letzte MCP-Aufrufe" (recent MCP calls).

Data minimisation and purpose limitation: through curated tools, a call fetches only the requested data, without full access to the DMS; the adapter keeps nothing.
Processing on behalf: the provider and processor is rooom AG; eNetworkers GmbH supports it in operations. A data processing agreement under Art. 28 GDPR with rooom AG is available on request (see GDPR). The DMS remains the responsibility of the authority.
Revocation: a revoked endpoint stops working immediately, see Administration & revocation.