Data isolation and security
APEX runs every Company on one shared platform while keeping each Company's data sealed off from every other Company. This page describes how that separation is enforced, how authentication and two-factor work, what the audit log captures, and the security properties the platform is built against. It states what holds today and flags what is still on the roadmap.
How your data stays separate
Each Company is a tenant. Every record that belongs to a tenant carries that tenant's identifier, and the database itself, not just the application, enforces the boundary. When a request comes in, APEX reads the tenant from the signed-in user's token and sets it on the database connection for that request. The database then filters every read and every write to that tenant. A query that forgets to scope itself returns nothing rather than another tenant's rows. The database fails closed.
Partner users have a second boundary on top of the tenant one. A partner is pinned to their own organization as well, so a partner signed in for one Company cannot see another Company's data even when the same partner works with both.
Requests for data outside your scope return 404, not 403. This is deliberate: it means account identifiers cannot be enumerated by probing for which ones exist.
Logins and two-factor
APEX issues a signed access token at login and stores it in an HTTP-only cookie, so the token is never readable by page JavaScript. A separate cookie handles refresh.
| Property | Detail |
|---|---|
| Access token | RS256-signed JWT, loaded against a public key at startup |
| Token storage | HTTP-only cookies (apex_access for access, a separate cookie for refresh) |
| CSRF protection | Double-submit pattern: apex_csrf cookie echoed in the X-CSRF-Token header on data-changing requests |
| Two-factor (2FA) | Time-based one-time passcode (TOTP), built into the login layer |
| 2FA secret storage | Encrypted at rest with AES-256-GCM |
| Passwords | Hashed with bcrypt (cost 12); password reset uses single-use, short-lived tokens |
Two-factor is recommended for Owner and Admin roles.
NOTE
The source describes self-serve 2FA enrollment as "rolling out." Confirm whether self-enrollment is available in your account before documenting it as a standard step for users.
The audit log
APEX records every change: who did it, what they changed, and when. Each entry is written after the action completes and is scoped to your tenant.
Each audit entry captures the following.
| Field | What it records |
|---|---|
id | Unique entry identifier |
tenant_id | The Company the entry belongs to |
timestamp | When the action happened |
user | Who performed the action |
action | What was done |
resource | What was acted on |
details | Structured detail of the change, stored as a JSON string |
category | Classification of the action |
severity | Severity level of the action |
ipAddress | Source IP address of the request |
projectId | Related project, when applicable |
taskId | Related task, when applicable |
created_at | When the entry was written |
The audit log is append-only. The platform's runtime database role can write entries but cannot update or delete them, so the record cannot be rewritten from the application. The log reads through the Administration area of the Company portal and is scoped to your tenant; today it is queryable as JSON.
NOTE
Which roles can open the audit log is governed by Company-portal access and a per-user "view audit log" capability rather than a dedicated auditor role. Confirm the exact role and capability gating with engineering before stating it for customers.
NOTE
Full before-and-after change diffs and CSV or SIEM export are described as roadmap items, not current features. Do not present them as available.
Security posture
APEX is built against an internal security review baseline. The properties below describe what the platform enforces today.
| Property | What it means |
|---|---|
| No hardcoded secrets | Keys and credentials come from environment variables or external secret stores; the process refuses to start if a required one is missing |
| No SQL injection vectors | Database queries use parameterized statements rather than string-concatenated SQL |
| Signing-secret validation | A required signing secret is checked at startup; if it is missing the process refuses to start. The RS256 keypair is loaded at startup and its absence is logged loudly |
| Database role separation | The runtime database role can read and write data but cannot change the schema; schema changes use a separate role |
| CSRF protection | Double-submit cookie pattern on every data-changing request |
| Password handling | Bcrypt at cost 12; reset tokens are single-use with a short lifetime |
| Transport security | TLS 1.2 or higher; TLS terminated at the edge, with HTTP redirected to HTTPS |
| Tenant isolation | Enforced at the database layer by row-level security, not only in application code |
| Audit trail | Append-only and tenant-scoped |
NOTE
Edge transport details (HSTS, the exact TLS-termination point, and HTTP-to-HTTPS redirects) are set at the web edge rather than in the application code. Confirm the current edge configuration with engineering before quoting HSTS specifics to a customer.
On the roadmap
The following are described as planned, not shipped. Treat them as future work.
- Optional passkey / WebAuthn sign-in alongside TOTP.
- Per-row encryption at rest for license keys and credential numbers.
- A full SOC 2 audit cycle; the platform is currently building toward Type 1 readiness.
For role-level limits, see Roles and access. For connecting your own systems, see the REST API reference.