Security in this build

Implemented controls

• Sensitive fact values use AES-256-GCM with per-user data keys. The local wrapping key comes from environment configuration; a managed KMS is not connected.
• Sharing, sensitive reveals, original-document previews, export and deletion require a recent OTP or passkey confirmation.
• Profile access follows current family membership and delegated sections. Provider accounts can connect only to their owner's self profile.
• Partner payloads are signed with ES256 and verified using public JWKS. Share-token exchange is single use; revoked or expired consent blocks new access.
• Upload processing checks declared size, content type and SHA-256 against the actual stored bytes. This content check is not an antivirus scan.
• The audit table forms a hash chain. API keys stay on the partner server; extension bearer tokens are kept out of document URLs.

Before a production launch

• Enable managed key wrapping, production object storage, malware scanning and backup/restore monitoring in the target data region.
• Replace fixed sandbox OTP and simulated provider adapters with approved live services and verify their contracts.
• Complete an independent security and privacy review, including data lifecycle policies, operational access and incident response.
• The separate BTA portal keeps only synthetic sessions and applications in authenticated Redis with bounded retention. A real institution must use its approved system of record.

Report a problem

Use the project issue tracker for reproducible bugs. Keep passwords, identity documents and API keys out of public reports.