Check catalog

Watchtower ships 885 built-in checks. Each product page lists every check with its stable slug, severity, what it verifies, why that matters, and - because you should never have to guess what a vendor reads from your tenant - the exact application permissions and data sources its evaluation uses.

How the access column is derived (regenerated from code on every change, enforced in CI - it cannot drift from what the product actually does):

• Checks marked manual attestation are documented review steps; Watchtower reads no tenant data for them.
• Declarative checks name their data source directly in the catalog.
• Custom evaluators are statically analysed for every collected source they read, and those sources resolve to the permissions the collectors require.
• Collectors follow a standing evidence-minimisation rule: they project only the fields a check consumes - never credential material, message content, or personal identifiers that a check does not need.
• If a tenant has not consented to a permission, the affected checks report indeterminate rather than a fabricated verdict.

See also: Permissions we request - the consent surface from the other direction, one row per permission.