Trust Center
Security
HelmXP holds the executive narrative of US credit unions — financial figures, governance decisions, and institution strategy. This page documents the technical controls that protect it.
Encryption
All data at rest in Azure Database for PostgreSQL Flexible Server and Azure Blob Storage is encrypted with AES-256 using platform-managed keys. Azure Key Vault holds the key encryption keys (KEK); customer-managed key rotation is available on request.
All traffic between the client and Azure Application Gateway, between App Services, and between App Services and the database is encrypted with TLS 1.3. TLS 1.0 and 1.1 are rejected. Certificates are managed by Azure and auto-renewed.
API keys, session signing keys, and database credentials are stored exclusively in Azure Key Vault. Application Services retrieve them via managed identity — no secrets in environment variables or code.
Automated daily backups are encrypted at rest with the same AES-256 keys as live data. Point-in-time recovery is available for 30 days.
Authentication architecture
HelmXP authentication is built from zero — no third-party auth provider in the critical path. Every line is auditable.
argon2id with tuned cost parameters (m=65536, t=3, p=4). Passwords are never stored in plain text or in a reversible form. Password reset uses time-limited signed tokens, not the current password.
TOTP-based MFA (RFC 6238, compatible with standard authenticator apps) is supported for all seat holders. Hub administrators can enforce MFA for all seats via the institution security settings.
Service Provider-initiated SAML 2.0 is available for enterprise hubs. The hub configures its identity provider (Okta, Azure AD, Ping) via the institution settings. Just-in-time provisioning creates seats on first assertion.
SCIM 2.0 server-side support allows an identity provider to create, update, and deprovision seats automatically. Supported attributes: displayName, email, externalId, groups.
Server-side sessions stored in PostgreSQL. Default idle timeout is 8 hours; hub administrators can reduce this to 1 hour. Sessions are immediately invalidated on password change and on explicit sign-out.
Tenant isolation
Every hub on HelmXP is strictly isolated. No query, no file, and no AI corpus can cross the hub boundary. The controls below are layered: they are not alternatives, they are concurrent.
Row-Level Security
Every table containing hub data has PostgreSQL Row-Level Security (RLS) enabled with FORCE RLS. A policy checks that the session variable app.tenant_id matches the row's hub_id before any read or write is permitted.
withTenant wrapper
Every database query in the application goes through the withTenant() helper, which opens a transaction, sets SET LOCAL app.tenant_id, and runs the callback. Queries outside this wrapper cannot read hub data.
Subdomain resolution
The hub identifier is resolved from the request subdomain in Next.js middleware before any handler runs. A tenant_id from a request body or query parameter is never trusted.
Storage isolation
All Azure Blob Storage paths are prefixed with tenants/{tenant_id}/. The signing function validates the prefix before generating a presigned URL.
AI corpus isolation
Each hub's RAG corpus is stored under its tenant prefix in Azure Blob Storage. Cache keys include the hubId. No cross-hub embeddings or shared fine-tuning.
Audit logging
Every material action in HelmXP is logged with the seat ID, timestamp (UTC), and relevant context. Logs are immutable and retained for 7 years.
| Area | What is logged |
|---|---|
| Authentication events | Sign-in, sign-out, failed attempts, MFA enrollment, password reset, SAML assertions. |
| Data changes | Audited data changes are enumerated, not blanket: authentication events, briefing lifecycle and section sign-offs, motions and votes, AI drafting interactions and approvals, and cross-tenant operator actions are each written to append-only audit tables with the acting seat and timestamp. |
| AI interactions | Every AI draft request — model, prompt hash, token count, and the seat that requested it — is logged per hub. |
| Briefing lifecycle | Draft, section sign-off, briefing lock, Captain review, and export events are all logged and available in the Logbook. |
| Cross-tenant audit | HelmXP operator actions on any hub are written to a separate audit table that is not subject to hub-level RLS. |
Security practices
Penetration testing
Annual third-party penetration test against the production environment. Most recent test: Wave B1 target (pre-production; first paying customer milestone). Test scope covers the web application, API, and authentication flows.
Bug bounty
A responsible disclosure program is planned for Wave B2, once the SOC 2 Type II audit closes. Until then, report security issues to security@helmxp.com. We commit to acknowledging reports within 2 business days and providing a status update within 10.
Dependency scanning
Automated dependency vulnerability scanning runs on every pull request and nightly against the main branch. Critical and high CVEs block merge.
Secret scanning
Pre-commit and CI hooks scan for committed secrets. Azure Key Vault holds all production credentials.
Security questions
To report a security issue, request our security questionnaire, or discuss our architecture, contact security@helmxp.com. We acknowledge all reports within 2 business days.