Security

The principle we design to

The safest data is the data you never held. Most of our security posture follows from that one idea: ask for the narrowest permission that does the job, keep as little as possible, and make it trivial to take away.

Least privilege, in practice

It is easy to claim least privilege. Here is what it actually cost us to mean it:

• We do not request access to your Gmail. Not to read it, not to send from it. Where a client needs mail sent on their behalf, we use Microsoft's send permission or authenticated delivery through our own mail infrastructure.
• We do not request access to your whole Google Drive. We use the narrower drive.file permission, which can only reach files our application created or that you explicitly selected. The rest of your Drive is invisible to us — not by policy, but because the permission we hold cannot see it.
• We request read-only where reading is all we need — for example checking calendar availability, or importing contacts.

Those choices remove entire categories of risk rather than promising to manage them.

Who can see what

• Authorisation tokens are never displayed in any administrative interface, to anyone.
• Application credentials are stored encrypted. Engineers who create them can record and replace them, but cannot read them back — retrieval is restricted to the company principal.
• Staff access is limited to the people supporting your account.
• External contractors work in a separate, restricted environment that has no access to client data, billing or business systems.

Auditing

Administrative actions across our platform are written to an activity log recording who did what and when. Logs are designed to record that an action occurred without capturing the contents of your data, and authorisation tokens are explicitly excluded from logs and from diagnostic output.

Revocation

Access is designed to be removable in seconds, without our cooperation:

• Disconnecting through us deletes the stored token and instructs the Provider to revoke it.
• You can revoke us directly in Google Account permissions, Microsoft My Apps, or your Dropbox connected-apps settings — at any time, without asking us.
• Revocation is immediate at the Provider. We cannot override it, and we would not want the ability to.

Provider review

Before any client account is connected, each integration goes through that Provider's own security and privacy review — including verification of our identity, our domain ownership, and a scope-by-scope justification of every permission we request. We treat that review as a floor, not a finish line.

Where we are honest with you

What we do instead: keep the attack surface deliberately small, hold the narrowest permissions that work, encrypt what we store, restrict and log access, and submit each integration to the Provider's own review. As Connect grows and client requirements demand it, formal certification is the natural next step — and we will say so here when it happens, not before.

Reporting a security issue

If you believe you have found a vulnerability, please tell us at info@workaholicdevelopers.com with the subject line SECURITY. Please include enough detail to reproduce it.

We will acknowledge you, keep you updated while we fix it, and credit you if you would like to be credited. We will not pursue legal action against anyone who reports a genuine issue in good faith, gives us reasonable time to respond, and does not access or destroy other people's data in the process.

If something goes wrong

If a security incident affects your connected accounts, we will tell you directly and promptly — what happened, what it touched, what we have done, and what you should do — alongside any notification the law requires. We would rather deliver an uncomfortable message early than a comfortable one late.