Security Practices

Last updated: March 10, 2026

Our Commitment

Helm handles sensitive financial data. We treat security as a foundational requirement, not an afterthought. This document outlines our Information Security Policy (ISP), security architecture, and the controls we enforce to protect your data.

Zero Trust Architecture

Helm follows a zero trust security model. Every request is authenticated, authorized, and validated regardless of origin:

  • No implicit trust: All API requests require valid authentication tokens - there are no trusted internal networks or bypassed endpoints
  • Row-Level Security (RLS): Database-level policies enforce data isolation per user. Even service-level vulnerabilities cannot access another user's data
  • Short-lived tokens: JWT access tokens expire frequently and are refreshed via secure HTTP-only cookies
  • Least privilege: Application code uses user-scoped database clients by default. Service-role access is restricted to admin operations (account deletion, audit logging) and never exposed to client code
  • Multi-factor authentication: TOTP-based 2FA is available on all consumer accounts, adding a second verification layer beyond passwords
  • Rate limiting: Authentication endpoints enforce per-identity rate limits to prevent brute force and credential stuffing attacks

Encryption

In Transit

All data transmitted between your browser and our servers is encrypted using TLS 1.2 or higher. This includes API requests, authentication flows, and financial data transfers. Our infrastructure enforces HTTPS on all endpoints with no fallback to unencrypted connections.

At Rest

Your data is stored in encrypted databases using AES-256 encryption provided by our infrastructure partners (Supabase / AWS). Database backups are also encrypted. Encryption keys are managed by the infrastructure provider and are not accessible to application code.

Authentication & Access Control

  • Passwords are hashed using bcrypt before storage - we never store plaintext passwords
  • Password strength is enforced at signup and password change (uppercase, lowercase, number, special character, minimum 8 characters - must meet 4 of 5 requirements)
  • Two-factor authentication (TOTP) is available and recommended for all accounts
  • Authentication uses short-lived JWT tokens with secure, HTTP-only cookies
  • Login attempts are rate-limited (5 failed attempts per 15-minute window triggers a temporary lockout)
  • Signup and password reset requests are rate-limited to prevent abuse
  • All authentication events (logins, password changes, session revocations) are logged for audit purposes
  • You can view your login activity and sign out all other devices from Settings > Security

Multi-Factor Authentication

Helm supports time-based one-time password (TOTP) two-factor authentication on all consumer accounts. When enabled, users must provide a verification code from their authenticator app (Google Authenticator, Authy, 1Password, etc.) in addition to their password when signing in.

  • MFA can be enabled from Settings > Security > Two-Factor Authentication
  • MFA is enforced at login - the session is not granted full access until the TOTP challenge is completed
  • Protected routes verify the authentication assurance level (AAL) and redirect to MFA verification when required

Data Isolation

Every database table enforces Row-Level Security (RLS) policies at the database level. This means your financial data is isolated from every other user - even in the event of an application-level vulnerability, the database itself prevents cross-user data access.

Access Control Policy

Helm maintains a defined access control policy governing who can access consumer financial data and under what conditions:

  • Production database: Access restricted to service-role credentials, used only by automated server-side processes. No direct human access to production data during normal operations
  • Infrastructure access: Cloud provider accounts (Supabase, Vercel, GitHub) require multi-factor authentication for all team members
  • API keys and secrets: Stored in encrypted environment variable vaults (Vercel), never in source code or client-side bundles
  • Third-party integrations: Plaid API credentials use separate keys per environment (sandbox, production) with minimum necessary scopes
  • Code access: Source code repositories require authenticated access with MFA-enabled accounts

Internal Security Controls

MFA on Internal Systems

All internal systems that store or process consumer data require multi-factor authentication:

  • Supabase dashboard (database, auth management)
  • Vercel dashboard (deployment, environment variables)
  • GitHub (source code, CI/CD pipelines)
  • Plaid dashboard (account aggregation configuration)

Periodic Access Reviews

Access to production systems and consumer data is reviewed on a quarterly basis. Reviews include:

  • Auditing active team member access to all internal systems
  • Revoking access for any departed or transferred personnel
  • Verifying MFA is enabled on all privileged accounts
  • Reviewing API key scopes and rotating credentials as needed
  • Reviewing database RLS policies for correctness

Employee Offboarding

When a team member departs or transfers to a role that no longer requires access to consumer data, their access is revoked within one business day. This includes:

  • Removal from all cloud provider accounts (Supabase, Vercel)
  • Removal from source code repositories
  • Revocation of any API keys or tokens associated with the individual
  • Rotation of shared secrets if applicable

Vulnerability Management

  • Dependency scanning: Automated vulnerability scanning via GitHub Dependabot monitors all dependencies for known CVEs and creates alerts for remediation
  • Static analysis: GitHub CodeQL performs automated code scanning on every pull request to detect security vulnerabilities before they reach production
  • Infrastructure scanning: Cloud infrastructure providers (Vercel, Supabase) perform their own continuous vulnerability assessments
  • Remediation SLA: Critical vulnerabilities are addressed within 48 hours. High-severity issues within 7 days. All others within 30 days

Plaid Integration Security

We use Plaid to connect your financial accounts. Key security details:

  • Helm never receives or stores your bank login credentials
  • Plaid authenticates directly with your financial institution using bank-level security
  • We receive only read-only access to account data - we cannot initiate transactions or transfers
  • Plaid is SOC 2 Type II certified and undergoes regular security audits
  • You can revoke Plaid access at any time through your bank's connected apps settings or by deleting your Helm account

Infrastructure

  • Hosting: Vercel (serverless, edge-optimized, automatic DDoS protection)
  • Database: Supabase (managed PostgreSQL with automated backups, RLS, and encryption)
  • Secrets: Environment variables are stored in encrypted vaults, never in source code
  • Dependencies: Continuously monitored for known vulnerabilities via automated scanning
  • Audit logging: All authentication and security events are logged with timestamps, IP addresses, and user agents

Responsible Disclosure

If you discover a security vulnerability in Helm, please report it responsibly. Contact us at security@helmterminal.dev. We ask that you:

  • Do not access other users' data
  • Do not perform destructive actions
  • Allow reasonable time for us to address the issue before public disclosure

Information Security Policy

Our formal Information Security Policy (ISP) is publicly available at /security/isp. This document covers access control, de-provisioning, periodic reviews, vulnerability management, incident response, and all security controls in detail.

Questions

For security-related questions, contact security@helmterminal.dev.