Security & trust

The governance tool that can't become your biggest risk.

Every access-governance tool that can fix access holds a powerful credential over the estate it audits — and becomes the richest target in it. Mortar is architected so that's structurally impossible. This page is the summary; the full answer pack for your vendor security review is one email away.

Request the Security & Trust Pack

Read-only by architecture

The identity that scans your estate cannot write — Mortar's write path won't accept its token at all. This is a structural invariant in the code, not a permission setting that can drift.

Writes are human-first

The default — and only out-of-the-box — write path is the approver's own Databricks identity: your audit log names the person. No usable identity? Mortar hands the approver the exact command instead of acting.

The executor is opt-in and disclosed

Orgs may enable an executor service principal for stewards without API access. That is a write-capable credential Mortar then holds — which is why it's off by default, acts only for an OAuth-verified group manager, stamps the acting human into the audit entry, and has every use counted separately on the trust page.

Metadata only — never your data

Grant structure, group membership, principal identifiers, usage metadata. Never table rows, files, query results, or notebook contents. If a SELECT on your data would be needed to produce it, Mortar doesn't have it.

EU-hosted, encrypted, revocable

Hosted in Frankfurt by default. Credentials encrypted at rest (Fernet, rotatable); every bearer token Mortar issues is stored only as a SHA-256 hash. Deactivate the service principal on your side and Mortar's access is severed instantly.

Verifiable, not just claimed

A tamper-evident, hash-chained audit log with one-click integrity verification — and an in-product trust page that shows which identities Mortar holds and counts every change by how it executed, from your own data.

Practices, in brief

Authentication

Clerk (SOC 2 Type II) — MFA, SSO/SAML; admin-revoked sessions enforced server-side on every request.

Tenant isolation

Org-scoped queries plus PostgreSQL row-level security as a database-enforced backstop — the API connects as a role that cannot bypass RLS.

Secretless option

The scanner can authenticate via OIDC workload-identity federation — no stored secret for your account at all.

Application hardening

Output escaping against stored XSS from estate-controlled names, CSV formula-injection neutralization, SSRF guards on customer-supplied URLs, signature-verified webhooks, a production config validator that refuses to boot misconfigured.

SDLC

~1,800 automated tests in CI against SQLite and Postgres, dependency lockfiles, static security analysis, CVE monitoring, structured logging with per-request IDs.

Data lifecycle

Rolling snapshot retention; org-configurable audit retention; full deletion on termination with written confirmation; your evidence is exportable at any time.

Incident response

security@mortarsec.com — acknowledged within 24 hours; customer breach notification within 72 hours of confirmation (GDPR-aligned).

What we don't have yet — hear it from us first

We're a young vendor. There is no SOC 2 report yet (a Type I engagement is planned once design partnerships are underway) and no external penetration test yet (internal hardening audits are performed and documented; we welcome customer-led testing against a staging tenant). Compensating controls are everything above — plus a zero-trust trial path: a self-hosted app that runs the same read-only scan inside your own workspace, before any credential leaves your tenant. We complete security questionnaires (CAIQ/SIG) in full.

Running a vendor security review?

We'll send the full pack and complete your questionnaire.

security@mortarsec.com