Trust & Security Overview

This section describes how Ascent protects your data and the security controls built into the platform. We believe MSPs deserve to see exactly what we do before trusting us with their clients' information.

Overview

This page covers, accurately and without overstatement:

• How sessions are authenticated across Ascent's three separate surfaces.
• How access is authorized once you're signed in (RBAC).
• How sensitive data is encrypted, and the precise threat model that encryption is designed to resist.
• How tenants are isolated from one another.
• The secure-development controls that run in our build pipeline.
• Where the hosted model ends and self-hosting begins.

Compliance Posture

We want to be upfront about where we stand:

• We do not currently hold SOC 2, HIPAA, or GDPR certifications. We do not claim compliance with any of these frameworks for the hosted service.
• On-premises deployment is available for customers whose compliance obligations require data to stay inside their own infrastructure. On-prem customers control their own encryption keys, backups, and data retention, and operate Ascent under their own compliance program.
• GDPR data subject requests are supported operationally. See Data Handling for details.

If your procurement process requires formal attestations, reach out at [email protected] and we will tell you honestly what is and isn't in scope today.

Authentication and Access

Ascent uses three separate authentication systems, each with its own cookies, endpoints, and middleware. A token issued for one surface cannot be used on another.

System	Audience	Access Cookie	User Model
Platform	Ascent operators	ascent_platform_token	PlatformUser
Organization	MSP technicians and admins	ascent_access_token	User + OrgMembership
Portal	Your end clients	ascent_portal_token	Contact + portal user record

Key properties:

• All session tokens are stored in httpOnly cookies — they are not accessible to client-side JavaScript, which closes the most common XSS token-theft paths.
• Cookies are set with SameSite=Lax and, in production, the Secure flag (HTTPS-only). SameSite=Lax is the cookies' built-in CSRF mitigation: the session cookie is not sent on cross-site sub-requests. The platform "View As Org" bridge cookie uses the stricter SameSite=Strict.
• Access tokens are short-lived (15 minutes for org and portal, 1 hour for platform) and are paired with longer-lived refresh tokens that rotate on use. Platform, org, and portal tokens carry distinct JWT audiences, so a token from one system is rejected by the others.
• Multi-factor authentication is supported. Org and portal users can use TOTP and WebAuthn (hardware keys, platform authenticators), and both are issued single-use recovery codes. Platform admins use TOTP with recovery codes as a fallback.
• Single sign-on (OAuth/OIDC) is available: each organization configures its own providers (Microsoft Entra ID, Google, Authentik, Generic OIDC), and the portal supports per-client SSO. All SSO flows use PKCE, and stored client secrets are encrypted at rest.
• Passwords are hashed with Argon2id. MFA recovery codes are hashed the same way. Passwords are never stored in plaintext or reversibly encrypted.

Authorization

Once authenticated, access inside an organization is governed by a role-based access control (RBAC) system with a three-tier role hierarchy — OWNER, ADMIN, MEMBER — plus granular per-resource permissions. UI elements gate on permission checks, and API endpoints re-verify those permissions server-side through dedicated permission middleware. A user who lacks a permission cannot reach the underlying data, regardless of which client they use.

Platform operators have their own separate roles (PLATFORM_ADMIN, PLATFORM_SUPPORT, PLATFORM_BILLING) that govern platform-level actions and are entirely distinct from org roles.

Encryption

• In transit: all traffic to the hosted service is served over TLS.
• At rest (sensitive fields): integration credentials, OAuth/SSO client secrets, API tokens, persisted AI assistant chat logs (the conversations that involved an action), and similar secrets are encrypted with AES-256-GCM. Each organization's data is encrypted under a key derived via HKDF-SHA256 from a master key kept in our secrets store — outside the database — combined with a per-organization salt stored in the database. Because authenticated encryption (GCM) is used, ciphertext cannot be silently tampered with: a modified value fails to decrypt.
• At rest (platform secrets): a small set of platform-wide secrets that are not tied to any organization are encrypted with a key derived solely from the master key.

What This Model Does and Does Not Cover

We want to be precise about the threat model, because the words people commonly use in this space ("zero-knowledge," "end-to-end," "split knowledge") mean specific things that do not apply here.

• The hosted encryption model is designed to resist partial compromise — a leaked database dump, or a leaked master key. An attacker who obtains only a database dump (salts, no master key) or only the master key (no salts) cannot decrypt tenant data: both the master key and the per-org salt are required.
• It is not a zero-knowledge or end-to-end encrypted design. Ascent operates the hosted service, and authorized Ascent personnel with production access can decrypt tenant data when both key components are reachable (for example, when a background job syncs email using stored OAuth tokens, when responding to an incident, or when running a migration). We do not treat this capability as a feature — it is a consequence of running the service on your behalf.
• Both inputs are operator-held. The master key and the salts are controlled by whoever operates the deployment. In the hosted service that is Ascent; for self-hosted deployments it is the customer.
• Customers whose compliance posture requires that Ascent itself be cryptographically unable to read their data should use the on-premises deployment, which keeps the master key entirely inside the customer's infrastructure.

