How changes execute

Every access-governance tool that can fix access holds a credential powerful enough to become the biggest risk in the estate it audits. Mortar is architected so that's structurally impossible.

The read path can't write

The service principal that scans your estate is read-only. Mortar's write code structurally accepts only a WriteToken, and the scanner credential can never produce one. So a bug, a misconfiguration, or a compromise of the scanner cannot write to your Databricks - there is no code path from the read credential to a write.

Changes run as the human who approved them

When you approve a membership change or an access request, Mortar executes it in Databricks under your own identity, using a short-lived token you connected (OAuth, or a personal access token). Databricks' own audit log shows you made the change, not a bot. The execution ladder is human-first:

1. Your own token. The change runs as you.
2. An opt-in executor (only if you enable it) acts on behalf of a real Databricks group manager who can't execute directly - and only when their identity is verified. Every such change is attributed to the human it acted for.
3. A manual command. If neither is available, Mortar hands you the exact SCIM/GRANT command to run yourself. It never silently does nothing.

Verified identity

Mortar matches you to your Databricks rights by the identity you proved at consent (via OAuth), not by your login email - which can differ from your Databricks identity for SSO and guest accounts. That keeps recognition and capability aligned, and keeps the audit trail honest.

Why this matters

The result is a governance tool that can see everything and change only what a specific human authorized, as that human. You can verify it from your own data on the Security & trust page in-product, which reports that changes executed "via the read-only scanner" are zero by construction.

See Security & trust for the full trust model.