Customer boundaries and change flow
How customer grants, customer-bound execution and attempt receipts keep one tenant's work separate from another's.
TenantVigil only reads your Microsoft 365 tenant. It never changes a setting: you apply each fix yourself.
Need a hands-on starting point?
Start with one tenant or talk to the team if you want help evaluating fit, permissions, or rollout approach.
Customer boundaries
Each person sees only the tenant data their current grants allow. A customer context is re-checked when it is opened, so a suspended or ended grant does not keep working.
Stored findings, inventory and history stay with the customer. The partner console projects each customer's data without mixing tenants.
Change flow
A change is staged as an exact plan with safety checks and scoped approval. Approved changes run through a customer-bound broker that checks the current customer, actor and consent before sending.
The broker records what was attempted and what Microsoft returned. An unclear outcome stays unclear and is never resent automatically.
Operator practices
TenantVigil operators maintain incident runbooks and rehearse recovery on local test data. They also rehearse switching between built releases while preserving supported behavior and accepted-write records.
Those are internal operating practices, not a customer-run recovery feature, a residency guarantee or a certification.
What this page does not describe
This page explains the operating model without credentials, private topology, or deployment-specific internals.
It also does not claim per-customer isolation testing on every release, a guaranteed residency, or a universal undo for every change.
Next action
Plan a change and read its receipt, then review desired state and drift.
- Plan a change and read its receipt
- Review desired state and drift