Approvals & audit
Every write in CrossTenant is deliberate: confirmed before it runs, recorded after, and optionally held for a second approver. None of it is promised in a policy: it is enforced by the product.
Prefer email? Get in touch and we run onboarding with you.
What's included
Confirmation and dry-run
No cross-tenant write executes without an explicit confirmation, and bulk actions render a dry-run preview per customer before anything is applied. The default posture is deliberate: you see what will change, and where, before it does.
Optional second-approver gate
A gate you switch on: elevated writes then park as pending requests instead of executing. Requester and approver are separate people, an approver can only act on requests they could already read, and an unactioned request expires rather than lingering. The gate ships off; enabling it is your explicit act.
Fresh-eyes review
An approver never signs off on a stale snapshot. The review screen fetches a live preview at review time and runs a deterministic drift check, so approval is of what will run now, not of what was queued earlier. An optional AI advisory can annotate a request; it never replaces the deterministic checks.
Approver notifications
Eligible approvers are emailed when a request parks, with reminders before it expires and a per-user opt-out. Notification never widens authority: who can approve and who gets told are separate questions. Approval email requires your SMTP configuration.
Fail-closed gating
If the approval store or its policy cannot be read, gated writes are refused rather than silently ungated. A broken gate looks like a refusal, never like permission: the console does not degrade into executing what it could not check.
Tamper-evident audit
Every write lands in a per-tenant, hash-chained audit log. Each entry binds to the one before it, so an edit, a deletion, or a reordering is detectable at the first affected entry, and a verify endpoint recomputes the chain on demand. Degraded audit health blocks further production writes.
The second-approver gate is optional and ships off, so you decide which actions are worth the friction; approval emails need your SMTP configuration. The audit chain is tamper-evident rather than tamper-proof, and the difference is one specific case: chaining detects any edit, reorder, or deletion inside the log, but someone with write access to the file could remove only its most recent entries and leave a chain that still verifies. Shipping each entry to an append-only store off the machine is the control that closes that, and it is specified and not yet built. Our security statement sets out the whole picture.
Approvals & audit
Make every change answerable
Confirmation before a write runs, a second pair of eyes when you want one, and a tamper-evident record afterwards: change control across your whole book.