WOSP asks for access to every Google Workspace tenant you manage. That is a serious thing to ask for, so here is how that access is scoped, protected, and kept accountable.
Each client tenant is connected through credentials that tenant's own administrator authorizes. Nothing is inherited, assumed, or shared between clients, and the authorization can be withdrawn from the client's Google Admin console at any time, without going through us.
WOSP requests the narrowest permission each individual operation needs, not one blanket grant. A tenant that has authorized only part of the set still works for the areas it approved, and the rest simply stays unavailable rather than failing open.
Tenant credentials are encrypted at rest. Secrets entered in the interface are write-only after saving: they can be replaced, never read back out, and are never rendered to a screen or a log.
Five fixed roles, each with an explicit tenant scope. Technicians do not get platform administration. Client logins reach only their own tenant. Read-only means read-only, enforced on the server rather than by hiding buttons.
WOSP does not read mailbox contents. It manages mail settings, such as forwarding, delegation, and filters, because those are where account compromise hides. The messages themselves are out of scope by design, not by configuration.
Administrative actions are recorded in a platform audit log, separate from Google's own. Automation and API access carry the same role and tenant scoping as a person, and write access through the API and AI integrations is off until an administrator deliberately turns it on.
Reporting a problem
If you believe you have found a vulnerability in WOSP, we want to hear about it before anyone else does. Reach us through Honey House (opens in a new tab) and say that the report is a security issue so it is routed quickly. See also our security.txt.
Please give us a reasonable window to investigate and ship a fix before disclosing publicly. We will not pursue or support legal action against anyone who reports in good faith, tests only against their own instance and data, and avoids privacy violations or service disruption while doing it.
For contractual terms, data handling, and liability limits, see our Terms of Service, Privacy Policy, and Data Processing Addendum.
This page describes how access and data are handled. It is not a compliance certification, and we will say so plainly rather than imply an audit we have not had.
