Security architecture.
No compliance certifications are claimed, because none have been obtained. What follows is how the platform is designed — mechanisms you can check against the architecture rather than badges you would have to take on trust.
Only data-plane workers decrypt credentials, in memory, for the duration of a run.
| Component | Holds | Boundary |
|---|---|---|
| Control plane | Configuration, flow versions, audit, secret references | Control plane |
| Data-plane workers | Records in transit, decrypted credentials in memory | Data plane |
| Secrets store | Connection credentials and signing secrets | Neither — referenced by handle |
| Log store | Structured logs with no secret material | Data plane |
Design
Eight areas, stated as mechanisms.
The control plane holds configuration and references to secrets. The data plane holds records and, briefly and in memory, the decrypted credentials needed to move them. The separation is what makes the claims below true rather than aspirational.
- Encryption
TLS 1.2 or higher in transit, with HSTS on every host. Records, credentials, queues and backups are encrypted at rest with managed keys.
Separate customer-managed keys per environment make the control-plane / data-plane boundary enforceable in the cloud IAM policy, not just in application code.
- Secrets management
Connection credentials are held in a dedicated secrets store and referenced by handle. They are never written to logs, never returned by the API, and write-only in the interface after creation.
Decryption happens only in data-plane workers, in memory, for the duration of a run. The control plane stores a reference, never the secret.
- API authentication
Environment-scoped bearer keys with a prefix that identifies the environment (zx_sk_live_ / zx_sk_sandbox_), last-used tracking, instant revocation and optional IP allowlisting.
Keys are stored hashed; only the prefix is kept in clear so a key can be identified in a list. A key is displayed once, at creation.
- Access control
Role-based permissions across five roles, enforced server-side in one policy layer on every mutation — never in the client and never only at the route level.
Environment is part of every authorization check, so a sandbox-scoped key cannot read production data.
- Environment separation
Sandbox and production hold separate connections, credentials, keys and data. There is no cross-environment read.
Promoting a flow to production requires re-binding every connection reference to a production connection; sandbox credentials are never carried forward silently.
- Audit logs
Every configuration mutation records actor, action, target, before and after values, IP and timestamp. The log is append-only and exportable.
Because flow versions are immutable, the audit trail and the version history cannot disagree with each other.
- Data handling and retention
Run-record and log retention are configurable per plan. Payload capture can be disabled per flow, and field-level redaction rules mask named fields before anything is persisted.
With payload capture off, execution records keep status and reason codes but no payloads — observability survives without storing sensitive data.
- Network and tenancy
Workers run in private subnets and egress through stable NAT addresses that can be published for allowlisting. Databases are not publicly reachable.
Multi-tenancy is logical, with workspace-scoped predicates and per-workspace concurrency caps to prevent noisy-neighbour effects.
API authentication
Keys that say what they are.
# keys carry their environment in the prefixzx_sk_live_... # productionzx_sk_sandbox_... # sandbox — cannot read production data # stored hashed; only the prefix is kept in clear for display# revoked instantly; optional IP allowlist per keycurl https://api.zentrixquark.com/v1/customers \ -H "Authorization: Bearer zx_sk_live_…" # → 401 when revoked{ "error": { "type": "authentication_error", "code": "key_revoked", "request_id": "req_7c31a9" } }Illustrative. No production API is live yet.
Role-based access control
Five roles, deliberately not more.
No role can read secret material. Operator exists because day-2 operations must not require deploy rights. Role changes are audited, and an invitation states the permission delta in plain language.
| Role | Connections | Flows | Deploy | Runs | Keys & secrets | Team & billing |
|---|---|---|---|---|---|---|
| Owner | Full | Full | Yes | Yes | Full | Full — sole role that can delete the workspace or change billing |
| Admin | Full | Full | Yes | Yes | Full | Manage members; view billing |
| Developer | Create, edit, test, rotate | Full | Yes | Yes | Own keys | View members |
| Operator | Test, disable | View, pause, resume | No | Re-run, cancel | None | View members |
| Viewer | View (no credential fields) | View | No | View | None | None |
Planned — not yet audited
What does not exist yet.
Listing this honestly is more useful than a badge wall. None of the items below are in place today; they are the security roadmap, in rough order.
- PlannedIndependent security review
- PlannedSOC 2 readiness programme
- PlannedData processing agreement and subprocessor list
- PlannedSSO / SAML and SCIM provisioning
- PlannedRegional data planes for residency
- PlannedMulti-factor authentication (TOTP)
Responsible disclosure: report a suspected vulnerability to security@zentrixquark.com. We will acknowledge receipt and keep you informed while it is investigated.
Contact the team