Security

Threat model (what we defend against)

We design the product with common SaaS risks in mind. Examples of threats we explicitly consider:

• Unauthorized access to user portfolios, positions, or transactions.
• Cross-tenant data leakage (user A seeing user B’s data).
• Abuse of public endpoints (rate/traffic spikes, scraping, brute forcing access codes).
• Accidental exposure of secrets through logs, commits, or client-side bundles.

No system is risk-free. If you need a formal security package (SOC2/ISO, pen-test report, etc.), contact us for enterprise evaluation.

Authentication & access

• Auth provider: user identity handled via managed authentication.
• Beta gate: invite-only during beta, enforced via access gating.
• Principle of least privilege: users only access what they own.

If you suspect account compromise, contact us immediately and rotate any relevant credentials.

Data separation (RLS)

User data lives in a database with Row-Level Security (RLS) policies. RLS is designed to prevent accidental cross-user leakage by enforcing authorization at the database layer, not just in the UI.

• Portfolios/positions/transactions are scoped to a user (directly or via portfolio ownership).
• Policies restrict reads/writes based on the authenticated user identity.
• We prefer server-side enforcement for critical boundaries.

Data handling & retention

• What we store: account identifiers, portfolio records, and events/feedback you submit.
• What we don’t do: we don’t connect to your brokerage to place trades on your behalf.
• Retention: we retain data to operate the service; you can request deletion via privacy contact.

Operational security

• Secrets: stored in environment variables, never committed to source control.
• Logging: avoid logging secrets; log enough to support debugging and abuse detection.
• Abuse controls: rate limiting and gating on sensitive endpoints when needed.

Vulnerability reporting

If you find a security issue, please report it responsibly and include steps to reproduce.