Architecture overview
How the pieces fit, at a level safe to publish. The operational detail is account-gated.
This is the public-safe overview. It is enough to evaluate the design and ask hard questions. The implementation detail a reviewer needs for diligence (isolation internals, key custody, the exact write path) lives in the account-gated Trust and Architecture section, available once you have a Watchtower account.
The three commitments
Almost everything in the system follows from three commitments.
- Findings are durable, scans are ephemeral. A scan is an event that produces observations; findings persist and carry their own lifecycle. This is what makes drift, mute, accept-risk, and historical reasoning structural rather than bolted on.
- Checks are data, not code baked into the engine. Frameworks, checks, and their mappings are rows. The engine executes checks; it does not know about frameworks. Adding one is a data operation.
- One model, two shapes of customer. An MSP managing hundreds of tenants and an enterprise with a handful of legally-isolated entities share one schema. Tenancy and isolation are configuration.
The shape of the system
At a high level: a web application serves the dashboard and API. Scans run as durable background work that reads Microsoft 365 through a vendor adapter, evaluates your checks, and updates findings. Evidence is stored in an object store inside your boundary. Every state change writes to the tamper-evident audit log in the same transaction as the change itself.
Isolation, stated plainly
Multi-tenant isolation is defense in depth: an application permission check, explicit scoped queries, and database-level row security, each independent of the others. The point of the layering is that the last layer still holds if an earlier one is bypassed by a bug. The mechanics are in the gated section; the property is that cross-tenant exposure requires more than one independent failure.
Customer-authored checks are sandboxed
You can write checks the platform has never seen. Code the platform has never seen is code the platform does not trust: customer-authored checks run inside a hardware-isolated sandbox with no network, no host filesystem, and no access to other tenants' data. This is the same posture Watchtower applies to every input it does not author itself.
Deployment
Watchtower runs inside your boundary on commodity infrastructure. The audit trail is built so that you can verify it yourself, and so that it can later be anchored to an independent third party without re-architecture. Where the platform must hold a capability it cannot make cryptographically absent, that boundary is named explicitly in Who we are not.