Security

Foundry runs on a shared Postgres database where every tenant’s rows are fenced by row-level security policies bound to the authenticated session. Application code never adds a tenant predicate by hand — the database itself refuses to return another tenant’s data.

Your Financial Health Rating is computed by a transparent rule engine, not a language model. AI is used only to read structured numbers out of a statement you upload; those numbers are validated before they ever reach the rating, and the score itself is always reproducible.

All traffic is served over TLS. Data is encrypted at rest by our infrastructure providers, and uploaded statements are stored with private access and reached only through short-lived signed URLs.

Passwords are hashed with a slow, salted algorithm (scrypt) and never stored in the clear. Sessions are signed tokens checked against a server-side allowlist, so a sign-out — or a security event — can revoke access immediately rather than waiting for a token to expire.

Credentials are resolved through a single secrets seam, never read ad-hoc from application code, and a lint rule enforces that boundary across the codebase so a secret can’t leak into the wrong layer.

• Tenant isolation verified by automated cross-tenant tests in continuous integration.
• Structural lint rules keep database, vendor, and secret access behind their proper seams.
• Append-only audit records make sensitive changes traceable.

We are building toward formal third-party attestation and penetration testing. We’ll describe our compliance posture here as those milestones are reached — we won’t claim a certification we don’t hold.

Found something? Email security@oba.solutions and we’ll acknowledge within one business day.