Trust

Security

Last updated August 5, 2026

ForgeWatch is built to be provably safe to connect: read-only access, no credentials held, revocable by you in one step, and only the minimum data needed to do the job.

01Read-only by design

ForgeWatch requests only read-only permissions from your identity provider — never a write or mutate scope. On Microsoft 365 / Entra ID, that is a minimal set of four read permissions (Application.Read.All, Directory.Read.All, AuditLog.Read.All, User.Read.All); on Google Workspace, the equivalent read-only scopes. The permission set is enforced in our code, so ForgeWatch cannot change, delete, or send data in your environment.

02We never hold your credentials

ForgeWatch does not store your users’ passwords, API keys, or secrets, and it cannot log in as your users. Access is granted through your provider’s standard administrator-consent flow and lives in your own directory — not as a credential we hold on your behalf.

03You can revoke access instantly

Because access is consent-based and lives in your environment, you can cut it off at any time — for Microsoft 365, by removing the ForgeWatch enterprise application from your tenant; for Google Workspace, by removing the authorization. Revocation takes effect immediately and requires no action on our side.

04Deliberate data minimization

The only per-customer identifier ForgeWatch needs is your directory (tenant) ID — a non-secret value. Alongside it we hold the read-only scan results (your app inventory and findings), keyed to your organization. We collect nothing about the contents an application can reach — only the fact of the grant and its scope.

05Tenant separation

Each customer’s records are keyed to their own organization and tenant identifier, and the Service is designed to keep one customer’s data separated from another’s. Separation is enforced within a single access-controlled store rather than by scattering per-customer files, which is more auditable and easier to prove.

06Protecting our own keys

ForgeWatch authenticates to provider APIs using its own application identity, whose secret material is kept out of source control and read from a protected environment/secret store — never committed and never placed alongside customer data. We favor certificate-based authentication with scheduled rotation as our production posture.

07Data in transit

All connections between ForgeWatch and provider APIs, and between ForgeWatch and report recipients, use encrypted transport (TLS).

08Responsible disclosure

We welcome reports from security researchers. If you believe you have found a vulnerability, please contact us at forgewatch@outlook.com and allow us a reasonable opportunity to investigate and remediate before any public disclosure.

Questions about this policy? Reach us at forgewatch@outlook.com or through the contact page.