Security built into the schema.
A warehouse runs on trust: your inventory counts, your clients’ data, your shipping records. We isolate tenants at the database layer, enforce access at three layers, and encrypt what we store. Here is how, in plain terms a security reviewer can check.
Your data is isolated in the database, not just the app.
Multi-tenancy is enforced by PostgreSQL Row-Level Security. Every tenant-scoped table carries an RLS policy, so a query can only ever return the rows belonging to the authenticated tenant. The isolation lives below the application code, where a forgotten WHERE clause cannot leak across customers.
- Row-Level Security on every tenant table
- Policies filter by tenant at the row level; cross-tenant reads are impossible by design.
- Least-privilege database roles
- The running application connects as a restricted role limited to DML. Schema migrations use a separate, tightly scoped credential.
- Isolation is tested, not assumed
- Dual-actor tests assert that one tenant cannot read or mutate another tenant’s records through any endpoint.
Role-based access, enforced at three layers.
Seven roles, from Super Admin to read-only 3PL Client, map to granular permissions. Authorization is checked at the API gateway, again in the service layer, and finally by the database policies, so a gap in one layer is caught by the next.
- Granular, fine-grained permissions
- Access is resolved per action against a permission catalog, not by coarse role names alone.
- First-class audit log
- State-changing actions are recorded with actor, tenant, and context. The audit trail is itself tenant-isolated.
- Anti-lockout safeguards
- Permission changes cannot strip the last administrator of access to the account.
Encrypted in transit, encrypted at rest.
Traffic is served over TLS 1.3. Data is encrypted at rest. Secrets that must be stored, integration tokens, OAuth credentials, and MFA seeds, are sealed with authenticated encryption so a database snapshot alone never exposes them.
- TLS 1.3 in transit
- Modern transport encryption on every connection between client, API, and integrations.
- AES-256-GCM for stored secrets
- Integration access tokens and TOTP/MFA secrets are encrypted with authenticated encryption, keyed outside the database.
- Signed session integrity
- The role signal carried to the edge is HMAC-signed and verified on every request; it cannot be forged client-side.
Hardened against the common classes of attack.
Inputs are validated at the boundary, outbound requests are guarded against SSRF, sessions rotate, and accounts can require a second factor. These controls are built into the framework so every endpoint inherits them.
- Schema-validated input
- Every request body is parsed against a strict schema; unexpected fields are rejected, not ignored.
- SSRF-guarded outbound calls
- Webhook and integration URLs are validated against private-network and protocol allow-lists before any request is made.
- Refresh-token rotation and MFA
- Refresh tokens rotate on use and detect replay. Time-based one-time-password MFA is available, and can be enforced for admin roles.
- Rate limiting
- Authentication and sensitive endpoints are rate-limited to blunt brute-force and flooding.
Operated with discipline, not just configured once.
We follow SOC 2-aligned operational practices. We do not claim a certification we have not completed; we are happy to walk security reviewers through our controls during evaluation.
- SOC 2-aligned controls
- Access review, change management, and audit logging follow SOC 2 control families.
- Retained, bounded audit history
- Audit logs are retained on a defined schedule with safeguards against accidental mass deletion.
- Reviewer-friendly evaluation
- Enterprise prospects can request a controls walkthrough and documentation as part of procurement.
Found something? Tell us.
If you believe you have found a vulnerability, email security@fluxvantage.com. We acknowledge reports promptly, investigate in good faith, and will not pursue researchers who disclose responsibly.