Security

Odin Platforms handles financial data for finance teams. This page describes our security posture as it actually exists today — not aspirations. Where something is on the roadmap, we say so plainly.

Data architecture — bifurcated by sensitivity

We separate data by sensitivity. Non-PHI financial data (ledgers, KPIs, forecasts) lives in Supabase Postgres with row-level security (RLS) enforcing per-tenant isolation. Protected Health Information (PHI), where a regulated healthcare workload requires it, is isolated in a separate AWS-hosted environment under stricter controls. The two stores are not commingled.

Encryption

All traffic is encrypted in transit (TLS). Data is encrypted at rest by the underlying managed databases. OAuth tokens for connected accounting and banking systems are sealed with AES-256-GCM envelopes before storage and are never returned to the browser.

AI routing & BAA

AI inference is routed through our internal model router to Amazon Bedrock, so prompts stay within a controlled boundary rather than being sent to consumer AI endpoints. For regulated workloads, a Business Associate Agreement (BAA) governs the AI path; non-PHI demo data is clearly labelled as illustrative and never carries patient identifiers.

Access & least privilege

Connectors are read-only — Ymir never moves money. Application database roles are scoped to the minimum required; raw materialized views are not exposed to application roles. Every value in the product carries provenance back to its source row, so access and lineage are auditable.

Compliance roadmap (honest status)

We are not SOC 2 certified today, and we don't display badges we haven't earned. SOC 2 Type II is on the roadmap. BAAs are available for regulated healthcare deployments. If your diligence needs something specific, email us and we'll tell you exactly where we are.

Contact

Security questions or disclosure: PeterY@odinplatforms.ai.