Built for trust, not theater.
HELM holds sensitive financial data — account balances, holdings, transactions, beneficiaries, documents. We engineer for that responsibility from day one. No marketing fluff below — just what's actually deployed.
Encrypted at rest
AES-256 encryption on the Postgres database. Document Vault uploads are encrypted before storage.
TLS 1.3 in transit
All traffic between your browser and our servers uses TLS 1.3 with HSTS enforced. No mixed-content fallbacks.
Per-tenant isolation
Every query scopes to your operator_id via a Supabase JWT. No row leakage between accounts is possible at the API layer.
MFA available
Two-factor authentication via TOTP on every account. We strongly recommend enabling it from Settings.
No data sales — ever
We do not sell, broker, or share your data with advertisers, data brokers, or aggregators. Sub-processor list below.
GLBA-aligned
Voluntary alignment with the Gramm-Leach-Bliley Act and NY DFS Part 500 — written program, security lead, vendor diligence, IR plan, annual review.
What HELM never stores — and never will
Most wealth tools fail at the data-collection layer. They request brokerage logins through aggregators, pull every transaction in plaintext, retain everything indefinitely. HELM's architecture is the opposite — manual-first means the entire class of aggregator breaches is impossible by design, not by policy.
| Item | Why HELM doesn't have it |
|---|---|
| Brokerage / bank login credentials | HELM has no Plaid, Yodlee, MX, or Finicity integration — and never will. There is no place in our codebase to put a banking password. |
| Full account numbers | We ask only for last-4 (optional) when tagging a beneficiary or insurance policy for identification. Full numbers are never collected. |
| Bank routing numbers / wire instructions | No field for them. No webhook accepts them. No function reads them. |
| Social Security number | Never collected. There is no SSN field in any form, schema, or API endpoint. |
| Government IDs (driver's license, passport) | Never collected. We don't run KYC. |
| Credit card numbers | Stripe is the controller of card data. We receive only a customer ID and last-4. We never see the full PAN. |
| Plaintext passwords | Bcrypt-hashed by Supabase Auth before any HELM code touches them. Anthropic engineers cannot recover a password. |
| Browser fingerprints / device IDs | No fingerprinting library deployed. We log only standard server access (IP, user-agent, route, timestamp) for 30 days for security/abuse detection. |
| Reverse-enrichment cookie data | No Clearbit Reveal, RB2B, or visitor-deanonymization service is loaded — anywhere. Standing rule across the entire studio. |
| Tracking pixels for ad networks | No Meta Pixel, no Google Tag Manager, no LinkedIn Insight, no TikTok Pixel. Privacy is a product feature. |
If we ever change any of these (we don't plan to), we will email every operator at least 14 days before the change with a non-marketing, plain-English explanation. You can opt out by exporting your data and deleting your account at any time.
Sub-processors
The complete list of vendors that can touch your data. Same list as in our Privacy Policy, surfaced here for transparency.
| Vendor | Purpose | Compliance | Region |
|---|---|---|---|
| Supabase | Authentication (email + OAuth), JWT signing | SOC 2 Type II | US |
| Neon | Postgres database, encrypted at rest | SOC 2 Type II, HIPAA-eligible | US |
| Anthropic | Claude AI (Ask HELM, Tax Brain, weekly digests) | SOC 2 Type II — no training, no retention | US |
| Stripe | Payments & subscription billing | PCI-DSS Level 1, SOC 1 + SOC 2 | US |
| Brevo | Transactional email (welcome, weekly digest, receipts) | GDPR-aligned, ISO 27001 | EU |
| Netlify | Hosting, edge CDN, serverless functions | SOC 2 Type II | US |
| Namecheap | Domain registrar (atthelm.com) | — | US |
Authentication & access
- Auth provider: Supabase Auth (email + Google OAuth). Passwords are stored hashed with bcrypt. We never see plaintext.
- Session tokens: short-lived JWTs signed with HS256, refreshed via secure httpOnly cookies.
- Two-factor (MFA): TOTP-based, available via Settings.
- Password reset: single-use, 24-hour expiry tokens, sent via Brevo SMTP.
- Failed-login lockout: automatic rate-limiting on consecutive failed sign-ins.
Application security
- Per-tenant row-level security. Every database query filters on operator_id derived from the verified JWT. There is no admin endpoint that bypasses it in production.
- HTTP security headers. X-Frame-Options: DENY · X-Content-Type-Options: nosniff · Referrer-Policy: strict-origin-when-cross-origin · Strict-Transport-Security: max-age=31536000; includeSubDomains; preload · Permissions-Policy: geolocation=(), microphone=(), camera=().
- SECRETS_SCAN on every deploy. Netlify scans every build for accidentally-committed credentials and blocks deploys that contain them.
- Dependency hygiene. Monthly `npm audit` review, prompt patching of high-severity CVEs.
- CSV imports. Files are parsed in-memory in a serverless function. The original file is never written to disk or stored.
AI safety
Incident response
If we detect a security incident affecting your data, our process is: contain, investigate, notify, remediate.
- Notification timeline: we will email affected operators within 72 hours of confirming a breach involving personal data.
- Status page: incidents and resolutions are posted at our public incident log.
- Post-mortem: for any material incident, we publish a written post-mortem within 14 days.
Vulnerability disclosure
If you've found a vulnerability, please report it privately. We commit to acknowledging within 48 hours and remediating critical issues within 7 days.
- Email: security@atthelm.com (PGP key on request)
- Machine-readable: /.well-known/security.txt (RFC 9116)
- Scope: atthelm.com and all its subdomains, helm-app GitHub repository
- Out of scope: third-party sub-processors (report directly to them), social-engineering of staff, physical attacks
- Safe harbor: good-faith research will not be the basis for any legal action by us
Annual review
We conduct an annual review of: sub-processor list, security policies, IR runbooks, dependency posture, access controls, and disaster recovery. The most recent review was completed in April 2026; the next is scheduled for April 2027.
Last updated May 4, 2026 · Vantage Digital LLC · Texas, United States