Security & privacy posture

All tenant data — organizations, instruments, analyses, audit entries, watchlist items, uploaded financial statements, and loan security documents — is stored in Google Cloud’s Montreal region (northamerica-northeast1). The primary Firestore database is named financial-viability-db and the storage bucket is regionally pinned to the same Canadian region.

We do not replicate data outside Canada for hosting. The only cross-border data flow is the LLM inference call to Anthropic described in the next section, which sends financial-statement content to their US infrastructure for processing and discards it on completion.

Financial-statement extraction and narrative analysis are powered by Anthropic Claude. The specific model in production is claude-opus-4-5-20251101. The same vendor and model is used for the (optional) loan security document analysis.

• Zero training: Anthropic does not train any models on data submitted via their commercial API. We use the standard commercial endpoint — not a consumer Claude.ai account.
• Audit-only retention: Anthropic retains request metadata for abuse detection. They do not retain document contents for ongoing use, and we do not log document contents on our side beyond what is needed to render results back to you.
• No third-party fan-out: Financial Viability does not forward your data to any other LLM or analytics vendor.
• Human-in-the-loop optional: Every LLM-extracted field can be reviewed and edited before it is persisted.

Sign-in uses Firebase Authentication with one-time email codes (OTP). There are no long-lived passwords stored anywhere in the system. Sessions are short and refreshed via Firebase’s ID-token mechanism.

Borrower upload portals use signed magic links scoped to a single instrument and a single use. Links expire on first use and re-issue automatically when an admin resends a reminder.

• In transit: TLS 1.2+ for every browser ↔ server, server ↔ Firestore, server ↔ Storage, and server ↔ Anthropic API connection. HSTS is enabled on the public origin.
• At rest: All Firestore documents and Storage objects are encrypted with Google-managed keys (AES-256). No tenant data ever lives in plaintext on disk.
• Secrets: Anthropic API keys, Firebase service accounts, and Resend keys are stored in environment configuration and rotated when contributors leave the project.

Every user belongs to one or more tenants. Within a tenant they hold one of three roles:

• Member — read all portfolios in the tenant, create and edit organizations and analyses.
• Admin — everything Members can do, plus invite users, manage covenants, configure custom indicators, and delete portfolios or organizations.
• Super-admin — Charitability staff only. Used exclusively for impersonation during incident response, with every action recorded in the audit trail.

Access is enforced both client-side (UI gating) and server-side (Firestore security rules and authenticated API routes) so a modified client can never escalate.

Every state-changing action writes an immutable entry to a tenant-scoped audit log. Recorded actions include — but are not limited to — user invitations, role changes, organization create / update / delete, portfolio delete, analysis save, watchlist triggers, security-document upload, and security-analysis generation. Each entry captures actor, target, timestamp, and a structured payload so you can reconstruct exactly what happened.

Tenant admins can browse the log directly from the in-app Audit screen and export it on request.

Tenant admins can permanently delete any portfolio or organization from the Settings page. Deletion is gated by a GitHub-style typed-name confirmation: you must literally type the name of the record before the destructive action becomes available.

Server-side, deletes go through dedicated admin API routes that run a recursive cascade — wiping every analysis, instrument, watchlist item, document reference, security analysis, custom indicator, and stored file — before logging the action to the audit trail. There is no soft-delete: the data is gone.

For full account-level off-boarding, contact privacy@charitability.ca and we will delete the entire tenant within 30 days.

We use a deliberately small set of third-party sub-processors. Any additions are announced before they go live and reflected on this page.

We build to the OWASP Application Security Verification Standard (ASVS) and treat the OWASP Top 10 (2021) as the floor, not the ceiling. Practical controls that map directly to those categories:

• A01 — Broken access control: RBAC enforced in both Firestore rules and server routes; admin actions double-checked server-side; tenant isolation on every query.
• A02 — Cryptographic failures: TLS 1.2+ in transit, AES-256 at rest (Google-managed keys), no plaintext secrets in source.
• A03 — Injection: No raw SQL — Firestore is a document store accessed via the typed Admin SDK. LLM prompts are composed server-side with field separation between system and user content.
• A05 — Security misconfiguration: Firestore / Storage rules deployed via versioned scripts; CSP and HSTS headers on the public origin.
• A07 — Identification & authentication failures: Passwordless OTP via Firebase Auth, magic-link borrower portals, short session lifetimes.
• A09 — Security logging & monitoring failures: Comprehensive in-app audit trail for every state-changing action.
• A10 — Server-side request forgery: The only outbound network call from server code is the typed Anthropic client; we do not accept user-supplied URLs for fetching.

Penetration testing and dependency vulnerability monitoring are run on a recurring cadence; results are available under NDA on request.

Because Financial Viability puts an LLM directly in the path of borrower financials, we also align with the OWASP Top 10 for LLM Applications (LLM01–LLM10, 2025 edition). Each item below is mapped to a concrete control in the product:

• LLM01 — Prompt injection: System prompts live server-side and are never user-editable; uploaded documents are passed as separate, clearly-labeled inputs to the model rather than concatenated into the system prompt. The model’s output is treated as untrusted text — we never feed it back as instructions to another tool.
• LLM02 — Sensitive information disclosure: We use Anthropic’s commercial API with the zero-training term in effect; document contents are not retained for training. No financial data is ever included in outbound transactional email (Resend).
• LLM03 — Supply-chain risk: Anthropic and Google Cloud are the only model/infrastructure dependencies and both are listed publicly in the Sub-processors section. We do not load third-party LLM plugins or community tools into the request path.
• LLM04 — Data & model poisoning: We do not fine-tune custom models on tenant data. Indicator definitions and the composite index are deterministic functions of LLM-extracted fields — the LLM does not get to choose how a number is interpreted.
• LLM05 — Improper output handling: Extraction output is parsed into a strict JSON schema before it touches persistence; any field that fails the schema is rejected and surfaced for human review rather than silently saved. Narrative output is rendered as markdown with a sanitised renderer (no raw HTML, no script execution).
• LLM06 — Excessive agency: The LLM is a read-only analytical component. It cannot trigger writes, email, deletes, or any external action — every state- changing action is performed by typed server code in response to an explicit authenticated user request.
• LLM07 — System-prompt leakage: Prompts do not contain credentials, tenant secrets, or routing logic; if a prompt were ever exposed it would not yield privileged information beyond the wording of our analysis instructions.
• LLM08 — Vector & embedding weaknesses: We do not currently run a RAG pipeline against tenant data. If/when we add embeddings, they will be tenant-scoped and never shared across tenants — this is documented in advance of any feature that would require it.
• LLM09 — Misinformation & over-reliance: Every LLM-extracted field is reviewable and editable by the user before persistence; narrative output is clearly marked as analysis, not advice. Composite scores and indicator calculations are computed by deterministic code, not by the LLM, so a hallucinated narrative cannot move a risk score.
• LLM10 — Unbounded consumption: Per-tenant document size limits, per-request token caps, and concurrency limits prevent a single tenant from running up an unbounded inference bill or starving the queue. Failed requests fall back to surfacing the raw error rather than silently retrying forever.