Your Work Account
Connecting a work account isn't only your decision. Here's who else holds a say, and what to ask before you connect.
Your employer may already have an answer to this, even if nobody has told you. This page names who decides, what a security reviewer will ask, and what we cannot yet truthfully claim.
The short version
Your Google Workspace admin controls a work grant, and can withdraw it without asking us first. Beemy has no admin console, no SSO, no SCIM, and no signed data-processing agreement on the self-serve path. Ask your admin before you connect a work address, or connect personal first and add work later.
On this page
Who actually decides
Your employer holds a say too.
A work Gmail grant lives inside your employer's own Google account, under your employer's own rules.
Your employer's Google admin holds this control.
A work Gmail grant sits inside the Google account your employer owns. A Google Workspace administrator on that domain can allow this app, or withdraw it, at any time. Google does not ask Beemy first, and Beemy cannot override that decision.
n/a · Google Workspace admin console, your employer's own tool
Nobody at your company can see or govern your Beemy from inside Beemy.
Beemy has no admin console today. Nobody at your company can see your Beemy account, review what it does, or switch it off from the inside. Only your own Google admin, and only from the Google side, holds that lever.
n/a · no admin-facing route or table exists in backend/src today
The cut runs both ways. Your admin can shut the door from their side. Nobody at your company can open it from ours.
What a reviewer asks
Seven questions a security review always raises, answered plainly.
This is the table to hand your IT or security contact. Each answer carries the code that makes it true.
| Question | Answer |
|---|---|
| What can it read? | Exactly two Gmail scopes: read and send. That is the ceiling Beemy can ever ask for, on any category, at any time. CONNECTOR_REGISTRY · backend/src/connectors/registry.ts, CONNECTOR_REGISTRY (gmail entry, leastPrivilegeScopes) |
| Can it send on day one? | No. Every category starts read-only. When no grant row exists yet for a category, the policy engine treats that absence as read-only. PolicyEngine.getLevel · backend/src/db/schema/autonomyGrants.ts; backend/src/policy/policyEngine.ts, PolicyEngine.getLevel |
| Where does work data sit? | In its own silo, under its own encryption key. A read across silos is not merely blocked by a rule. The database has no key that could decrypt the other silo's rows. siloKeys · backend/src/db/schema/siloKeys.ts, siloKeys (one row per silo and key version, wrappedDek) |
| Can an admin or a colleague reach it? | No. The database enforces at most one silo of each kind per person, with nothing in that table's design for a company or a colleague to reach through. silos_user_kind_unique · backend/src/db/schema/silos.ts, unique("silos_user_kind_unique") |
| Is there a log? | Yes. Every entry is append-only and chained by hash to the one before it, per silo. A database trigger rejects any attempt to edit or delete a row. forbid_audit_mutation · backend/drizzle/0001_invariants.sql, forbid_audit_mutation(); backend/src/db/schema/auditEvents.ts (prevHash/hash) |
| Can it be removed? | Yes. Revoke the grant from your own Google account at any time, or ask Beemy to delete the silo. Deletion destroys the encryption key as well as the rows. DeletionService.eraseSilo · backend/src/deletion/deletionService.ts, DeletionService.eraseSilo |
| Who else touches the data? | A published, named list of every sub-processor, what each one sees, and its own data-processing terms. n/a · see /sub-processors |
Three things we cannot truthfully tell you
The ceiling, stated plainly.
This is the part that makes this page worth reading. We would rather name the ceiling than let you assume past it.
Beemy is not SOC 2 certified. We are readiness-stage: the controls an audit would check are already built, but no auditor has observed them yet.
There is no admin console, no single sign-on, and no SCIM provisioning on a personal account today. Those arrive only as part of an enterprise rollout.
There is no signed data-processing agreement on the self-serve path. What exists in writing today is our terms, our privacy notice, and our sub-processor register.
When the answer is no
Three situations where you shouldn't connect a work address.
Your workplace may block third-party OAuth apps outright. Check with your admin before you try to connect.
Your Google Workspace admin may not have allowed this app for your domain yet. Ask first, rather than finding out mid-connect.
If your inbox holds regulated client data, treat that as a reason to pause and ask first.
Personal-only still gives you triage, drafts, and a quiet inbox for your own life. It costs you the cross-silo view this site sells elsewhere, and your work inbox stays manual.
What to do next
Three moves, depending on where you stand.
Ask your admin.
Send the summary below to your IT or security contact, and ask them to allow the app for your domain.
Connect personal first.
Connect your personal Gmail today. Add a work account later, once your admin has answered.
Send Enterprise to whoever owns the decision.
If your company is evaluating Beemy as a team, point whoever owns that decision at Enterprise & Platform.
Copy the block below into an email to your IT or security contact. It carries every fact from this page, and nothing else.
Beemy — summary for IT or security review What it asks for: two Gmail scopes, read and send. It cannot ask for a scope that deletes, moves, labels or edits a message. What it can do on day one: nothing beyond reading and drafting. Every category starts read-only until a person turns it up. Where the data sits: one silo per person, per account kind, encrypted under its own key. No company-wide column, no admin path from inside Beemy. What is logged: every action, append-only, hash-chained, and rejected by the database if anyone tries to edit or delete an entry. How to remove it: revoke the grant from Google's own admin console at any time, or ask Beemy to delete the silo, which destroys the key. What we do not have yet: SOC 2 certification, an admin console, single sign-on, SCIM provisioning, or a signed data-processing agreement on the self-serve path. Sub-processors: see beemy.co/sub-processors for the full, named list.
Read next
Get your time back.
Beemy is in private beta. Join the waitlist and go from connect to a quiet, triaged inbox before you close your laptop tonight.
You're in the hive. We'll buzz you when it's your turn.
While you waitLast updated