What we do with the access you give us
A new vendor asking to read your entire identity estate should expect hard questions. These are the answers, before you ask.
The access we ask for
- App-only, and read-first. Scanning uses application permissions, not a user's session. There is no agent to install and no user-facing disruption.
- Consent is per product, scoped and documented. Each product has its own Entra application, declaring only the permissions that product needs. Enabling a further product means a further admin consent — so nothing inherits permissions it has no use for, and revoking one product revokes exactly one.
- Write access is separate. Remediation requires its own explicit consent on top of the read grant. Withdrawing it stops all write paths and leaves your findings and evidence intact.
- Metadata, not content. We read who can reach what. We do not read your documents or your mail.
How the platform is built
- Tenant isolation. Each tenant owns its own connectors, findings, governance records and history. There is no shared tenant data. Templates may seed a tenant, but instantiated records belong to that tenant.
- Tamper-evident audit. The audit trail is hash-chained, so a record that was altered after the fact can be shown to have been altered. Support access through impersonation is recorded in it like anything else.
- An approval gate for providers. Where a managed service provider operates inside your tenant, you can require that their actions are approved first.
- Nothing is overwritten. Controls, desired states, findings, remediations, approvals and waivers preserve their history. Governance decisions overlay the facts; they never rewrite them.
- No fabricated passes. A control that cannot be assessed — no exported logs, an unsupported plane, a missing permission — is reported as "not assessed", with the reason. It is never scored green by default.
This website
Static files, served over HTTPS with HSTS via the host. No cookies, no third-party scripts, no external requests of any kind. The source is public, so any claim on this page can be checked against the code that makes it.
Reporting a vulnerability
Email jeff@jeffops.com. Include enough detail to reproduce the issue. We will acknowledge within two working days and keep you informed until it is resolved. We will not take legal action against anyone acting in good faith to find and report a problem, and we are happy to credit you unless you would rather we did not.
Machine-readable contact details are published at /.well-known/security.txt.