Odin

Security & data protection

Odin handles deal data — CIMs, financials, target outreach, board decks. The list below describes the controls we have in place today. We do not make certification claims we have not earned.

Identity & access

  • Clerk-managed auth. All sign-in goes through Clerk. Passwords, MFA enrollment, session tokens, and SSO are managed by Clerk — Odin never sees a password.
  • Two-factor authentication. Available on every account: an authenticator app (TOTP) plus single-use backup codes, enrolled from account settings. Enrollment is currently each member's choice — we do not yet offer an org-wide requirement, and we do not accept SMS as a second factor.
  • Role-based access control. Owner / admin / analyst / BD / partner / IC. Permission checks run server-side on every API route, with Postgres row-level security as a second line of defense.
  • Per-deal access control. Optional. Workspace admins can restrict which members see a given deal.

Data storage & isolation

  • Per-org isolation. Every Odin row carries anorg_id. Database queries filter on it; row-level security policies enforce it again at the Postgres layer.
  • Encryption at rest. Database and object storage are encrypted at rest by our infrastructure providers (Supabase, Vercel), AES-256 by default.
  • Encryption in transit. TLS 1.2+ on every customer-facing endpoint.
  • Document storage. Uploaded documents live in a per-org Supabase storage bucket with signed-URL access only. Documents are never publicly listable.

Payments & cardholder data

  • Stripe handles PCI. Card numbers never touch Odin servers. Checkout and the customer billing portal are Stripe-hosted; we store only the Stripe customer ID and subscription metadata.

AI & model use

  • No model training on customer data. Odin's AI features (Huginn chat, Muninn deep analysis) call the Anthropic API. Anthropic does not train on inputs from API calls — that's table stakes for our use of their API.
  • Per-org metering. Every AI call is logged to our usage table tagged with the org. Customers can see their own usage; we do not surface it across orgs.

Operational

  • Hosted on Vercel + Supabase. Both vendors maintain SOC 2 Type II reports.
  • Backups. Daily automated Postgres backups via Supabase.
  • Monitoring. Automated AI-usage spike alerts; structured request and audit logging. Error monitoring (Sentry) where enabled.

Change management & engineering controls

  • Security-gated CI. Six required checks on every change — typecheck, lint, tests, build, security guards (IDOR/permission/secret linting), and dependency audit. A change that fails any of them does not merge.
  • Branch protection. Production deploys only from the protected main branch. We are a solo-maintainer shop today, so there is no required peer review — the CI gate is the reviewer — and we say so rather than implying one.
  • Append-only audit log. Sensitive actions are recorded with actor, IP, and user agent; entries are never updated or deleted by application code.
  • Secret scanning. A commit-time lint blocks credentials from entering the repository; dependencies are monitored via Dependabot.

Coming soon

  • SOC 2 Type 1. We will engage an auditor as customer demand warrants. We will update this page when we start an audit, not before.
  • SSO (SAML/OIDC). Available on enterprise plans via Clerk on request.
  • Customer-managed retention. Org-wide data export is available today; configurable retention windows are on the roadmap.

Reporting a security issue

Email security@txnhub.app, or use the form below — it alerts us directly rather than waiting for a mailbox to be opened. We acknowledge within one business day. Please include reproduction steps and any relevant URLs or request IDs. We do not yet run a formal bounty program.

Last updated: 2026-08-13