Security & compliance

GovBridge is built as a public-sector component, designed for confidentiality and traceability. This chapter collects the security- and privacy-relevant properties.

Encryption of the backend credentials

The access credentials for the backend (basic password or OAuth2 client secret — for the CMIS DMS as well as for the FIT-Connect submission API) are never stored in plaintext:

• Method: AES-256-GCM (authenticated encryption).
• Format: v1:<base64-iv>:<base64-ct||tag> — byte-compatible between the SovrGPT platform (lib/secret-crypto.ts) and the bridge service (services/govbridge/src/crypto.ts), so that the same key works on both sides.
• Key: GOVBRIDGE_ENCRYPTION_KEY, a 32-byte key (base64), only as a server environment variable — never in the code, never in the repository, never client-side.
• Transient decryption: the credentials are only decrypted in RAM, for the duration of a single tool call (resolver.ts) and are never logged.

Two-factor tenant resolution

Every call carries two independent factors, and both must point to the same endpoint row:

1. Slug in the URL path (/<slug>/<protocol>) — identifies the endpoint.
2. Bearer token in the Authorization header — proves authorisation.

Security details:

• Only the SHA-256 hash of the token is stored; the plaintext exists once, at provisioning time (one-time reveal) — after that it cannot be retrieved.
• The comparison is constant-time (timingSafeEqual) and returns false on a length mismatch instead of throwing → no timing side channels.
• A failure always returns a generic 401 — it is never revealed which of the two factors did not match.
• The URL <protocol> must match the provisioned protocol exactly (no cross-protocol token reuse).

Least privilege

• The model can call only the curated cmis_* tool set — there is no raw CMIS SQL pass-through.
• CMIS SQL queries are assembled server-side exclusively from escaped string literals; model text never reaches the query verbatim (injection protection).
• Write actions (cmis_dokument_ablegen, cmis_dokument_verschieben) can be switched off per endpoint via allow_writes. When write access is off, these tools are neither listed in tools/list nor executed ("write access is not enabled for this endpoint").

FIT-Connect end-to-end encryption

For fit-connect endpoints, encryption is not optional but part of the protocol:

• Application data, attachments and metadata.json are encrypted as compact JWE (RSA-OAEP-256 + A256GCM) with the public key of the destination — the bridge decrypts nothing, and the backend only ever sees ciphertext.
• No compression (zip header), as required by v2.
• Integrity through SHA-512 hashes per content part, embedded in the contentStructure of the metadata.json.
• Submitting is a deliberately gated, irrevocable action: fit_antrag_senden requires allow_writes and additionally triggers the confirmation requirement (confirm_writes) on the SovrGPT side.

Metadata-only logging

The service logs strictly metadata only (logger.ts):

• Allowed: org/endpoint IDs, tool name, protocol, status, duration, byte counts, correlation ID.
• Never logged: document contents, bridge tokens, backend credentials, the Authorization header.
• A redaction allowlist additionally scrubs sensitive keys automatically (authorization, token, password, client_secret, credentials, content, body, …) — even if an over-rich object is passed by accident.

EU data residency

All three stations of the data path are inside the EU:

There is no hyperscaler in the data path and no caching of business content — every tool call pulls live from the DMS.

GDPR aspects

• Data minimisation: only the data requested by the respective tool call flows; nothing is held in reserve.
• Purpose limitation & least privilege: curated tools, switchable write access, no full access to the DMS.
• Processing on behalf: operated by eNetworkers (see GDPR); the DMS remains the responsibility of the authority.
• Traceability: every provisioning step and change is recorded in the platform's audit log; every tool call is logged at the metadata level.

Revocation & rotation

• An endpoint can be deactivated or revoked at any time; revoked rows are no longer resolved by the bridge service.
• If a bridge token is lost or a leak is suspected, the endpoint is re-provisioned (new slug + token); the old one becomes unusable immediately.

Next

• Architecture & request flow.
• Operations — hosting, limits, error behaviour.