How your Hub's data is isolated

Every Hub on HelmXP is isolated from every other Hub at the database, storage, and application layers. A bug in one tenant's session cannot expose another tenant's data.

The short version: HelmXP uses a shared database with row-level security enforced by PostgreSQL. Every query is automatically scoped to your Hub. Your files are stored under a path that is prefixed with your Hub's unique identifier. No query can reach another Hub's data without a deliberate, audit-logged cross-tenant operation.

Database isolation

HelmXP uses a single PostgreSQL database shared across all Hubs. Isolation is enforced by PostgreSQL Row-Level Security (RLS):

• Every table that stores tenant-specific data has an RLS policy requiring that tenant_id matches the current session's Hub context
• The Hub context is set at the start of every database transaction via SET LOCAL app.tenant_id = '{hub_id}'
• Queries that do not set the Hub context return zero rows from protected tables — there is no fallthrough to "all tenants"

The application layer enforces a second check: every database query goes through a withTenant() wrapper that sets the Hub context from the authenticated session. A query that bypasses this wrapper is flagged at code review and blocked by CI.

Storage isolation

All files uploaded to HelmXP — GL exports, NCUA 5300 files, ALM models, briefing attachments — are stored in Amazon S3 under a path that begins with your Hub's unique identifier:

tenants/{hub_id}/briefings/{briefing_id}/...
tenants/{hub_id}/uploads/{file_id}/...

The application signs short-lived presigned URLs for file access. Unsigned access to S3 objects is blocked at the bucket policy level. Presigned URLs expire after 15 minutes and are scoped to a single object.

Request-level isolation

Every request to {your-hub}.helmxp.com is processed by middleware that:

1. Extracts the subdomain
2. Looks up the corresponding Hub identifier
3. Attaches the Hub identifier to the authenticated session
4. Rejects any request where the session's Hub identifier does not match the subdomain

This happens before any route handler or database query runs. A session authenticated against demo.helmxp.com cannot make requests to riverside.helmxp.com.

Cross-tenant operations

Only HelmXP operators (staff at admin.helmxp.com) can perform cross-tenant operations. These operations require:

• Authentication to the super-admin surface, which is IP-restricted
• An explicit IGNORE_TENANT_BOUNDARY flag on the operation
• An audit log entry written before the operation runs

No credit union's data is accessible to another credit union's executives, Sub-seats, or Captains under any circumstances.

Your data at rest

Data isolation applies at rest as well. If a backup of the database were restored, RLS policies would prevent any query from accessing data without the correct Hub context — the isolation is not application-layer-only.

S3 objects are encrypted at rest with AES-256 using AWS-managed keys. Bucket policies block direct access; all access goes through the application layer.

See also

• [[helmxp-security-overview]] — full security posture overview
• [[data-residency-and-storage]] — data residency, retention, and deletion
• [[authentication-and-access-controls]] — how sessions are authenticated and scoped