Security & trust

Mortar audits your access, so it has to be the least risky thing connected to your estate, not the most. This page is the summary; the public Security & trust overview has the full story, and a Security & Trust Pack (data flow, subprocessors, CAIQ) is available for your vendor review.

What Mortar touches

• Access metadata only. Grants, group memberships, ACLs, admin footprint. Never the contents of your tables.
• Read-only scanning. The scanning service principal cannot write to your estate; the write path structurally rejects the read credential. See How changes execute.

How data is protected

• Encryption. Stored credentials are encrypted at rest; tokens are never logged and never returned once stored.
• Tenant isolation. Multi-tenant data is scoped at the application layer and enforced by PostgreSQL row-level security under a database role that cannot bypass it - so even a query bug can't cross tenants. This is independently verifiable, not just asserted.
• Tamper-evident audit. Every governance action is written to a per-tenant hash-chained audit log you can verify.
• Human-first execution. Changes run as the human who approved them, never a god-mode bot.

What we don't have yet

We're honest about the gaps. There is no SOC 2 report yet (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.

Running a vendor security review? Request the Security & Trust Pack and we'll complete your questionnaire.