Security & privacy at InboxGuards

InboxGuards connects to your Microsoft 365 tenant or Google Workspace with read-only access to supported audit logs, security configuration status, and basic directory information (like which users have MFA enabled, where your Microsoft plan exposes that report). That means we can report provider-recorded sign-ins, rule changes, permission grants, and selected posture signals, but we cannot change settings, send email, delete anything, or act on your behalf in any way.

• ■We never see or store your password — you sign in directly with Microsoft or Google
• ■We cannot read the contents of anyone's email, files, or attachments
• ■We cannot send email as you or modify anything in your account
• ■You can revoke our access at any time from your Microsoft or Google admin console

Authorization is a serious ask, so here is precisely what the consent screen grants — nothing more is requested, and you can verify every item on the consent prompt before approving.

Microsoft 365 (multi-tenant Entra app registration, admin consent, application permissions — all read-only): Office 365 Management APIs “ActivityFeed.Read” (audit log feed; the optional “ActivityFeed.ReadDlp” adds DLP events if you grant it), and Microsoft Graph “AuditLog.Read.All” (MFA coverage report), “Policy.Read.All” (security defaults status), “User.Read.All” (guest-account counts, your active user count for billing, and the list of user email addresses for the daily dark-web check), and “IdentityRiskEvent.Read.All” (Microsoft-flagged risky sign-ins). Microsoft only serves the MFA coverage report and Identity Protection risk detections to tenants licensed for Entra ID P1 or P2; on other plans those two checks are marked unavailable on your dashboard rather than reported. InboxGuards' own sign-in detections do not depend on that license.

Google Workspace (OAuth consent by your super-admin): “admin.reports.audit.readonly” (audit logs) and “admin.directory.user.readonly” (2-Step Verification coverage, your active user count, and the list of user email addresses for the daily dark-web check). Both scopes are Google's read-only variants.

Neither provider grants us any mailbox, file, calendar, or contact scope — we could not read message contents even if we wanted to, and revoking consent in your admin console cuts off access immediately.

Google's API Services User Data Policy requires the narrowest permissions that still deliver the feature. We request exactly two read-only Google scopes, each tied to a specific screen you can see in the product:

“admin.reports.audit.readonly” — the Admin SDK Reports API is the sole source for every Google Workspace detection: sign-ins from new locations, impossible-travel and password-guessing patterns, third-party app grants, Gmail forwarding and mailbox delegation changes, email monitors, domain-wide delegation, admin privilege grants, 2-step verification changes, Drive downloads and sharing changes. These become the alerts in your dashboard feed, your email alerts, and your login history. Google offers no narrower audit scope — without it there is nothing to monitor.

“admin.directory.user.readonly” — used for three features: the security posture card that reports which accounts do not have 2-Step Verification enabled (and the drift alert raised when an account that had it no longer does); your active user count, which pre-fills billing; and the daily dark-web check, which needs the list of every user's primary email address so that dormant mailboxes are checked too, not just accounts that have signed in. We request only three fields per user (primary email, 2-step enrollment status, and whether the account is suspended). Google exposes 2-step enrollment nowhere else, and there is no per-user or narrower directory read scope, so this is the least-privilege option available.

Neither scope allows any write, and neither grants mailbox, file, calendar, or contact access. Your super-admin can revoke both at any time in the Google Admin console, which stops our access immediately.

1. Your administrator grants read-only consent directly on Microsoft's or Google's own consent page — credentials never pass through us. 2. Approximately every 5 minutes, our backend requests new audit records from the provider's API over TLS. 3. Records matching configured signals are written as alerts scoped to your organization; everything else is discarded after evaluation. 4. Once a day, the user email addresses read from your directory are checked against Have I Been Pwned and LeakCheck (see Hosting and subprocessors for exactly what is sent); new findings become alerts. 5. Alerts are delivered to the recipients you configure (email, or your own Slack channel if you connect one). 6. You review alerts in your dashboard; any tenant changes are performed by your administrator or MSP, never by us.

InboxGuards runs on Base44 (a Wix company), which provides application hosting, database storage, and transactional email delivery. Payments are processed by Base44 Payments — card details are entered on the payment page and never touch our systems.

Two narrow external lookups support specific features: alert source IPs are geolocated through an IP-geolocation service (the IP address only), and the dark-web check sends every user email address read from your directory to two breach-data services once a day — to Have I Been Pwned as the plain address (their API accepts nothing else), and to LeakCheck as a one-way SHA-256 hash of the address, plus each email domain your users have for LeakCheck's domain search. Leaked values returned by those services (such as passwords) are never stored or displayed — only the breach name, date, and the types of data exposed. If you connect Slack alerting, alert summaries are sent to the Slack channel you choose. No audit-log contents are shared with any other party.

InboxGuards is owned and operated by Orion CMD LLC of Omaha, Nebraska — built by the team behind DME Computer Services, a managed IT and cybersecurity provider. You can reach a human before connecting anything: call 402-650-8407 or use the contact page.

To report a security vulnerability or a suspected incident involving InboxGuards itself, use the same channels and mark the message as a security report — security reports are prioritized ahead of general support.

We read audit log metadata: who signed in, from where, what settings changed, what rules were created. When something looks suspicious, we store that event as an alert — the event type, the account involved, the source IP, and a snippet of the audit record as evidence.

For the daily security posture check, we also store aggregate counts — how many users have MFA enabled (Entra ID P1/P2 tenants only), guest account counts, and whether security defaults are on — plus a limited sample of the email addresses of users without MFA, kept as a single snapshot that is overwritten each day.

For the daily dark-web check, we store one record per user email address (the address, when it was last checked, and the names of the leaks it has already been reported in) and one per domain (the domain, when it was last swept, and which leaked addresses have already been reported). Findings become alerts that name the leak, its date, and the kinds of data exposed — never the leaked values themselves.

We do not store your email content, file contents, contact lists, or calendar data — we never have access to them in the first place.

InboxGuards uses TLS for supported provider and browser connections. Application access controls scope alerts and organization-linked records to the authorized organization, while operator access is role-restricted. No storage or hosting control eliminates all security risk.

When you cancel, monitoring stops and polling of your audit logs ends. Stored Google and Slack credentials are deleted when the organization is deleted. Organization-linked records are retained in an operator-only archive for nine months for dispute and recovery purposes and then automatically purged; operational IP-geolocation cache and monitor-run records are retained for no more than 90 days.

InboxGuards is a monitoring and alerting service, not a guarantee against compromise. We check supported audit records approximately every 5 minutes and alert when configured signals appear. No monitoring service can catch every attack, provider ingestion can be delayed, and we can only see what the provider records and exposes through its APIs. Our Terms of Service and Disclaimer spell this out in full.