Multi-Tenancy Isolation

Every record in Ascent is scoped to an organization. Queries are constrained by organization ID at the middleware layer, and the data model enforces the relationship at the schema level. Cross-tenant access is not possible through the product UI or API. In the client portal, access is further restricted by the contact's type (for example, technical contacts do not see invoices), so even within a single client's data, portal users only see what their role permits.

Audit Trail Integrity

Ascent keeps an organization-scoped audit trail (AuditLog) of security- and data-relevant events. To make that trail usable as compliance evidence (ISO/IEC 27001:2022 A.8.15 Logging, SOC 2 CC7.x), the trail is append-only and tamper-evident:

• Append-only at the database layer. A Postgres trigger rejects every DELETE against AuditLog and every UPDATE that would change audit content. The only UPDATE permitted is the foreign-key-driven nulling of the orgId/userId references when an organization or user is deleted (those columns are ON DELETE SET NULL), so deleting an org or a user remains possible without leaving the trail mutable.
• Hash chain. Each row carries a rowHash = SHA-256(prevHash ‖ canonical content) linked to the previous row in the same organization's stream. Any silent edit or deletion — for example by someone with direct database access who bypasses the application — breaks the chain at a detectable point. The referential orgId/userId columns are deliberately excluded from the hashed content so that the permitted FK nulling above is never mistaken for tampering.
• Verification. An admin-only endpoint (GET /api/audit/verify-integrity) walks an organization's chain and reports whether it is intact, identifying the first broken link (a content edit or a removed/spliced row) when it is not.
• Continuous monitoring. The same verification runs automatically on a schedule, and admins are alerted if it ever fails. The audit monitor also watches for other high-risk patterns — mass deletions, bursts of permission/role changes, and repeated failed sign-ins — and notifies admins when a signal crosses a configurable threshold, with a cooldown to avoid duplicate pages. Admins tune all of this on the Audit Logs admin page.
• External anchoring ("genesis trust"), optional. As defense-in-depth on top of the append-only database protections, operators can enable external anchoring (AUDIT_ANCHOR_SINK=database; disabled by default). A daily job publishes each organization's current chain head to an append-only, write-once store, and the verification above cross-checks those anchors — raising a distinct anchor-mismatch if a previously anchored head has vanished, the signature of a wholesale log rewrite that an internally consistent chain alone can't detect. Anchoring is fully compatible with the retention policy below: a recorded retention purge never raises a false alarm.
• Configurable retention. Each organization sets how long audit rows are kept (default 365 days; set 0 to keep them forever). A daily job moves rows older than that window into a separate cold-storage archive and removes them from the live trail, so the log satisfies storage-limitation expectations (GDPR Art. 5(1)(e)) without losing the evidence. The archived rows keep their hash, so the purge cannot be used to quietly drop history — the verification above still detects any deletion that was not a recorded retention purge. Admins manage the window on the Audit Logs admin page.

The platform audit trail (PlatformAuditLog) is a separate concern and is not part of this organization-level chain. Full details, including the threat model and known limitations, are in docs/AUDIT_COMPLIANCE.md.

Secure Development Lifecycle

A mix of automated pipeline gates and human process controls govern how changes reach production:

• Dependency vulnerability auditing — CI runs a dependency audit on every pipeline run and on a weekly schedule (Mondays). Known vulnerabilities fail the build unless a documented, override-file exception is on record.
• Dependency freshness checks — an outdated-dependency check keeps direct dependencies within a bounded distance of upstream and reports drift on every pipeline run and on the weekly schedule.
• Container scanning — Docker images are scanned with Trivy after build, filtered to CRITICAL and HIGH severities (unfixed vulnerabilities ignored). The scan publishes a findings report and uploads results as a build artifact for review.
• Code review — all changes go through pull request review with mandatory QA sign-off. Security-sensitive areas (auth, encryption, billing, middleware) require additional review.
• Recurring maintenance — beyond the automated gates, we run a recurring, human-reviewed dependency and vulnerability triage that handles coordinated upgrades and transitive pins automation cannot resolve on its own. This is an operational process rather than a build step.

On-Premises Deployment

For customers with data-residency, compliance, or regulatory requirements we cannot meet in the hosted service, Ascent is available as a self-hosted deployment. On-prem customers:

• Run Ascent inside their own infrastructure (Docker / docker-compose).
• Supply their own PostgreSQL instance and encryption master key.
• Control backups, retention, and disaster recovery under their own policies.

Because the master key lives entirely inside the customer's environment, the on-prem model is the only configuration in which Ascent personnel are cryptographically unable to read tenant data.

Contact [email protected] to discuss on-prem licensing and deployment.

Reporting a Security Concern

If you believe you've found a security issue in Ascent, please see Vulnerability Reporting.