Security is the product.

Endpoint agent and actions

• Signed content only. The agent executes action packs and Autofix policies only when they carry a valid Ed25519 signature from DexRite's signing key. Unsigned or tampered content is rejected and reported to the console.
• Signing keys stay off application servers. Private signing keys never live on the servers that run the API or talk to devices.
• Signed agent and signed updates. The agent binaries and Windows installer are code-signed. Updates are signed, rolled out in stages, and roll back automatically if the new version fails.
• Safe rollout of changes. Actions and policies roll out to a small group first and pause automatically when failures rise. High-risk actions need approval. Autofix policies can run in monitor mode first, reporting what they would fix without changing anything.
• Minimal collection. The agent collects only what features need. It never collects document contents, keystrokes or screen content.

Device identity and transport

• Per-device certificates. A device enrolls with a single-purpose token and receives its own certificate. All agent traffic uses mutual TLS.
• TPM-backed keys. Where the device has a TPM, its private key is generated inside it and is not exportable, so the identity cannot be copied to another machine.
• Encrypted in transit and at rest. All connections use TLS; stored data is encrypted at rest with managed keys.

Tenant isolation

Each client of an MSP, and each direct customer, is a separate tenant. Isolation does not depend on a single check:

• Scoped in the application. Every query carries the tenant it belongs to.
• Enforced in the database. PostgreSQL row-level security applies the same rule again, so a mistake in application code cannot read another tenant's rows.
• Cross-client views by permission. MSP technicians see several clients only through roles that grant it, and every cross-client action is audited.

Access control

• Single sign-on. Microsoft Entra ID, Google Workspace, generic OIDC and SAML 2.0.
• SCIM provisioning. Your identity provider creates, updates and disables DexRite users and group memberships automatically.
• Role-based access. Permissions are checked on every API call and every action, scoped per client. Co-managed client IT teams get only the access you assign.

Audit

An append-only audit log records every query, action, policy change and sign-in: who did it, on which devices, when, and with what result. Entries cannot be edited after they are written.

Data handling and residency

• One region per account. Each account is hosted in exactly one region for its whole life, and its data stays in that region.
• Regions. The European Union is the first production region. India and further regions are planned as separate, independent deployments.
• Retention. Data is kept for a defined period per tenant and then deleted.
• Secrets. Credentials are held in a managed secrets store, never in code, logs or configuration files.

No standing staff access

DexRite staff have no standing access to your tenants' data. When you need help, your admin grants support access from the console for a limited time, at a chosen level (read-only by default), with a reason. The grant expires automatically, can be revoked at any time, and everything staff do under it is recorded in your audit log. Staff sign-in uses phishing-resistant multi-factor authentication.

Compliance status

DexRite is in early access and does not yet hold third-party security certifications or attestation reports. We will publish their status on this page when they exist. Until then we are glad to answer security questionnaires and walk your team through the architecture.

To report a vulnerability, email security@dexrite.com.